Can AI shoppers see your Shopify loyalty program?

AI Build Your Business
1

We ran a small comparison across AI buyer assistants using a Shopify test storefront with a public, AI-readable loyalty signal.

The question was simple: if an AI buyer assistant is helping a shopper decide where to buy, can it tell that the store offers loyalty rewards?

The result was mixed.

Some assistants read the public loyalty signal and correctly explained that the store had a loyalty program. Others could not verify the storefront, or missed the signal entirely. One assistant reached the most useful shopping answer: it checked a product page, calculated the expected points, and explained that the purchase would earn points but would not yet unlock the first reward tier.

Two failure modes stood out, and both are bad for merchants. One assistant could not fetch the signal and then filled the gaps with assumptions, describing loyalty benefits the store does not actually offer. Another could not fetch it and concluded the store had no loyalty program at all, treating a failed retrieval as proof of absence.

The takeaway: agentic commerce discovery is already happening, but it is uneven. A loyalty program that is visible to humans in a widget or account page may still be invisible to AI shoppers unless there is a clean public signal for assistants to read.

Full test, including the prompts and the exact endpoints we used:
Can AI shoppers see loyalty?

The reason this matters: when an assistant compares similar stores, readable loyalty can become a reason to recommend one merchant over another. Same product, same price, but one store earns points. If the assistant cannot read that signal, the advantage disappears at the moment of decision.

So, has anyone here checked whether their own store’s rewards show up when you ask an AI about it? I’d be curious whether other loyalty apps get read or ignored, and whether anyone has found a hosting setup that assistants reliably fetch.

2

The failure mode I’d watch most closely is treating retrieval failure as proof of absence. A loyalty widget can be obvious to a human shopper and still be invisible to an AI assistant if the benefit, eligibility and points calculation are only rendered after scripts or login.

I’d test the two surfaces separately: human storefront visibility, then a fixed set of AI prompts using the same product, market and date. Record whether the assistant can identify the program, explain the reward condition correctly, link to the relevant product/page, and preserve the answer through PDP → Add to Cart → purchase.

The observed fact is that assistants disagree. “The loyalty program is not discoverable” is still a hypothesis until you separate a missing signal from a failed fetch or an unsupported assistant path.

3

I’ve checked this on stores I manage, and widget-only rewards details are the easiest for assistants to miss.

What has worked better:

  • Publish a normal, crawlable loyalty page linked in the footer. Put the earn rate, redemption thresholds, exclusions, expiry, and market limits in plain page text, not only inside the widget.
  • Add a short loyalty section to product pages with a real example, such as this $50 item earns 50 points. Make sure it appears in the initial HTML when logged out.
  • Test with 3 fixed prompts using the same product URL. Ask whether a program exists, how many points the item earns, and what reward those points qualify for. Record wrong answers separately from fetch failures.
  • Recheck after theme or app changes. I’ve seen visible text disappear from the page source even though the widget still looked fine in-browser.
4

Interesting test. The key distinction is between “not retrieved” and “not offered”—an assistant should never infer either loyalty benefits or the absence of a program from a failed fetch.

For merchants, I think the safest setup is to make loyalty details available on a stable, public, server-rendered URL (for example /pages/loyalty-rewards) rather than only inside a JavaScript widget or behind login. The page should clearly state:

  • how points are earned
  • the points-per-currency rate
  • reward thresholds and values
  • exclusions/eligibility
  • whether points are applied automatically or redeemed by the customer
  • when points become available

Structured data could help assistants understand the page, but it needs to match the visible terms exactly; there doesn’t seem to be a universal schema specifically for loyalty-program mechanics.

It would also be useful to test across multiple prompts, assistants, locations, and logged-in/logged-out states. A successful result from one assistant may reflect indexing, crawling access, or temporary retrieval behavior—not reliable universal visibility.

I’d be interested in seeing a standard public “loyalty capability” format emerge, ideally from Shopify or loyalty platforms, so assistants can validate the offer rather than guessing.

5

@clickfromai @SaadDigital — your replies shaped what we built.

The benchmark is now a guided test inside Stabile, our Shopify loyalty AI agent app. That
“not retrieved” vs “not offered” distinction is the core of it: a fetch failure and a genuine
absence get different labels, and the one merchants react to hardest is the assistant that
couldn’t fetch and then told the shopper no program exists.

One finding worth passing back. Stabile now verifies its own published signals are live
before scoring an answer, so a merchant sees their side was fine and the failure was the
assistant’s — rather than a vague “check your endpoints are reachable,” which no shop owner can act on. I got this wrong first: my initial version blamed an assistant for an outage
that was on my end.

@SaadDigital, on the capability-format question — Claude read my JSON capabilities doc,
noticed it was hosted by the loyalty provider rather than the merchant’s own domain, and
wanted storefront corroboration before it would treat the offer as real. That’s a direct
argument for your /pages/loyalty-rewards point: the machine-readable signal and the human
page do different jobs.

So which is the missing piece — a merchant-verifiable claim, or simply living on the
merchant’s own domain?

If you want to do this by hand, the “what merchants should do now” section of the blog I
linked earlier covers both halves. If you’d rather not maintain a second page, Stabile
publishes the machine-readable half for you from your program rules, then walks you through
the same check: you run the prompt in the assistant yourself and paste the answer back, so
you stay in the loop at every step.