google ads12 min readBy Phloz team

Google Ads MCC for agencies: the operational playbook

Most agencies inherit a Google Ads MCC and never restructure it. The 5 things every MCC needs from day one, the 4 things every account needs verified, and the cross-account patterns that scale to 50+ clients.

TL;DR

Google Ads Manager (formerly MCC — My Client Center) is the parent account that holds every client's Ads account under one login + one billing relationship. Most agencies inherit an MCC from a previous owner or build one ad-hoc and never restructure. The result: orphan accounts nobody owns, conversion actions scattered across accounts with inconsistent definitions, audiences trapped per-account when they should be portable, billing relationships that break when a client's card expires. This post: the 5 things every MCC needs from day one, the 4 things to verify per Ads account inside the MCC, the conversion-action sharing strategy that survives churn, and the audience-portability + reporting patterns that scale to 50+ client accounts. Includes specific access tiers, naming conventions, and the verification cadence we use.


If you've run a digital agency for any length of time, you've inherited at least one Google Ads MCC and you've felt the pain. It's named something like "Old Agency Group" with three former employees still on it, eight client accounts that haven't run in two years, billing on a card that bounced last quarter, and a sub-MCC nested two levels deep that nobody can explain.

This isn't an exception. It's the typical state. Google Ads Manager (Google's official rename of MCC; we'll use both terms interchangeably) is one of the most powerful agency tools and one of the most frequently mismanaged. The cost of mismanagement is real — it shows up as conversion-tracking fragmentation, audience portability gaps, billing drift, and access-control accidents that occasionally end in legal conversations.

Below: the operational playbook. Everything below assumes a "standard" agency MCC managing 5-50 client Ads accounts. Patterns scale up; for 100+ accounts you'd add another layer of structure, but the principles hold.

What an MCC actually is (and isn't)

An MCC is a parent account that:

  • Holds child accounts: every client's Google Ads account links to your MCC. The link can be revoked by either side.
  • Centralizes login: your team accesses every linked account through one Google login + one MCC dashboard.
  • Centralizes billing (optionally): the MCC can pay for child accounts via consolidated billing — useful for a few patterns we'll cover, harmful for others.
  • Owns conversion actions globally (optionally): as of 2024, you can create conversion actions at the MCC level + share them across child accounts. Most agencies don't use this and should.
  • Aggregates reports: cross-account reports surface in the MCC dashboard. Looker Studio + native reports both work at MCC level.

What an MCC is NOT:

  • It's not a billing entity Google holds money from. Each child account has its own billing relationship + payment method by default.
  • It's not a conversion-tracking source of truth. Conversion actions live on child accounts unless you explicitly create them at MCC level.
  • It's not Google Workspace. The login is via your standard Google account; MCC permissions are separate from any Workspace org access.

The 5 things every MCC needs from day one

Every link to a child account has a display name visible in the MCC dashboard. Default is whatever the client named the account. Result: you scan a list of 30 accounts and 12 of them are called variants of "Marketing" or "Ads Account."

The fix: rename links to a standardized format. We use [Client Slug] | [Service Type], e.g. acme-foods | search-only or bright-app | search+shopping. Client slug is the same identifier you use everywhere else (your CRM, your project tool, your tracking infrastructure map). Service type is short — search, display, pmax, search+shopping, video. Nobody types out "Performance Max."

This is renames-on-link, not renames-on-account. The client's view of their own account name doesn't change.

2. Access tiers — minimum 3, maximum 4

Google Ads access has 5 levels: Email-only, Read-only, Standard, Admin, Email-only-with-billing. Most agencies grant Admin to everyone on the team and nobody else.

The agency-shaped tiering:

Access LevelWhoWhy
AdminSenior leads, financeFull control including user management + billing
StandardPPC specialists, account managersCan edit campaigns, can't manage users or billing
Read-onlyReports analysts, junior staff in shadowingView only, useful for training + report-building
Email-onlyClient stakeholders who want notifications without loginReceives reports, no dashboard access

Avoid the 5th level (Email-only-with-billing) unless a specific contractor needs invoices without dashboard access. It's confusing.

Audit cadence: quarterly. Pull the user list per the MCC + every linked account; compare against your actual team roster. Off-boarded contractors are the most common access gap; we typically find 1-2 stale Admin permissions per audit.

3. The MCC-level conversion library

This is the single biggest leverage point most agencies miss.

Pre-2024, conversion actions had to be created per-account. Each client had their own set of conversions, and "purchase" on Client A wasn't the same conversion entity as "purchase" on Client B — they were separate definitions, separate measurement protocols, separate reporting.

As of 2024, you can create conversion actions at the MCC level + share them across child accounts. This means:

  • One canonical "purchase" definition (event source, attribution model, count rule, value source) shared across every client where it's relevant.
  • Cross-account reporting becomes coherent — you can ask "which agency clients drove the most purchases this quarter" and the answer aggregates correctly.
  • New clients onboard faster — a new account links to the existing conversion library instead of recreating each one.

The setup: in MCC dashboard → Tools → Conversions → switch the dropdown from "Account" to "Manager." Create the canonical conversions: purchase, lead-form-submission, qualified-lead, phone-call, etc. Per child account, share down the conversions that apply to that client.

This is per-platform — every conversion shared from MCC to child account inherits the MCC definition. If you change the MCC definition (e.g. attribution model from data-driven to first-click), it propagates to every child.

Watch for: clients who already had account-level conversions when you took them over. These don't auto-migrate to MCC-level. Best practice is to disable the old account-level conversion + share down the MCC-level equivalent + update any campaigns that referenced the old conversion. Verification per conversion tracking verification is essential — measure the new conversion firing for a week before disabling the old one.

4. Cross-account billing strategy

Three billing patterns:

  • Per-account direct (default): each client has their own card on their own account. Agency manages campaigns; client pays Google directly.
  • Consolidated MCC billing: MCC pays Google; agency invoices clients separately. Simpler client UX (one bill from agency), more cash-flow burden on the agency (you front the spend).
  • Hybrid: some clients direct-billed, some via consolidated. Most agencies end up here naturally.

The right choice depends on your agency's cash-flow position + the client tier. Strategic-tier clients on consolidated; everyone else direct.

The trap: card-bounce blast radius on consolidated billing. If your MCC card declines, every child account on consolidated billing pauses simultaneously. We've seen this happen on the Friday before a Black Friday weekend. Risk-mitigation: keep two cards on file at the MCC (one primary, one backup), set up balance alerts, never let a single card carry more than $10K/day in spend.

5. The audit cadence

The MCC + every child account needs a verification pass on a documented cadence. Without it, configuration drifts: conversion actions get created off-MCC, audiences expire, sitelinks point at dead URLs, ad groups accumulate that aren't running anything.

Our cadence:

  • Weekly per active account: PPC specialist's standard optimization loop (see department workflows). Catches campaign-level drift.
  • Monthly per account: account-level health check — billing, access list, conversion firing rates, audience freshness. ~15 minutes per account.
  • Quarterly at MCC level: all linked accounts audited, all MCC users audited, all MCC-level conversions reviewed, all sub-managers (if any) verified. ~3-4 hours.
  • Annually: full restructure pass — kill orphan accounts, archive linked accounts that haven't run in 6 months, re-validate the entire access tier.

The artifact that holds this state is your tracking infrastructure map. Each Google Ads account is a node; conversion actions are nodes attached to accounts; audiences are nodes too. Health states (working / broken / missing / unverified) map directly to "did the conversion fire in the last 7 days" or "is the audience still receiving members."

The 4 things to verify per Ads account

Inside the MCC, every linked Ads account needs these four things checked — at onboarding, then on the cadence above.

Conversion actions firing correctly

For every conversion configured on the account:

  • Is it firing? Check the Conversions report → last 7 days. Zero firings = either the campaign isn't running OR the conversion is broken. Both are problems.
  • Is the count rule correct? "One per click" vs "Every conversion" — affects ROAS math materially. Ecommerce purchases = "Every"; lead forms = "One per click."
  • Is the attribution model intentional? Default in 2026 is data-driven for most accounts, but legacy accounts may still be on last-click. Check + standardize.
  • Is the value parameter correct? Lead forms with "value: 1" report ROAS that's meaningless. Either pass actual value (where measurable) or set Value: don't report.

Customer-list uploads still synced

Customer-list audiences (CRM-uploaded users for retargeting + lookalikes) need ongoing refresh. Most agencies upload once at engagement start + forget. After 6 months, the list is stale + the audience size shrinks below useful thresholds.

The fix: a documented refresh cadence per client (monthly is typical) + an integration that automates it (Phloz uses Klaviyo / HubSpot / Shopify direct integrations to push customer lists into Google Ads).

Audit check: in Audience Manager → Your data sources → Customer list. Look at "List size" + "Date last uploaded." Anything older than 60 days = flag.

Negative keyword lists current

Search campaigns accumulate wasted spend on irrelevant queries. The negatives list should be reviewed weekly per active account.

Two mistakes most agencies make:

  1. No shared negative list. Each campaign has its own. Result: when you find a new negative, you add it to one campaign + miss the others. Use shared negative lists (managed at account or MCC level) for branded negatives + competitor names.
  2. Negative-only mode. Some accounts inherit a negative-list-only practice from a previous agency where every search query gets reactively negated. This blocks future relevant queries forever. Better: negate aggressively in the first 3 months, then trust the bidding strategy + match-types.

Quality Score across active ad groups

Quality Score isn't a Google-published metric anymore in the same way it was — but the underlying signals (expected CTR, ad relevance, landing-page experience) still drive auction dynamics + cost-per-conversion.

Audit: pull the historical Quality Score column for active ad groups. Anything 5/10 or below has structural issues — usually mismatched ad copy / landing page, or a keyword theme that's too broad. Fix the ad group structure or kill the underperforming keywords.

This is harder to systematize than the other three items because the fix depends on the specific account. Senior PPC time, not junior.

Cross-account patterns that matter

Three operational patterns that come up frequently at MCC scale:

Audience portability across accounts

Google's audience-sharing model is partial. Some audience types (custom-segments, customer-list, in-market) can be created at MCC level + shared. Others (remarketing-list-from-tag, similar-audiences) are account-bound.

Practical agency workflow:

  • Custom segments: create at MCC, share to every account. Define once, reuse.
  • Customer lists: ideally upload once at MCC, share down. In practice, most agencies end up uploading per-account because the customer-data source is per-client.
  • Remarketing lists: stay account-bound. Cannot port across.
  • Lookalike (Similar) audiences: Google deprecated these in 2024 and replaced with in-market + custom-segment combinations. If you're still using them, plan a migration.

Cross-account reporting

Looker Studio + Google Ads MCC connector pulls data from every linked account. For agency-level dashboards (e.g. "total spend across all clients", "best-performing campaign across all clients"), this is the right tool.

Two common mistakes:

  1. Joining on conversion-action name without normalizing. If Client A's "Purchase" and Client B's "Purchase" are separate conversion actions (not MCC-level), the join is meaningless. The fix is the MCC-level conversion library above.
  2. Aggregating cost-per-conversion across clients. This metric isn't comparable across industries — a $50 CPL might be excellent for B2B SaaS and terrible for ecommerce. Aggregate metrics that ARE comparable (ROAS within a client, growth-vs-prior-period across clients) instead.

Sub-MCC structure (when you actually need one)

Some agencies build sub-MCCs to segment their book of business — e.g. one sub-MCC per client portfolio, or one per geographic region. Do NOT do this until you're past 50 active clients.

Reasons sub-MCCs add friction:

  • User permissions are inherited downward but not flat — you grant access at sub-MCC level, not MCC level. Tracking who has what access becomes harder.
  • Conversion actions don't auto-share across sub-MCCs. You'd duplicate them at every sub-MCC level.
  • Reporting aggregation is per-MCC, not across sub-MCCs (mostly — Looker Studio can join across, but that's another tool layer).

The legitimate use cases for sub-MCCs: regulated-industry agencies that need access boundaries between jurisdictions, white-label agencies running on top of another agency's MCC. For everyone else, one MCC is the right answer until it isn't.

The Phloz angle

Phloz models every Google Ads account as a node on the tracking infrastructure map — typed, with health states, with documented relationships to GA4 properties, GTM containers, and conversion actions. The MCC sits as the parent + every child account links via an inherited-from-mcc edge.

The advantage: when something breaks at the MCC level (a conversion action gets disabled, a customer list expires), the tracking-map graph shows the blast radius — which child accounts depend on it, which campaigns those accounts are running, which clients are affected. Without that visibility, the agency discovers the breakage only when ROAS drops on a Wednesday and somebody starts asking why.

We don't replace Google Ads (or any ad platform). We model the structure so the senior team knows what's where without keeping it in their heads.

Closing

If you've inherited an MCC and never restructured it, the highest-leverage thing this quarter is the audit pass: rename child-account links, kill orphans, tier access, build the MCC-level conversion library, document the audit cadence. Budget 8-12 senior hours to do it once + 30 minutes/week to maintain.

The compounding payback: every new client onboards faster (the MCC-level conversion library = no per-account conversion setup), every audit takes less time (documented baseline), every off-boarding closes cleanly (access tier + link list = clear boundary). For an agency running 15+ Google Ads accounts, this is one of the highest-ROI 12-hour blocks you can spend this quarter.

Try Phloz free (2 active clients, 2 seats) to see the tracking-infrastructure model in action, or see pricing for the full breakdown.