What Actually Breaks When a Media Buying Team Works Remotely
A cloud browser for media buying agencies runs each client ad account inside its own isolated browser on a remote node, with a coherent device fingerprint and a matching residential exit IP. Your buyers log in from any laptop, hand profiles to teammates without sharing passwords, and stop leaving the same device hash on every account they touch.
📌 TL;DR Executive Summary
- Core Takeaway: Each client ad account lives in its own stored profile — fingerprint, cookies, timezone, exit IP — that opens already signed in from any device.
- Key Risk/Challenge: Platforms link accounts by device signals, not just IP. Incognito clears cookies but leaves the fingerprint identical, and in summer 2024 Google began emailing accounts where it had identified the actual device being used to access them.
- Recommended Solution: Isolated cloud profiles with built-in residential proxies, shared to paid teammates instead of passwords, plus Team-plan automation when you need to reconcile dozens of accounts.
A Day in the Workflow of a Distributed Media Buying Team
Buyers in three timezones, client accounts that never sleep, and a spreadsheet of logins somebody updates at midnight. Here is how the same day runs once the profiles live on cloud nodes instead of three separate laptops.
07:40 — Market checks before the client’s first coffee
Your EMEA buyer opens the browser on a train and clicks the client’s profile. It loads already signed into the ad account, with the German locale, Europe/Berlin clock and a Frankfurt exit IP, because timezone, locale and geolocation follow the proxy rather than the machine she happens to be holding. No fresh login prompt, and no code sent to a phone sitting in another country.
She checks pacing, pauses two ad groups that overspent overnight and shifts budget to the campaign that is converting. The platform sees the same fingerprint it saw yesterday — a browser that looks like the machine that has always managed this account. That consistency is why multi-session cloud browser setups for agencies have largely replaced the one-VM-per-client arrangement.
12:10 — Creative swaps, landing page tests, client walkthroughs
The US buyer takes over the same profile. He shares a live cloud session with the account manager so she can watch a bid change land during a client call, then keeps working in the profile after she closes her view. The session gets shared, not the password, so nobody rotates credentials afterwards and the account keeps seeing one continuous device instead of three people fighting over a login form.
18:30 — Handover, reporting, and the audit question
By evening the day’s changes sit inside the ad account’s own change history, and the profile that made them is still named after the client and its owning buyer. If a client asks who paused that campaign on Tuesday, you answer from those two records rather than from memory. It is also the hour you pull yesterday’s spend — by hand for one account, or through the local Automation API on the Team plan when fourteen accounts need reconciling before the weekly report.
Where Paid Media Teams Actually Get Burned
Every agency that scales past a handful of clients hits the same failure modes, and none of them are about bidding strategy. They are about how the accounts are accessed. A cloud browser for media buying agencies is worth the switch only if it closes the five gaps below.
1. Device fingerprints travel with the person, not the account
Ad platforms hash device signals — installed fonts, GPU strings, canvas rendering output, screen resolution — into a fingerprint that persists across sessions and IP addresses. If one buyer manages five client accounts from one laptop, that laptop is a shared signal across all five, even when every account resolves to a different proxy.
Tying a profile to a proxy changes the IP but not the machine; both have to move together before each account looks like a separate computer. If you want the underlying detail, device fingerprinting signals covers what actually gets hashed and how the values combine.
2. Password sharing breaks platform policy and your audit trail
Google Ads does not support password sharing at all. Access is user-based: you add a person’s Google account under Tools & Settings > Access and security and assign a role. The available roles are Admin, Standard, Read-only and Email-only, and every login stays tied to a named human rather than a shared credential.
For agency work, a Manager Account (MCC) is usually the better structure. It lets you manage multiple client accounts without being added as a direct user on each one, and the client keeps ownership and approves the link with your Manager Account ID. Neither model fixes device-level linking. They fix governance.
3. Google started identifying the actual device in summer 2024
In summer 2024, Google began emailing accounts where it had identified the actual device being used to access them. For teams cycling through many accounts from shared machines, the practical result was a traffic drop while access got sorted out. Treat device consistency as an operational metric you maintain on purpose, not something you get for free.
4. Proxies that contradict the rest of the persona
A US exit IP on a profile with a German locale and a Berlin clock is a contradiction a risk system can surface in a single request. Timezone, locale, geolocation and WebRTC should follow the exit IP automatically, which is how Send.win profiles behave. When you bring your own SOCKS5 instead, verify those four settings by hand before the first login.
5. Offboarding is where access reviews quietly fail
When a buyer resigns, you need a fast, honest answer to two questions: which client profiles could they open, and which logins live inside those profiles? If the answer is a spreadsheet of passwords, you are rotating credentials for the next three weeks.
Why Incognito, VPNs and Tab Switchers Fall Short
Most teams arrive at cloud profiles after trying the cheap options first. Each one solves a single slice of the problem and leaves the rest exposed.
| Approach | What it separates | What stays shared | Fit for agency work |
|---|---|---|---|
| Incognito / private window | Cookies and local storage for that session | Device fingerprint — two private tabs on one laptop share the same device hash | Not enough on its own |
| VPN or one rotating proxy | The IP address | Fonts, GPU, canvas output, resolution, timezone | Covers one axis |
| One laptop or VM per client | The whole machine, until it is the wrong machine | Handover time, hardware cost, no remote access | Workable for a handful of accounts |
| Session-switching extensions | Tabs, sometimes cookies | The underlying engine fingerprint shared by every profile in that browser | Gets brittle as headcount grows |
| Cloud browser profiles | Fingerprint, storage, locale, timezone and exit IP, per profile | Nothing inside the profile leaks into the next client’s | Built for distributed teams |
One caveat on shopping: many “best antidetect browser” roundups are published by the vendors themselves and rate competitors as high detection risk. There is no independent detection score you can trust, so judge a cloud browser for media buying agencies on mechanism — what it isolates, and whether you can export your data and leave. If you are weighing tab-level tools against full profiles, this breakdown of cloud browser vs extensions covers where each one breaks under a real client load.
Step-by-Step: Setting Up Send.win for a Media Buying Team
You can finish this in an afternoon. Work in this order, because steps 4 and 5 are what stop a new profile from triggering a security check on its first login.
- Pick your runtime. The cloud browser runs on Send.win’s EU and US nodes from any device with nothing to install, with a free preview of 10 minutes a day and unlimited cloud browsing time on Pro and Team. The Sendwin Browser desktop app is a local install for Windows, macOS and Linux when you want heavier local sessions. Many teams run client work in the cloud and keep the desktop app for their own accounts.
- Create one profile per client ad account — not per client. If a client has a Google Ads login and a separate Meta Business login, those are two profiles. Mixing them puts two unrelated identities behind one fingerprint.
- Assign a proxy per market. Every plan includes residential proxies (10 on the trial, 20 on Pro and Team, plus monthly bandwidth) and you can bring your own HTTP or SOCKS5. Match the exit city to the account’s market or billing country, not to where your buyer happens to sit.
- Run the pre-launch QA before the first login. Timezone matches the exit IP. Language and locale match the market. WebRTC reports the proxy address, not the local one. Geolocation is consistent with the city. Screen size and fonts look like a normal laptop for that market. No two profiles in your workspace share a fingerprint.
- Log in once and let it stick. Cloud sync keeps the login attached to the profile and follows you across devices on paid plans, so a buyer switching from the office desktop to a home laptop does not create a fresh device event.
- Share the profile, not the password. Sharing a profile with a paid teammate means it opens already signed in — no credential ever changes hands. Layer the platform’s own roles on top for Google Ads: Admin for whoever owns billing, Standard for buyers, Read-only for reporting.
- Adopt a naming convention on day one. CLIENT-MARKET-PLATFORM-OWNER. It sounds trivial until you have 90 profiles and need to find the three that belong to a client who just called.
- Write the offboarding procedure now. Seat removed, profile access revoked, passwords inside any profile that person could open rotated, shared list reviewed. Two lines in your onboarding doc saves a week later.
The sharing model is the change that alters daily habits fastest — sharing client profiles with paid teammates removes the credential handover ritual entirely, along with the Slack message asking for the new password.
Scaling Tips: From 10 Client Accounts to 500
The jump from a five-person shop to a forty-client agency is a bookkeeping problem more than a browser problem. Four things decide whether a cloud browser for media buying agencies stays cheap to run at 500 profiles instead of turning into a second job.
Match the plan to profile count, not headcount
Agencies often buy seats they do not need and run out of profiles they do. Count the distinct logins you manage, then check profile, concurrency and sharing limits.
| Your situation | Plan that fits | Why it holds |
|---|---|---|
| Testing the workflow with a few accounts | 30-day free trial | 10 isolated profiles, 10 residential proxies and 1 GB of bandwidth at $0 for 30 days, then it continues on Pro |
| Solo buyer or small team, 20–100 client accounts | Pro — $19/mo, or $6.99/mo billed annually | 150 profiles, 20 proxies, 5 GB/mo, cloud sync on 20 profiles, profile sharing with up to 20 paid members, 6 seats |
| Multi-market team with scripted reporting | Team — $49/mo, or $20.99/mo billed annually | 500 profiles, 20 GB/mo, sharing with up to 50 paid members, 16 seats, 9 concurrent cloud sessions, local Automation API |
Top-ups stay à la carte on Pro and Team: $6 per GB of proxy bandwidth and $0.05 per extra profile, with no plan change and a 7-day money-back guarantee if you get the sizing wrong.
Keep proxy bandwidth predictable
Bandwidth is the line item that surprises agencies, because ad platform interfaces are heavy. Business Manager screens, video creative previews and bulk image uploads inside a profile burn gigabytes quickly. Watch which profiles run heaviest, and buy GB in blocks before the end of the month rather than reactively when a report generation stalls at the wrong moment.
Automate the repetitive pulls over CDP
Send.win’s local Automation API is available on the Team plan and works with Selenium, Puppeteer and Playwright. The useful pattern is attaching to a profile that is already running on your machine rather than launching a fresh browser, so the script inherits the same fingerprint and the same signed-in session you use by hand. Playwright’s connect_over_cdp attaches to an existing Chromium browser over the DevTools Protocol, and the profile has to expose a remote debugging port for that endpoint to exist.
from playwright.sync_api import sync_playwright
# Copy this endpoint from the profile's automation settings in Sendwin Browser
CDP_URL = "http://127.0.0.1:PORT"
with sync_playwright() as p:
browser = p.chromium.connect_over_cdp(CDP_URL)
context = browser.contexts[0]
page = context.pages[0] if context.pages else context.new_page()
page.goto("https://ads.google.com/aw/overview")
page.wait_for_load_state("networkidle")
print(page.title())
browser.close()
Two things to know before you build on it. Playwright’s documentation notes that connect_over_cdp is lower fidelity than connect(), and if the browser was launched without Playwright’s curated arguments, some functionality can break. connect() works differently: it attaches to a Playwright browser server through a websocket endpoint from BrowserServer.wsEndpoint(), and the connecting and launching Playwright versions must match on major and minor numbers. Pick one approach and standardise, or your reporting script breaks on a library upgrade.
One hard rule: never expose a raw CDP endpoint to the open internet. Anyone who reaches it can drive the browser, read pages and execute JavaScript inside it. Keep the endpoint local, or use a hosted runtime that handles authentication and session isolation — the trade-offs are documented in the Playwright browser type reference.
Run a quarterly access review
Reconcile three lists: profiles, the paid teammates each one is shared with, and the client accounts inside them. Anything that fails the check gets revoked the same week. Confirm at the same time that the client still owns their own Google Ads account and that your MCC link is the only agency-level access they granted.
When a Cloud Browser Is the Wrong Tool
If you are a single-brand in-house team running three accounts, the platform’s own access model is enough. Google Ads roles plus a Manager Account will do more for governance than any browser, and you should start there.
If your actual need is bulk data extraction with no human in the loop, a script-first browser-as-a-service runtime may fit better than a managed profile you have to name and maintain. Cloud profiles earn their keep when account count, market count or headcount rises — that is where shared logins turn into real coordination cost.
Whichever route you take, keep an export path. Cloud desktops do get discontinued — Mighty Browser, once a well-known cloud desktop, is gone — so never store the only copy of a client’s session state somewhere you cannot leave.
And keep the account structure inside platform rules. Profile isolation keeps separate accounts genuinely separate and keeps your team’s access documented; it is not a licence to break a platform’s terms, and no tool can promise you an account will never be restricted.
🏆 Send.win Verdict
A cloud browser for media buying agencies lives or dies on two things: consistent device fingerprints and clean credential handovers. Send.win handles both with the same object — a profile carries its own fingerprint and its own logins, so a teammate opening a shared client profile never needs a password change and the platform keeps seeing one machine. The 30-day trial with 10 profiles and 10 residential proxies is enough to run a real pilot on live accounts before you commit, and the Team plan’s local Automation API keeps reporting scripts on the same profiles your buyers use by hand.
Try Send.win free today — run the desktop app or a cloud profile free for 30 days, $0 today, and see whether your client accounts stay quiet across a full week of handovers.
Frequently Asked Questions
Can a cloud browser run Meta Ads and Google Ads accounts without linking them?
It can keep them on separate fingerprints, separate cookie stores and separate exit IPs, which removes the device-level signals platforms use to connect accounts. That is a meaningful part of the problem, and it is not a guarantee. Bidding behaviour, payment methods, contact details and shared admin users are also linkage signals, so keep those distinct per client too.
Do I still need residential proxies if the browser already spoofs fingerprints?
Yes, because the two cover different signals. The fingerprint makes the machine look separate; the proxy makes the network path look separate. A profile with a spoofed fingerprint behind your office IP still shows up as coming from one place, and both have to line up with the account’s market.
How do I share a client ad account with a teammate without sending the password?
Two layers. Inside Send.win, share the profile with a paid teammate and it opens already signed in — no credential changes hands. On the platform side, follow the rules: Google Ads access is user-based, so add the teammate’s Google account with the right role, or manage the client through a Manager Account so you are never added as a direct user.
Is a cloud browser or a desktop antidetect browser better for a distributed team?
Cloud for client work, desktop for heavy local sessions. A cloud browser for media buying agencies is the better default when buyers move between office, home and travel, because the profile follows the person and cloud sync keeps logins attached to it. The desktop app is the better choice when you need a lot of local profiles running at once on your own hardware.
Which Google Ads role should an agency use for client accounts?
Standard for buyers who make changes, Read-only for reporting and analytics people, and Admin only for whoever genuinely needs to manage access and billing. Use a Manager Account when you handle many clients, because it keeps the client as the account owner and reduces the number of direct users you accumulate.
What fingerprint signals do ad platforms inspect beyond the IP?
Fonts, GPU and driver strings, canvas and WebGL rendering output, screen resolution, audio stack, timezone, language and the behaviour of media devices. They get hashed into a value that survives clearing cookies, which is why a private window on the same laptop is not a fresh identity.
What is the difference between Playwright connect() and connect_over_cdp()?
connect_over_cdp() attaches to a Chromium-based browser that is already running, through the DevTools Protocol, which is what you use to inherit an existing profile and its login. connect() attaches to a Playwright browser server over a websocket endpoint, gives higher fidelity, and requires the connecting and launching Playwright versions to match on major and minor numbers.
How do I audit which teammate touched which ad account last week?
Combine two records. The platform’s own change history inside the ad account shows what changed and when. Your profile naming and sharing structure shows who could open that profile and which buyer owned it. Review both together in a quarterly access check and revoke anything that no longer matches a live client or a current employee.
Run Cloud Browser For Media Buying Agencies in the Cloud With Send.win
Send.win’s cloud browser runs your isolated profiles on remote infrastructure — open a clean, fingerprint-isolated session from any device without installing anything:
- Instant cloud sessions – launch an isolated browser in seconds, no local install
- Isolated profiles – separate fingerprint, cookies, and storage per session
- Cloud sync & profile sharing – pick up the same profiles on the desktop app (Windows, macOS, Linux) or share them with your team
- Built-in residential proxies – with automatic timezone and locale matching
You can try it right now: the Send.win demo browser opens an isolated cloud session directly in this browser tab. The 30-day free trial needs no credit card, and paid plans start at $6.99/month billed annually — see pricing.