MAP Enforcement and Brand Protection Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does collection scope get underestimated on every brand protection build?

Because collecting everything sounds like a decision and is actually an unbounded commitment. Marketplaces rate limit. Page structures change without notice. A full sweep of a large catalogue across several sites produces far more data than anyone reads, and the cost of maintaining that sweep grows with every market you add rather than staying flat.

What makes it specific to this category is that the volume is adversarial. You are not collecting a stable dataset, you are collecting from parties who benefit from being hard to find, on platforms that change their markup for their own reasons. An adapter that worked last quarter can silently return an empty result set, and an empty result set looks exactly like a quiet week for compliance. Teams read the falling violation count as success.

The fix is to tier by value at risk and to measure coverage. Top revenue products in contested categories get checked daily or better, the long tail gets a weekly sweep, and new listings get checked as they surface, because that is where fresh offenders appear. Use marketplace application interfaces wherever they exist, since they are stable and permitted, and take advice on what you do beyond them. Then report coverage, meaning the share of listings for your products you actually saw this week, per marketplace and per product tier. Without a denominator, a report of forty violations tells you nothing about whether it is the picture or a corner of it.

What goes wrong with matching your product inside someone else's listing?

Everything, if you match on one signal. This is the inverse of normal catalogue work. You are not organising your own data, you are finding your product inside listings written by people who would prefer you did not. Titles are deliberately misspelt, model numbers are omitted or altered, your item is buried inside a bundle with a cheap accessory so the price is arguably not comparable, listings use lifestyle photographs rather than product shots, and the same item appears under three regional model designations.

A single signal matcher fails in both directions and the second failure is the one that kills programmes. Missed listings are invisible. False positives are highly visible: a violation report full of items that were not yours, or were a different regional variant with a different price rule, and the channel team stops opening the report. Once trust is gone it does not come back easily.

Match on a stack instead. Identifiers where present, model number patterns including the deliberate corruptions sellers use, image similarity against your own official asset library which catches sellers reusing your photography, and text similarity against your own descriptions which catches copied bullet points. Hold a confidence score, route the uncertain band to human review, and feed those decisions back so the matcher learns your specific variant conventions. Handle bundles explicitly in both the policy and the detector, because leaving them to fall out of the report is the most common evasion route.

Why do marketplace collection adapters break after launch?

Because they are dependent on someone else's product decisions and nobody owns them after go live. A marketplace redesigns a listing page, changes a rate limit, or adjusts what an interface returns, and one adapter degrades. If collection is written as a single pipeline, that degradation can stop everything. If it is written as independent adapters, it stops one source, which is what you want.

The deeper problem is monitoring. Conventional alerting checks that a job ran, not that it returned a sensible amount. An adapter that runs cleanly and returns two hundred listings where it used to return nine thousand will pass every health check you have.

Build each source as an independent adapter with its own health signal based on expected volume rather than on exit status. Alert on a collapse in listings seen for a marketplace, not just on errors. Keep the parsing logic separate from the matching logic so a markup change is a small repair rather than a regression across the whole system. And budget adapter maintenance as a standing line, because marketplaces will keep changing regardless of your release schedule, and a fixed price project that ends the day it ships leaves you with a system that decays quietly.

What happens when the policy and legal structure is not covered?

Two failures, one commercial and one legal. The commercial one is that advertised price policy is treated as a single number. It is not. It is a price per product, per region, per period, with promotional windows where the floor moves, exceptions for authorised clearance of discontinued lines, and different treatment for advertised price, checkout price and price in cart. Encode that as a static threshold and your report fills with violations that are not violations, which is the same failure as a bad matcher and has the same result.

The legal one matters more. In the United States, advertised price policies are generally structured as unilateral policies a brand announces and enforces by choosing whom to deal with, rather than as agreements on resale price, and state law varies in how it treats resale price maintenance. Other jurisdictions differ again. Software that hosts negotiation of prices with resellers, or that records enforcement as a bilateral agreement, is creating records that may one day be read as evidence about how your policy operated.

Take the structure of the policy from antitrust counsel first, then build software that supports exactly that structure. Hold the policy as versioned data with effective dates, product scope, regional scope and explicit bundle and promotion handling, and make every violation record cite the exact policy version and clause it breached. That kills most false positives and makes disputes short.

Should you build custom or configure Red Points or MarqVision?

Buy if your problem is counterfeits rather than diversion through your own channel. Counterfeit removal through platform intellectual property programmes is a well solved service problem, and Red Points and MarqVision have both the takedown workflows and the volume relationships to work it at a scale an internal team will not match. Corsearch is credible where trademark work is the core need. Amazon's own brand programmes are worth using regardless of what else you run. If you monitor one or two marketplaces and have a modest number of unauthorised sellers, a build will not return the money.

Build when the real problem is diversion by your own authorised partners, because no external monitor can diagnose that. They cannot see your shipment records, and the answer lives there. Build when your price policy has regional and promotional structure that generic monitoring keeps flagging incorrectly, when sellers relist under new aliases faster than your process connects them, or when your authorised dealers are raising channel conflict as a commercial issue rather than a legal one.

There is also an ownership argument. The seller entity graph and the enforcement history compound in value every month, and they are what make your fourth notice a case rather than another letter. That asset should not sit with a vendor you might change.

How do hidden costs get into the quote?

Five ways. Marketplace and region count, since each adapter is separate work with an ongoing maintenance burden that nobody prices. Catalogue size and variant complexity, because forty products and four thousand are different matching problems, not the same problem at different scale. Image similarity at scale, which adds genuine infrastructure cost that a proposal written around a database rarely includes. Language coverage, if you monitor markets where listings are not in your language. And integration into your own distribution records for serial traceback, which depends entirely on whether your shipment data carries serial ranges, and which nobody checks before quoting.

Check that last one first. Ask your supply chain team today whether you can map a serial or lot code on a unit back to the distributor it shipped to. If the answer is no, then test buys will identify a seller and never identify a source, and half the value of the programme is unavailable until that is fixed. Better to know in discovery than in month five.

What separates a brand protection build that works from one that fails?

The programmes that work treat sellers as persistent entities. Storefronts get clustered on signals that are expensive to change: shipping origin and handling times, reused photographs detected by perceptual hashing, description text fingerprints, return addresses, and repricing behaviour patterns that leave a recognisable signature. In the United States, seller business details disclosed under the INFORM Consumers Act have made this materially easier for high volume sellers. The cluster carries a confidence level, an alias history and a full enforcement timeline, and it can be split easily when it is wrong, because merging two legitimate resellers into one entity produces an escalation letter you cannot defend.

They also run test buys as a tracked workflow rather than an occasional errand: budget control, chain of custody on the received item, photographs, and an automated lookup from the serial code back through your shipment records. The output is a diversion report by authorised partner, which is the single most valuable artifact the system produces, because it stops supply rather than removing one listing.

Finally, settle ownership before kickoff. You should own the repository, the seller entity graph and the enforcement history. At Digital Heroes the client owns everything from the first commit.