Google MCM Manage Inventory: The Operator Guide to MI vs MA, Applications, and Exit

Google MCM (Multiple Customer Management) lets publishers access Google Ad Exchange through a parent publisher's GAM 360 account. Two delegation types exist. Manage Inventory (MI) delegates specific ad requests to the parent's account; the child gets no GAM reporting and the parent pays revenue after deducting their fee. Manage Account (MA) gives the parent edit access to the child's own GAM account; the child retains visibility and admin rights. Under both types, the parent publisher bears policy compliance responsibility for served inventory. A child can have up to 15 MI parents simultaneously but only one MA parent. Applications require Google site review and take approximately two weeks.

What MCM actually does

MCM is the mechanism by which a publisher without direct AdX access participates in the AdX marketplace through a parent publisher that has it. The parent has a GAM 360 account with a direct Google AdX relationship. The child has their own Ad Manager network (GAM 360 is not required on the child side). The parent invites the child, the child accepts, and the delegation type determines what the parent can do once the relationship is active.

The historical context matters for understanding the approval bar. MCM replaced Google's Scaled Partner Management (SPM) program in February 2022. The name change came with stricter eligibility requirements and tighter policy enforcement. Publishers who were in SPM were migrated automatically. New entrants face a higher bar than SPM required.

What MCM provides to the child publisher: access to AdX demand, which requires GAM 360 and is not available to standalone AdSense publishers; access to programmatic guaranteed and preferred deal inventory; and in some cases access to the parent's existing direct advertiser relationships. What it does not provide: a guarantee of higher eCPMs. eCPM uplift depends on the parent's demand relationships, the quality of the child's inventory, and how the parent traffics it.

What MCM provides to the parent publisher: fee revenue from managing child inventory, expanded impressions under their AdX seat (which improves their negotiating position with advertisers), and in some cases audience data from the child's traffic that enriches their own targeting.

MCM covers both web and app inventory. For app publishers, the mechanics are similar but the tagging implementation differs. Web publishers use GPT tags; app publishers use the GAM SDK. This article addresses both but focuses on the web implementation flow. If you are evaluating demand architecture decisions around MCM, the Mediation Waterfall vs In-App Bidding guide covers the demand-side considerations for app publishers sitting at that fork.

Most publishers encounter MCM through a vendor pitch. A header bidding partner or a managed services network says "we can get you into AdX through our MCM," and the publisher moves forward without understanding which delegation type they are being offered, who controls what, or how to exit if the relationship does not work out. That gap is what this article fills.

MI vs MA: the real difference

The MI vs MA distinction is the most consequential decision in an MCM relationship and the most consistently underexplained one in vendor materials. The two types have different implications for control, revenue flow, reporting visibility, and policy liability. They are not interchangeable configurations of the same relationship.

Manage Inventory (MI) in operator terms

Under MI, the parent operates the child's delegated inventory from within their own GAM account. The parent creates the ad units, builds the ad unit hierarchy, sets targeting, and traffics line items. All of this happens in the parent's account, not the child's.

The child publisher's GAM account exists but is not where the monetization of delegated inventory happens. The child's network code is embedded in the ad tag so that Google can attribute impressions to the correct publisher for policy tracking, but the actual line item management and reporting lives in the parent's account.

The child sees no GAM reporting on MCM-managed inventory. If the child wants performance data, they have to request it from the parent. That is an important structural point: the child is trusting the parent's reporting rather than accessing first-party data from their own account.

Revenue flows from Google to the parent publisher. The parent then pays the child their agreed share after deducting the management fee. The fee is set at the time of the MCM invitation and is specified as a percentage of AdX earnings.

A child publisher can have up to 15 MI parents simultaneously. This means a publisher can test multiple MCM partners, run different inventory segments under different parents, or maintain redundant relationships. That flexibility is the primary operational advantage of MI for child publishers.

Manage Account (MA) in operator terms

Under MA, the parent receives edit access to the child's own GAM account. They can view and modify orders, line items, ad units, and settings within the child's account directly.

The child retains full admin rights. The child can see everything the parent does. The child is not locked out of their own account.

Revenue and reporting stay in the child's account. The parent's management fee is deducted automatically through the MCM relationship, and the child receives their net share directly from Google. That is meaningfully more transparent than MI: the child can verify their revenue directly in their own account and in their Google payments dashboard, without depending on the parent to report it.

The child can only have one MA parent. Once a publisher has an MA parent, they cannot add another MA parent until the first relationship is terminated.

MA is the right structure when the parent is providing full-service ad ops and the child wants to retain account ownership and direct visibility. It is the wrong structure when the child wants to test multiple partners or maintain operational independence at the ad unit level.

The choice in practice

For the vast majority of independent web publishers accessing AdX through a managed service, MI is the structure being offered. MA is more common in white-label ad ops arrangements where the parent is running the child's entire GAM account as an outsourced service.

One restriction that operators rarely spell out clearly: the same parent cannot manage the same child under both MI and MA simultaneously. If a publisher is already in an MA relationship with a parent, that parent cannot also have an MI relationship with them. This matters when a child publisher wants to add additional inventory segments under a second parent while keeping the MA parent for full-service management.

If a vendor pitches "MCM access" without specifying MI or MA, that omission is not accidental. Ask directly which type is being offered. The answer changes what the relationship means for your reporting, your revenue flow, and your ability to add other partners.

The application process and approval bar

There are two layers to the MCM application: parent publisher eligibility and child site eligibility. Operators frequently conflate them.

Becoming a parent publisher (MCM operator)

To act as an MCM parent, a publisher must have direct Google AdX access through a GAM 360 account. GAM 360 is not freely available. It requires a direct agreement with Google and is gated by traffic volume and account history. A publisher cannot simply apply to become an MCM operator independently. They must qualify for GAM 360 and AdX first, then activate MCM through their account manager relationship with Google.

The practical implication: the parent in an MCM relationship is typically a mid-to-large publisher or an ad tech company with existing scale. A small publisher cannot bootstrap an MCM operation without first meeting Google's threshold for GAM 360.

Adding a child site

The parent invites the child publisher to join the MCM relationship. The child receives an invitation at the email address associated with their Ad Manager account and accepts. Once the relationship is established, the parent submits the child's site or app for Google's review. Google's review takes approximately two weeks.

Google's eligibility criteria for MCM child sites, and what causes rejection:

First, the site must have a valid ads.txt file in the root domain. A missing or malformed ads.txt is the most common and most avoidable rejection cause. The ads.txt does not need the MCM-specific entry at the time of application (that comes after approval), but it must exist and be valid.

Second, there must be no copyright infringement history associated with the site. Sites with prior DMCA notices or that publish scraped content are ineligible.

Third, site content must not promote restricted categories including gambling, adult material, or violence. Sites in edge-case content categories should verify their category compliance before applying.

Fourth, the site must be verifiably operated by the entity applying. Parked domains, under-construction pages, and sites without substantive content are rejected. Google also reports rejections for sites with very low page counts, high bounce rates, or content that appears auto-generated, though this criterion is not explicitly stated in Google's published help documentation.

Rejection notices from Google are not specific. A publisher who is rejected receives a generic policy-violation or eligibility notice without precise detail on which criterion failed. This is a structural problem: publishers cannot efficiently fix a rejection they cannot diagnose. If your application was rejected and the notice does not tell you why, a structured review of your site's ads.txt, content categories, and site verification status usually surfaces the issue. If you want an independent read on what failed, book a free 30-minute call.

Reapplication: a parent can resubmit a rejected site after addressing the deficiency. There is no published waiting period, but resubmitting too quickly before fixing the underlying issue results in another rejection.

The relationship structure: payment flow, attribution, and reporting

Payment flow under MI

Google pays the parent publisher for all AdX revenue generated from the child's delegated inventory. The parent then pays the child their agreed share.

The agreed share is set at the time of the MCM invitation and is specified as a percentage. A typical range reported by operators is 60-80% of net AdX revenue to the child, with 20-40% retained by the parent as a management fee. This range is not published by Google. It is entirely negotiated between parent and child. The MCM system enforces the percentage as configured in the invitation, but it does not mandate a minimum share to the child.

Under MI, the child publisher does not receive payment directly from Google for MCM-managed inventory. Publishers who do not understand this before joining an MI relationship are sometimes surprised by the absence of a Google direct payment. If you are expecting a Google payment and your inventory is under MI, it will not arrive from Google. The parent pays out on their own schedule, per the private agreement.

Payment flow under MA

Revenue flows into the child publisher's own GAM account. Google deducts the parent's management fee automatically and pays each party their portion directly. The child receives their AdX earnings from Google minus the agreed fee. They can verify this in their own account and in their Google payments dashboard, without relying on the parent's reporting.

Reporting access

Under MI, reporting is the parent's. If a child publisher wants to understand fill rate, eCPM, advertiser category performance, or traffic quality metrics for their MCM-served inventory, they have to ask the parent. Some MCM operators provide regular reporting dashboards or exports; others do not. Before accepting an MI invitation, confirm specifically what reporting you will have access to and in what format.

Under MA, reporting stays in the child's own account with full GAM access.

Network code attribution under MI

The ad tag served on the child's site contains both the parent's network code and the child's network code. The tag includes an identifier for the child so that Google can attribute impressions to the correct publisher for policy tracking. Both network codes appear in ads.txt entries for this reason.

The child's network code under MI is an attribution identifier, not a revenue account. The revenue account is the parent's. This distinction matters when a child publisher is trying to understand why they do not see AdX revenue in their own GAM account.

Configuring MCM in GAM

Parent publisher side

MCM activation: the parent requests MCM activation through their Google account manager. Once activated, the MCM section appears in the parent's GAM admin settings under "Network settings" and "Multiple Customer Management."

Inviting a child publisher: in the MCM admin panel, the parent selects "Add child publisher" and enters the child's email address. The invitation specifies the delegation type (MI or MA) and the revenue share percentage. Once sent, the invitation cannot be modified. If the terms are wrong, the parent must cancel the invitation and reissue it.

Adding child sites: after the child accepts the invitation, the parent submits the child's sites or apps for Google review. For web sites, the parent submits the domain. For apps, the parent submits the app store ID. Each site or app is reviewed independently.

Ad unit creation under MI: the parent creates ad units in their own GAM account that will serve the child's delegated inventory. The ad unit setup uses the child's network code as a parameter. These ad units are distinct from the parent's own ad units and should be organized in a dedicated section of the ad unit hierarchy to avoid confusion.

Ad unit creation under MA: the parent creates and modifies ad units within the child's own GAM account directly.

Child publisher side

Accepting the invitation: the child navigates to their GAM account, finds the MCM invitation notification, and accepts. If the email on the invitation does not match the email on the Ad Manager account, the invitation will not appear. This mismatch is one of the most common setup errors and it is easy to miss.

Tagging under MI: the child replaces their existing ad tags with the parent-provided GPT tags. These tags include the parent's network code and the child's network code as a parameter. The child does not configure line items or ad units in their own account; those are managed by the parent in the parent's account. The child's role is to deploy the tags correctly and update ads.txt after approval.

Tagging under MA: the child's existing tags remain in place. The parent manages the GAM account directly, so ad units and tags are handled within the child's existing setup.

Common operational pitfalls

Each pitfall below follows the same structure: what breaks, why it breaks, and what to do about it.

ads.txt not updated after MCM approval

After the child site is approved and the MCM relationship goes active, the child must update their ads.txt to authorize the parent publisher to sell their inventory via AdX. The entry format under MCM differs from a standard AdX direct entry. It includes the parent's publisher ID and the Google seller ID, and may require both a DIRECT and RESELLER entry depending on the delegation structure. The exact format is specific to the MCM operator and must be confirmed with the parent after approval.

If ads.txt is not updated, Google's programmatic buyers will see a mismatch between the declared seller and the serving network code. The result is lower bid rates and CPMs as buyers with ads.txt enforcement active skip the non-compliant inventory. The fix is simple: update ads.txt immediately after the parent confirms the child site is approved and active. Confirm the exact entry format with the parent publisher before publishing. For app publishers validating their AdMob configuration before joining MCM, the AdMob Approval Checker is a useful first audit.

Child ad units left active alongside MCM ad units

Under MI, when the child publisher deploys the parent's GPT tags, the child's previous ad serving setup must be removed from the delegated placements. Running both the parent's MCM tags and the child's existing setup simultaneously causes ad call conflicts, double-serves, or impression loss. Publishers who try to run MCM alongside their existing setup without cleanly transitioning the delegated placements typically see degraded fill rates.

Treat MCM tag deployment as a replacement of the previous setup on delegated placements, not an addition to it.

Third-party demand not accounted for in MCM line item setup

MCM does not preclude a child publisher from running other demand sources on non-delegated inventory. But if a publisher is also running a header bidding wrapper alongside their MCM setup, the interaction between MCM line items and the external demand can produce conflicts. The most common issue: MCM line items in the parent's account are set up without floor price awareness of what the child's existing header bidding setup is achieving. The parent's MCM line items then win impressions at CPMs below what header bidding was capturing.

The fix requires the parent to know the child's existing header bidding floor levels before setting MCM line items. If the parent is not asking about this before setup, that is a problem worth naming before you deploy the tags.

Revenue reconciliation gaps under MI

Because the parent receives all AdX revenue from Google and then pays the child, the child has no independent way to verify the revenue numbers. A parent who provides monthly summaries without underlying impression or CPM data gives the child no ability to reconcile what Google paid versus what the child is owed. This is not necessarily fraud, but it is structural opacity.

Before agreeing to MI terms, request at minimum monthly reports showing total AdX revenue by site, impressions, and eCPM. If the parent declines to provide this data, that is a material flag, not a minor negotiation point.

MCM identity verification failure (April 2024 change)

Effective April 2024, MCM Manage Inventory publishers must complete identity verification (IDV) through Google's online verification process and mailing address verification via PIN. Publishers who do not complete verification cannot display ads and will not receive earnings distribution.

The IDV process is separate from the MCM approval process and must be completed by the child publisher independently. If the child publisher's Ad Manager account does not have a verified identity, the parent cannot serve on their inventory regardless of MCM approval status. This step is not part of the MCM invitation flow and is easy to miss.

Category exclusion conflicts between parent and child

Under MI, restricted category settings and EU user consent configurations are set in the parent publisher's network, not the child's. If the parent's network has restricted categories that the child's site relies on for revenue (alcohol advertising, pharmaceuticals, for example), those exclusions apply to all inventory the parent serves, including the child's.

Publishers whose content categories are at the edge of Google's restricted categories should confirm explicitly what the parent's network-level category settings are before joining an MI relationship.

For app publishers who also need to audit their mediation SDK configuration alongside MCM setup, the Mediation SDK Checker identifies compatibility issues between adapters. See the Mediation SDK & Adapter Compatibility Guide for the full adapter version reference.

The exit strategy

Exiting an MCM relationship is operationally messier than entering one. This is the section that vendor MCM pages do not cover, for obvious reasons. Read it before you enter the relationship, not after you want to leave.

Who can terminate the relationship

Either party can terminate an MCM relationship. The parent can remove the child from their MCM panel. The child can remove the parent from their own Ad Manager account settings. Google does not mandate a notice period for MCM termination. The terms are governed by whatever agreement the parent and child signed privately, not by the MCM system itself.

What needs to be unwound before exiting

Ad tags are the first priority. Under MI, the child's live pages are running the parent's GPT tags. Those tags stop serving correctly as soon as the MCM relationship is terminated. The child must replace every parent-provided tag with their own ad serving setup before or immediately after termination. If the site goes live with no valid tags, it serves no ads.

ads.txt must be updated. The MCM-specific ads.txt entries authorizing the parent must be removed. If the child intends to continue running AdX through another partner or through their own GAM account, new entries must replace the MCM entries. Allow 24-48 hours for ads.txt changes to propagate fully.

Ad unit inventory does not transfer. Under MI, all the ad units that served the child's inventory exist in the parent's GAM account. When the relationship ends, those ad units stay with the parent. The child does not inherit the ad unit hierarchy, the line items, the deal configurations, or the trafficking history. They start from zero in their own account.

Revenue settlement for the period before termination must be handled between parent and child per the terms of their private agreement. Google's MCM system does not handle final settlement. The parent receives any remaining Google payment for the period and is responsible for paying the child's share.

Programmatic guaranteed and preferred deals that the parent structured on behalf of the child's inventory exist in the parent's account. They cannot be transferred to the child or another MCM parent without re-negotiating with the advertiser. If those deals represent material revenue, exiting without a deal transition plan creates a revenue gap.

The clean exit sequence

Do not click "remove parent" without running through the checklist above first. The clean sequence: prepare replacement ad tags, arrange alternative demand (own GAM account, new MCM parent, or header bidding setup), update ads.txt to reflect the new configuration, confirm revenue settlement terms with the current parent, then remove the relationship. Running the replacement setup in parallel for 7-14 days before removing the MCM relationship is the lowest-risk transition approach.

If you are in an MCM relationship that is structured in a way that makes it difficult to leave or hard to verify, that is exactly the kind of situation where an outside review of the terms and your options is useful. That is the kind of structured engagement we cover. Book a free 30-minute call.

MCM and policy compliance

Policy responsibility in MCM is one of the least understood aspects of the relationship and one of the most consequential.

The parent is accountable for policy compliance on served inventory

Under MCM, Google holds the parent publisher responsible for ensuring that all child publisher inventory they serve complies with Google's publisher policies. If a child publisher's site receives a policy violation, the consequence does not flow to the child's own AdSense or standalone GAM account. It flows to the parent's AdX account. A parent operating 100 child publishers is accepting policy liability for all 100 sites. This is why MCM operators maintain site review processes before accepting child publishers. They are protecting their own AdX account, not doing the child a favor.

What the parent controls for policy compliance

EU user consent settings and privacy configurations are set in the parent's network for MI relationships. The parent determines how consent signals are handled for the child's inventory. Restricted category settings apply at the parent network level and affect all inventory the parent serves, including child inventory. Invalid traffic detection and ad fraud prevention are the parent's responsibility. If IVT is detected on a child publisher's traffic, the parent's account is at risk.

What the child controls

The child publisher is responsible for their site content remaining compliant with Google's content policies. A site that was clean at the time of MCM approval can go out of compliance if the publisher adds content that violates Google's policies after the fact. That is the child's responsibility to maintain.

The child is also responsible for completing identity and mailing address verification (see pitfalls section above) and for maintaining the ads.txt entries that authorize the parent to serve.

The asymmetry

Child publishers sometimes assume that because the parent is "responsible for policy," the child has no policy obligations. That is incorrect. The parent is responsible for policy at the serving layer. The child is responsible for the content on their own site. If the child's site content causes a Google policy violation, the consequence affects the parent's account, which in turn affects the child's revenue. The child is not isolated from the consequences of their own content decisions just because they are in an MCM relationship.

Operator decision framework: should you join an MCM relationship?

This is a decision framework with explicit criteria, not a discussion. Scan to your situation and get a direct answer.

You should consider joining MCM (as a child publisher) if:

You need AdX access and cannot qualify for GAM 360 directly. If your traffic volume or account history does not meet Google's threshold, MCM through a qualified parent is the path to AdX demand.

You have a site or app that meets Google's content standards and has a valid ads.txt. If you are not confident on either point, resolve them before applying. Submitting a deficient site wastes the two-week review period.

You are evaluating Manage Inventory specifically (not Manage Account) and want to maintain the option to test multiple partners. MI's 15-parent limit gives you flexibility that MA does not.

You have confirmed the revenue split, the reporting access, and the exit terms before accepting the invitation. Do not accept an MCM invitation without written confirmation of all three.

You should be cautious about MCM if:

The parent operator cannot tell you which delegation type they are offering. If a vendor pitches "MCM access" without specifying MI or MA, ask directly before proceeding.

The parent is not providing any independent reporting access under MI. If you have no way to verify revenue, you are trusting the operator's numbers entirely with no recourse.

Your existing setup (header bidding, direct deals, other demand) has not been factored into the parent's MCM trafficking plan. An MCM setup that does not account for your existing demand relationships is likely to degrade your total yield on delegated inventory.

The revenue split is below 60% to the child. No floor is mandated by Google, but a split below 60% net to the child is below the lower bound of what established MCM operators typically offer. That does not make it automatically wrong, but it warrants asking what additional services justify the higher management fee.

You should not pursue MCM if:

Your site or app does not comply with Google's content policies. MCM will not get a non-compliant site into AdX. It will add a two-week rejection cycle.

You are looking for an AdSense alternative because your AdSense account was suspended or terminated. MCM does not circumvent an AdSense policy ban. If the underlying content or account history is the issue, MCM surfaces the same problem.

You have no GAM account at all. You must create a GAM network (free) before you can participate as a child publisher in MCM.

If you are being offered an MCM relationship and you want an independent read on whether the terms are structured in your interest, that is a focused conversation. Book a free 30-minute call as the starting point.

Frequently Asked Questions

What is the difference between MCM Manage Inventory and Manage Account?

In Manage Inventory (MI), the parent publisher operates the child's delegated inventory from within their own GAM account. The child has no GAM reporting access to that inventory and receives payment from the parent rather than directly from Google. In Manage Account (MA), the parent receives edit access to the child's own GAM account and manages it there. The child retains admin rights and receives revenue directly from Google minus the agreed management fee. A child publisher can have up to 15 MI parents simultaneously but only one MA parent. For the majority of independent publishers accessing AdX through a managed service, MI is the structure being offered.

Why was my MCM application rejected by Google?

Google's review considers four main eligibility criteria. First, the site must have a valid ads.txt file in the root domain. A missing or malformed ads.txt is the most common and most fixable rejection cause. Second, there must be no copyright infringement history associated with the site. Third, the site content must not promote restricted categories including gambling, adult material, or violence. Fourth, the site must have sufficient content and be verifiably operated by the entity applying; parked domains and under-construction pages are ineligible. Google's rejection notices do not specify which criterion was not met, which is why diagnosing the issue requires working through all four before resubmitting.

What revenue split is normal in an MCM relationship?

There is no Google-mandated minimum share to the child publisher. In practice, operators report child publisher shares of 60-80% of net AdX revenue as the typical range among established MCM partners. A share below 60% is below the lower bound of what most operators offer and warrants asking what additional services justify the higher management fee. Under Manage Inventory, the parent receives all revenue from Google and pays the child their portion on a schedule set in the private agreement. Under Manage Account, Google pays each party directly per the percentage configured in the MCM invitation. In both cases, confirm the split and payment schedule in writing before accepting the invitation.

Do I lose control of my GAM account in MCM?

Under Manage Inventory (MI), the child publisher's own GAM account is largely uninvolved in the monetization of delegated inventory. The parent operates the delegated inventory from their own account. The child does not lose admin access to their own account, but the child has no view into the parent's account where the actual line items and reporting live. Under Manage Account (MA), the parent has edit access to the child's own GAM account, but the child retains full admin rights and can see all parent activity. Neither delegation type results in the child losing their own GAM account. But MI effectively moves the operational layer for delegated inventory to the parent's account, and the child cannot verify performance independently without requesting data from the parent.

Can I leave an MCM relationship after joining?

Yes, either party can terminate the relationship. However, exiting an MCM relationship requires several steps to avoid revenue gaps. Under Manage Inventory, the child's live pages are running the parent's ad tags. Those tags must be replaced with a new ad serving setup before or immediately after termination. The ads.txt entries authorizing the parent must be removed and replaced with entries for the new setup. Any programmatic guaranteed or preferred deals the parent built on the child's inventory exist in the parent's account and cannot be transferred. Outstanding revenue for the period before termination must be settled per the private agreement. A clean exit requires running a replacement setup in parallel for 7-14 days before removing the MCM relationship.

Who is responsible for ads.txt in an MCM setup?

Both parties have responsibility, but for different things. The child publisher is responsible for maintaining their own ads.txt file and keeping it current. After MCM approval, the child must add the specific ads.txt entries that authorize the parent publisher to sell their inventory through AdX. If these entries are missing or incorrect, Google's programmatic buyers will see a seller authorization mismatch and reduce or eliminate bids on the inventory. The parent publisher is responsible for providing the child with the correct ads.txt entry format after the site is approved. The format includes the parent's publisher ID with the Google seller ID and is specific to each MCM operator; it is not standardized across all MCM parent publishers.

Closing

MCM is the path to AdX for most independent publishers who cannot qualify for GAM 360 directly. Whether the specific relationship on offer is structured in your interest depends on four things: the delegation type, the revenue split, the reporting access, and the exit terms. Those four things are worth understanding before you click accept on the invitation. If you want a second opinion on a specific offer, book a free 30-minute call.