MAP Monitoring: How to Detect Minimum Advertised Price Violations
How to run a MAP monitoring program that actually catches violations: build the reseller URL map, extract advertised prices on a schedule, keep timestamped evidence, and tell a real violation apart from an in-cart discount.
By the ClawEngine team
July 2026 · 10 min read
Hit Extract to turn this page into clean, LLM-ready data.
robots.txt respected · public data only
What MAP monitoring actually is
MAP monitoring is the practice of watching the prices your authorized resellers advertise publicly and flagging anyone who advertises below the minimum advertised price in your policy. It is not a pricing algorithm and it is not a legal service. It is a data job with three parts: collect the advertised price from every reseller page on a schedule, compare each price to the MAP for that SKU, and keep timestamped evidence of every violation so your enforcement letters are backed by something a reseller cannot argue with.
Most brands discover they need it the same way. Sales through the authorized channel look fine in aggregate, then a regional retailer notices your product listed 22 percent cheaper somewhere else and asks why they should keep stocking it at full margin. By the time that conversation reaches you, the price has usually been live for weeks and other resellers have already matched it downward. The whole point of monitoring is to compress that lag from weeks to a day.
Why spreadsheets stop working around 200 SKUs
Nearly every MAP program starts as a manual check. Someone on the channel team opens twenty reseller sites on Monday morning, records prices in a spreadsheet, and emails the offenders. That works, right up until the point where it does not, and the failure is arithmetic rather than effort.
Take a realistic mid-size brand: 300 SKUs across 40 authorized resellers. That is 12,000 price checks. At even ten seconds per check you are looking at more than 33 hours of clicking to produce a single snapshot, which is stale before it is finished. Weekly coverage is impossible, so the program silently degrades into spot checks on the SKUs someone happens to remember, which is exactly the pattern a reseller testing your enforcement will exploit.
The second failure is evidentiary. A spreadsheet cell reading $119 is not evidence. When a reseller replies that the price was a display error, or that it applied only to a cart promotion that has since ended, you need the URL, the exact timestamp, the price as displayed and ideally the promotional text that accompanied it. Manual checks almost never capture that, so enforcement conversations turn into memory contests.
The technical shape of an automated MAP program
Once you automate it, the system is small. There are four moving parts, and the sequencing matters more than the sophistication of any single one.
1. A reseller URL map keyed to your SKUs
This is the part everyone underestimates. You need to know that reseller B's product page /shop/trail-runner-gtx-11 is your SKU TR-GTX-11, and that mapping has to survive URL changes. Build it from the strongest identifier the page publishes. Many retailers expose a GTIN, UPC or MPN inside their JSON-LD product markup, which gives you a reliable join key. Where they do not, fall back to brand plus model number, and treat fuzzy title matching as a suggestion that a human confirms once rather than a rule the system reapplies every night.
2. Scheduled extraction that returns structured fields
Each run needs the advertised price, any strike-through list price, the promotional text, stock status and the seller name, in the same shape from every retailer. This is where hand-rolled scraping collapses, because every retailer renders pricing differently and many build it client-side after a variant selector loads. A price monitoring API that renders the page and fills a schema you define removes the per-retailer parser entirely, which is the difference between a system that keeps running and one that quietly returns nulls after a redesign.
3. An observation store, not a price column
Write one row per check with the URL, timestamp, price, promo text and stock status. Do not update a single current-price field. The history is what turns monitoring into leverage: it shows whether a violation was a one-hour glitch or a sustained 30-day position, whether a reseller reoffends after a warning, and how quickly the rest of the channel follows a violator down.
4. A rules layer and an alert
The rule itself is trivial: if the advertised price is below the MAP floor for that SKU, record a violation. What needs care is the noise control around it. Set a small tolerance so rounding and currency conversion do not generate false positives, require a violation to persist across two consecutive checks before it pages a human, and route alerts to whoever actually contacts resellers. The discipline is the same one you would apply to watching a production endpoint and getting paged when it breaks: an alert that fires constantly is an alert nobody reads.
What a violation record should contain
Aim for a record that a reseller's account manager can verify in thirty seconds without trusting you.
| Field | Example | Why it matters |
|---|---|---|
| url | reseller-b.example.com/p/tr-gtx-11 | Lets them reproduce it immediately |
| observed_at | 2026-07-19 04:12 UTC | Answers "that was months ago" |
| advertised_price | 119.00 | The number in dispute |
| map_floor | 149.00 | The policy figure it breached |
| promo_text | "Extra 20% off at checkout" | Distinguishes advertised from in-cart pricing |
| seller | Reseller B Outdoors | Identifies third-party sellers on multi-seller sites |
| consecutive_runs | 6 | Separates a glitch from a strategy |
Advertised price versus the price in the cart
This distinction is the single most common source of arguments, and it is worth getting right before you send anyone a letter. MAP policies govern the advertised price, the number a shopper can see on the page or in an ad. A price that only appears after the item is added to the cart, or after a code is applied at checkout, is generally not an advertised price, and many policies explicitly permit it. That is precisely why the practice exists at scale.
Practically, that means your extraction has to capture both the displayed price and any promotional text, and your rules layer has to know which one your policy governs. If you flag in-cart discounts as violations under a policy that permits them, your channel team burns credibility on the first three emails and stops trusting the system. Encode the policy honestly, even where it means recording fewer violations.
How often to check
Match the interval to how fast the category moves, and tier your list rather than crawling everything at the same rate. Furniture, apparel and most consumer packaged goods shift on a weekly cadence, where a daily check is already generous. Consumer electronics, tools and anything subject to algorithmic repricing can move several times a day, which justifies hourly checks on a short priority list of high-margin SKUs and known repeat offenders. Crawling 12,000 URLs hourly mostly buys noise and a larger bill.
One scheduling detail that pays for itself: run the full sweep at a consistent time each day. Prices move around promotional windows, and a sweep that drifts between 2am and 2pm produces changes that are really just time-of-day artifacts. Consistency makes the diff meaningful.
The legal boundary in one paragraph
Collecting publicly displayed prices is broadly lawful in the United States, and courts have repeatedly declined to treat access to public web pages as unauthorized access under the Computer Fraud and Abuse Act. What binds you is each site's Terms of Service and robots.txt, and, more importantly for a MAP program, antitrust law. A unilateral MAP policy that you set and enforce yourself sits on very different ground from coordinating prices with a competitor or agreeing with resellers on resale prices. Treat the data collection as routine and the policy design as something your counsel signs off on. Our guide to whether web scraping is legal covers the collection side in detail, and the compliance policy explains the boundaries we hold to. None of this is legal advice.
Where automated monitoring genuinely fails
Two honest limits, because a monitoring vendor that claims total coverage is selling you a future disappointment.
The first is large marketplaces. Amazon, Walmart marketplace and similar platforms run aggressive anti-bot systems and their terms restrict automated access. We do not target them, and neither should a vendor that wants your pipeline to still work in six months. If marketplace buy-box data is central to your program, license it from a provider with an agreement in place and use crawling for the rest of the channel.
The second is closed channels: prices behind a dealer login, in a PDF price list emailed to accounts, or quoted by phone. No crawler reaches those, and violations there are found by field reps and mystery shopping. Automation should cover the open web comprehensively and free your team to work the channels it cannot see.
Start with the smallest useful version
You do not need a platform to begin. Pick your twenty highest-margin SKUs and your ten largest resellers, build the 200-URL map, extract them nightly into an append-only table, and diff. That is a weekend of work and it will find violations in the first week, which is what buys you the mandate to expand. Scale the SKU count once the matching logic and the alert thresholds have been tuned against real data rather than assumptions.
If you want the extraction half handled, the price monitoring API returns price, promo, stock and seller as typed JSON from any public retailer page, and the same call pattern covers broader ecommerce catalog extraction when you want competitive assortment data alongside pricing. There is also a walkthrough of the competitive side in monitoring competitor prices with an API.
See ClawEngine turn pages into clean data
Point ClawEngine at any public or permitted site and get back clean markdown, JSON, or typed structured fields in one call. Crawl at scale, render JavaScript, and feed your RAG pipelines and AI agents, robots.txt and Terms of Service respected.