What Evidence Should You Capture for a MAP Violation?

When a brand decides to act on a below-MAP price, the question that follows is "can we prove it?" The answer depends on what was captured at the time, and most programs capture the wrong thing: a screenshot, taken by whoever noticed, saved wherever they were working, with the date in the filename if they remembered.

This article sets out what a record of a MAP violation needs in order to survive the challenge it will eventually face — from a seller, a distributor, a marketplace or counsel — and why the parts that feel most technical are the ones that matter most.

What the record has to establish

A challenge to a MAP finding comes in a handful of forms, and a good record answers each of them in advance.

• "That was not my listing." The record names the seller by the marketplace's own identifier, not by a storefront name that may since have changed.
• "That was not the price." The record carries the exact advertised price and currency the source reported, with the condition, fulfillment and Buy Box state alongside.
• "That was not against your policy at the time." The record names the policy version the price was measured against — the floor in force on that date, not the floor in force today.
• "You changed it afterwards." The record is fingerprinted at the moment it is sealed, and the fingerprint is checked every time it is read.
• "Somebody just decided this." The record names the person who confirmed the finding and when.

A screenshot answers, at best, the second of these, and even that weakly.

The five records a package rests on

The most durable way to build the record is not to capture a new artifact at all but to assemble it from records that already exist and are already immutable. In MapProtector an evidence package points at five of them:

Because each of these is written once and never edited, the package can be reproduced from its inputs at any later date. A package built from a screenshot cannot be reproduced from anything; there is only the screenshot.

Three values are copied into the package at capture rather than read live: the product title, the seller's storefront name, and the seller's authorization standing. The last is the important one. If the brand authorizes the seller next month, the package sealed this month must still say they were unknown when the price was observed — otherwise the record quietly rewrites itself into a description of a compliant sale.

Sealing, and what a fingerprint proves

A record that could have been edited is a record a seller will say was edited. Sealing closes the question.

Sealing computes a cryptographic fingerprint — a SHA-256 hash — of the record's canonical form and of every attached file, and writes the fingerprints with the time and the person who sealed. From then on, every read recomputes the fingerprints and compares. A mismatch is reported as a first-class status; nothing is repaired or served quietly.

Two details decide whether this actually works.

Canonical serialization. The same facts must always produce the same bytes, or an intact record will fail verification because two systems wrote its fields in a different order. Sorted keys, money as exact decimal strings rather than floating-point numbers, nothing silently dropped: a record serialized that way hashes identically whoever assembles it and whenever.

No automatic repair. A verifier that "fixes" a hash it finds wrong has turned the one control that could detect tampering into a mechanism that hides it. Verification must recompute, compare, report, and change nothing.

The MAP Evidence Checklist lists what to check on a package before relying on it; Hash verification describes how the checks run.

Where screenshots fit

A screenshot of the listing shows what a customer would have seen, and that is genuinely useful in a conversation with a seller — it is persuasive in a way a table of fields is not. It has two limitations worth being honest about.

It establishes appearance, not provenance. It does not say which seller id made the offer, which policy version applied, or that the image has not been edited since.

And how it was obtained matters. A screenshot taken by a person in a browser is fine. A screenshot taken by automation that solved a challenge, rotated proxies or otherwise worked around a marketplace's access controls is evidence of a terms-of-service problem by the party presenting it — which makes it worse than no screenshot. MapProtector does not take screenshots of Amazon for exactly this reason, and says so on every package: the record is derived from MapProtector's own records of what the source reported, and it is not a picture of the listing page. Why Screenshot-Only MAP Evidence Is Weak goes further into the trade-off.

If your team takes its own screenshots, keep them in the case file with the URL, the date and who took them, alongside the sealed record — not instead of it.

Who should be able to seal

Sealing produces the artifact a brand may put in front of a marketplace or a court, and the only correction afterwards is a second record saying the first was wrong. That is the same class of act as approving a notice, and it belongs with the role that owns the workspace — a brand administrator — with a fresh second factor, rather than with whoever happened to be working the queue. A support engineer at the vendor should not be able to seal at all: the record is the brand's assertion, and it has to be attributable to a person inside the brand.

A minimum checklist

Before treating a MAP finding as proven, check that the record carries:

1. the seller's marketplace identifier and the storefront name as it was at the time;
2. the advertised price and currency, condition, fulfillment and Buy Box state;
3. the instant of observation, in UTC, and the coverage of the scan;
4. the policy version and the effective MAP after tolerance, promotion and treatment rules;
5. the seller's authorization standing at the time of capture;
6. who confirmed the finding and when;
7. a SHA-256 fingerprint, the sealing time and the person who sealed, and a verification that still passes.

A record with all seven is one you can hand to anyone. A record with a screenshot and a date is one you can hand to a colleague.