What is field overwrite in an online store?

This is not about overwriting a file, or about one CSS rule in the theme overriding another. It is about data: a product field that somebody wrote and another system wrote over, without anyone deciding it should be that way. The symptom is familiar in any store with more than one tool connected: you fix a description in the afternoon and the next morning the old one is back, or the title your agency prepared disappears after you install a new app. It matters for a store because lost work gives no warning: the product page is still published, looks fine, and says something else.

How it works

The last one to write wins. An integration that sends the full value of a field and saves it as is, without looking at what was there, cannot know whether someone changed it first. If two systems write the same field that way, the outcome does not depend on which one is right, but on which one synced later. The problem is old enough that the HTTP standard gives it a name: the If-Match header is mostly used on requests that change data to prevent accidental overwrites when several agents act on the same resource at once, that is, to prevent the "lost update" problem.⁠^{[1]IETF. RFC 9110, HTTP Semantics, 13.1.1 If-Match} The server applies the change only if the resource is still the one the client read; if someone changed it in between, it refuses.⁠^{[1]IETF. RFC 9110, HTTP Semantics, 13.1.1 If-Match}

Platforms solve it halfway, and optionally. In Shopify, metafields are written with the metafieldsSet mutation, which according to its documentation sets the value whether or not the metafield existed before. Since API version 2024-07 it supports a prior check: if the writer sends the compareDigest field, the mutation saves the value only if the stored one matches the one that was read; if it does not match, it returns an error instead of overwriting.⁠^{[2]Shopify.dev. metafieldsSet mutation (GraphQL Admin API)} It is the right protection, but it is optional: an app that does not send that field writes over it without asking.

Sometimes the last one wins by design. Not every overwrite is an error. In Google Merchant Center, an attribute rule called "Take latest" takes, for price and availability only, the most recently updated value among two or more data sources and uses it to fill the attribute.⁠^{[3]Google Merchant Center Help. Set up your attribute rules} It is a declared overwrite: someone decided that on those two fields the freshest data rules, wherever it comes from. What turns an overwrite into a problem is that nobody decided it.

Where it usually happens. There are three typical situations in a store:

• A source system that exports everything. A PIM or an ERP that sends the full product on every sync puts back its own value on any field that was edited in the store.
• Two apps on the same field. Two SEO tools, or an SEO tool and a translation tool, that write the same title or description overwrite each other in whatever order they run.
• The platform or the theme. A bulk CSV import, a template that fills an empty field or a theme change that rewrites default values write over what was published.

The date is not enough to detect it. The quick way to get suspicious is to compare the product's modified date with your last write. It works as an alarm, but not as proof: in Shopify, a product's updatedAt is the date of its last modification and can change for other reasons; for example, an order for a product with inventory tracking counts as an update.⁠^{[4]Shopify.dev. Product object (GraphQL Admin API)} To know whether a field was overwritten, you have to compare the field's value.

In a store

An ordinary night at a mountain gear store on Shopify, with a PIM that exports every night and an SEO app. It is a fictional example: the store, the times and the texts are invented to show how an overwrite chains together.

The fourth row is the overwrite: nobody decided to go back to the manufacturer's text, but the PIM rules that field and nobody told the content team. The fifth is the one that survives, and only because that field is not in the export. The fix is not technical but a matter of who owns what: either the description is edited in the PIM, or the PIM stops exporting it. When the platform or a PIM overwrites a field Clione published, Clione flags it on the next sync with the date and the exact fields, and republishing it is your decision.

How to check it

1. List everything that writes to your catalog: the platform, the PIM, the ERP, every app with write permission, CSV imports and the people on the team.
2. Write the field map: for each field, a single system in charge and the rest only receiving. A field with two systems writing is an overwrite waiting to happen.
3. Test one field. Change a value by hand on a test product, wait for each system's next sync and see whether it is still there.
4. Compare values, not dates. Save what you published and compare it with what is in the store; the modified date only says that something changed.⁠^{[4]Shopify.dev. Product object (GraphQL Admin API)}
5. Ask each integration whether it writes with a prior check, with If-Match on an HTTP API or with compareDigest on Shopify metafields, or whether it writes over without looking.⁠^{[1]IETF. RFC 9110, HTTP Semantics, 13.1.1 If-Match}⁠^{[2]Shopify.dev. metafieldsSet mutation (GraphQL Admin API)}

Related concept: data drift

Data drift is the difference that builds up over time between two places that should say the same thing, like the product feed and the published product page. Overwrite is a specific event: one write that erases another. Often one leads to the other, because every overwrite nobody detects leaves two versions of one value, the one you meant to publish and the one that got published. Drift is found by comparing; overwrite is prevented by deciding who writes each field, and detected by comparing the value right after each sync.

To keep going, the platform publishing reading path orders the rest of the terms, and the entry on the PIM explains how a catalog is divided among systems.