Google is making loyalty data part of the AI shopping answer

A loyalty programme used to identify a customer after the click. Google is starting to use that relationship before the click, while the customer is still asking what to buy.

Google has expanded its Loyalty Customer Match documentation to include AI Mode and Gemini, added more countries and moved the service into the Merchant API. The update also makes clear that merchants do not need an active Google Ads account to participate.

That sounds like a product documentation change. It is more useful to read it as a change in the role of loyalty data. Membership can now become part of the context used to personalise an organic shopping experience, including member-specific pricing and benefits.

What Google changed

Search Engine Roundtable identified several changes in Google's Merchant Center guidance on 2 October 2026. The headline additions were AI Mode, Gemini and five more markets. The documentation also now describes Loyalty Customer Match as a Merchant API service, says participation is open to non-advertisers and expands the membership conditions that can qualify a shopper.

Those details matter together. Google is widening the surface, the geographic reach and the route by which a retailer supplies the data.

The service lets a merchant or an authorised loyalty provider associate a customer identifier with a loyalty tier. The Google Merchant API describes a single ManageLoyaltyCustomerMatch method that can insert, update or remove that association. A valid tier other than NON_MEMBER creates or updates the relationship. Sending NON_MEMBER removes it.

Google's API documentation also says the service can be used by non-advertisers and does not require a Google Ads account. That separates loyalty personalisation from media activation. A retailer can supply the membership signal to Merchant Center even if it is not buying Google Ads.

The shopping surface is moving into the answer

Traditional Shopping gives a retailer a product tile. AI Mode and Gemini can assemble a response to a more involved question: which products fit a need, which offer is available and what trade-off should the shopper consider. The format changes the commercial unit from a placement to an explanation.

Member pricing or a loyalty benefit can therefore appear in a different position in the journey. The shopper may see a product recommendation, an offer or a price distinction while the answer is being formed, rather than discovering the benefit on the retailer's own site after selecting a product.

Google's Merchant API guide describes the current use in terms of organic loyalty personalisation on Google Search, including member-specific pricing. Search Engine Roundtable reports that the updated guidance now names AI Mode and Gemini. The sensible interpretation is not that every member benefit will automatically appear in every generated answer. It is that loyalty status is becoming an input available to Google's shopping surfaces beyond a conventional ad campaign.

That puts more weight on the relationship between three records: the product, the offer and the customer tier. If those records disagree, the shopping answer has a harder job. If they agree, the retailer has a way to make a relevant benefit visible earlier.

The hard part is the data plumbing

The API makes the interface cleaner. It does not make the underlying customer data simple.

A retailer needs a defined loyalty programme in Merchant Center, a known tier order and at least one valid identifier for the customer. The Google guide lists email, physical address and phone number as possible identifiers. The user must also have granted the necessary consent for Google to use the loyalty data.

The system is deliberately difficult to inspect from the outside. Google does not expose ordinary GET or LIST operations for loyalty associations. The API is designed around a single management method, which means the retailer can add, update or remove a status without using the endpoint to probe whether a person is recognised or enrolled.

That privacy design creates an operational requirement. The source of truth needs to be maintained before the upload. A customer who moves from a free tier to a paid tier, lapses, joins a points programme or changes their contact details must be represented correctly in the next update. A silent API success does not prove that the customer matched or consented.

The new integration work therefore sits across loyalty, ecommerce, data engineering, product feeds and legal review. It is not a campaign setting owned by a media buyer.

What changes commercially

The immediate opportunity is better visibility for a benefit that already exists. A member price, points offer or completed-order status can become useful earlier in the shopping process. That may improve the relevance of a recommendation, but it also changes what the retailer needs to measure.

This is why the expansion matters beyond personalisation. Loyalty data is becoming part of the merchandising and discovery layer. A retailer that treats it only as a CRM export will miss where the information now operates.

It also creates a different relationship between retail media and loyalty. The retailer can still use Customer Match for advertising where eligible, but the Merchant API service does not depend on an advertising account. Organic shopping personalisation and paid audience activation can be governed as separate uses of the same first-party relationship.

What retailers should do now

Start with the membership definition, not the API call.

List the loyalty states that have a commercial meaning: free member, paid member, points holder, recent purchaser, lapsed member and any tier that changes price, delivery or access. Check which states are eligible under Google's programme rules and which are actually represented in Merchant Center.

Then audit the joins:

• Customer identifiers are collected with the required consent and normalised before matching.
• Merchant Center tiers correspond to the order used by the API.
• Member pricing, points and benefits agree with product and promotion data.
• Updates and removals have an owner and a defined cadence.
• Reporting can separate a member benefit shown in discovery from a paid impression or a completed order.

Finally, test real shopping questions. Do not only ask whether the loyalty record uploaded. Ask whether the right member benefit appears for the right product, in the right market, on the devices where the feature is available. That is the business outcome the integration is meant to support.

Google's expansion gives loyalty programmes a wider distribution surface. It does not make a weak offer more attractive or an inconsistent catalogue more reliable. It gives retailers another reason to treat membership, product data and shopping discovery as connected commercial work.