Heads up: Amazon Data Kiosk Analytics Economics will remove FNSKU from ProductIdentifierGranularity on 2025-10-30 across all marketplaces.
TLDR
- Stop using FNSKU granularity. Switch to ASIN or Seller SKU.
- Update request payloads, filters, joins, and warehouse models.
- Build a mapping table linking fnsku, asin, sku, marketplace_id with validity windows.
- Ship behind a feature flag. Canary 10–25 percent. Compare KPIs, and keep a rollback ready.
What changes
- Any request that sets productIdentifierGranularity = FNSKU will fail, or return empty data, after the cutoff.
- Replace with ASIN or SKU, and update downstream logic accordingly.
Why this matters
- Dashboards that slice by FNSKU may go blank or undercount.
- ETL joins on FNSKU can break or cause silent data drift.
- Historical analyses keyed by FNSKU need enrichment to preserve continuity.
Quick identifier refresher
- FNSKU is fulfillment focused, and it can change over time.
- ASIN is catalog focused and stable per marketplace entry.
- Seller SKU is merchant defined and often stable inside your systems.
Migration checklist
1) Audit: search code, configs, and BI for FNSKU and productIdentifierGranularity. 2) Requests: switch payload builder to ASIN or SKU based on use case. 3) Models: add asin and sku to facts and dims; update joins and filters. 4) Mapping: create a dimidentifiermap with columns fnsku, asin, sku, marketplaceid, validfrom, validto, iscurrent; backfill history. 5) Canary: enable via feature flag for a cohort; compare units, revenue, and key rates daily. 6) Cutover: move to 100 percent if parity holds; block FNSKU usage post date. 7) Rollback: keep old path available behind a flag for at least two weeks.
Common pitfalls
- Validation errors or empty responses due to leftover FNSKU payloads.
- Broken joins if marketplace_id is not included in key matching.
- Silent undercounting if errors are swallowed or unmatched rows drop during joins.
Choosing ASIN vs SKU
- Catalog level analysis and cross seller comparisons: choose ASIN.
- Internal catalog, ERP reconciliation, and merchant centric reporting: choose SKU.
- If unsure, store both asin and sku in the warehouse, and let BI select per use case.
Data quality guardrails
- Block jobs that attempt FNSKU after 2025-10-30.
- Monitor row count and metric parity between old and new keys during canary.
- Track join coverage and null rates for asin and sku.
- Alert on marketplace-scoped collisions or mapping gaps.
Backfilling without rewriting history
- Keep original fnsku columns for lineage.
- Enrich historical facts with asin and sku using mapping valid at fact_date and marketplace.
- Use deterministic tie breaking rules when multiple mappings exist.
Observability
- Daily deltas for units, ordered revenue, and key rates by marketplace and top products.
- Coverage and latency checks for new joins.
Rollback plan
- Feature flag to revert to old path.
- Preserve FNSKU based marts for short term comparison; mark deprecated.
- Keep mapping maintained for audits and future backfills.
Suggested timeline
- Week 1: Audit usage, build mapping, add columns, prep flags.
- Week 2: Stage dual path, validate extracts and joins, start backfills.
- Week 3: Canary 10–25 percent; monitor KPI parity; fix gaps.
- Week 4: Scale to 50–100 percent; finalize docs and monitoring.
- Before 2025-10-30: Complete cutover; enforce no FNSKU in payloads.
Final checklist
- Zero FNSKU requests after cutover date.
- KPI parity within agreed thresholds.
- Mapping coverage greater than 99 percent for active catalog; exceptions documented.
- Dashboards and runbooks updated; on call aware; rollback documented.
