Dual Login
Playbooks

How to Manage Client Ad Accounts as an Agency: 2026 Playbook

Dual Login Team·2026-08-20·16 min read

How to Manage Client Ad Accounts as an Agency: 2026 Playbook

A practitioner's playbook for agencies: keep client ad accounts isolated, avoid cascading bans, and scale your team without ever sharing passwords.

Every agency that survives past its first dozen clients eventually learns the same lesson, usually the hard way: the ads are rarely what gets you banned. The way you access the accounts is.

A media buyer logs into eight different Meta Business Managers from the same Chrome window before lunch. Google sees one browser, one device, one IP address, hopping between advertisers in three countries. Then one client — the one who sold sketchy supplements before they hired you — catches a policy strike. Within a week, two unrelated client accounts get pulled into review. Nobody at the platform will tell you why, but you already know: the accounts were linked through you.

This guide is about how to manage client ad accounts as an agency so that never happens. It covers the access structures the platforms actually want you to use, the browser-level isolation they never mention but absolutely track, and the operational habits — naming, billing, 2FA, offboarding — that separate agencies who scale calmly from agencies who spend every Monday filing appeals.

Agency media buyer managing multiple client ad accounts in isolated browser profiles

Why Agencies Lose Ad Accounts (It's Rarely the Ads)

When an ad account gets restricted, everyone's first instinct is to audit the creative. Was the claim too aggressive? Did the landing page trip a policy? Sometimes, sure. But ask anyone who has run appeals at volume and they'll tell you the majority of agency-side restrictions trace back to two things: association and anomalous access patterns.

The association problem

Ad platforms don't evaluate accounts in isolation. They build graphs. Accounts that share a payment method, a device fingerprint, an IP address, a login session, or even a browser profile get clustered together. That clustering is mostly invisible until something goes wrong — and then it works like contagion. One node in the cluster gets flagged for circumventing policy, and the platform's automated systems start scrutinising everything attached to it.

For a solo advertiser this barely matters. For an agency it's existential, because you are the shared node. Your laptop, your office IP, your browser — every client account you touch inherits a thread connecting it to every other client account you touch. Manage twenty clients from one machine the naive way and you've quietly built a twenty-account cluster where the riskiest client sets the risk level for everyone.

What platforms actually see when you log in

It's worth being concrete about the signals, because most agency owners underestimate them:

  • IP address and ASN. Not just "where you are" but whether the IP is residential, datacenter, or a known VPN exit — and whether fifteen advertisers in different countries all authenticate from it.
  • Browser fingerprint. Canvas rendering quirks, WebGL renderer strings, installed fonts, audio processing signatures, screen geometry, timezone, language. Combined, these identify a specific browser on a specific machine with unsettling accuracy. If that's new territory, our explainer on what browser fingerprinting is and how it works covers the mechanics; you can also see your own fingerprint live at the EFF's Cover Your Tracks tool.
  • Cookies and session continuity. Platforms notice when the same session cookie jar touches multiple unrelated business entities.
  • Behavioural patterns. Login times, navigation rhythm, the sequence of pages you hit. Automated review systems weigh all of it.
  • Mismatch signals. A browser reporting a New York timezone while its IP resolves to Frankfurt is a classic tell. So is a UK client account only ever accessed from a Philippine IP with an American English locale. (More on fixing this in our guide to timezone and geolocation consistency.)

None of these signals alone will kill an account. Together, over time, they decide whether your access looks like a legitimate marketing partner or like an account farm. The whole discipline of managing client ad accounts as an agency is about making each account's access story internally consistent — and keeping the stories separate.

The Foundation: Get the Access Structure Right First

Before any talk of browsers and proxies, get the boring part right, because it's the part the platforms explicitly support and the part that saves you when a client relationship ends badly.

The golden rule: the client owns the asset, the agency is granted access. Never build client accounts inside your own business entity, and never accept a client's personal username and password as your access method. Both feel faster on day one. Both are debt.

Meta: partner access through Business Manager

On Meta, the correct structure is that the client has their own Business Portfolio (Business Manager) which owns the ad account, the Page, the pixel/dataset, and the domain verification. Your agency has its own separate Business Portfolio. The client grants your portfolio partner access to the specific assets you need, with the specific permission levels you need — and nothing more. Meta's Business Help Center documents the flow, and it takes ten minutes.

Why insist on it? Three reasons. First, if your agency portfolio ever gets restricted, assets owned by the client survive. Second, offboarding is one click — the client removes the partner, no password resets, no arguments about who owns the pixel data. Third, Meta's own trust systems treat properly-structured partner access more kindly than a mystery login from a new device.

Google's equivalent is the manager account, still widely called an MCC. Your agency runs one manager account; each client's Google Ads account links to it. You get consolidated billing views, cross-account scripts, and user management, while the client keeps ultimate ownership of their account and its history.

The common mistake here is agencies creating fresh client accounts under their MCC with agency billing attached. It works until you part ways, at which point untangling ownership is miserable and the account's payment history — one of Google's strongest trust signals — belongs to the wrong entity.

TikTok and everyone else

TikTok mirrors the same idea with Business Center: the client owns the advertiser account, your Business Center requests partner access with member roles (TikTok's help center walks through it). Microsoft Ads has manager account hierarchies. Amazon has partner network access. The pattern repeats everywhere because the platforms all learned the same lesson: shared credentials cause chargebacks, hijacks, and disputes they'd rather not adjudicate.

Structure alone, though, doesn't solve the association problem. Partner access tells Meta who you are. Your browser tells Meta what else you touch. That's the second half.

One Client, One Browser Environment

Here's the operating rule that prevents cascading bans: every client gets its own complete, persistent, isolated browser environment. Not a Chrome tab. Not an incognito window. A separate browser identity with its own cookies, its own local storage, its own fingerprint, and — for accounts that are geography-sensitive — its own proxy.

Why normal Chrome profiles fall short

Chrome's built-in profiles do separate cookies, and that's genuinely useful. But every Chrome profile on your machine shares the same fingerprint: same canvas hash, same WebGL renderer, same font list, same audio signature, same screen resolution, same timezone, same IP. To a platform's device-graph, your eight Chrome profiles are transparently one device wearing eight hats. The cookie separation prevents accidental cross-logins; it does nothing about association.

Incognito is worse — it throws away the session every time, so each login looks like a brand-new device, which is itself a suspicion trigger. Platforms like seeing a familiar, stable device return day after day. What you want is stability within a client and separation between clients.

What an antidetect browser changes

An antidetect browser like Dual Login runs each profile as a genuinely separate browser instance. Each profile gets:

  • A unique, internally consistent fingerprint — canvas, WebGL, audio, fonts, navigator properties, screen metrics, user agent — generated once and then held stable for the life of the profile. Consistency matters more than novelty: a fingerprint that never changes and matches its claimed hardware reads as a real device.
  • Its own persistent data directory — cookies, localStorage, IndexedDB, cache. Log into a client's Business Manager once, complete 2FA once, and the session persists across days and reboots exactly like a real employee's laptop would.
  • An optional dedicated proxy, so the account's traffic originates from an IP that matches the client's market rather than your office.
  • Real process isolation — each profile is its own OS process with its own memory, so there is no technical path for state to bleed between clients.

The result: Client A's account lives on what looks like one specific machine in one specific city, forever. Client B lives on a different machine in a different city. Your riskiest client can burn to the ground without singeing anyone else, because as far as the platforms can tell, there is no "anyone else."

One note on legitimacy, because agencies reasonably ask: using an antidetect browser to keep legitimate client accounts operationally separate is standard practice and there's no law against it — the legal risk lives in what you do with accounts, not the tooling. We've written a plain-English breakdown in Is using an antidetect browser legal? if compliance wants a reference.

Matching proxies to client geography

Proxies are where most teams overcomplicate things, so here's the simple version:

  • Local clients, low sensitivity: you may not need a proxy at all. An agency in Manchester managing a Manchester dental clinic from a Manchester office IP is a perfectly coherent story.
  • Clients in other markets: use a static residential or ISP proxy located in the client's country, one per client, never shared between profiles. Static, because the account should see the same IP (or at least the same city and ISP) every session.
  • Avoid datacenter IPs for login sessions. They're fine for scraping; for authenticating into ad platforms they're a flag.
  • Match everything. If the proxy exits in Toronto, the profile's timezone, locale, and geolocation should say Toronto too. Dual Login derives timezone, language, and geolocation from the proxy's exit IP automatically, which removes the most common mismatch mistake entirely.

Day-to-Day Operations: A Workflow That Scales

Isolation is the architecture. What makes it liveable at 30, 50, 100 clients is operational discipline.

Naming conventions and grouping

Decide a naming scheme before you have enough profiles to regret not having one. Something like ClientCode – Platform – Role works: ACME – Meta – Buying, ACME – Google – Billing. Group profiles by client, not by platform, so everything belonging to one engagement lives together and offboarding is a single sweep. Tag profiles with the account manager responsible. Future-you, staring at 200 profiles at 11pm during an incident, will be grateful.

Team access without credential sharing

The old agency workflow — passwords in a spreadsheet, 2FA codes shouted across Slack — is both a security incident waiting to happen and a detection problem: five staff members logging into the same account from five different devices and home IPs is exactly the anomalous pattern platforms watch for.

The fix is to make the browser profile the unit of access instead of the password. In Dual Login, team members are granted permission to open specific profiles or profile groups. When a buyer opens the ACME – Meta profile, they inherit its fingerprint, its proxy, and its logged-in session. The platform sees the same familiar device it always sees, regardless of which human is driving. Nobody ever learns the password. Revoke the team member, and their access to every client evaporates in one action — with no password rotations and no re-triggered security checkpoints.

This also fixes the multi-machine problem. Sessions and fingerprints sync through the cloud, so a profile opened on the office workstation continues seamlessly on a buyer's laptop — same device identity, same cookies, no fresh-device challenge. If you've ever tried to move a logged-in session by hand you know how fragile that is; there's a full walkthrough in our guide to transferring browser profiles between computers.

Two-factor authentication, done sanely

2FA on every client account is non-negotiable — ad accounts with stored payment methods are prime hijack targets. The agency-friendly setup: use TOTP (authenticator-app codes) rather than SMS, store the TOTP secrets in your team password manager (Bitwarden, 1Password — both can generate the rotating codes), and keep recovery codes with the client, not with you. SMS-based 2FA tied to one employee's personal phone number is how agencies lock themselves out of their own clients' accounts every January when someone changes carriers.

The pleasant side effect of persistent isolated profiles is that you face 2FA challenges rarely. A stable device on a stable IP with a live session doesn't get re-challenged every morning.

Payment methods and billing hygiene

Short version: client's card in the client's account, wherever humanly possible. Agency-funded billing creates a shared payment instrument across accounts — a hard link in the association graph — and makes you the merchant of record for disputes that aren't yours. If you must run agency billing (some markets and some clients demand it), use distinct virtual cards per client from a provider built for it, keep the billing profile's company details matching the client entity, and document the arrangement in your contract. Never, ever recycle a card from a banned account onto a new one; payment instruments are among the strongest links platforms use to connect a new account to a dead one.

Onboarding a New Client Ad Account: The Checklist

Here's the sequence we'd recommend for every new engagement. It takes about an hour and prevents most of the disasters described above.

  1. Verify ownership. Confirm the client actually owns the ad account, Page/channel, pixel, and domain. If assets are missing, create them in the client's entity before doing anything else.
  2. Request partner access through the platform's official mechanism (Business Manager partner access, MCC link request, Business Center invitation) with the minimum roles your team needs.
  3. Create the client's profile group in Dual Login and a browser profile per platform, following your naming convention.
  4. Assign a proxy matching the client's market to each profile, and confirm the profile's timezone/locale/geo derived correctly.
  5. First login, gently. Open the profile, log in, complete 2FA, and then behave like a human: browse the account, check settings, look at past campaigns. Don't bulk-upload 40 campaigns in the first ten minutes on a new device.
  6. Capture the essentials into your docs: account IDs, billing thresholds, payment method owner, pixel IDs, who holds recovery codes.
  7. Grant team access to the profile group for the assigned buyer and account manager only.
  8. Set a hygiene reminder to review access quarterly — people change roles; permissions rot.

If you're spinning up several similar environments (say, three profiles for one client's three regional accounts), it's faster to configure one profile perfectly and duplicate it — our step-by-step on cloning a browser profile with cookies covers when that's safe and when each profile genuinely needs a distinct fingerprint.

Offboarding: The Part Everyone Skips

Engagements end. Do it cleanly:

  • The client removes your partner access at the platform level (or you unlink from your MCC). Because you structured ownership correctly, this is one click and nothing breaks.
  • Archive — don't immediately delete — the client's browser profiles. Thirty days is a reasonable retention window in case of billing disputes or a final report request; after that, delete them and their stored sessions.
  • Remove team assignments, hand recovery codes back to the client if you ever held them, and remove any agency payment method.
  • Export final reports before access ends. Obvious. Frequently forgotten.

An agency that offboards cleanly gets referred. An agency that holds a client's pixel hostage gets talked about in Slack groups. This industry is smaller than it looks.

When an Account Gets Flagged Anyway

Even perfect hygiene doesn't make you flag-proof — policy enforcement is automated, noisy, and sometimes simply wrong. When it happens:

Don't panic-login from everywhere. The instinct is for three people to immediately pile into the account from three devices to "check what happened." That's fresh anomalous-access fuel on a fire. One person, the usual profile, the usual IP.

Appeal through official channels, factually, once. Repeated frantic appeals slow reviews down. State what the account does, that access is structured through official partner mechanisms, and request specifics.

Quarantine, don't contaminate. Because the account lived in its own isolated profile with its own IP, the blast radius is one client. Keep it that way: don't touch the flagged account from any other profile, and don't move its payment method or assets anywhere.

Diagnose the real cause. Pull the timeline: new creative? new payment method? new team member logging in from home without the profile? A flag almost always follows a change. Find it, document it, feed it back into your onboarding checklist so the next client doesn't repeat it.

Comparing the Ways Agencies Actually Manage Access

Approach Isolation between clients Session persistence Team access Realistic ceiling Cost pattern
Shared logins in one browser None — one device graph for everyone Good Password spreadsheet (insecure) ~5 accounts before incidents Free, until the ban
Chrome profiles per client Cookies only; fingerprint & IP shared Good Per-machine, no sync ~10–15, association risk grows with each Free
VPS or spare laptop per client Excellent Good Painful (RDP juggling) ~10 before cost and ops overwhelm $10–40/client/month
Antidetect browser (Dual Login) Full — fingerprint, storage, process, IP per profile Excellent, synced across machines Built-in roles, no shared passwords Hundreds of profiles Flat, scales with profiles not clients

The VPS-per-client approach deserves a word because serious agencies genuinely used to do it — it works, it's just brutally expensive in money and sanity at scale. An antidetect browser gives you the same isolation guarantee as separate machines at a fraction of the cost; if you're budgeting the switch, our antidetect browser pricing comparison breaks down what the major tools actually cost at agency seat counts.

FAQ

Do I really need an antidetect browser if I already use Business Manager partner access?

Partner access solves ownership and permissions; it doesn't stop platforms from fingerprinting your device and linking every account you touch into one cluster. The two are complementary: partner access is the legitimate front door, browser isolation keeps one client's problems from becoming everyone's problems.

Is it against ad platform rules to manage client accounts this way?

Managing clients' accounts with their authorisation through official partner mechanisms is exactly what agency programs exist for. Antidetect browsers are a workspace-isolation tool; nothing in Meta's or Google's terms prohibits choosing your browser. What the platforms prohibit is circumventing enforcement — running new accounts for a banned advertiser, misrepresenting who you are. Tooling doesn't make prohibited activity permitted, and it doesn't make permitted activity prohibited.

Should every client profile have a proxy?

No. Local clients managed from a plausible local IP often don't need one. Use a dedicated static residential or ISP proxy when the client's market differs from your location, when you manage many accounts on one platform, or when an account has a history of reviews. Never share one proxy across multiple client profiles.

How do multiple team members work on the same client account safely?

Make the browser profile the shared unit, not the password. Team members open the client's Dual Login profile and inherit its session, fingerprint, and proxy — so the platform always sees the same familiar device, and nobody ever handles credentials. Revoking a person revokes everything at once.

What's the single biggest mistake agencies make with client ad accounts?

Creating or billing client accounts inside the agency's own entity. It links every client through shared ownership and payment instruments, makes offboarding adversarial, and means an agency-level restriction takes every client down simultaneously. Client owns, agency accesses — no exceptions.

Can I recover an ad account that was banned for being linked to another banned account?

Sometimes, via official appeal, if you can demonstrate the businesses are genuinely unrelated and access is properly structured. But association bans are the hardest to reverse precisely because the platform's graph evidence is invisible to you. Prevention — isolation from day one — is dramatically cheaper than the appeal.

The Takeaway

Managing client ad accounts as an agency comes down to two disciplines running in parallel. At the platform layer: clients own their assets, you take partner access through official channels, minimum permissions, clean offboarding. At the browser layer: one client, one isolated environment — its own fingerprint, its own persistent session, its own IP story — so no client ever shares fate with another.

Neither discipline is glamorous. Both are what let an agency go from 10 clients to 100 without the Monday-morning appeal ritual.

Dual Login was built for exactly this shape of work: isolated profiles with consistent native fingerprints, per-profile proxies with automatic timezone and locale matching, synced sessions across your team's machines, and role-based access so passwords never leave the vault. If your client roster has outgrown Chrome profiles and password spreadsheets, download Dual Login and set up your first client group — the free tier is enough to isolate your riskiest client today, which is usually the one that matters.

Run every account like a separate device

Dual Login gives each profile a real fingerprint, its own proxy and sealed storage — free plan, no card required.

More reading

Playbooks

Browser Profiles for Affiliate Marketers: 2026 Playbook

Browser Profiles for Affiliate Marketers: 2026 Playbook Browser profiles for affiliate marketers shown as separate isolated browser windows, each with its own fingerprint, cookies and proxy Every affiliate who has run more than one ad account has had the same morning. You open the ads manager, the account you spent three weeks warming is restricted, the appeal form gives you a text box and a shrug, and nothing you did yesterday explains it. That is the pa

Playbooks

How to Create Multiple Ad Accounts Without Getting Banned

How to Create Multiple Ad Accounts Without Getting Banned Every media buyer eventually hits the same wall. One ad account isn't enough — you're running offers for different clients, testing angles that might trip an over-cautious policy review, splitting budgets across geos, or simply protecting yourself against the random disable that takes down a profitable campaign at 2 a.m. So you create a second account. Then a third. And within a week all of them ar

Use cases

Antidetect Browser for Facebook Ads Agency: 2026 Playbook

Antidetect Browser for Facebook Ads Agency: 2026 Playbook Every Facebook ads agency has a version of the same story. A media buyer logs into a client's Business Manager on the same laptop they use for four other clients. Two weeks later one of those clients trips a policy flag — a rejected ad, a chargeback on a payment method, a compromised admin — and within days the other accounts start hitting the dreaded \"advertising access restricted\" screen. Nobod