The MCM Liability Trap: Why One Bad Publisher Can Kill an Entire Network

There is a sentence in Google's Multiple Customer Management Partner Guidelines that anyone running a publisher network should be able to recite from memory. Most cannot, which is a problem, because it describes the circumstances under which their entire business stops.

Paraphrased closely: as between the parent and Google, the parent is responsible for any and all policy violations occurring on child inventory it manages or represents — whether that inventory is served through the child's account or the parent's — and whether the violation was caused by the parent, the child, or any other party. Google reserves the right to take enforcement action against the parent, up to and including disabling the parent's use of MCM.

Four words carry the weight: or any other party. Not "the parent's negligence". Not "violations the parent failed to prevent". Any other party. Somebody with no relationship to your business, no contract with you, and no interest in your survival can cause a violation on inventory you represent, and the liability is yours.

Before the objections start: this is not unreasonable of Google, and reading it as hostile misses the point. Google has a supply chain with hundreds of thousands of endpoints and no practical way to audit each one. Pushing responsibility onto the party that chose to represent an account is the only enforcement model that scales, because it makes the entity closest to the risk the one who carries it.

The problem is not that the rule is wrong. It is that a great many networks operate under it without having read it, and have priced their business as though liability travels downward.

What "any other party" means on a Tuesday

Consider a network representing forty publishers. One of them — a small regional site, entirely honest, running clean — becomes the target of a competitor who buys bot traffic and points it at that site's ad units.

The publisher did nothing. The network did nothing. The traffic is invalid, it arrived on inventory the network represents, and under the guidelines above the enforcement exposure sits with the network.

That is not a hypothetical shape. Invalid-traffic extortion against publishers is documented — an email demanding cryptocurrency, with the threat of flooding the target's ads until enforcement lands. What the MCM structure adds is that the blast radius is no longer one publisher. It is every publisher the network represents, because what is at risk is the network's MCM privilege itself.

The four ways it usually arrives

In practice the violation that ends an MCM relationship comes from a small set of places, and only one of them involves anybody being dishonest:

• A publisher buys traffic without telling you. Usually to protect a revenue figure after a bad month, usually from a vendor whose quality they had no way to inspect. This is the most common one by a distance.
• A layout change creates accidental clicks. A redesign puts a unit next to navigation, or a sticky element lands under a thumb, and the click rate rises without a single person intending anything.
• Somebody aims traffic at a represented site. A competitor, an extortionist, or occasionally a scraper misbehaving at scale.
• A publisher does it deliberately. Real, but rarer than the first three combined — and the only one where screening at admission is the whole defence.

Notice that three of the four are recoverable if caught early and terminal if caught late. That ratio is the argument for surveillance in one line.

Both ends are liable at once

A common misreading is that MCM shifts liability from the publisher to the network — that a child under management is somehow shielded. It is not.

The guidelines also make the child responsible to Google for violations on its own inventory, however that inventory is managed and whoever caused the violation. Liability is not transferred. It is duplicated. A single violation can trigger enforcement against the child's account and against the parent's MCM privilege, independently, for the same event.

For a publisher evaluating whether to be represented, that is the fact to internalise: being under a network's management does not put a layer between you and Google. It adds a party who is now also exposed to your traffic quality, which is precisely why a competent network will ask you questions that feel intrusive before agreeing to represent you.

Why this changes what a network is for

Duplicated liability quietly redefines the business. A network is often sold to publishers as a demand-access service: we have relationships you do not, so we can monetise your inventory better than you can alone.

Under these guidelines it is also, unavoidably, a risk-management service. The network is accepting exposure to every represented publisher's traffic quality, permanently, in exchange for a revenue share. Whether or not the network has noticed it is doing that does not change that it is.

Which suggests a useful question for a publisher choosing between partners: does this network talk about traffic quality as something it does for me, or as something it does to protect itself? The honest answer is both, and a partner who says so has understood their own business.

MCM is invitation-only, and the reason is stated

Google does not open MCM to anyone who wants it. Partners are approved against quality criteria, and those criteria explicitly include the protection of represented inventory against ad fraud — invalid traffic, click spam, accidental and forced clicks.

That is worth reading as what it is. Google is not describing fraud protection as a value-add a good partner might offer. It is describing it as a condition of holding the privilege at all.

The mechanics operators actually have to know

Two delegation types exist, and the difference determines who can see what — which in turn determines who can detect a problem before Google does.

Manage Account (MA)

The child keeps their own Ad Manager account and their own ad tags. Settings live in the child's account. The parent is granted full access to that account and works inside it.

The publisher retains visibility and control. The network sees everything because it is operating in the publisher's own account. For a publisher who wants to keep their independence and eventually be able to walk away with their setup intact, MA is the structure that supports that.

Manage Inventory (MI)

The child uses the parent's ad tags, carrying a child identifier. Settings live in the parent's account. Reporting data for MI inventory sits in the parent's network — and the child has no visibility into it.

That last point is the one that causes disputes. Under MI, a publisher cannot independently verify what their inventory earned. They see what the parent reports. Everything about the relationship then rests on the parent choosing to be transparent, because the structure does not require it.

The dependency nobody mentions until it bites

There is a structural consequence of MI that publishers should understand before signing anything: if the child ends the agreement, they cannot serve ads until they are reconnected to a new platform partner.

The tags belong to the parent. Ending the relationship means the inventory has no serving path until a replacement is in place. That is not a penalty anyone imposes — it is just what the architecture implies — but it means "we can leave whenever we like" is not quite true, and the time to discover that is not during a dispute.

Sub-partners, and where the chain gets long

MCM also permits a parent to represent inventory through sub-partners, which produces a chain rather than a flat list — the parent, an intermediary, and the publisher underneath.

Every additional hop does two things, both bad for the party at the top. It increases the distance between the parent and the actual inventory, so problems are seen later. And it does not reduce the parent's liability by a single word, because the guidelines make the parent responsible for inventory it manages or represents regardless of how many entities sit between.

A parent taking on a sub-partner is therefore accepting responsibility for accounts it has never evaluated, admitted by a party whose screening standards it does not control. That can be a perfectly sound commercial decision. It should be a deliberate one.

The "2% rule" that does not exist

Ask around any MCM operator community and someone will tell you there is a safe threshold — that Google tolerates violations up to some percentage of your represented inventory, commonly quoted as 2%.

There is no such published threshold. Google does not state one, and treating an invented number as a compliance target is how an operator ends up defending a position that was never real.

What is true is the underlying instinct, stated properly: this is portfolio risk management. A network's exposure is a function of how many accounts it represents, how carefully it screens them, how quickly it detects a problem, and how fast it can remove one. Keeping aggregate violations low is the objective. Believing there is a line you can safely sit just under is not a strategy, it is a hope.

What the number should actually be

If you want a metric to manage rather than a myth to hide behind, the useful ones are not violation rates at all. They are leading indicators:

• Time to detection. From the moment an account's pattern changes to the moment somebody at the network knows. If this is measured in weeks, nothing else matters.
• Time to removal. From knowing to the account no longer serving. Contracts that make this slow are a liability disguised as a commercial term.
• Share of represented inventory admitted in the last 90 days. New accounts are where unscreened risk lives. Rapid growth in this number is rapid growth in exposure.
• Share of represented publishers with meaningful organic traffic. A portfolio skewed toward paid-acquisition sites is an MFA problem waiting to become a policy problem.

What the defence actually consists of

Three things, and none of them is a filter you buy once.

1. Screening at admission

The cheapest violation to survive is the one you never took on. That means asking, before representing anybody: what is the traffic history that predates this conversation, what is the organic versus paid split, does the referral composition make sense for the subject matter, is there a real organisation behind the contact details.

Every one of those is unglamorous and every one is cheaper than an enforcement action.

2. Continuous surveillance, not periodic review

A monthly check is close to useless against something that escalates in days. The relevant signals are the ones the enforcement systems themselves key on — behavioural mismatch, a click rate moving while engagement stays flat, a traffic-source composition shifting faster than an audience can — and they need watching continuously across every represented account, not reviewed in a quarterly meeting.

This is also the one part of the job that genuinely benefits from operating at network scale. A pattern that is ambiguous on one property is often obvious the third time it appears across accounts in the same week.

3. An evidence trail, kept before you need it

When something does happen, the difference between an appeal that asserts and one that demonstrates is contemporaneous data. What did this account's traffic look like for the twelve months before the anomaly? When exactly did the pattern change? What was the source composition before and after?

That record has to exist already. Nobody has ever successfully reconstructed it afterwards.

And the fourth thing: be willing to eject

This is the part operators find hardest, because it means firing revenue.

An account generating a violation pattern is not a support problem to be nursed. Under the liability clause at the top of this article, it is a threat to the privilege that lets you represent everyone else. Removing it quickly protects forty publishers; keeping it protects one invoice.

What "fast" actually has to mean

Operators consistently underestimate the speed required, so it is worth being concrete about the clock.

The recoverable stage of enforcement is the ad serving limit — the point at which a platform is signalling that it cannot verify traffic quality rather than concluding that it is bad. From there, the window before escalation is measured in weeks at best.

A monitoring cadence of "we review accounts monthly" is therefore not a lighter version of continuous monitoring. It is a system that will reliably detect the problem after the window has closed, which is functionally the same as not detecting it. The cadence has to be shorter than the escalation, and the escalation does not wait for your reporting schedule.

The record-keeping that survives a partner change

One practical detail that catches operators mid-transition: the evidence trail has to belong to you, not to the platform.

Reporting inside Ad Manager is subject to that platform's retention windows and to your continued access. An account that gets disabled is an account whose historical reporting becomes considerably harder to pull at exactly the moment you need twelve months of it. The same is true in reverse for a publisher leaving an MI arrangement — the reporting lived in the parent's network, and it does not walk out with them.

Whatever the monitoring layer is, it should hold its own copy of the baseline: source composition, engagement depth, click rate and volume, per account, going back far enough to describe a normal year. Exportable, and independent of whether any particular platform relationship still exists.

What this means if you are the publisher, not the network

Most readers of this Journal are on the other side of the relationship, so it is worth turning the argument around.

Everything above tells you what to ask a prospective partner. A network that has thought about any of this will have ready answers. One that has not will find these questions surprising, which is itself the answer:

• Which delegation type are you proposing, and why that one? If it is MI, ask what reporting you will get and how often, because the structure gives you none by default.
• What do you monitor on my traffic, and what will you tell me? "We watch for invalid traffic" is not an answer. Ask what specifically, and how quickly they would tell you.
• What happens to my account if another publisher you represent causes a problem? A partner who has never considered this has not read the guidelines they operate under.
• If I leave, what do I keep? Under MA, your account and setup. Under MI, ask precisely — the tags are not yours.

The contractual half nobody writes

One closing point, aimed at operators, because it is where good technical practice goes to die.

All of the surveillance in the world achieves nothing if the contract with a represented publisher does not permit acting on it. The agreement needs to say, in plain terms, that the network may suspend or terminate serving on traffic-quality grounds, at its discretion, without a notice period long enough for enforcement to arrive first.

Publishers reasonably dislike that clause and will push back. The honest way to sell it is the truth: it exists because the alternative is that one account's problem removes everyone's monetisation, and the publisher asking for a thirty-day notice period is also one of the thirty-nine protected by its absence.

A network with excellent monitoring and a contract that requires a month's notice to act has built a very good alarm attached to a door it is not allowed to close.