Server-side tracking explained: pixel vs server-side after iOS 14.5

Admaxxer is a marketing analytics and attribution platform for DTC brands and SaaS companies. This is the overview guide to server-side conversion tracking: what it is, why it became essential after iOS App Tracking Transparency, how it differs from the browser pixel, and where to go next for the platform-specific setup. If you only read one page on the topic, read this one — then follow the link to your platform's step-by-step guide.

What server-side tracking is

Conversion tracking is how an ad platform learns which clicks led to purchases, so it can optimize bidding and report results. There are two ways to send that signal:

• Browser-side (the pixel/tag): a snippet of JavaScript runs in the shopper's browser and sends the conversion event directly to the ad platform.
• Server-side (the conversions API): your server sends the conversion event to the ad platform directly, server-to-server, without depending on the shopper's browser.

Server-side tracking means firing your conversion events — purchases, sign-ups, leads — from your own server rather than (or in addition to) the browser. The event still describes the same thing; it just travels by a more reliable road.

Why it matters after iOS 14.5

In April 2021, Apple's iOS 14.5 introduced App Tracking Transparency (ATT), the prompt that asks users whether an app may track them across other companies' apps and websites. A large share of users decline. For advertising, this broke the deterministic link between an in-app ad click and a conversion on your site for most iOS users. Apple's user-privacy documentation defines what "tracking" means in this context.

ATT was the start, not the end. Browser-side tracking faces a stack of compounding pressures:

• Ad-blockers drop pixel requests at the network layer before they ever reach the ad platform.
• Safari's Intelligent Tracking Prevention truncates the cookies pixels rely on, so even pixels that fire match less reliably.
• Link-tracking protection on iOS can strip click identifiers (like Meta's, Google's, TikTok's, and Pinterest's) from links shared in Messages, Mail, and Private Browsing.
• Slow pages can unload before the pixel's JavaScript executes, simply losing the event.

Every one of these is a browser-side failure. Server-side tracking sidesteps all of them because the event originates on your server. This is why the major platforms — Meta, TikTok, Pinterest, Google — all built server-side conversion APIs, and why running one is now considered table stakes for serious advertisers.

Pixel vs server-side: not either/or

A common misconception is that server-side tracking replaces the pixel. It doesn't. The recommended setup across every platform is to run both legs and tie them together:

	Browser pixel	Server-side API
Where it runs	Shopper's browser	Your server
Blocked by ad-blockers?	Yes	No
Affected by Safari ITP?	Yes	No
Has browser cookies/click IDs?	Yes, when present	Only if you pass them
Survives a slow/abandoned page?	No	Yes

The pixel contributes browser-side signals (cookies, click identifiers) that the server may not have; the server leg recovers everything the browser loses. The glue that makes them work together — instead of double-counting — is a shared event ID sent on both legs, which lets the platform recognize the two as one conversion and merge them. For a deeper treatment of why platform-reported and pixel-reported numbers differ even when both are set up correctly, see platform vs pixel conversions.

Match rate: the quality of server-side events

Sending a server-side event is only half the job — the platform still has to match it to a user. It does that using the identifiers you include: a hashed email, a hashed phone, a stable customer ID, the click identifier, and the customer's IP and user agent. The more strong identifiers you send (correctly hashed, correctly normalized), the higher your match rate — and match rate directly affects how many conversions get attributed and how well the bidder optimizes. We explain this in depth in the CAPI match rate glossary entry.

Platform-specific setup guides

The mechanics are the same across platforms — send strong identifiers, use a shared event ID to deduplicate, validate before trusting the numbers — but each platform has its own endpoint, field names, and token setup. Follow the guide for your platform:

• Meta: Meta Conversions API server-side setup — the Purchase event, hashed email/phone/customer-ID, and the 48-hour deduplication window.
• TikTok: TikTok Events API server-side setup — the CompletePayment event and TikTok's distinct payload shape.
• Pinterest: Pinterest Conversions API server-side setup — the checkout event and Pinterest's identifier set.

Google Ads has its own server-side path (Enhanced Conversions); the same identity-and-deduplication discipline applies there too.

ECOM vs SaaS: what changes

Everything above is written around an ecommerce "purchase." If you run a SaaS product, the only thing that changes is which event you send and what value you attach to it:

• A purchase becomes a subscription started (Subscribe), a trial converted, or a registration completed (CompleteRegistration), depending on the milestone.
• The value you send should reflect the contract or first-payment amount, not zero, so the bidder optimizes toward revenue rather than raw sign-ups.
• Everything else — strong identifiers, shared event ID, validation — is identical.

Label your events to the right milestone and the same server-side reliability benefits apply to a SaaS funnel as to a DTC store.

How Admaxxer fits in

Admaxxer ships server-side conversion tracking for Meta, TikTok, Pinterest, and Google as part of the platform — the strong identifiers pre-wired, the real customer IP and user agent passed through correctly, and the shared event ID deduplication handled for you, so your browser and server events merge instead of double-counting. You connect each platform once and the server-side conversion stream flows from then on. See pricing for what's included, browse the documentation for setup, or jump straight to the Meta, TikTok, or Pinterest integration.

FAQs

What is server-side tracking in simple terms? It's sending your conversion events (purchases, sign-ups) to ad platforms from your own server instead of relying only on a pixel in the shopper's browser. The event describes the same thing — it just travels a more reliable road that ad-blockers and browser privacy controls can't break.

Does server-side tracking replace the pixel? No. Run both legs and tie them together with a shared event ID. The pixel contributes browser signals; the server leg recovers what the browser loses; together they beat either alone.

Why did server-side tracking become necessary? iOS 14.5 App Tracking Transparency broke the deterministic link between ad clicks and conversions for most iOS users, and ad-blockers, Safari's tracking prevention, and link-tracking protection compound the browser-side losses. Server-side delivery sidesteps all of those because the event originates on your server.

Is this legal / privacy-safe? Server-side tracking sends hashed identifiers, not raw personal data, and you remain responsible for honoring consent and your privacy policy. It changes how the event travels, not what consent you need — gate your events on the shopper's consent choices as you would the pixel.

How is server-side tracking different for SaaS? Send a Subscribe / CompleteRegistration event with the contract or first-payment value instead of a Purchase event. The reliability mechanics are identical; only the event name and value change.

Where do I start? Pick your platform and follow its setup guide — Meta, TikTok, or Pinterest — then validate with that platform's test/diagnostics tool before trusting the reported numbers.