# What Is Data Drift in a Product Catalog?

> What data drift is in an online store: a correctly published value that later changes on the page, its usual causes and how to catch it in time.

URL: https://clione.ai/glossary/data-drift/
Lang: en

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](/glossary/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](/glossary/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](/glossary/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](/glossary/pim/), the title from the store's admin and the [JSON-LD](/glossary/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](/glossary/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.[^shopify-theme-update] A hand-written [structured data](/glossary/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](/glossary/rich-results/) for temporary content that is no longer relevant.[^google-sd-policies] [Google Merchant Center](/glossary/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](/glossary/web-crawler/) 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.[^mc-auto-updates]

## 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.[^vertex-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.

| Field (fictional example)                       | Verified on September 1             | Read on the page on October 1  | Cause found                                                                   |
| ----------------------------------------------- | ----------------------------------- | ------------------------------ | ----------------------------------------------------------------------------- |
| Price in the JSON-LD                            | 79.00                               | 89.00                          | The ERP sent the previous rate again in its nightly sync                      |
| Description                                     | Reviewed text, with sizes and usage | Supplier's text                | The PIM rewrote the field in its weekly import                                |
| FAQs on the product page                        | Five questions                      | None                           | After the theme update, the code edit that inserted them was not carried over |
| [Meta description](/glossary/meta-description/) | 20-liter backpack with sleeve…      | 20-liter backpack with sleeve… | No drift                                                                      |

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.


**Merchant Center's automatic updates do not fix your page's drift.** They update your products in Shopping with what their crawlers find on your site, structured data markup included, so if the value that drifted is the one in the markup, that is the one they can read. And with products whose price or availability changes more than once a day they may not work: Google warns that the product may be rejected instead of updated.[^mc-auto-updates]


## 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](/glossary/webhook/) topics such as `products/update`, and Shopify sends each notification to the configured address with the topic in the `X-Shopify-Topic` header.[^shopify-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.[^shopify-theme-update]
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.[^mc-auto-updates] 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](/glossary/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](/learn/measurement-and-verification/) orders the rest of the terms, and the guide that follows [a Shopify value all the way to the published page](/guides/metafield-to-published-page/) shows where it can get lost along the way.