What is data drift in a product catalog?

Data drift has two meanings. In machine learning it is the change in the data a model receives once it is in production, and it has its own section further down. In a product catalog, the meaning that matters to a store, it is a value that was published correctly and stops being correct on the public page without anyone deciding it in the tool that published it: the price in the markup is no longer the one on the product page, the description goes back to the supplier's, the FAQs vanish after a theme update. It matters to a store because publication verification tells you whether the value arrived on the day it was published, and drift is what happens to that value from the next day on.

How it works

A product value can have several owners. The price may come from an ERP, the description from a PIM, the title from the store's admin and the JSON-LD block from a theme template or an app. Each one can write to the same field, or to a copy of the same fact somewhere else on the page, and drift appears when one of them changes and the others do not find out. Here are four of the ways it happens.

Another system rewrites the field. A PIM or an ERP that syncs every night writes the value it had stored back over the one that was published afterward. This is field overwrite, and the treacherous part is that the system causing it is doing exactly what it was asked to do.

A theme update. On Shopify, when you update a theme, what you customized in the theme editor is copied to the new version. Code edits, made by you or by an installed app, are only included if they do not conflict with the update; if they do, Shopify warns that they could not be included and you have to reapply them by hand.⁠^{[1]Shopify Help Center. Updating themes} A hand-written structured data block in a template is exactly that kind of edit.

An app that gets deactivated. If an app inserts a value into the page, deactivating or uninstalling it removes the value from the page even though the data is still stored in the app.

Two copies of the same fact. Someone lowers the visible price in the admin, but the markup is generated by another tool that still has the old value. Neither is wrong on its own; the page is.

Drift is costly because search engines compare. Google asks that structured data be a faithful representation of the page's content, that it not mark up content the reader cannot see and that the information be up to date, and it warns that it does not show a rich result for temporary content that is no longer relevant.⁠^{[2]Google Search Central. General structured data guidelines} Google Merchant Center, for its part, can update your products in Shopping ads and free listings using the structured data markup and other product data its crawlers find on your site. Its example: if your latest feed says a product costs $4 and the page says $3, it updates it to $3.⁠^{[3]Google Merchant Center Help. Allow Merchant Center to update product information automatically}

In machine learning, something else

On a data team, data drift names a problem with models, not pages. Google Cloud's documentation explains it this way: after a model is deployed, the data it receives can move away from the data it was trained on, or its distribution can shift a lot over time, and that deviation is called drift. It distinguishes two cases: training-serving skew, when the distribution of the production data moves away from the training distribution, and inference drift, when that distribution changes a lot over time, which can be monitored without having the training data.⁠^{[4]Google Cloud, Gemini Enterprise Agent Platform documentation. Introduction to Model Monitoring}

The difference is in what gets compared. The statistical meaning compares distributions of many values; the catalog meaning compares one specific value on one specific product page with the one that was published. A wrong price on a single product page does not move any distribution, and in a store it is exactly the case that matters. If someone in a meeting talks about "drift" and someone else is thinking of the model, it is worth saying which of the two.

In a store

A store verified four fields on a product page on September 1 and reads them again on the public page on October 1. This is a fictional example: the values and the causes are made up to show how drift gets recorded.

Three readings. The first: without a dated reference value there is no drift, only a value. The second: none of the causes is on the page, they are all in a system that writes to it, which is why looking only at the page tells you what changed but not why. The third: drift gives no warning. The price in the markup could have been wrong since the second night or since the last one, and the table cannot tell; only more frequent reads narrow down when it happened.

How to check it

1. Keep a dated reference value. For each field you care about, what you published and the day you saw it on the public page. It is the first column of any comparison.
2. Read the page again after every change to the store, not only on a calendar: a new theme, a new app or a PIM import are the moments when drift starts.
3. Make changes announce themselves. On Shopify, an app can subscribe to webhook topics such as products/update, and Shopify sends each notification to the configured address with the topic in the X-Shopify-Topic header.⁠^{[5]Shopify, developer documentation (version 2026-10). Webhooks} A notification does not say whether the page changed, but it says when to look again.
4. Before updating the theme, save a copy of the custom code, as Shopify asks, and afterward check whether any edit was left out.⁠^{[1]Shopify Help Center. Updating themes}
5. Review your products in Merchant Center if you sell on Google Shopping: when it detects that the page does not match your data, a product can end up rejected.⁠^{[3]Google Merchant Center Help. Allow Merchant Center to update product information automatically} There are tools that watch for overwrites for you; Clione, for example, flags on the next sync the product page whose field the platform or a PIM has overwritten, with the date and the exact fields, and clears the flag when the values come back.

Related concept: field overwrite

Field overwrite is one cause of drift, not the whole of it. It names a specific mechanism: one system writes a value over another in the same field. Drift names the result, that the page no longer says what was published, and it can arrive without anyone touching the field, through a theme that does not keep a code edit or an app that stops inserting its block. Detecting overwrites covers the cause that leaves a trace in a field; reading the page covers all of them.

To go further, the measurement and verification reading path orders the rest of the terms, and the guide that follows a Shopify value all the way to the published page shows where it can get lost along the way.