From product.csv to Consented Conversions

For: teams whose catalog still reaches Google and Amazon as an exported spreadsheet. Premise: the spreadsheet isn't wrong, it's late. Everything below replaces the lateness, not the catalog. Companions: The Trust Framework for why a record matters; AI Trust Framework Requirements for the REST layer; Global compliance harness checklist for the wider release gate. Download: CONSENTED-DATA-LAYER-TEST-HARNESS.md, the eighteen-test harness · diagrams as image or PDF (challenge, solution, benefit) and image or PDF (before and after).

The gap, in one sentence

A product.csv export describes the catalog as it was when someone ran the export. Google and Amazon now ask about each event as it happens, and they drop the events that can't show consent.

A nightly file can't say what a shopper agreed to at 14:32, because at 14:32 the file didn't exist.

What changed in the last year

Date	Platform	Change	What it does to a CSV data layer
2026-08-18	Google	Content API for Shopping sunset; HTTP 410 errors from Sept 1, full shutdown early 2027	Programmatic feeds must move to the Merchant API
2026-06-30	Amazon	Consent signal required on the Ad Tag, Conversions API and Events API for UK and EEA traffic; some sources add Switzerland	Conversions with no signal aren't used
2026-06-15	Google	`ad_storage` alone gates conversions and remarketing (reported, not yet confirmed by Google)	No fallback when consent is missing
2026-04-14	Google	Product data spec update: `video_link`, handling cutoff, minimum order value; 500×500 image minimum from 2027-01-31	New columns a static export doesn't carry
2025-07-31	Amazon	XML and flat-file listings feeds retired	Listings must go out as `JSON_LISTINGS_FEED`

None of these is a ban on spreadsheets. Each one moves a decision from the file to the moment of the event.

Challenge, solution, benefit

Open the SVG full size (1600 × 744) · Download the image · Download the PDF.

Read each row left to right. The consent row is the goal. The other three make sure the data that reaches it is current, joined by key and owned by one system.

Source. The export is replaced by webhooks. A price changed in Shopify reaches the PIM when it changes, not at the next import.
Feeds. The retired channels are replaced by the APIs that replaced them. Nothing about the catalog changes; only the door it leaves through.
Joins. Rows matched by position are replaced by one key, shopify_variant_id + market. ERP cost and stock arrive keyed by SKU and variant.
Consent. The consent state travels with the event instead of being assumed. An event without it is not sent.

Before and after

Open the SVG full size (1600 × 848) · Download the image · Download the PDF.

The catalog and consent take separate paths, and that separation is the design, not a gap.

The PIM owns the product record. It writes only its own tables and never reads CRM data at runtime. It runs on its own if the CRM is absent.
The CRM owns the person. Consent, identity and conversions live there, and only there.
They meet offline, by key. shopify_variant_id + market reconciles a conversion to the product it was for, without either system reading the other's tables.

A PIM that never holds personal data can't leak it, and it doesn't have to be in scope for every privacy request.

Readiness checklist

Each item has a test with the same ID in the harness below.

Feeds

FD-01 No Content API calls anywhere in the codebase
FD-02 Any Google feed push uses Merchant API v1, not an alpha or beta version
FD-03 Amazon listings go out only as JSON_LISTINGS_FEED or through the Listings Items API
FD-04 Every product image is at least 500×500 before 2027-01-31
FD-05 video_link, handling cutoff and minimum order value are mapped, or left out on purpose
FD-06 native_commerce and merchant_item_id sit in a supplemental source, if checkout inside Google AI Mode is wanted

Identifiers and joins

ID-01 Every product has a GTIN, or a brand plus MPN
ID-02 Every catalog row carries shopify_variant_id + market
ID-03 ERP fields arrive keyed by SKU and variant, never by CSV row order
ID-04 product.csv is an import or export only; the PIM is the record of truth

Consent

CN-01 The banner sets ad_storage, ad_user_data, ad_personalization and analytics_storage before any Google tag fires
CN-02 UK, EEA and Swiss visitors send amzn_user_data and amzn_ad_storage, or a TCF string with vendor 793
CN-03 Server-side conversions carry the consent state and a dedupe ID
CN-04 No ad cookie is set before consent

PIM and CRM boundary

BD-01 The PIM writes only the tables its boundary contract names
BD-02 The PIM never reads CRM tables at runtime
BD-03 The three GDPR webhooks are handled
BD-04 No customer personal data is stored in the PIM

The test harness

Download the consented data layer test harness (Markdown) →

Eighteen tests, one per checklist item. Seven are shell commands you can run from the repository root today. One runs in the PIM's own test page. The other ten are browser or dashboard checks with a stated pass condition.

Run it in order. The feed and boundary checks are fast and catch code problems. The consent checks need a UK or EEA exit and a clean browser, and they catch configuration problems that no code search will find.

A test that hasn't run is not a pass. The harness ends with a results log. An empty row is an open item, not a green one.