Version control and change management for product catalogs

The uncomfortable fact this lesson exists to manage: Shopify product data has no version history. No undo, no diff, no "what did this look like in March," no rollback. Whatever changed it - an import, an app, a colleague, an API integration - the previous state is simply gone. Every practice here is a compensation for that fact, and together they amount to giving your catalog what developers take for granted: history, accountability, and reversibility.

Snapshots: manufacturing history

The foundation is scheduled full exports - weekly at minimum, nightly for high-change catalogs - stored somewhere durable and dated (Matrixify's scheduled exports to cloud storage make this a set-once job; even a disciplined manual Friday export beats nothing). This turns "no history" into "history at weekly resolution": any field's past value is findable, any disaster has a restore point, and - quietly valuable - snapshots enable diffing: comparing consecutive exports surfaces every change in the window, including the ones nobody announced (that app that "helpfully" rewrote SEO fields; the integration that nulled a metafield). The pre-change export from Phase 2 remains the per-job habit; snapshots are the safety net under everything else, catching the changes you didn't know were jobs.

Attribution: who changed what, and why

History without attribution is half a system. The layers available: Shopify's admin activity feed (recent staff actions on products - useful, shallow retention, doesn't cover apps/API well); the change log from lesson one (human-maintained, covers intentional operations); and the structural version - routing changes through few, known channels. This is the underrated one: a catalog edited ad-hoc by six people, four apps, and two integrations is unattributable by construction. Mature operations narrow the write paths: bulk changes through the documented pipeline, enrichment through the platform, day-to-day edits by a small set of owners, and every app's write permissions actually reviewed (apps request broad scopes reflexively; an app that only needs to read products shouldn't be able to write them - audit this, it's five minutes in the admin and it shrinks your mystery-change surface permanently).

Release discipline: changes as events, not weather

The change-management layer, scaled to catalog work: classify changes by risk (Phase 2's blast-radius instinct, formalized - content edits vs. structural changes like handles/types/variant restructures vs. destructive ones like deletions) and match process weight to class: low-risk flows freely; structural changes get the staged rollout, a pre-announced window, and a named owner watching downstream surfaces (GSC, feed diagnostics - the Phase 7 propagation map tells you where to watch) for the following days; destructive changes get a snapshot taken at decision time and a second pair of eyes. And the pattern that ties this phase together so far: changes are announced. A one-line heads-up in the team channel - "reworking titles on outerwear this afternoon, expect feed re-reviews" - costs nothing and converts every downstream surprise ("why did Shopping spend dip?") into an expected event. Catalogs at scale change constantly; the discipline isn't slowing that down, it's making change legible - which is exactly what lets the next lesson automate it safely.