“Server-side tracking” is one of the most pitched upgrades in analytics right now. Agencies sell it as the fix for missing conversions, the answer to “cookie deprecation” and a way to beat ad blockers. Some of that is true, some of it is outdated and some of it is risky.

In this guide I explain what server-side tagging is, what it does and does not fix, what it costs to run and when a Nepali business actually needs it. I also give a phased plan and the checks I use to validate a setup.

About the author: I am Arjan KC, a digital marketing expert in Kathmandu and co-founder of Gurkha Technology. I plan and run analytics, tracking and conversion work alongside search, paid, social, content and web projects for clients, and I teach measurement in my university courses. Results from client work are published on our case studies page.

Many sales decks still say Chrome is about to remove third-party cookies. That plan is off.

Diagram of website events flowing from a browser to a first-party tagging server and then on to Google Analytics, Google Ads and Meta
  • In July 2024, Google said that instead of deprecating third-party cookies it would introduce a user-choice experience in Chrome (Privacy Sandbox blog).
  • In April 2025, Google said it would maintain its current approach to third-party cookie choice and “will not be rolling out a new standalone prompt for third-party cookies” (Privacy Sandbox blog).
  • Google later announced it was retiring several Privacy Sandbox technologies, including the Attribution Reporting API and Topics, citing low adoption (Privacy Sandbox blog).

So “cookie deprecation” is not a reason to move to server-side tagging. There are better reasons.

What actually limits your measurement

Safari and tracking prevention

Apple’s WebKit, the engine behind Safari, blocks all third-party cookies by default. It also deletes cookies created in JavaScript after 7 days without user interaction with the site, and caps them at 24 hours when the visitor lands from a link carrying a click ID (WebKit). Analytics and ad tags set their cookies with JavaScript, so a returning Safari visitor can look like a new user.

Ad blockers and privacy tools

Some browser extensions stop analytics and ad scripts from loading. How common they are varies by audience, and I have not seen reliable data for Nepal, so treat any agency claim of a specific “recovered” percentage with caution.

Where you use a consent banner, visitors who decline should not be tracked in the same way. Google’s Consent Mode adjusts tag behaviour based on those choices (Google).

Page speed

Every pixel and analytics library adds JavaScript and network requests. On mid-range Android phones on mobile data, which is how many Nepali customers browse, that weight matters.

Client-side versus server-side, explained simply

With standard client-side tagging, the visitor’s browser loads a Tag Manager container and sends separate requests to GA4, Google Ads, Meta and any other tool you use.

With server-side tagging, the browser sends one stream of events to a tagging server you control. That server then sends the data on to each vendor. Google describes the server as running in your own Google Cloud project or another environment you choose, where “only you have access to the data in the server until you choose to send it elsewhere” (Google).

Google lists three main reasons to use it: better privacy controls, better website or app performance and better data quality (Google). Specifically, Google says it can reduce third-party code in the browser, let you remove data such as IP addresses before it reaches vendors, and make cookies more secure and durable because your own domain sets them (Google).

A server container does not replace your web container. Google’s advice is to keep tags that rely on browser activity in the web container and move the rest to the server (Google). If you are new to the concept, my dictionary entry on server-side tracking is a shorter primer.

How a server-side Tag Manager container works

A server container uses the same tags, triggers and variables as a web container, plus a new piece called a client. A client receives incoming requests, turns them into events and passes them to the container. Server containers come with two clients included, Google Analytics and Measurement Protocol, and a Google Analytics tag ready to use (Google).

On the website side, you point the Google tag at your server container URL instead of sending data straight to Google (Google).

Hosting: where the server runs and what it costs

Google documents two routes:

  1. Cloud Run (Google Cloud): provisioned automatically from Tag Manager or manually in Google Cloud. You need a Google Cloud account and a billing account (Google).
  2. Manual setup elsewhere: the tagging server is a Node.js server in a Docker image, so you can run it in other environments. You need one preview server and a cluster of tagging servers. Google warns that whoever owns the server environment may have access to your data, so read that provider’s terms (Google).

Tag Manager is free, but hosting is a running cost. Google’s Cloud Run guide says each server in its configuration “costs approximately $45 /month (USD)” and recommends a minimum of two instances to reduce the risk of data loss. It also warns that request logging at high volumes, such as more than a million requests a month, can add significant logging charges, and suggests a billing alert (Google). Use the Google Cloud Pricing Calculator linked from that guide for your own estimate.

For a Nepali business, that cost is paid in US dollars on an international card, so check your card’s foreign currency limits before you start. Compare it with your monthly ad spend; my Nepal digital marketing benchmark report gives typical advertiser cost ranges for context.

Use a first-party domain

When a tagging server is first created, it sits on the cloud provider’s domain. Google says that on the default domain the server runs in a third-party context and can only set JavaScript cookies. To get the security and durability benefits of server-set cookies, the tagging server and website must share a domain, either the same origin (for example example.com/metrics, Google’s stated best practice) or a subdomain (for example metrics.example.com) (Google).

The way you map the domain matters for Safari. WebKit caps cookies at 7 days when a first-party subdomain resolves through a CNAME or IP address belonging to a third party (WebKit). Test the setup in Safari rather than assuming a subdomain is enough.

Measurement Protocol: events from your own server

The GA4 Measurement Protocol lets you send events directly to Google Analytics over HTTP, for example offline conversions or interactions that happen on your server. Google is clear that it is meant to “augment automatic collection through gtag, Tag Manager, and Google Analytics for Firebase, not to replace it,” and that sending events only through the protocol may give partial reporting (Google). Google now recommends the Data Manager API for new server-to-server integrations, while confirming the Measurement Protocol will remain operational.

Nepali examples where this helps:

  • A payment confirmed on your server after an eSewa or Khalti checkout, even if the customer closes the browser before the thank-you page loads.
  • A cash-on-delivery order marked “delivered” in your back office.
  • A WhatsApp lead that closes days later in your CRM. My post on UTM naming and offline conversions for WhatsApp and COD covers the tracking logic.
  • Meta Conversions API: Meta describes it as a connection between an advertiser’s server, website platform, app or CRM and Meta’s systems for ad optimisation and measurement (Meta for Developers). It is usually run alongside the Meta Pixel with deduplication. See my Meta Conversions API setup guide.
  • Google Ads enhanced conversions: these supplement your conversion tags with first-party data such as email addresses, hashed with SHA-256 before being sent to Google. Enhanced conversions for leads also works with imported offline lead conversions (Google Ads Help). See my enhanced conversions setup guide.

Consent Mode includes the consent types ad_user_data and ad_personalization alongside ad_storage and analytics_storage (Google). Google’s server-side guide uses the web container to collect consent and the server container to process it: the Google tag adds consent parameters to its requests, and Google product tags in the server adjust what they send. Server containers support both basic and advanced consent mode (Google). Set this up before you move tags. My Consent Mode v2 setup guide walks through it.

A note on Nepal’s privacy law

Nepal’s Privacy Act, 2075 (2018), often called the Individual Privacy Act, says that consent must be obtained when collecting a person’s personal data, and that data a public body or company collects with consent should be used only for the purpose it was collected for (Nepal Law Commission). I am not a lawyer, and you should take legal advice for your situation, but the direction is clear: server-side tagging is a tool for controlling data responsibly, not for getting around a visitor’s choice.

When a Nepali business needs it, and when it does not

Consider server-side tagging if you are:

  • An e-commerce business with meaningful ad spend across Google and Meta, where small gaps in purchase data change bidding decisions.
  • A bank, insurer or large enterprise that needs tight control over what data leaves your site.
  • An app or multi-platform business that wants one place to process events from web, app and back-office systems.
  • Running many vendor tags that slow your site down.

Standard GA4 and Tag Manager is enough if you are:

  • A clinic, school, restaurant or local service business whose leads mainly come by phone and WhatsApp.
  • Still unsure which events count as key events, or seeing duplicate tags. Fix those first; my post on duplicate GTM and double-firing pixels is a good start.
  • Unable to budget for hosting and someone to maintain it.

A phased implementation plan

  1. Audit the web setup. Confirm GA4 key events, ad conversions and consent work in a normal Google Tag Manager web container. Remove duplicates.
  2. Settle ownership. The business should own the Google Cloud project, billing account, GA4 property and both containers. See who should own GA4 and Tag Manager.
  3. Provision the server. Create the server container and deploy on Cloud Run or your chosen environment. Set a billing alert.
  4. Map a first-party domain. Use the same origin or a subdomain, following Google’s custom domain guide.
  5. Route GA4 first. Send GA4 through the server container, run both in preview and compare event counts.
  6. Add ad platforms. Add Google Ads conversion tracking with the Conversion Linker tag, then Meta Conversions API with deduplication.
  7. Add back-office events. Use the Measurement Protocol for payments, deliveries and CRM outcomes.
  8. Trim the browser. Remove client-side vendor tags that the server now handles; this is where the speed benefit comes from.

QA and validation

  • Server health: append /healthy to your server container URL; a working server returns ok (Google).
  • Tag Manager preview: use Preview in both web and server containers and check that each request is claimed by the right client and fires the expected tags.
  • GA4 DebugView: enable debug mode through Tag Assistant and watch events arrive. Google notes that events will not appear in DebugView if consent mode is active and the user has not granted analytics consent (Google Analytics Help).
  • Compare numbers: compare purchases or leads in GA4, Google Ads, Meta and your own order or CRM records for at least a few weeks.
  • Test in Safari: check which cookies are set and how long they last.

Common mistakes

  • Proxy only. Routing the same browser tags through a server without removing anything leaves the page as heavy as before. Google’s speed benefit depends on the browser sending fewer requests (Google).
  • Staying on the default domain, which loses the server-set cookie benefits.
  • Double counting because both the browser and server send the same conversion without deduplication.
  • No billing alert, then a surprise logging bill.
  • Never updating the tagging server. Google recommends updating at least for each major version (Google).
  • An agency-owned cloud project, which turns your tracking into lock-in.
  • Ignoring consent on the assumption that server-side data is invisible.

Server-side tagging is a solid upgrade for businesses that already measure well and need more control. For most, the bigger win is getting conversion tracking and Google Analytics right first, then adding a server once the numbers justify the cost.

Sources