What each setup actually does, without the vendor framing
Client-side is what you already have. Every vendor ships a script into the visitor's browser; each one opens its own connection to its own hostname, writes its own cookies with JavaScript, and reports what it can see. Your page is the loading dock and every vendor drives their own van into it.
Server-side keeps collection in the browser and moves distribution. The browser sends one request to a tagging server you run — usually a container on a subdomain of your own site — and that container decides what to forward, to whom, with which fields removed. Google's documentation describes it as instrumenting your tags to measure activity wherever it happens; the shift that matters commercially is that the request now leaves from your infrastructure rather than the visitor's.
That single change is the entire product. Recovery, privacy control and page speed all follow from the request having a different origin.
| Client-side | Server-side | |
|---|---|---|
| Where the tag runs | In the visitor's browser, once per vendor | In a container you host and pay for |
| What the browser loads | One script per vendor, each on its own domain | One request to a hostname you own |
| Who writes the cookie | JavaScript, in the browser | The server, in an HTTP response header |
| Blocked by ad blockers and DNS filters | Often, matched on hostname | Less often, because the hostname is yours |
| Who sees the full payload first | The vendor | You, then whatever you choose to forward |
| Cost when nothing is happening | Nothing | The instances are still running and still billing |
| Who maintains it in month seven | Whoever owns the tag container | Whoever owns the tag container and the server |
What server-side genuinely recovers
This part is real, and worth separating from the part that isn't. Four things genuinely come back.
- Requests blocked at the hostname. A blocker matching a well-known analytics or ads domain doesn't match
data.yourbrand.in. Be honest about the arms race, though: list maintainers add first-party tagging endpoints when they find them, so this recovery erodes. - Cookie lifetime, on browsers other than Safari. A cookie written by your own server in an HTTP response header escapes the cap browsers put on JavaScript-written cookies. On Chrome and Firefox that genuinely extends how long a returning visitor stays recognised.
- Conversions the browser never got to report. A payment confirmed by your gateway's webhook can be sent from your backend even if the customer closed the tab on the redirect. With UPI redirects and cash-on-delivery confirmations, this is the most valuable item on the list and the one least often mentioned in the pitch.
- Control over what leaves. You can strip fields a vendor was never meant to receive. Under the DPDP Act that is a governance argument rather than a marketing one, and it is a legitimate reason to build at any volume.
What it does not recover, however it is sold
Every item below gets quietly folded into the recovery estimate in a proposal. None of them is a transport problem, so none of them is fixed by changing where the request comes from.
- Declined consent. Consent mode's denied state is a permission, not a route. Moving the request to your own server doesn't create agreement you weren't given, and firing regardless is a compliance decision dressed as a data fix.
- Safari. Apple's ITP caps the expiry of any cookies set in the HTTP response to 7 days when it detects a CNAME-cloaked third-party request — the same cap it applies to cookies created through JavaScript. A subdomain CNAME'd to a vendor's host buys the appearance of a first-party cookie, not the lifetime.
- Enquiries that never happen in a browser. Calls, WhatsApp, walk-ins, marketplace leads. Tracking WhatsApp and phone leads is the cheaper problem and usually the bigger one.
- A form that never collected the source. If your enquiry form posts a name, a number and a message, the evidence was destroyed before any tag was involved — how to attribute revenue to SEO works through the four records that have to join.
- Analytics matching your CRM. They count different objects in different systems on different clocks. A server-side build narrows one gap out of four.
- Bot traffic. This one can get worse: some of the browser signals filtering depends on are exactly what you moved out of the request path, so a new server-side property often needs bot filtering rebuilt.
What it costs to build, run and keep alive
Two of these five lines appear in most quotes. The other three arrive later, which is why this gets its reputation as a mystery line item.
| Line | What it costs | Who carries it after launch |
|---|---|---|
| The tagging server | Google's Cloud Run guide prices each server at about $45 a month and recommends a minimum of two — call it ₹7,500–₹9,000 a month for the pair, depending on the rupee. | You. It bills whether or not anyone visits. |
| The preview server | A separate instance, needed before you can debug anything at all. | You. |
| The build | In our scoping, 20–40 hours for one destination and more once Google Ads and Meta are both in scope. At the ₹1,500–₹8,000 an hour Indian agencies charge, that is a range wide enough that you should ask for the hour count, not the price. | The agency, once. |
| Per-destination work | Every vendor is its own configuration, field mapping and deduplication logic. Three destinations is not one build with three checkboxes. | The agency, then you. |
| Keeping it alive | Container image updates, vendor API changes, a re-test after every site release. | Nobody, usually. This is where these builds die. |
The conversion volume below which it does not pay
Start from what the money buys. Server-side gets you more recorded conversions, not more conversions. That extra record pays in exactly two ways: it gives the ad platforms more signal to optimise against, and it makes your own percentages steadier. Both improve with volume, and neither does anything at low volume.
Then the arithmetic, which anyone can run before a sales call. Infrastructure at roughly ₹8,000 a month plus a ₹1,00,000 build amortised over two years is about ₹12,000 a month. If that recovers 10% more attributed conversions on a business doing 100 a month, you have bought ten extra rows in a report — rows that now have to change a decision worth more than ₹12,000, every month, for two years. Google expects two to ten servers to handle 35–350 requests a second, so even the minimum configuration is a pipe several orders of magnitude wider than that business will ever fill, and the pipe bills either way.
So, our position, stated as a threshold rather than a philosophy: below roughly 500 conversions a month, or under about ₹5 lakh a month of paid media, we won't quote for this. The same money spent on the form, the consent configuration and the CRM join changes the number instead of the record of it.
- Above 500 conversions a month with real paid spend — the extra signal reaches the platforms' optimisation and your percentages stop wobbling. This is the honest case.
- iOS-heavy audiences with a long consideration period — the cookie-lifetime argument bites hardest here. Check what share of your traffic is Safari before assuming it applies to you.
- Webhook-confirmed purchases — UPI redirects, gateway callbacks, cash on delivery. This earns its keep well below 500 a month, because it recovers conversions the browser genuinely never saw rather than ones it mislabelled.
- Anything else, quoted as a fix for falling conversions — treat as an upsell until someone shows you which loss on this page it addresses.
The cheaper things to exhaust first
Every one of these is smaller, faster and more likely to be your actual problem. Work down the list; if you're still short of data at the end of it, the server-side conversation becomes a reasonable one.
- Hidden first-touch fields on every form. Landing page, referrer, date and click ID, written into write-once CRM fields. Two days of developer time, no recurring cost, and it fixes a break no tagging architecture can reach.
- Events on your
tel:andwa.melinks. On most Indian sites the majority of real enquiries leave the browser entirely, and this is the only instrumentation that sees them go. - Consent configured properly rather than fired regardless. Notice, then choice, then tags — and know that modelled recovery has a volume floor most Indian properties never reach.
- Offline conversion import from your CRM. Upload closed deals back to the ad platforms using the click IDs you stored at form submit. It delivers much of the signal benefit server-side is sold on, with no container and no monthly bill.
- Bot and internal traffic filtering. Half the conversion gaps we're asked to investigate turn out to be a counting problem in the other direction.
- Ask the customer. One optional free-text question at intake covers every channel your tags can't see, for the price of a form field — the full argument is in self-reported attribution versus analytics.
The verdict, by question
Asking whether server-side recovers conversions you're losing — partly. It recovers requests blocked at the hostname, cookie lifetime outside Safari, and purchases the browser never got to report. It recovers nothing lost to declined consent, nothing that happened on a phone call, and nothing your form failed to capture.
Asking whether it's worth it at your volume — below roughly 500 conversions a month, no, and the fixed monthly bill is the reason. Above it, with real paid spend or webhook-confirmed purchases, yes, and the case is short enough to write in two sentences.
Asking which to run — both. Server-side is a distribution layer sitting behind client-side collection, and the vendors' own documentation assumes you send from both. Anyone describing it as a switch you flip has told you something useful about the proposal.