Proxies for Marketing Agencies: One Plan for Many Clients

Group your services by what they do on the network, not by department. Four patterns cover nearly everything an agency runs.

Two rows in that table surprise people. Client site crawls rarely need a proxy, because you have permission: ask the client's developer to allowlist a fixed IP for your crawler, and the crawl becomes faster and less noisy than routing it through a rotating pool. And client account management usually should not touch a proxy at all, which gets its own section below.

What remains is public data collection at volume, and that is where a single shared plan pays for itself. The existing guides on datacenter proxies for SEO rank tracking and how brands use proxies for ad verification cover those two jobs in technical depth. This post is about running them for many clients at once.

When an account manager logs in to a client's ad account or brand page with the client's own username and password, from an agency office in another country, through a proxy IP, the platform sees an unfamiliar device, an unfamiliar network and possibly an unfamiliar country for that account. That combination triggers security checks, and on ad accounts it can pause spend at the worst moment.

The major platforms solved this years ago with delegated access. Google Ads manager accounts, Meta's business portfolio partner access, LinkedIn page admin roles and TikTok's business centre all let an agency act on a client's assets from the agency's own identity. The client keeps ownership, access is revocable without a password change, and there is an audit trail of who did what. No proxy is involved, and none should be.

Keep proxies out of client account work unless there is a specific, documented reason, such as QA-ing how a campaign renders in a market where nobody on your team is located. Even then, look at the ad as a visitor on a proxy, and manage it from the platform through your normal partner access.

The one legitimate exception is accounts the agency itself owns and runs, for example a network of brand profiles you operate for testing or content distribution. Those need a stable residential or mobile IP per account, and that is a different product from the collection plan in this guide. The mobile proxies for social media automation guide explains how that setup works.

Agencies over-buy when they size by client count ("we have 20 clients, so we need a big plan") and under-buy when they size by monthly volume. Neither matches how proxy plans that bill by threads work. What you pay for is how many requests run at the same moment, and concurrent connections are set by your schedule far more than by your client list.

Work it out in three steps:

1. List each recurring job with its daily request count and a realistic seconds-per-request figure for the target (search pages and heavy landing pages are slower than JSON endpoints).
2. Give each job a time window. Rank checks at 02:00 to 05:00, ad checks during local business hours, price monitoring every four hours.
3. Add up the threads needed in the busiest overlapping window. Threads for one job are roughly: requests x seconds per request / seconds in the window.

The busiest window is your plan size, plus 30 to 50% headroom for retries and ad-hoc client requests. If one job dominates the peak, moving it by two hours is cheaper than a bigger plan.

One more constraint that is easy to miss: a plan's fair-usage speed ceiling (25 Mbps on SparkProxy Starter, up to 150 Mbps on Plus) is a ceiling for the plan, so treat it as shared by every client job running at that moment. Collection jobs that download images, video and fonts they never parse eat that ceiling for nothing. Block those resources in headless browsers and skip them in HTTP clients.

An illustrative agency, using assumed request timings rather than measured ones:

The busiest moment is a price-monitoring run that overlaps staff research and a review sweep: roughly 40 + 20 + 4 = 64 threads. With 50% headroom that is about 96, which fits a 100-thread plan such as SparkProxy Starter at $75 a month, with unlimited bandwidth.

Two lessons from the arithmetic. Rank tracking, the service clients think of first, barely registers at 8 threads, because it runs overnight in a long window. And the job that does set the plan size (price monitoring) could be halved by stretching each run from 20 to 40 minutes. Agencies that look at a monthly request total never see either point.

A flat plan has no per-client meter, which is great for predictability and awkward for billing. You need your own meter, and you already have one if every job logs what it did.

Log a client tag on every request

Whatever runs your jobs (a scheduler, a rank tracking tool's export, your own scripts), make sure each request or batch records a client ID, a job type and a timestamp. A plain CSV is enough.

Allocate by share of usage

import csv
from collections import Counter

PLAN_COST = 75.00          # monthly plan price, e.g. SparkProxy Starter
FIXED_SHARE = 0.20         # part of the bill split evenly, covers idle headroom

requests_by_client = Counter()
with open("proxy_jobs_2026-09.csv", newline="") as fh:
    for row in csv.DictReader(fh):          # columns: client, job, requests
        requests_by_client[row["client"]] += int(row["requests"])

total = sum(requests_by_client.values())
clients = len(requests_by_client)
for client, n in requests_by_client.most_common():
    fixed = PLAN_COST * FIXED_SHARE / clients
    usage = PLAN_COST * (1 - FIXED_SHARE) * n / total
    print(f"{client:20} {n:>9,} requests  ${fixed + usage:7.2f}")

The fixed share matters. Headroom exists because every client benefits from jobs running reliably, so the smallest client should carry some of it. Allocating purely by requests makes large clients subsidise the capacity that keeps small ones working.

Choose how it appears on the invoice

Whichever you pick, recompute the allocation quarterly. Clients add markets and keywords without thinking of the proxy cost, and a client that tripled its tracked markets should see that reflected before renewal, not after.

Separate credentials by tool or job family, not by person. When a rank tracking tool's settings page leaks a proxy password, you want to rotate one credential, not the agency's only one. If your provider supports multiple credentials or sub-users, a pattern like one credential per tool plus one for ad-hoc staff use is enough for most agencies. Our sub-user and credential rotation guide covers the mechanics.

Client offboarding is the step agencies forget. When a client leaves, remove their jobs from the scheduler, delete their tag from the allocation, and check that no client-side system (a dashboard they host, a script their developer copied) still holds an agency proxy credential. If one does, rotate it.

Whitelist slots are the other constraint. IP whitelisting lets a fixed server use the proxy without a password, and each plan includes a set number of slots: 5 on SparkProxy Starter, 10 on Core, 15 on Boost and 25 on Plus. Spend them on fixed servers you control. Cloud tools and laptops change IP, so use username and password there. IP whitelisting for proxies explains the trade-off.

SparkProxy's four published datacenter plans, all unlimited bandwidth and 30 days validity, mapped to agency size by peak concurrency rather than headcount:

The "typical fit" column is a rule of thumb, not a guarantee: one client with an aggressive monitoring schedule can need more threads than twenty clients with weekly checks. Size from your own busiest window.

For client work on JavaScript-heavy sites, SparkProxy's Scraping API is an alternative to running your own headless browsers: 1,000 free credits with no card, then plans from $49 for 250,000 credits, with 1 credit per plain fetch and 5 per rendered page. The same per-client tagging works there, and the API's tag parameter echoes a label back in each response, which makes the allocation log easier to build.

A single datacenter plan will not cover every agency need, and pretending otherwise leads to blocked jobs and awkward client calls.

• Google SERPs at high volume. Search engines are among the hardest targets for datacenter IPs. Many agencies are better served by a rank tracking tool or SERP data API for the Google portion and a proxy plan for everything else. Test on your own keyword set before you commit either way.
• Static residential or mobile IPs for owned social accounts. SparkProxy sells datacenter proxies only. Buy those per account from a specialist, and bill them to the client or programme they serve, since they do not share well.
• Competitor ad creative research. Before building a proxy job to collect competitor ads, check the platforms' own public libraries. Meta's Ad Library and the Google Ads Transparency Center show active ads by advertiser and region without any proxy. Use proxies for what those libraries do not show: the landing page a local visitor actually reaches, its prices, and its offers.
• City-level local SEO checks. Map pack and local results depend on location signals beyond the IP, so check what your local rank tracking tool supports before buying city-targeted proxies.

Put these in the statement of work, in plain language. They protect the agency more than the client.

1. Scope of collection. Public pages only, named competitor domains or categories, and no collection of personal data beyond what the service needs.
2. Target site terms. The agency follows robots directives and reasonable rate limits, and will stop collecting from a site if asked by its owner.
3. No fake engagement. Proxies are not used to create reviews, inflate engagement, or click competitor ads. Beyond being against platform rules, this is the fastest way to lose a proxy account.
4. Cost treatment. Which allocation method from the table above applies, and when it is reviewed.

If a client asks for something outside those lines, you have a document to point at. Are proxies legal for business use covers the broader legal picture.