# Server-Side Tracking Explained: How to Set It Up | Crank

Source: https://wearecrank.com/measurement/tracking/server-side-tracking

Server-side tracking explained: why client-side tags fail, how server-side fixes broken attribution, and what a reliable implementation actually looks like.

---

[![Crank - Providing your levers for growth](/images/crank-logo-full.png?dpl=dpl_G2hPQ8SoVn1uS7YaWhbeKwHazHBo)![](/images/crank-icon.png?dpl=dpl_G2hPQ8SoVn1uS7YaWhbeKwHazHBo)](/)

* [Crank OS](/crank-os)

  * [Overview](/crank-os)
  * [How it works](/crank-os/how-it-works)
  * [The four layers](/crank-os#layers)
  * [Pricing](/crank-os/pricing)
  * [Compare](/crank-os/compare)
  * [Insights](/insights)
  * [Live demo](/crank-os/live-demo)
  * [Partners](/crank-os/partners)  
What it does

  * [Tracking](/crank-os/tracking)
  * [Dashboards](/crank-os/dashboards)
  * [Daily alerts](/crank-os/daily-alerts)
  * [Ad production](/crank-os/ad-production)
  * [Campaign builds](/crank-os/campaign-builds)  
Built for

  * [Online shops](/crank-os/ecommerce)
  * [B2B teams](/crank-os/b2b)  
Free

  * [Free scan](/crank-os/free-scan)
  * [Free companies report](/crank-os/free-companies-report)
* Services

  * [B2B marketing](/b2b-marketing)
  * [B2C ecommerce](/b2c-ecommerce)
  * [Paid media](/paid-media)
  * [Fractional CMO](/fractional-cmo)
* [Insights](/insights)

  * [All insights](/insights)
  * [Ecommerce growth strategies](/insights/ecommerce-growth-strategies)
  * [B2B marketing](/insights/b2b-marketing)
  * [Beauty marketing](/insights/beauty)
  * [Enterprise software marketing](/insights/enterprise-software)
  * [Paid media measurement](/measurement)
  * [Digital marketing glossary](/digital-marketing-glossary-for-senior-leaders)
* [Case studies](/case-studies)
* [About](/about)
* [Contact](/contact)

[Book a live demo](/contact?enquiry=live-demo)[Chat now](https://wa.me/447457416922?text=Help%20my%20business)

Tracking Guide

# Server-Side Tracking  
**What It Is, Why It Matters, and How to Implement It.**

Browser-based tracking is breaking down. Server-side tracking restores reliable measurement, cleaner attribution, and better bidding signals — before you scale spend on a broken foundation.

[Book a Strategy Call ](https://wa.me/447457416922?text=Hi%2C%20I%20read%20your%20server-side%20tracking%20guide%20and%20would%20like%20to%20talk.)

On this pageContents

1. [Why Client-Side Tracking Is No Longer Enough](#why-client-side-tracking-is-no-longer-enough)
2. [What Is Server-Side Tracking?](#what-is-server-side-tracking)
3. [Client-Side vs Server-Side Tracking: What Actually Changes](#client-side-vs-server-side-tracking-what-actually-changes)
4. [WeTracked vs Elevar: Choosing a Server-Side Tracking Tool](#wetracked-vs-elevar-choosing-a-server-side-tracking-tool)
5. [How Server-Side Tracking Improves Ad Platform Performance](#how-server-side-tracking-improves-ad-platform-performance)
6. [Implementing Server-Side Tracking: What the Process Looks Like](#implementing-server-side-tracking-what-the-process-looks-like)
7. [Get Your Tracking Infrastructure Right Before You Scale Spend](#get-your-tracking-infrastructure-right-before-you-scale-spend)

TL;DR

Client-side tracking is increasingly unreliable due to blockers and browser privacy restrictions, and server-side tracking restores more consistent measurement.

* Why browser-based tags fail more often (ad blockers and script restrictions)
* How privacy updates and ITP reduce cookie-based attribution
* What server-side tracking changes in your data flow
* Why consistency and control improve conversion reporting and optimisation

## Why Client-Side Tracking Is No Longer Enough

![Why Client-Side Tracking Is No Longer Enough](/images/seo/server-side-tracking-1.webp) 

Browser-based tracking is breaking down. Not dramatically. Not all at once—but steadily, in ways that compound over time and quietly distort your data before anyone notices.

Ad blockers stop tags from firing. Privacy extensions intercept requests before they reach Google or Meta. Intelligent Tracking Prevention (ITP) caps cookie lifetimes—sometimes to 24 hours—which makes cross-session attribution nearly useless. And browser vendors keep tightening what scripts can read and store.

The result isn't just missing data.

It's missing conversions, under-reported revenue, and fewer usable signals feeding into automated bidding. Your campaigns end up optimising against an incomplete picture.

We see this constantly during technical audits. A client thinks their conversion tracking is solid, then we dig in and find 20–30% of events are either blocked or misattributed. The gap between what's happening and what's being recorded is often much larger than teams expect.

So what does server-side tracking actually change?

Instead of asking the user's browser to run every tag perfectly—under whatever blockers, privacy settings, and restrictions happen to be active—you fire events from your own server or a server-side container. The request goes directly to the ad platform or analytics tool. Blockers can't intercept it.

That consistency matters. A few reasons why:

* **Conversion accuracy**: High-value events (purchases, sign-ups, trials) reach platforms reliably, so bidding algorithms have better data to work with.
* **Attribution**: Events carry first-party context you control, not whatever the browser decides to pass through.
* **Governance**: Consent logic, data minimisation, and event standardisation happen in one place—not scattered across dozens of browser tags.

The tricky part is knowing where to start. Audit your full event flow first. Identify where you're actually losing events before rebuilding anything. Then move your highest-value conversions to server-side first. For more on how this fits into a broader measurement setup, see [tracking](/measurement/tracking).

## What Is Server-Side Tracking?

![What Is Server-Side Tracking?](/images/seo/server-side-tracking-2.webp) 

Server-side tracking is a method of collecting and sending marketing and analytics events through your own server, rather than depending on a user's browser to fire data directly to ad platforms.

In a traditional client-side setup, tags like Meta Pixel or Google Ads run in the browser and shoot requests straight to third parties. With server-side tracking, the browser sends events to a first-party endpoint you control—and your server then forwards that data to platforms via their server-to-server integrations, commonly called Conversions APIs.

Server-side tracking

Server-side tracking is the process of sending website or app events from your own server to advertising and analytics platforms via their APIs, instead of firing tags directly from the user's browser.

The core shift is about where your "source of truth" lives.

Instead of scattering vendor scripts across the site and hoping browsers execute them consistently, you centralise event collection in a first-party data layer. Your site still captures user interactions—page views, add to cart, purchases, leads—but those events post to your server first. From there, the server normalises the data, applies whatever rules you need, and sends the final payloads to each platform's API. Filtering, deduplication, consent handling—all of it happens in one place you actually control.

### The core components of a server-side tracking setup

Most implementations come down to three moving parts.

**1\. A tracking server (usually on a subdomain you own)**

This is the endpoint that receives event data from the browser. A common pattern is a dedicated subdomain—something like `track.yourdomain.com`—routed to a server-side container or lightweight event collector. It receives requests, validates them, enriches them where needed, and routes them to the right destinations. Think of it as your central dispatch for tracking data.

**2\. A tag management layer (server-side)**

You still need a way to manage what gets sent where without hard-coding every integration. A server-side tag manager typically handles:

* Mapping your site events to each platform's expected schema
* Adding or stripping parameters (value, currency, content IDs, lead type, etc.)
* Setting rules around when an event should actually be forwarded
* Deduplication logic, so the same conversion isn't counted twice in a hybrid setup
* Version history and release management—similar to what you'd expect from client-side tag management

**3\. Platform API integrations**

Instead of a pixel firing from the browser, the server sends data directly to each platform's API. The pattern is consistent across platforms: event name, timestamp, identifiers, event details. For ad platforms, this usually includes privacy-safe matching fields—hashed email or phone, where you have consent and a legal basis—plus metadata like purchase value and currency.

### How the data typically moves

So what does this actually look like end to end?

* The browser captures an interaction (say, a purchase confirmation page view)
* Your site sends an event to your first-party tracking endpoint via `fetch` or XHR
* Your server receives it, applies your tracking rules—validation, formatting, enrichment, routing
* The server forwards the event to one or more endpoints: Meta CAPI, Google Ads Enhanced Conversions, analytics tools, your CRM
* Platforms return success or error codes, which you log and monitor to catch issues fast

This architecture gives you one place to govern all of your tracking. Your event spec, your quality checks, your outbound integrations—centralised. You're no longer at the mercy of third-party scripts behaving differently across browsers and devices.

We see it pay off almost immediately once a setup is properly implemented. That's not a small thing.

#### Common server-side tracking tool stack

Google Tag Manager (Server-Side) Meta Conversions API Google Ads Enhanced Conversions Google Analytics 4 Cloudflare Google Cloud Run 

## Client-Side vs Server-Side Tracking: What Actually Changes

![Client-Side vs Server-Side Tracking: What Actually Changes](/images/seo/server-side-tracking-3.webp) 

Client-side tracking runs in the user's browser. Analytics and ad tags load on the page, set or read cookies, and fire events directly from the device to each platform. Server-side tracking routes those events through a server endpoint you control—often called a server container or a lightweight collection API—before forwarding them to your analytics and ad platforms.

The difference goes well beyond "more data."

It changes where collection happens, how reliable delivery is, how much engineering you need, what it costs to run, and how much control you have over what actually gets shared.

| Factor                | Client-side tracking                                                                             | Server-side tracking                                                                                                |
| --------------------- | ------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------- |
| Data completeness     | More likely to miss events when browser execution is interrupted or network requests are blocked | Can capture more events because collection happens off the page and can be retried/queued server-side               |
| Latency & reliability | Depends on page performance and user connection; events may drop on bounces or slow devices      | More consistent delivery once the server receives the event; still depends on your implementation and upstream APIs |
| Setup & maintenance   | Typically faster to launch with a tag manager; less backend involvement                          | More moving parts (endpoints, auth, event schemas, monitoring) and needs ongoing maintenance                        |
| Cost                  | Mostly tool costs (tag manager, analytics); minimal infra                                        | Additional infra and potential per-request fees; engineering time becomes a real line item                          |
| Control & governance  | Limited control: each tag decides what it sends once it runs                                     | More control: you can filter, transform, and standardise what gets forwarded                                        |

### Data completeness: what you recover (and what you still won't)

Client-side tracking is fragile by design. It depends on the browser running your code, completing outbound requests before the user navigates away, the page reloads, or a script fails. Any of those things can drop an event entirely.

Server-side setups improve completeness because events hit your endpoint first. Your server then handles delivery to each platform, with retry logic and batching you actually control.

But server-side isn't a magic recovery tool. If a user never triggers an event—or you never instrumented it in the first place—there's nothing to capture. Identity still requires a clear approach to consent, first-party identifiers, and event design. Switching to server-side won't fix a measurement strategy that's unclear to begin with.

### Data latency: what changes and why it matters

Client-side events can fire quickly when everything loads cleanly. The problem is variance. Page speed, script load order, and device conditions all affect whether that event actually sends. Server-side reduces that variance—once your server receives an event, forwarding is more consistent and far less sensitive to what's happening in the user's browser.

That said, server-side can introduce its own latency. Heavy enrichment calls, complex transformations, or a server that doesn't scale well under traffic spikes will all slow things down.

The real goal is predictable delivery. Not necessarily faster delivery.

### Complexity of setup: where the work shifts

Client-side is usually quicker to get running. Tags, triggers, and variables in a browser-based manager, QA'd with standard debugging tools. Most teams can ship something in days.

Server-side is a different story entirely.

Endpoints, authentication, payload validation, logging, monitoring, error handling, versioning event schemas—it's a proper engineering project, not a tag management task. We see this constantly during technical audits: teams underestimate the ongoing maintenance burden and treat server-side as a one-time migration rather than a system to run.

It does force clearer thinking about event standards and naming, which is genuinely valuable. But it takes real time, especially when multiple teams own different parts of checkout, CRM, and consent management.

#### Example: purchase event quality improving with server-side routing

A retailer sees inconsistent purchase events in ads platforms because the browser sometimes fails to send the final conversion call after checkout. With server-side tracking, the site still sends a purchase event from the browser to a first-party collection endpoint, but the server validates required fields (order\_id, value, currency), deduplicates against repeat submissions, and forwards a clean event to analytics and ad platforms. Reporting becomes more consistent, but the team also has to maintain the endpoint, monitor delivery errors, and keep the event schema aligned with site changes.

### Cost implications: infra, tooling, and people time

Client-side costs are mostly tool spend and time in tag management. Predictable, relatively contained.

Server-side adds hosting, scaling, and security overhead. In most organisations, the bigger cost is engineering time—building a reliable event pipeline and keeping it maintained as platforms change their requirements is an ongoing commitment, not a project you close out.

High event volumes make this more expensive still. You're now handling more requests yourself. The return is real in the right situations, but it needs to be modelled against your actual volumes, platforms, and internal capacity. Not assumed.

### Control over what data gets shared: a real reason to go server-side

This is one of the most practical arguments for server-side, and it's often underweighted.

With client-side tags, each platform tag sends its own payload once it fires. You have limited visibility into what's actually leaving the page. With server-side, you decide centrally what gets forwarded, what gets stripped, and what gets standardised across destinations.

In practice, that means:

* filtering out fields you don't want leaving your systems,
* enforcing consistent naming and formatting across platforms,
* adding server-generated metadata like internal campaign mapping,
* and keeping a clear audit trail of what was sent, when, and where.

It's not a substitute for consent management. But it does make compliance and internal policy enforcement much easier to apply consistently—rather than chasing it across a dozen individual tag configurations.

#### Pros (client-side)

* Fast to implement and iterate via tags and a browser-based manager
* Lower infrastructure burden; fewer backend dependencies
* Easy to debug with common browser tools and platform helpers
* Good fit for small sites or simpler measurement needs

#### Cons (client-side)

* More fragile delivery: scripts, page performance, and browser conditions can cause dropped events
* Harder to standardise data across multiple platforms when each tag behaves differently
* Limited central control over payloads once tags run in the browser
* More exposed to client-side breakage from site releases and third-party script conflicts

The honest takeaway: server-side tracking moves where reliability, governance, and troubleshooting live. It can meaningfully improve both completeness and control. But it adds real implementation and maintenance work that doesn't go away after launch. Whether it's the right call depends on your measurement goals, event volume, and whether your team has the capacity to run tracking like a system—not just a collection of tags.

## WeTracked vs Elevar: Choosing a Server-Side Tracking Tool

WeTracked and Elevar both come up when ecommerce teams start shopping for server-side tracking. Both can improve how conversion events reach ad platforms. But they're built around different assumptions—about your stack, your team, and how much control you actually want.

The short version: Elevar is Shopify-native and opinionated. WeTracked gets evaluated when brands need a broader fit.

| Criteria               | WeTracked                                                                              | Elevar                                                                       |
| ---------------------- | -------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
| Best fit               | Mixed stacks (Shopify + other platforms), multi-store, or custom setups                | Shopify-first ecommerce teams wanting a guided implementation                |
| Setup approach         | More flexible; often requires clearer specs on what events/IDs you'll send             | More prescriptive Shopify framework; faster when you align to their model    |
| Integrations           | Varies by plan/implementation; typically positioned for broader platform coverage      | Strong Shopify + common ecommerce marketing stack integrations               |
| Deduplication strategy | Depends on how you configure event IDs and routing; flexibility can be a pro or a risk | Clearer Shopify-centric event design, typically easier to standardise dedupe |

### Target use case: Shopify-first vs broader stacks

**Elevar** tends to be the stronger choice when:

* Shopify is your core platform and will stay that way for the next 12–24 months.
* You want a structured, well-worn path to better Meta/Google tracking without building custom architecture.
* Your team prefers a productised implementation—where the tool nudges you toward consistent event naming and payloads.

**WeTracked** is usually the better fit when:

* You're running multiple storefronts, multiple domains, or blending platforms (Shopify plus headless, marketplaces, or a custom checkout layer).
* You want precise control over what data gets collected, transformed, and forwarded—including consent-driven routing.
* Your tracking model is likely to evolve, and you don't want your tool locking you into one ecosystem's conventions.

### Setup complexity: fastest path vs most control

Server-side tracking is never set-and-forget. But the effort varies considerably depending on which direction you go.

With **Elevar**, implementation is relatively straightforward for Shopify teams. The tool is built around Shopify's event model. That said, it still needs proper scoping—what counts as a conversion, how you handle refunds and cancellations, what identifiers you can legally send given your consent setup.

With **WeTracked**, the setup conversation is usually more architectural. That can actually be a good thing if you're already thinking carefully about data governance and event design. But it means tighter requirements up front: event taxonomy, required parameters per channel, and a plan for managing changes over time.

The practical takeaway: Elevar often reduces decisions—and therefore time—for Shopify-only brands. WeTracked tends to reduce rework later if your stack is going to get more complex.

### Platform integrations supported: check your "must-haves"

Both tools are typically evaluated for measurement across paid social and paid search. Where teams get caught out is assuming "integration" means the same thing in every context.

So before deciding, nail down your non-negotiables:

* Which ad platforms must receive server-side events—Meta, Google Ads, TikTok?
* Do you need GA4 events mirrored server-side, or is this primarily for ad platforms?
* Are you using a CMP and need consent-aware routing?
* Do you have downstream needs—enriched events going to a warehouse or CRM—even if that's a phase two?

Elevar is usually strongest when your integrations map cleanly to Shopify and the most common ecommerce marketing tools. WeTracked tends to get chosen when you need coverage across a wider or less standard platform mix.

### Pricing model transparency: what you can actually compare

Pricing is genuinely hard to compare here. "Server-side tracking" can bundle together very different things:

* a tool subscription,
* event or order volume considerations,
* implementation fees,
* ongoing maintenance and monitoring.

**Elevar's pricing feels clearer for Shopify brands** because the product scope and supported patterns are more defined. **WeTracked is harder to benchmark on price without a precise scope**—flexibility introduces variability, which usually means more configuration options, more potential support needs, and quotes that require a proper brief.

If you're comparing vendor quotes, ask both the same questions:

* What's included vs billed separately—setup, support, troubleshooting, ongoing changes?
* Are there event limits, and what happens if you exceed them?
* What does "support" actually mean: response times, implementation help, proactive monitoring?

### Support quality: don't just assess friendliness—assess outcomes

This matters more with server-side tracking than most marketing tools. When something breaks, it can break revenue reporting and bidding signals at the same time.

A practical way to assess support for either platform:

* Ask how they diagnose discrepancies—what logs exist, what visibility you get into what's happening.
* Ask what they consider "working" (event received vs deduplicated vs attributed are very different things).
* Ask how changes are handled when platforms update their requirements—new parameters, new dedupe behaviours.

> From our side at Crank, Elevar is usually the smoother path for Shopify-only teams, while WeTracked tends to win when the tracking model needs to span multiple platforms or more custom data rules.

### Deduplication: the difference between "more events" and "better events"

Deduplication is where a clean server-side rollout separates itself from a noisy one. When you're sending both browser and server-side versions of the same purchase event, you need a consistent way for the destination platform to recognise they're the same event and count it once.

A common mistake we see: teams confirm events are arriving but never validate that duplicates are actually being ignored. Those are two very different things.

What to look for in both tools:

* **Event IDs:** Can you generate and consistently pass an event ID across browser and server events?
* **Source of truth:** Is the purchase event anchored to a stable order or transaction ID, even across retries?
* **Consistency across channels:** Meta, Google, and others have different expectations. You need a plan per destination, not a single "dedupe setting."
* **Testing workflow:** Validation should confirm not just that events arrive, but that duplicate events are being correctly ignored.

Elevar's advantage is that Shopify-centric implementations make it easier to standardise how event IDs and order IDs flow through the system. WeTracked's advantage is flexibility—if your checkout is non-standard, you can design a dedupe approach that matches your actual reality.

The risk with flexibility is misconfiguration. If IDs aren't consistent, you can accidentally inflate conversion counts or end up with mismatched reporting across platforms.

We see this in audits more than you'd expect.

Choose based on your stack and requirements, not tool popularity.

[Get a tracking audit](/crank-os/free-scan) 

### Which is the stronger fit?

A simple decision lens we use:

* Choose **Elevar** if you're **Shopify-first**, want a **guided implementation**, and prefer a **well-defined framework** with fewer moving parts.
* Choose **WeTracked** if you need **cross-platform flexibility**, expect your stack to evolve, or have **custom checkout or data requirements** that don't neatly fit a Shopify-native model.

Whichever direction you go, treat this as a measurement design project—not just a software purchase. The accuracy of your tracking usually comes down to event definitions, identifier strategy, and a proper QA process. Not the logo on the invoice.

## How Server-Side Tracking Improves Ad Platform Performance

Ad platforms optimise on the conversion data they receive. Not on what actually happened. When that data is incomplete, bidding and audience building run on partial signals—and the symptoms are familiar: unstable CPA, learning phases that never settle, campaigns that over-index on easy-to-track conversions instead of valuable ones.

Server-side tracking fixes this by feeding cleaner, more complete data back into platforms like Meta and Google. The impact isn't magic. It's mechanical. Better inputs produce better bidding signals.

Event Match Quality (EMQ) score

Meta uses Event Match Quality to reflect how well your events can be matched to Meta accounts, based on the customer information you send (e.g., email, phone, external ID) and implementation quality.

Source: Meta Business Help Center (Conversions API + Event Match Quality documentation)

### 1) More conversions get attributed, so algorithms learn faster

Meta's delivery system and Google's Smart Bidding both adjust bids based on observed conversions and the patterns around them—device, time, audience, creative, placement. If a chunk of conversions never makes it back to the platform, it will consistently under-bid for the users and contexts that actually drove those results.

Server-side tracking closes those gaps. Conversions get captured from your backend—checkout, CRM, subscription platform—and sent to the ad platform in a format it can reliably ingest.

The feedback loop improves:

* **More conversion events per campaign** (not just the easy ones)
* **Better conversion timestamps and values**
* **More consistent event firing and de-duplication**
* **Higher confidence in attribution and optimisation**

The wins are usually most visible in long funnels, cross-device behaviour, or purchases that complete after redirects. Payments, BNPL, third-party checkout flows. That's where browser-side tracking drops the most events.

### 2) Better identity matching improves optimisation quality (Meta)

Meta depends on matching events back to real people to optimise delivery and reporting. That's where **Event Match Quality (EMQ)** matters.

EMQ improves when you send stronger customer parameters—hashed email, phone, external IDs—and when events are consistent, deduplicated, and correctly structured. Server-side implementations make this easier because your server already has access to verified identifiers from logged-in sessions, checkout records, or your CRM.

Better match quality doesn't just clean up reporting.

It affects how confidently Meta can identify which users are converting—and build lookalikes or broad targeting models from those signals.

### 3) Google Enhanced Conversions strengthens Smart Bidding signals

For Google Ads, the equivalent is **Enhanced Conversions**. When a conversion happens, you provide hashed first-party customer data so Google can match it back to signed-in users more accurately, reducing "unknown" conversions and improving the training data for Smart Bidding strategies like Target CPA and Target ROAS.

Server-side tracking is well-suited here because you're capturing conversion details at the point of truth—your order confirmation, your backend transaction record. It's also more stable than relying on front-end form events and page-level tags that break every time someone touches the design.

### 4) LinkedIn Insight Tag: useful, but more limited for optimisation

LinkedIn's Insight Tag works well for basic conversion tracking and retargeting. But compared to Meta and Google, it has real limitations—particularly around identity resolution depth and optimisation maturity when you're chasing low-volume, high-consideration conversions.

Server-side approaches can improve event reliability and support offline conversion flows on LinkedIn. Set expectations accordingly, though. LinkedIn typically benefits more from a strong audience strategy—job function targeting, company lists, ABM—and clean conversion definitions than from incremental tracking sophistication alone.

### 5) Stronger signals aren't only "online": offline conversion imports can matter

A common reason performance plateaus is that the platform is optimising for the wrong conversion.

It sees early-funnel proxies—lead submit, trial start—but not downstream quality: SQL, revenue, retention. We see this constantly during audits on SaaS accounts where the pipeline is long and the real value event happens days or weeks later.

Server-side tracking pairs well with importing later-stage outcomes, so you're training the algorithm on what actually matters. If you have CRM-qualified events or revenue confirmed post-close, offline conversion import should be part of your signal strategy: [offline-conversion-import](/crank-os/tracking/hubspot-ad-lead-tracking).

#### ⛔ Important

Server-side tracking can harm performance if events aren't deduplicated across browser + server, or if you send inconsistent event names/parameters. Always implement strict event IDs, validate in platform diagnostics (Meta Events Manager, Google Ads conversion diagnostics), and protect PII by hashing and following consent rules.

### 6) What "better bidding signals" looks like in practice

So what changes when platforms actually receive richer, cleaner conversion data?

* **More stable learning**—less oscillation because the algorithm has more confirmed outcomes to work from
* **Better value-based optimisation** when purchase value or lead quality is passed through correctly
* **Improved audience building** because seed events are higher quality and better matched

This doesn't replace good creative, strong landing pages, or the right offer. But it removes a constraint that holds a lot of otherwise solid campaigns back.

The platform can only optimise for what it can see.

> When we diagnose underperforming paid social or search, tracking isn't the only issue—but it's often the reason good campaigns can't scale. Once the platforms consistently receive the right conversion events with reliable identifiers and values, optimisation usually becomes more predictable and easier to control.

## Implementing Server-Side Tracking: What the Process Looks Like

Server-side tracking isn't something you just switch on. It's a migration. Rush it, and you'll break attribution, double-count conversions, or quietly lose critical parameters before anyone notices. The sequence below is what a stable, verifiable implementation actually looks like.

### 1) Audit your existing client-side tracking (and document the gaps)

Start with what you already have. GA4, Google Ads, Meta, TikTok, affiliate platforms, CRM events, ecommerce events like add\_to\_cart, begin\_checkout, purchase, refunds—all of it.

You're looking for three things:

* **Event coverage:** Which events fire consistently, on which pages, and across which devices and browsers?
* **Parameter quality:** Are you sending the right identifiers—transaction\_id, order\_id, value, currency, item arrays, click IDs?
* **Consistency across platforms:** Does "Purchase" mean the same thing in GA4, Meta, and Google Ads, or are triggers and values mismatched?

This baseline matters more than most teams expect. Without it, you can't prove server-side improved anything. And you'll have no reference point when discrepancies appear—and they will.

### 2) Choose your server-side infrastructure

Most implementations land in one of these buckets:

* **GTM Server-Side container:** Good for teams already in GTM who need flexibility—multiple destinations, routing rules, custom templates.
* **Hosted GTM server-side (e.g. Stape):** Similar capability, with hosting and some tooling managed for you.
* **Native tools for ecommerce stacks (e.g. WeTracked/Elevar):** Often faster for Shopify and common ad platform destinations, fewer moving parts—but you trade some customisation for speed.

The right choice depends on your stack, your internal capability, and how many destinations you're sending to. There's no universal answer.

### 3) Set up your first-party domain endpoint

Next comes the first-party subdomain—something like `metrics.yourdomain.com`—which acts as your collection endpoint. This involves DNS (CNAME) pointing to your server-side container, SSL/TLS for secure requests, and routing so the endpoint receives and forwards events correctly.

This is where projects stall.

It touches DNS, it often needs developer access, and teams consistently underestimate the back-and-forth involved. Plan for it—budget more time than feels necessary.

### 4) Configure platform API integrations and deduplication logic

With the endpoint in place, you wire up each platform's server-side integration: Google Ads enhanced conversions, Meta CAPI, TikTok Events API, GA4 Measurement Protocol where relevant.

The tricky part is deduplication. We see this mishandled constantly.

* Each conversion needs a stable **event\_id** shared across browser and server events.
* Purchase events need consistent **transaction/order IDs**.
* Each platform needs to know which source is "primary"—and some only deduplicate automatically if the right fields are present and consistent.

Skip deduplication and you'll inflate conversions. Inflated conversions mislead bidding algorithms. It compounds quickly.

### 5) QA and validate events before launch

QA at two levels:

* **Technical:** Are requests arriving at the endpoint? Are responses OK? Any dropped events?
* **Business:** Do counts, revenue, and key parameters line up with your baseline—within expected variance?

Treat this like a software release. Test environments, controlled rollouts, clear pass/fail criteria. Not just a quick check in the platform UI.

#### Server-side tracking implementation timeline

Phase 1

#### Audit & baseline

Inventory existing tags, events, and parameters across GA4 and ad platforms; document gaps and define a baseline for comparison.

Phase 2

#### Infrastructure choice

Select GTM server-side, hosted SS (e.g. Stape), or a native tool (e.g. WeTracked/Elevar) based on stack, destinations, and resourcing.

Phase 3

#### First-party endpoint setup

Configure a first-party subdomain, DNS, and SSL so events can be collected reliably and forwarded server-side.

Phase 4

#### Integrations & deduplication

Connect platform APIs and implement event\_id/order\_id logic so browser and server events don't double-count.

Phase 5

#### QA, launch, and monitoring

Validate event payloads and counts against the baseline, then monitor match quality and attribution stability after release.

### 6) Monitor event match quality after launch

Watching conversion totals after launch isn't enough. Look deeper.

* **Match quality signals** in ad platforms, where available
* **Share of modelled vs observed conversions**
* **Revenue discrepancies** between your ecommerce platform, GA4, and ad platform reporting
* **Event volume drift**—sudden drops or spikes usually point to routing or deduplication issues

Expect iteration. A few rounds of adjustments to identifiers, event schemas, or routing rules is normal. It's not a sign something went wrong—it's just how this works in practice.

#### Pre-launch validation checklist

* Confirm baseline event counts and revenue for a fixed date range (e.g. last 7–14 days).
* Verify the first-party subdomain resolves correctly, serves SSL, and receives requests.
* Validate required parameters for each event (event\_id, transaction/order ID, value, currency, item data where relevant).
* Test deduplication by triggering the same conversion and confirming only one is counted per platform.
* Check click ID capture and persistence (gclid, fbclid, ttclid or equivalents) where applicable.
* Ensure consent mode/consent signals are respected in both browser and server event flows.
* Run end-to-end tests across devices and browsers (including iOS) and key user journeys (checkout, upsells, refunds).
* Confirm error handling: retries, timeouts, and logging for failed server-to-platform requests.

#### ⚠ Common implementation errors

The most frequent issues we see are missing deduplication (double-counted conversions), sending PII in the wrong format or without hashing where required, and skipping baseline validation—so teams can't tell if differences are an improvement or a break in tracking.

## Get Your Tracking Infrastructure Right Before You Scale Spend

Ad performance is only as good as the data feeding it. If your measurement layer has gaps, you're not optimising your campaigns — you're optimising a fiction.

Scaling spend on top of broken tracking doesn't fix the problem. It makes it worse.

Server-side tracking isn't an optional upgrade. It's the foundation that makes your ad data reliable enough to act on. Without it, budget decisions are based on figures that don't reflect what's actually happening on your site.

We see this constantly during audits — usually right before a client is about to push spend up significantly.

Before you increase budget:

* Audit what's firing and what's being lost
* Check whether the signals reaching your ad platforms are accurate
* Identify where partial data is causing campaigns to learn from the wrong inputs

That last point is where most teams underestimate the damage. Partial data doesn't just mean incomplete reporting. It means your bidding algorithms are optimising against a distorted picture of reality.

Once the foundation is solid, every pound works harder. Not because the ads changed — but because the signals driving them can finally be trusted.

### Get a Tracking Audit From Crank

We review your current setup, identify gaps, and recommend the right server-side tracking approach for your business.

[Speak to Crank](/contact) 

## Frequently **Asked Questions**

Do I need a developer to implement server-side tracking?▼

Often, yes for at least part of the project. DNS/subdomain setup, server/container provisioning, and some ecommerce data-layer adjustments commonly need developer access. If you use a native tool (e.g. for Shopify) you may reduce dev time, but you still need someone who can handle domain/DNS and verify data passing correctly.

Will server-side tracking affect my cookie consent setup?▼

It can, and you should plan for it. Server-side doesn't remove the need for consent—your implementation still needs to respect user choices and pass consent signals through to tags and platform APIs. The goal is to keep measurement compliant and consistent, not to bypass consent.

How long does implementation typically take?▼

For a single-site setup with a few destinations, you can often reach a stable first release in days to a couple of weeks, depending on DNS access, ecommerce complexity, and how much custom event mapping is needed. Multi-region sites, complex checkout flows, and many destinations usually take longer because QA and deduplication become more involved.

What's the best way to prove it's working?▼

Compare against a documented baseline. Validate event payloads, counts, and revenue for the same user journeys before and after launch, and confirm deduplication by testing repeated conversions. Post-launch, monitor platform match quality and any divergence between your ecommerce backend and reporting tools.

You might also find helpful

[ResourcePaid media trackingThe full tracking guide: where server-side fits into your broader setup.](/measurement/tracking)[ResourcePaid media measurement hubFrameworks, KPIs and reporting for B2B paid media.](/measurement)[ResourceHubSpot ad lead trackingSend CRM lead outcomes back to ad platforms to improve bidding signals.](/crank-os/tracking/hubspot-ad-lead-tracking)[ResourceFree tracking scanCheck your site for tracking gaps before you scale spend.](/crank-os/free-scan)[ResourceMeta Ads not matching ShopifyWhy platform and store numbers disagree.](/insights/meta-ads-not-matching-shopify)

[Back to Paid Media Tracking](/measurement/tracking)