Executive summary
- What changed: As of GraphQL Admin API version 2026-10, segment query functions use MATCHES and NOT MATCHES instead of equality against true or false, and function parameters get their own operators.
- Why it matters: The new form is strictly more expressive, supporting comparisons that were previously impossible, but it is a syntax change you have to make deliberately.
- Who should care: Teams that build or generate customer segments programmatically, and anyone maintaining a library of saved segment definitions.
What changed
Three things, two of them mechanical and one of them genuinely useful.
First, function syntax. A query that read shopify_email.opened() = true is now written shopify_email.opened MATCHES (). The inverse uses NOT MATCHES. The boolean comparison is gone in favour of an operator that describes what the function actually does, which is test for a match.
Second, parameters now carry their own operators inside the match expression. The old form products_purchased(quantity: 5) = true becomes products_purchased MATCHES (quantity = 5). That looks cosmetic until you notice what it unlocks: products_purchased MATCHES (quantity != 5) and products_purchased MATCHES (quantity > 5) are both expressible now and were not before. Parameters were exact-match only, so range or exclusion logic had to be approximated with multiple segments.
Third, four named dates are deprecated: 12_months_ago, 90_days_ago, 30_days_ago and 7_days_ago. Use the existing date offsets instead. The mapping is direct, with 12_months_ago becoming the offset -12m, and the offset form was already available, so this consolidates two ways of saying the same thing into one.
Why it matters
For most Plus merchants the parameter operators are the headline. Segment definitions that previously needed workarounds collapse into one query. A segment for customers who bought more than five units of a product, or who bought any quantity other than a specific one, was awkward to express and often ended up as a hardcoded list refreshed by a scheduled job. That machinery can go away.
The caveat is that this is a breaking change, and breaking changes to segments have a long blast radius. Segments feed email audiences, discount eligibility, Flow conditions and personalization logic. A segment that silently stops matching throws no error a developer will see. It sends a campaign to four hundred people instead of forty thousand, and surfaces in revenue reporting a week later.
So treat this as an audit task rather than a find and replace. Inventory where segment queries are constructed, including the places nobody thinks of: an internal tool, a reporting script, a partner integration. Compare matched counts before and after rather than trusting that the rewrite was faithful. Segment accuracy underpins most of what makes enterprise personalization on Shopify Plus work, so it is worth the care.
Role-specific impact
- Marketers: No action in the admin, but validate audience sizes after your team upgrades API versions. A segment whose count moves sharply is the signal to investigate.
- Developers: Update generated and hardcoded segment queries to MATCHES form, move parameters inside the match expression, and replace deprecated named dates with offsets before adopting 2026-10.
- Store admins: Review saved segments that drive operational workflows and note which ones a marketing or development change could affect.
Use-case example
Real-world scenario
An apparel merchant maintained a loyalty tier segment defined as customers who had purchased a specific quantity of a core product, with three near-duplicate segments stitched together because parameters only supported exact equality. Under the new syntax that becomes a single query using a greater-than comparison on quantity. Three segments become one, the nightly reconciliation job that kept them aligned becomes unnecessary, and the audience is correct continuously rather than as of last night's run.
Implementation checklist
- Identify every place segment queries are written or generated, including scripts and internal tools.
- Rewrite function calls from equality against true or false to MATCHES and NOT MATCHES form.
- Move function parameters inside the match expression with explicit operators.
- Replace the four deprecated named dates with their equivalent date offsets.
- Look for logic that worked around exact-match parameters and simplify it with the new comparisons.
- Capture matched customer counts for critical segments before upgrading, then compare after.
- Upgrade to Admin API version 2026-10 only once the rewrites are verified in a development store.
- Tell marketing when the change lands so an audience shift is not mistaken for a performance problem.
FAQ
Q: Do we have to change anything before upgrading to 2026-10?
A: Yes, if you build segment queries in code. The new function syntax applies from that version, so rewrite and verify queries before you move.
Q: Are the deprecated named dates gone immediately?
A: They are deprecated rather than removed, but treat them as scheduled for removal. The date offset equivalents are already available and map directly.
Resources
Segment query language reference
Need guidance? Talk to Makro.