Most MAP programs fail in the same place. Not at collection, which is the part everyone worries about, but at the alert queue. A brand team turns on monitoring, receives four hundred violations in the first week, spends a month discovering that most of them are not violations, and quietly stops opening the report.
The detection was working. The rules were not.
What minimum advertised price actually is
Minimum advertised price is a policy under which a brand sets the lowest price at which a reseller may advertise its product. It governs the displayed price, not the transaction.
That distinction is the whole subject. A reseller can typically sell below MAP without breaching the policy, as long as the lower price is not advertised. This is why so many storefronts show a compliant price alongside “add to cart to see price”, “see price in cart”, or a coupon applied at checkout. Those patterns exist precisely because the sale price and the advertised price are different things.
MAP is also distinct from two neighbouring ideas that get conflated with it:
- Minimum resale price sets what a product may be sold for, which is a different arrangement with different legal treatment in most jurisdictions.
- Unauthorised selling is about who is selling, not at what price. A seller can be perfectly MAP-compliant and still have no right to be selling your product at all.
The second one matters because the two problems come from the same dataset and are usually run by the same team, but they need different rules and different escalation paths. The seller-identity side is covered in monitoring unauthorised sellers and MAP violations. This piece is about detecting the price violations themselves.
MAP policy design and enforcement carry real legal considerations that vary by jurisdiction. This article is about the detection mechanics, not legal advice on your policy.
What a detector must actually compare
The naive rule is observed_price < map_price. It generates the four hundred alerts.
A workable detector compares the advertised price against MAP, and that requires deciding what counts as advertised on each surface. At minimum, capture and evaluate separately:
| Field | Why it matters |
|---|---|
| Displayed list price | The headline number, and often not the advertised price |
| Strike-through or reference price | Sometimes the real advertised price, sometimes a fiction |
| Price after an automatically applied coupon | Advertised if the discount is shown on the page |
| Price revealed only in cart | Usually not advertised, and the reason the pattern exists |
| Bundle or multibuy unit price | A different product for MAP purposes in most policies |
| Delivery cost | Rarely part of MAP, frequently part of the complaint |
| Currency and tax display | A tax-exclusive display against a tax-inclusive MAP is a false positive factory |
The policy has to say which of these are in scope before the detector is written. Teams that skip that step end up encoding an implicit policy in a script, which is a bad place for policy to live.
Where the false positives come from
Five patterns account for most of the noise. Each has a rule that removes it.
Bundles and kits. A retailer sells your product with an accessory at a combined price. Divide it out and it looks like a violation. The rule is to match on exact product identity and exclude multi-item listings rather than trying to apportion value.
Legitimate promotions. Your own authorised promotional period allows a lower advertised price. The detector needs the promotional calendar as an input, and every MAP program should carry one with effective dates.
Currency and tax. A market that displays tax-exclusive prices will look non-compliant against a tax-inclusive MAP, every single time. Normalise both sides to the same basis per market before comparing.
Marketplace “from” prices. A listing showing the lowest price across several sellers, including used or refurbished condition. Compare against new-condition offers from the seller you actually mean.
Stale MAP values. The most embarrassing one. The policy changed and the reference table did not, so the detector is enforcing last quarter’s price. Version the MAP list with effective dates and record which version produced each alert.
Thresholds, persistence and severity
Even with clean rules, a binary comparison produces a queue nobody can work. Three refinements make it actionable.
A tolerance band. Small differences from rounding, currency conversion or display formatting are not violations. Define the band explicitly rather than letting each analyst decide.
Persistence. A price observed once may be a transient error on the retailer’s side. Requiring the same violation across two or more consecutive observations removes a surprising share of the queue and costs you only the detection delay.
Severity by depth and reach. A violation 2% below MAP on a low-traffic listing is not the same case as one 25% below on a major marketplace. Rank by depth of the breach and the visibility of the surface, so the team works the cases that actually damage the channel.
The output should be a small ranked queue, not a spreadsheet of everything that failed a comparison.
Evidence is the deliverable
MAP enforcement ends in a conversation with a reseller, so the detector’s real output is not an alert. It is a record that stands up when the reseller says the price was never that low.
Every confirmed violation should carry a full-page screenshot showing the price in context, the URL, a UTC timestamp, the seller identity as displayed, the observed price and the MAP version it was compared against, the market and the exit location the observation came from, and the persistence history showing how long it ran.
Retain it in a form you can hand over. An alert that says “violation detected” with no reproducible evidence produces a dispute you will lose, and it damages the relationship you were trying to protect.
The collection layer
Two properties of the collection matter more than raw throughput.
Market accuracy. Pricing, currency, tax display and seller mix vary by market. A US vantage point checking a European storefront is not observing what a European shopper advertises to. Each market’s monitoring has to come from that market, which is what residential proxies with country targeting provide. With the Shifter gateway, targeting goes in the credentials against p.shifter.io:443:
customer-USERNAME-country-fr-sid-map-fr-22-ttl-600:PASSWORDHolding one session across a seller’s listings keeps a snapshot internally consistent, rather than mixing observations taken from different vantage points into one comparison.
Neutrality. Retail sites personalise. A vantage point that has been observed checking the same listings repeatedly can start receiving different treatment, and that biases exactly the measurement you are trying to defend. Modest, spread-out request rates with real backoff, as in rate limiting and request throttling, keep the observation ordinary.
Track collection success rate per retailer alongside the violation counts. A drop in violations that coincides with a drop in your own success rate is a collection story, and reporting it as improved compliance would be wrong.
FAQ
Is selling below MAP a violation?
Usually not by itself. MAP governs advertising, which is why cart-reveal and coupon patterns exist. Your policy defines what counts as advertised, and the detector must implement that definition rather than a generic one.
How often should MAP monitoring run?
Daily is sufficient for most catalogues, with a faster cadence on the retailers and products where violations concentrate. Persistence requirements matter more than raw frequency, since a single observation is weak evidence.
Why did our violation count drop after we fixed the detector?
Because the original count was mostly bundles, tax display and stale MAP values. A smaller, cleaner queue that the team actually works is the goal, not a large one that goes unread.
Can automated detection replace the enforcement process?
No. It can find candidates, rank them and assemble evidence. Deciding what to do about a reseller relationship is a commercial and legal judgement that belongs with people.
The bottom line
MAP enforcement is a rules problem wearing a data problem’s clothes. The collection is the straightforward part. What determines whether the program survives contact with a brand team is whether the detector compares the advertised price as your policy defines it, excludes the five predictable false-positive patterns, applies a tolerance band and a persistence requirement, and produces evidence rather than alerts.
Get that right and the queue becomes small, ranked and credible. The product view is on the price intelligence page, with rates on the pricing page.