Module 02 — MAP and Pricing Intelligence Workflow

Transcript / lesson notes

Module 02 — MAP and Pricing Intelligence Workflow

This workflow has the highest redundancy risk. Franz must learn the difference between price observation, MAP violation lifecycle, seller authorization, alerting, and notification policy.

Price lens checklist

Before calling any pricing tile wrong, identify the price type:

• consumer price;
• business price;
• bulk-tier price;
• buy box or featured offer;
• our own store price;
• MAP price;
• old MAP versus April 1 MAP.

1. Price Intelligence / Lane B Pricing

Purpose: monitors B2B pricing, business offers, bulk-tier signals, featured offer behavior, and our-store pricing context.

Current status: very active. The inspected snapshot tracked 330 ASINs, 310 with business offers, 244 with our B2B offer, 94 own-store buy box wins, and a 38.52 percent own-store buy box win rate. Bulk-tier MAP break derivations were also active.

Main sources: SP-API itemOffers read batches, Lane B pricing snapshots, authorized sellers, MAP breaks, seller names, and pricing history.

Relationship: connects MAP, seller intelligence, buy box, and B2B exceptions.

Escalate when a product looks compliant in one tile but not another, especially if business or bulk-tier pricing is involved.

Ask Fergus: “Am I comparing consumer price, business price, bulk-tier price, featured offer, or our own store price?”

2. All MAP Violations Log

Purpose: chronological all-seller log of marketplace offers detected below MAP.

Current status: central MAP investigation tile. It is the broadest MAP-break lens: all sellers, current and historical, known and unknown.

Main sources: MAP break history, competitive pricing, seller names, authorized seller matching, and pricing snapshots.

Relationship: broader than Authorized Sellers & MAP Compliance; more violation-focused than Price Intelligence.

Escalate when the same seller/product appears multiple times, a violation seems resolved but still active, or the MAP reference date is unclear.

Ask Fergus: “Is this current active MAP, historical lifecycle, or a stale snapshot?”

3. Authorized Sellers & MAP Compliance

Purpose: separates authorized seller coverage and authorized-seller MAP behavior from unauthorized marketplace noise.

Current status: active and important. Some summary data may be older, so timestamp checks matter.

Main sources: authorized seller roster, authorized seller detail, authorized MAP break history, seller names, and pricing snapshots.

Relationship: tells you who is allowed to sell. All MAP Violations tells you who broke price rules. Seller Intel tells you who they may be.

Escalate when seller authorization status contradicts seller behavior, or storefront name and seller ID do not line up.

Ask Fergus: “Is this seller authorized, unauthorized, unknown, or just missing a storefront-name mapping?”

4. Brand Alerts

Purpose: unified alert log for MAP and brand-monitoring events.

Current status: active. Inspected alert data showed 978 current/open alerts. Treat this as a triage and logging layer, not as a command center for live Amazon changes.

Main sources: brand alert log, pricing/MAP derivations, email sender state, and alert policy.

Relationship: downstream of MAP and pricing detection. It summarizes what deserves attention.

Escalate when an alert looks duplicated, stale, noisy, or tied to the wrong MAP basis.

Ask Fergus: “Is this alert current, historical, resolved elsewhere, or duplicated by business-pricing or bulk-tier data?”

5. Alert Settings

Purpose: controls alert recipients, dry-run/live mode, and non-secret email policy settings.

Current status: active UI/API source of truth is Cloudflare R2 for non-secret settings. Provider API keys must not be stored in R2 or returned by the UI. The cron sender still has migration caveats.

Main sources: `/api/map-break-alert-settings`, R2 settings/activity logs, local sender config, and provider credentials kept outside dashboard settings.

Relationship: Brand Alerts is what happened; Alert Settings is who gets told and whether sending is dry-run or live.

Escalate before any recipient change, live/dry-run change, or test email.

Ask Fergus: “Is this a dashboard display issue, a dry-run test, or a live notification policy change?”

6. April 1 MAP Changes

Purpose: focuses specifically on products affected by the April 1 doTERRA MAP change.

Current status: active and recently refreshed. The inspected holdouts report showed 98 affected ASINs in the sheet, 97 checked, 3 ASINs with sellers below new MAP, and 3 total seller violations.

Main sources: April 1 MAP sheet, current competitive pricing, brand revenue estimates, authorized sellers, and price history.

Relationship: specialized MAP-change view. It overlaps with MAP Violations and Price Intelligence, but its lens is: did the market adapt to April 1?

Escalate when April 1 compliance differs from current MAP or another pricing tile.

Ask Fergus: “Which MAP basis is this using: old MAP, April 1 MAP, current pricing, or business-pricing data?”

Supporting MAP/pricing tiles

Loss Sellers identifies sellers pricing at or near loss. Useful for enforcement context.

Level Brands Compliance gives seller-specific compliance history. Useful but narrower than the main MAP tiles.

Seller Intel builds dossiers on suspicious sellers. Use it when you need to understand who a seller might be, not just what price they showed.

Workflow drill

Pick one ASIN with pricing concern. Trace it through:

1. Price Intelligence: what price type was observed?
2. MAP Violations: is there a current or historical MAP break?
3. Authorized Sellers: is the seller authorized?
4. April 1 MAP Changes: is this tied to the April 1 reference change?
5. Brand Alerts: did it become an alert?
6. Alert Settings: would any notification be dry-run or live?

If these disagree, suspect price type, MAP basis, seller-name mapping, timestamp, or alert lifecycle before assuming a bug.

End of module 02.