Price Sync

Quick Definition

Automated alignment of price fields across PDP, feeds, and ads.

More Details

Prevents disapproved ads and feed errors due to price mismatch.

Keep PDP, Feeds, and Marketplaces in Parity

If your product page ≠ feed ≠ marketplace, AI and shopping surfaces won’t trust you. “Price Sync” keeps price and availability identical everywhere, in near-real time.

⚡️TL;DR

Why it matters: LLMs/feeds drop sources that disagree with themselves. Parity is table stakes for eligibility and trust. See LLM Readiness.
How to do it: Map price/availability at the field level → wire a Sync Engine (webhooks + feed diffs) → enforce with alerts and a Parity Score.
Ship list: Structured PDP Fields, Product Schema (offers/price/availability), JSON-LD, and a monitored /offers pipeline.
Win condition: Parity Score ≥ 0.99 across PDP ↔ feed ↔ marketplaces. If not, fix the source and re-sync.

1) What “Price Sync” means (exactly)

Price Sync is the discipline and automation that keeps a product’s price, availability, and (optionally) promo price consistent across:

PDP (your product detail page)
Feeds (Google Merchant Center, social/affiliate feeds)
Marketplaces (Google Shopping, Amazon, Walmart, etc.)

It’s one slice of overall parity (price, availability, variant set). See Parity and Variant Parity.

2) Why it matters to AI & shopping surfaces

Eligibility: Inconsistent price/stock causes disapprovals and suppressed impressions in shopping feeds.
Trust: LLMs/answer cards skip or summarize without citing sources that contradict themselves. See It Was SEO the Whole Time.
UX & revenue: Nothing kills conversion like “$129 here, $139 there.”

Back it with machine-readable fields: Product Schema with offers.price, priceCurrency, availability, priceValidUntil (if used) to qualify for a Product Rich Result.

3) Symptoms you have a Price Sync problem

PDP shows $129, Merchant Center shows $134, marketplace shows $137.
“In stock” on PDP; Out of stock in feed.
Sale price on PDP; regular price in feed.
Frequent feed disapprovals or “Conflicting price” errors.
Support tickets: “Cart price different from ad.”

4) Implementation Blueprint (copy this)

Source of truth: PIM/ERP (or pricing service)
Targets: PDP → Feeds → Marketplaces

Step 1 — Map the fields

PDP HTML: render canonical price and availability in the UI and in JSON-LD Product/Offer.
Feeds: include price, sale_price, sale_price_effective_date, availability, link, gtin/mpn/sku.
Marketplaces: match their spec; keep one canonical rounding rule.

Step 2 — Wire a Sync Engine

Triggers: webhooks from PIM/ERP on price or stock change; scheduled diff jobs to catch misses.
Transport: API → PDP cache bust → regenerate feeds → push to marketplaces.
Order: update PDP first, then feeds, then marketplaces (so everything converges to PDP).
Safeguards: block publishes if any target lags > X minutes or parity would drop < threshold.

Step 3 — Validate & monitor

Compute a Parity Score every run:
score = (price_match + availability_match + variant_match) ÷ 3
Ship when ≥ 0.99; alert when < 1.00.
Log changes; keep diff history per SKU.
Alert channels: Slack/email with direct links to the SKU on PDP + feed + marketplace.

Step 4 — Prove it to machines

Serve valid Product Schema on the PDP, pass Schema Validation, and keep Field Consistency with internal links/crumbs.

5) Launch Checklist (copy/paste)

✅ PDP renders one canonical price (incl. currency) and availability.
✅ PDP exposes Product → Offer in JSON-LD.
✅ Feeds/marketplaces receive the same values (no hidden taxes/fees mismatches).
✅ Sync Engine configured (webhook triggers + scheduled diffs). See Sync Engine.
✅ Guardrails: MAP rules, rounding, timezone/currency normalization, promo windows.
✅ Monitoring: Parity Score, “conflicting price” errors, Feed Drift alerts. See Feed Drift.
✅ Breadcrumbs & entities resolved (brand/model) for citation trust. See Breadcrumb Schema.

6) Governance & Edge Cases

MAP / contract pricing: enforce minimum price; annotate reasons for deltas (and exclude from ads if required).
Currency & regions: normalize at render time; store canonical base currency; set priceCurrency.
Promo price: always send both price and sale_price and a valid window.
Bundles / kits: precompute effective unit price to avoid “conflicting price” flags.
Tax/shipping: keep policy consistent in PDP vs. feeds (don’t embed tax in one and not the other).
Time zones: use a single zone for pricing windows; do not let cron drift create temporary mismatches.

7) KPIs to watch

Parity Score (site-wide, daily): target ≥ 0.995.
Conflicting-price disapprovals: 0 per 1,000 SKUs/day.
Time-to-convergence: minutes from change → full parity across targets.
Eligible impressions / CTR on shopping placements post-parity.
Refunds / CS tickets from price mismatch (downward trend).

8) FAQ

Is Price Sync the same as “price matching” competitors?
No. This is internal parity—your properties matching themselves.

Do I need a separate microservice?
If you have >5k SKUs or >2 targets, yes. Put it behind a Sync Engine with webhooks + diffs and an operator UI.

Will schema alone fix it?
No. Schema makes it readable; parity makes it trustworthy.

Where Automation Fills the Gaps

Quarterly PDP Refresh Cadence