Server side tracking services: your measurement data passes through your own server first.

We wrote this guide for site owners who see that the numbers in their ad and analytics dashboards don’t match their order or lead records, and who want to reduce the tag load on their pages and control which data goes to which platform. Every mechanism we describe about server-side tracking is based on Google’s documentation on Tag Manager server-side tagging and Cloud Run, the Google Ads Help Center, and Meta’s Conversions API (server-side event reporting) documentation. We verified product names and settings against the source as of September 2026. Our own setup observations are marked separately under the heading “Expert note”.

Our server-side tracking work runs in three layers: setting up the server container on your site’s domain and connecting the browser tag to it; setting up the GA4, Google Ads and Meta connections with a shared event ID; and carrying consent choices and data minimization rules over to the server. We cover the web container, dataLayer and event plan side on our Google Tag Manager page; this page goes into the server container in depth.

What is server-side tracking, and how is it different from a tag in the browser?

Server-side tracking is a measurement architecture in which measurement events are sent not directly from the visitor’s browser to ad and analytics platforms, but first to a tagging server under your control. In Google’s documentation this setup is called server-side tagging: the server container doesn’t run in the visitor’s browser or phone, but on a server you control.¹ On the server side, data stays on a server only you can access until you choose to send it somewhere else; you decide the shape of the data and where it’s routed.¹

A server container doesn’t fully replace the tag on the page. The Google tag in the browser still captures the event on the page; it just uses your server’s address as its destination.¹¹

How does a request become an event in the server container?

Clients receive requests arriving at the server container and turn them into events; these events go through the same trigger, variable and tag model as in the web container, and the tags that fire send the event data to their destinations.¹ Clients run in priority order; the first client that can handle a request claims it, and later clients don’t run for that request.¹ The server container comes with Google Analytics and Measurement Protocol clients built in; on the site, the Google tag sends events to the server address with the server_container_url setting.¹

In this model, a single browser request feeds several destinations. Meta’s Conversions API tag converts the event model the GA4 client receives on the /g/collect path into Meta’s event schema and sends it to graph.facebook.com.⁸ The same event goes to the GA4 tag through one trigger, and to the Google Ads conversion tag through another.

Why should the tagging server run on your site’s domain?

When the tagging server runs on the same domain as your site, it gains a first-party context and can benefit from more durable cookies written by the server.² When the server is first set up, it runs on the default address the cloud provider gives it; this address delivers data to the container but is in a third-party context.² Google compares the three options like this:²

Google presents the same-origin option as the recommended practice;² it also recommends setting up the server container on a first-party domain and turning on production mode before sending production traffic.¹ We make the choice based on the site’s hosting and CDN setup, and keep the domain and DNS records in your account.

Where is the tagging server hosted, and what does its cost depend on?

The tagging server runs in your own Google Cloud project or another environment you choose;¹ on Cloud Run, the cost depends on the resources traffic uses and the number of instances kept running.⁴ The Cloud Run service can be set up automatically from Tag Manager or manually from Google Cloud.³ A Cloud Run setup opens two services: a preview server that provides the container’s preview feature, and a tagging server that handles live traffic.³ Google recommends running at least two instances to reduce the risk of data loss in a server outage.³ The same document expects a setup scaling between two and ten servers to handle 35 to 350 requests per second; performance varies with the number of tags and the work those tags do.³

How are GA4, Google Ads and enhanced conversions moved to the server?

Events are sent from the web container to the server address, and in the server container the GA4 client, the Conversion Linker and the Google Ads Conversion Tracking tag are set up; with these parts, Google Ads conversion tracking moves to the server.⁵ The client and tag needed for GA4 come built into the server container.¹ When the server address is added to the Google tag in the web container, all traffic is routed to the server container; so that data keeps flowing to GA4, a GA4 tag that fires on all events is set up on the server.⁸ According to Google’s documentation, moving conversion tags to the server reduces the code on the page and helps page load speed.⁵ We set things up in this order:

1. Conversion Linker: added to the server container so Google Ads can pass data to Tag Manager; Google presents firing it on All pages as the best option in most cases.⁵
2. Key event: the purchase or lead is defined as a key event in GA4 and sent with the GA4 event tag in the web container.⁵
3. Conversion tag: fires in the server container on the same event name; the transaction ID, conversion value and currency are read automatically from the ecommerce fields.⁵
4. Value: if needed, the conversion value is read on the server from a separate database, such as price or profit data; the server container encrypts the revenue value in the response sent back to the browser.⁵

Enhanced conversions can improve the accuracy of conversion measurement by hashing first-party customer data obtained at the moment of conversion, such as email, phone, name and address, one-way with SHA256 and sending it to Google.⁶ Enhanced conversions for web improve measurement of online conversions on the site, while enhanced conversions for leads improve measurement of sales that come from a web form and close offline later.⁶ If the party sending the data does the hashing, the data is normalized first: leading and trailing spaces are removed, text is lowercased, and the phone number is put into E.164 format.⁶

There are three ways to collect customer data in Tag Manager: automatic collection, manual configuration with CSS selectors or JavaScript variables, and configuration with code. Google recommends the code method for accuracy because it sends consistently formatted data, and requires the data to be added to the event tag with a parameter called user_data.⁵ In the server container, enhanced conversions work when consent is given;¹¹ when consent for user data for advertising (ad_user_data) is denied, hashed first-party data isn’t collected.¹⁰

How is the Meta Conversions API connected to the server container?

The Meta Conversions API is connected to the server container with a tag template that Meta writes and maintains.⁸ According to Meta’s documentation, the GA4 configuration in the web container takes the tagging server’s address through the “Send to server container” option or the transport_url field, the GA4 client on the server receives the event, and the Conversions API tag converts the event into Meta’s schema.⁸ The mapping includes the event ID (event_id), Meta’s browser ID fbp, the click ID fbc, external_id, and user fields such as email, phone and address; for user fields to pass to the server, the first_party_collection field is set to true.⁸ If the tagging server runs on a first-party domain, fbp and fbc are sent automatically; on the default domain, variables that read the _fbp and _fbc cookies are added.⁸

Meta recommends setting up the Conversions API together with the Meta Pixel for optimal ad performance.⁹ On ecommerce platforms such as Shopify, WooCommerce, Wix or BigCommerce, the Conversions API can also be set up through Meta’s partner integration.¹³ We explain the effect of Pixel and server events on the ad side on our Meta Ads consulting page. On the server side, parameter mapping and where the deduplication key will be generated are fixed in writing in the event plan before setup.

How are browser and server events deduplicated?

An event sent from the browser and from the server counts as one event when it carries the same name and the same event ID in both channels. On Meta, the Pixel’s eventID field must match the Conversions API’s event_id field, and the event name in the Pixel must match the event_name field.⁹ Deduplication is done only for events that arrive within 48 hours of the first event received with a given event_id; if the two events’ content isn’t meaningfully different, Meta generally prefers the one that arrived first.⁹

In Google Ads, if two conversions arrive for the same conversion action with the same transaction ID, the second is recognized as a duplicate and isn’t counted.⁷ Sending the ID as a fixed value backfires: because Google Ads can process only the first instance of a transaction ID, conversions are seriously undercounted.⁷

Does server-side tracking remove the need for consent?

No; server-side tracking doesn’t remove the obligation to get the visitor’s consent and respect their choice; it only carries that choice to the server. According to Google’s Consent Mode documentation, obtaining user consent on your website or app, and for data you upload to Google, is the site’s responsibility.¹⁰ Consent Mode doesn’t provide a consent banner on its own; it works together with your consent management platform.¹¹

The flow on the server side is this: the consent banner passes the visitor’s choice to the Google tag, the Google tag sends that choice to the server container by adding consent parameters to the HTTP request, and the Google product tags on the server adjust the amount and type of data they send according to that choice.¹¹ That’s why Consent Mode is set up only in the web container.¹¹ When ad storage consent (ad_storage) is denied, the server-side Google Ads conversion tag doesn’t write or read cookies.¹¹

What data is kept on the server, and what is filtered out?

On the server, only the fields platforms need for measurement are exposed to tags; the rest is filtered out before it reaches the platforms. The Transformations feature in the server container lets you include, exclude or change event parameters produced by the client before they’re exposed to tags.¹² There are three types of rule:¹²

• Allow parameters: only parameters written out explicitly are exposed to tags; the rest are dropped.
• Augment event: a parameter’s value is changed, or a new parameter is added to the event.
• Exclude parameters: specific parameters are removed from tags.

Rules can apply to all tags, to specific tag types or to individually selected tags, and can be tied to a condition.¹² An allow-list rule deletes every parameter not written out, including values Google tags need; the documentation asks you to review which parameters tags use before creating the rule.¹²

We set these rules up on the data minimization principle: which tag user fields, the IP address and browser information are passed to is written separately. We match decisions such as the privacy notice under KVKK (Türkiye’s data protection law), cookie preferences and the region the server runs in to the setup, and document them for your legal counsel’s approval.

When are server-side tracking services needed, and how do the first 30 days work?

Server-side tracking is needed on sites whose ad budget relies on conversion signals, that send the same event to several ad platforms, or that want to reduce the tag load on their pages; the first 30 days are split into audit, architecture, setup and verification weeks. On a site with a single analytics tag and no advertising, the maintenance and infrastructure cost of an extra server can outweigh the benefit; we say so plainly in the first meeting.

1. Week 1 · Audit: existing tags and the consent banner are reviewed; the gap between platform numbers and order or lead records is worked out.
2. Week 2 · Architecture and event plan: the domain option, hosting region, destination platforms, deduplication keys and fields to filter are decided in writing.
3. Week 3 · Setup: the Google Cloud project is opened in your name, the tagging and preview servers are set up and connected to the domain; the GA4, Google Ads and Conversions API tags go live.
4. Week 4 · Verification: events are traced end to end in preview mode, deduplication and consent states are tested, and cost and logging settings are checked.

Server-side GTM or a platform’s built-in Conversions API integration?

A server container isn’t the only way to send measurement from a server; many e-commerce platforms offer a ready-made Meta Conversions API connection. The choice depends on how many platforms receive data and how much control over fields you need:

Running two server connections at once can count the same purchase twice, so we decide in writing which one stays before migrating.

How to choose a server-side tracking specialist

1. Who owns the infrastructure: the Google Cloud project, its billing and the domain records are in your company’s name; the server doesn’t run in the partner’s account.
2. First-party domain: whether the tagging server runs on your site’s domain or the default cloud address is decided in writing.
3. Deduplication plan: where the event ID is generated and how browser and server events are matched is explained up front.
4. Consent and privacy: the partner can show what each tag sends when consent is denied; a promise to “get around cookie consent or ad blockers” is a red flag, under GDPR-style rules and Türkiye’s data protection law (KVKK) alike.
5. Cost monitoring: instance count, region and request logging settings are explained, and the infrastructure bill is checked regularly.

What drives server-side tracking setup pricing?

There are two separate items: the service fee for the team doing the work and the infrastructure fee paid to Google Cloud. The service fee depends on:

We work out the scope together in the first meeting and then send a written proposal; the Google Cloud infrastructure fee is separate from our fee and paid directly from your own cloud account.

Server-side tracking pricing: estimated ranges

Estimated range, excluding VAT; rows marked “/ month” are monthly, the others are one-off. Scope is confirmed in a written proposal after the first meeting. As of October 2026. Hosting costs for the tagging server are not included in the service fee.

If you’d like to read your current measurement setup together, pick a meeting day that suits you below; in the first meeting we also say plainly whether you need server-side tracking at all.