Agency ads operations guide

Give every ads client a persistent, owned login environment.

Ad platforms score logins too: a client account that logs in from a new device every week collects friction. Persistent profiles give each client one stable environment.

Guide updated 2026-09-01. Follow the steps in order.

Direct answer

Create one AliasMode profile per client ad account login, group profiles by client, and use the official manager structures (Google MCC, Meta Business Manager) for access — the profile handles the session, not the permissions.

What you will accomplish

Before you start

  • Google Ads manager account (MCC) and Meta Business Manager access per client
  • AliasMode installed with one group per client
  • One proxy per client profile, in or near the client's market
  • A media-buyer rota: who opens which client on which days

Step-by-step

  1. Structure access officially first

    Link client Google Ads accounts to your MCC and grant Meta Business Partner or partner-business access. The profile never replaces platform permissions; it stabilizes the environment you use them from.

  2. One profile per client login

    Create a profile per login the agency operates: client·google-ads, client·meta-bm. Fixed fingerprint seed. A client with both platforms gets two profiles.

  3. Proxy per client, matched to market

    Attach one residential proxy per client, in the client's country. Campaign accounts logging in from switching geographies draw security reviews at the worst time.

  4. Log in once, persist the session

    Log into the MCC or Business Manager inside the profile once. Cookies persist, so buyers open a returning session instead of a new device every week.

  5. Group by client, tag by platform

    One AliasMode group per client, tags for platform and role. Contractors get workspace access to their client's group only.

  6. Pre-check sessions before spend

    Before a buyer starts, launch the profile and confirm the session is live. For scripted checks, use the Local API to start the profile and inspect it over CDP.

    const res = await fetch('http://127.0.0.1:50400/api/v1/browser/start?user_id=' + profileId);
    const { data } = await res.json();
    const browser = await chromium.connectOverCDP(data.ws.puppeteer);
    // ... work inside the logged-in session ...
    await browser.close();
    await fetch('http://127.0.0.1:50400/api/v1/browser/stop?user_id=' + profileId);
  7. Keep the 2FA map

    Record where each client's 2FA codes land — an authenticator on your side or the client's phone. A buyer locked out mid-flight is an incident; a documented 2FA map is not.

  8. Hand off between buyers

    Close and sync the profile at shift end. The next buyer opens the same session through Cloud sync, on their own machine, with no credential movement.

The AliasMode workflow

  1. Preflight before spend

    Proxy preflight confirms the exit country before any buyer opens a spend-capable account.

  2. Local API session checks

    Scripted start, connectOverCDP, and stop let your internal tools verify sessions before shifts.

  3. Cloud handoffs

    Persistent sessions move between buyers through encrypted sync — never through shared passwords.

Verify it worked

  • Each client profile restores its session on relaunch with no security checkpoint.
  • Preflight reports the client's market for every profile before spend.
  • MCC and Business Manager roles match the signed access list per client.
  • The buyer rota log shows one open session per profile at a time.

Cautions

  • Google and Meta restrict certain regulated ad categories regardless of login hygiene; isolation does not change ad policy.
  • Do not run client ad accounts from personal logins outside the agency structure; it breaks access audits.
  • Shared office IPs across many clients' accounts create linking patterns — one proxy per client profile avoids it.

The client ads loop

  1. Pre-flight the client

    Preflight the proxy, launch the profile, confirm the session is live.

  2. Buy from the fixed environment

    All campaign work happens inside the client's profile — never from a buyer's side browser.

  3. Log changes against the client

    Budget and campaign changes go in the client's log with the operator's name.

  4. Close and sync at shift end

    The profile syncs so the next buyer inherits exactly this session.

Platform notes for ads teams

Official access versus session stability
LayerToolRule
PermissionsGoogle MCC, Meta Business ManagerAll access flows through official manager structures
SessionAliasMode profile per client loginOne fingerprint, one proxy, persisted cookies
TeamCloud workspace groupsContractors see only their client's profiles
ChecksLocal API start/stop and CDPScripted pre-shift session verification

Ads client accounts FAQ

Does the browser profile replace Business Manager or MCC access?

No. Permissions always come from the platforms' official structures. The profile stabilizes where and how your team logs in.

Why give each client a proxy?

Ad accounts that log in from one shared agency IP, then another, collect security reviews. A stable per-client IP reads like a normal office.

Can scripts check client sessions automatically?

Yes. The Local API on 127.0.0.1:50400 starts and stops profiles, and your script connects over CDP to verify the login state before a shift.

Sources and verification

  • Google Ads Help · About manager accounts (checked September 2026)
  • Meta Business Help Center · Add people and partners to Business Manager (checked September 2026)
  • Google Ads Help · 2-step verification and account security (checked September 2026)

Public product details can change after the check date. Facts are re-checked on a monthly cycle.