Server-side tracking on Admaxxer — Meta CAPI, Google EC, TikTok, Pinterest, Klaviyo

What is server-side tracking?

A traditional browser pixel fires from the visitor’s page, in their browser, over their network. Three things can stop that pixel reaching the ad platform:

• iOS App Tracking Transparency (ATT). Safari and the in-app browsers used by Instagram, Facebook, TikTok, and Pinterest strip third-party cookies and clamp the pixel’s ability to identify visitors.
• Safari ITP (Intelligent Tracking Prevention). Drops first-party cookies set via JavaScript after 7 days (or 24 hours for known trackers), invalidating the pixel’s view of the same user across sessions.
• Ad blockers and DNS-level blocklists. uBlock Origin, Brave Shield, NextDNS, Pi-hole, and most enterprise DNS resolvers block requests to known tracker domains (connect.facebook.net, analytics.tiktok.com, ct.pinterest.com, etc.).

Server-side tracking takes the same conversion event — Purchase, InitiateCheckout, AddToCart, Lead — and POSTs it from your server directly to the ad platform’s server-to-server API: Meta’s Conversions API, Google’s Enhanced Conversions for Web API, TikTok’s Events API, Pinterest’s Conversions API, and Klaviyo’s server-side track-events endpoint. The visitor’s browser is no longer in the loop, so iOS ATT, Safari ITP, and ad blockers can’t interfere.

Server-side tracking is not a replacement for the browser pixel — it’s a recovery rail that runs in parallel. Most browser pixel hits will reach Meta / Google / TikTok / Pinterest the normal way. Server-side recovers the subset that doesn’t.

How Admaxxer’s server-side forwarders work

Every conversion event Admaxxer captures — whether through the browser pixel, the Shopify Customer Events Web Pixel, the WordPress plugin, or a direct revenue webhook (Stripe, Paddle, Lemon Squeezy, Polar, Dodo) — gets a stable event_id stamped at the moment of capture. The same event then takes two paths:

1. Browser path. The browser pixel fires the conversion to the ad platform with event_id attached.
2. Server path. Admaxxer’s server-side forwarder POSTs the same conversion to the ad platform’s Conversions API, also with event_id attached, plus enriched identity (hashed email, hashed phone, IP, user-agent, FBC/FBP cookies, GCLID, TTCLID, click ID).

Both paths arrive at the ad platform. The platform sees the same event_id on both sides and deduplicates automatically — the conversion counts once. If the browser path was blocked (ATT, ITP, ad blocker), only the server path arrives and the conversion is recovered. This is the deduplication contract Meta, Google, TikTok, and Pinterest all publish in their server-API docs — we just follow it.

The forwarder lives in the Admaxxer worker queue (BullMQ on Upstash Redis). Every event flows through:

• collect.admaxxer.com — ingest endpoint.
• Tinybird datasource visitor_events — the source of truth for the conversion.
• A per-platform forwarder worker that reads the per-connection feature flag (credentials_meta.<platform>_capi_enabled), enriches the payload, and POSTs to the platform API.
• A retry queue with exponential backoff for transient 5xx errors, capped at 5 attempts (24-hour total window).

Identity enrichment uses everything the visitor session has accumulated:

• Hashed PII: SHA-256 of the lowercased+trimmed email, phone, first name, last name, city, state, zip, country. Hashing is done server-side before the POST so unhashed PII never crosses the wire.
• Click IDs: fbc (Facebook click), fbp (Facebook browser ID), gclid (Google click), ttclid (TikTok click), epik (Pinterest click).
• Network identity: client IP (forwarded by the pixel’s request headers), User-Agent, fbclid/UTM source URL.

Match quality on each platform’s dashboard improves measurably the first day server-side forwarding is on — Meta typically jumps from yellow to green, TikTok’s “Match score” climbs into the 7-9 range.

Meta Conversions API (CAPI)

Meta’s CAPI is the canonical server-to-server channel for sending Facebook + Instagram conversions. Admaxxer forwards to graph.facebook.com/v21.0/{pixel_id}/events on the version pinned in your workspace.

Prerequisites

• Active Meta Ads connection on Admaxxer (paste-token install via /documentation/meta-paste-token).
• Browser pixel installed (script-tag, Shopify Web Pixel, WordPress plugin, or any of the 35+ install paths under /documentation/install) — server-side does not replace it; it runs in parallel.
• Pixel ID visible in Meta Events Manager. Admaxxer reads this from your connection when you flip the toggle.

How to enable

1. Open /integrations/meta-ads on Admaxxer.
2. Under Server-side conversions, toggle Forward to Meta CAPI on. Internally this sets credentials_meta.meta_capi_enabled = true on the ad_platform_connections row.
3. Pick which events to forward. Defaults: Purchase, InitiateCheckout, AddToCart, Lead, CompleteRegistration. Leave defaults unless you have a custom event taxonomy.
4. Save. The next conversion captured by the browser pixel will also fire server-side. No code change required.

How to verify

1. Place a test order on your storefront.
2. Open Meta Events Manager › your pixel › Overview › Test events.
3. Look for the Purchase event with both sources: “Browser” and “Server.” The Deduplication column should show 1 deduplicated for that event — that’s Meta seeing the same event_id on both rails.
4. In Data Sources › Overview, the Event Match Quality score for that event source should climb to Great (8.0+) within 24 hours.

Troubleshooting

• Event Match Quality stays yellow. Open Events Manager › the event › Diagnostics. Meta lists which match parameters are missing (typically: hashed phone, hashed last name, hashed zip). Admaxxer forwards everything the pixel captured; if Shopify checkout didn’t collect phone, Meta can’t match on phone. Enable phone capture in Shopify checkout.
• Duplicate Purchase events on Meta’s side. This means the deduplication contract is broken — the browser and server events are firing with different event_ids. Open /documentation/troubleshoot/duplicate-payments for the fix; almost always it’s because a second pixel install (theme.liquid + GTM, or two separate Admaxxer workspaces) is firing the same conversion with its own event_id.
• 403 invalid token. Your Meta long-lived token expired or was revoked. Re-paste at /integrations/meta-ads. See /guides/meta-long-lived-token-rotation.

Authoritative reference: Meta Marketing API v21 / Conversions API docs at developers.facebook.com/docs/marketing-api/conversions-api.

Google Enhanced Conversions for Web

Google’s Enhanced Conversions for Web is the server-to-server channel for sending Google Ads conversions with hashed PII so Google can stitch the conversion to the ad click even when the browser cookie is missing. Admaxxer forwards to the Google Ads API uploadClickConversions + uploadConversionAdjustments endpoints, keyed by your GCLID + customer ID.

Prerequisites

• Active Google Ads connection (OAuth refresh token + developer token) via /documentation/google-ads-setup.
• A conversion action created in Google Ads UI with “Include in Conversions” on. Admaxxer needs the conversion action’s resource name (e.g., customers/1234567890/conversionActions/9876543210); the integrations page autocompletes this from your account.
• GCLID capture on the storefront. The browser pixel already does this when ads are auto-tagged (which is the Google Ads default).

How to enable

1. Open /integrations/google-ads on Admaxxer.
2. Under Server-side conversions, toggle Forward to Google Enhanced Conversions for Web on. Internally this sets credentials_meta.google_ec_enabled = true.
3. Map your conversion events to Google conversion actions: Purchase → Purchase, Lead → Lead, etc.
4. Save. Forwarding starts immediately.

How to verify

1. Place a test order.
2. Open Google Ads › Tools & Settings › Measurement › Conversions › click your conversion action.
3. Look at the Diagnostics tab. After ~30 minutes you should see “Enhanced conversions are being received” with a non-zero “Match rate.” 70%+ is the target; below 50% means your PII coverage is low (storefront isn’t capturing email/phone at the right step).

Troubleshooting

• Match rate stuck at 0%. The conversion action probably has “Enhanced conversions” toggled off in its settings. Open the conversion action › Settings › Enhanced conversions › turn it on, choose API as the source.
• 403 PERMISSION_DENIED. Your Google Ads developer token is in Basic Access (no API call permissions) or your OAuth refresh token expired. Re-auth at /integrations/google-ads. See /guides/google-ads-refresh-token-expired.
• Currency mismatch. Google rejects conversions whose currency doesn’t match the account default. Admaxxer forwards the currency captured at checkout; if your Shopify store sells in USD but your Google Ads account is GBP, set the conversion currency explicitly in Google Ads.

Authoritative reference: Google Ads API v17 docs at developers.google.com/google-ads/api/docs/conversions/enhanced-conversions-leads and conversions/upload-clicks. Note cost_micros / value_micros are in 1e-6 units — Admaxxer handles the conversion automatically.

TikTok Events API

TikTok’s Events API is the server-to-server channel for TikTok Ads. Admaxxer forwards to business-api.tiktok.com/open_api/v1.3/event/track/. TikTok is where server-side typically recovers the most volume — the in-app browser inside the TikTok app is the most restrictive in the industry, and roughly 40% of TikTok-driven conversions never reach the browser pixel in practice.

Prerequisites

• Active TikTok Ads connection via /documentation/tiktok-paste-token.
• TikTok Pixel created in TikTok Events Manager. Admaxxer reads the Pixel ID from your connection.
• TikTok Access Token with Events API scope. The paste-token install captures this.

How to enable

1. Open /integrations/tiktok-ads.
2. Toggle Forward to TikTok Events API on. Internally: credentials_meta.tiktok_capi_enabled = true.
3. Pick events. Defaults: CompletePayment (TikTok’s name for purchase), InitiateCheckout, AddToCart, Subscribe.
4. Save.

How to verify

1. Place a test order.
2. Open TikTok Events Manager › your pixel › Events. The CompletePayment row should show a non-zero Server column, and a Match score in the 7-9 range.
3. The Last received timestamp should be within the last few minutes.

Troubleshooting

• Match score stuck at 1-3. Your event payload is missing identity. Open the event row › Diagnostics. Typically you need to enable phone capture and pass it through at checkout. Admaxxer hashes whatever the pixel collected; it can’t enrich what wasn’t captured.
• 40113 invalid pixel_id. The Pixel ID stored on the connection doesn’t match an active pixel in TikTok Events Manager. Re-link at /integrations/tiktok-ads.
• Duplicates. Same event_id contract as Meta; if you see duplicates the second pixel install is the cause.

Authoritative reference: business-api.tiktok.com/portal/docs?id=1771101303285761 (TikTok Events API v1.3 reference).

Pinterest Conversions API

Pinterest’s Conversions API forwards to api.pinterest.com/v5/ad_accounts/{ad_account_id}/events. Pinterest is heavily female / DTC-skewed and ITP-blocked at high rates on Safari iOS — server-side recovery on Pinterest typically sits in the 25-35% range for DTC brands.

Prerequisites

• Active Pinterest Ads connection. The paste-token install at /integrations/pinterest-ads captures the OAuth access token, ad account ID, and tag ID (Pinterest’s name for the pixel).
• Pinterest Tag already firing on your storefront (the browser pixel that Admaxxer installs).

How to enable

1. Open /integrations/pinterest-ads.
2. Toggle Forward to Pinterest Conversions API. Sets credentials_meta.pinterest_capi_enabled = true.
3. Save.

How to verify

1. Place a test order.
2. Open Pinterest Ads Manager › Conversions › your tag.
3. The Source breakdown should show both Web (browser) and API (server). Coverage should climb to 90%+ within 24 hours.

Troubleshooting

• 401 invalid_token. Pinterest OAuth tokens expire after 30 days. Admaxxer’s token refresh worker should rotate them silently; if it fails, re-auth.
• Tag not receiving server events. Confirm the tag ID on the connection matches the active Pinterest Tag in Ads Manager. Mismatched tag IDs are the most common cause.

Authoritative reference: developers.pinterest.com/docs/conversions/conversion-management.

Klaviyo server-side track-events

Klaviyo isn’t an ad platform — it’s the email/SMS layer. But the same server-side pattern matters: Klaviyo’s flows trigger off events (Placed Order, Started Checkout, Viewed Product), and the browser pixel that fires these is subject to the same ATT/ITP/ad-blocker constraints as the ad-platform pixels. Admaxxer forwards every conversion event to Klaviyo’s server-side track endpoint at a.klaviyo.com/api/events/ via the v2024-10-15 API.

Prerequisites

• Active Klaviyo connection via /documentation/klaviyo-api-key (API key, not OAuth — Klaviyo’s server-side accepts private keys with events:write scope).

How to enable

1. Open /integrations/klaviyo.
2. Toggle Forward events to Klaviyo server-side. Sets credentials_meta.klaviyo_server_enabled = true.
3. Map events: Admaxxer’s Purchase → Klaviyo’s Placed Order, InitiateCheckout → Started Checkout, etc. Defaults match Klaviyo’s standard event taxonomy.
4. Save.

How to verify

1. Place a test order with a Klaviyo-known email.
2. Open Klaviyo › Profile › search that email › Activity. The Placed Order event should appear within ~30 seconds with the $source property set to admaxxer-server-side (Admaxxer tags every server-side event for auditability).

Troubleshooting

• Events appear without revenue. The browser pixel didn’t capture the order value (the visitor session ended before checkout_completed). Server-side reads the order value from the Shopify webhook payload when the browser path is empty.
• 403 missing scope. The Klaviyo API key needs events:write. Mint a new private key at Klaviyo › Settings › API Keys with that scope and re-paste at /integrations/klaviyo.

Authoritative reference: developers.klaviyo.com/en/reference/create_event (Klaviyo Events API v2024-10-15).

Recovery rates — what to expect

Recovery is the share of conversions that only the server-side rail captured — the conversions that would have been invisible without server-side tracking. Across the Admaxxer DTC cohort:

The phrase you’ll see across Admaxxer’s marketing copy is “typically 20–40% recovery, TikTok ~40%.” That’s the hedged honest summary — individual brands will land inside that band based on their iOS share, ad-blocker rate, and which platforms drive their traffic.

Recovery is not the same as ROAS lift. Recovery makes the dashboard complete; the ROAS lift comes from feeding the ad platforms’ bidders the conversions they were missing, which improves bid efficiency over ~14 days. Most brands see CPA come down 5–15% on the recovered platform inside the first month.

vs. Stape, Elevar, Blotout — the cost math

Server-side tracking is sold as a separate, recurring add-on by every other DTC analytics stack:

The honest trade-off: Stape and Blotout give you more tag-level control. If you need to fire a custom server-side tag to a niche platform Admaxxer doesn’t support natively (LinkedIn Insight Tag, Reddit Pixel, Bing UET via server, etc.), Stape’s Server GTM is still the right tool. For the five platforms Admaxxer ships natively (Meta, Google, TikTok, Pinterest, Klaviyo), the configuration is already done — you flip a toggle, we forward.

First-party CNAME — the second half of the recovery stack

Server-side tracking moves the conversion forwarding off the browser. First-party CNAME moves the pixel itself onto your own domain — so cookies are first-party, the request goes to t.yourbrand.com (not a shared vendor CDN), and Safari ITP + ad blockers stop targeting it.

The two stack. Server-side recovers the events the browser pixel missed; first-party CNAME makes the browser pixel miss fewer events in the first place. Both are included on every plan from $9/mo.

Read the first-party CNAME setup guide →

Related Admaxxer documentation

• First-party CNAME setup — the companion recovery rail for the browser pixel.
• Pro Tracking overview — the reserved __admx_* goals fired automatically when server-side is on.
• Meta paste-token install — how to connect the Meta long-lived token Admaxxer uses for CAPI.
• Google Ads OAuth setup — refresh token + developer token wiring for Enhanced Conversions.
• TikTok paste-token install — access-token install for the TikTok Events API.
• Klaviyo API key setup — minting an events:write private key.
• Shopify Web Pixel architecture — the upstream browser-pixel layer for Shopify checkout events.
• Duplicate-payments troubleshooting — what to do if the event_id dedup contract is broken.
• Glossary: CAPI match rate — how Meta scores the identity coverage of your server-side events.

FAQ

How do I enable Meta CAPI on Admaxxer?

Open /integrations/meta-ads, scroll to Server-side conversions, toggle Forward to Meta CAPI on, save. The next conversion captured by the browser pixel will also fire server-side with the same event_id, and Meta will deduplicate automatically. No code change required. Verify in Meta Events Manager › your pixel › Test events — you should see Browser + Server with 1 deduplicated.

What is server-side tracking, plainly?

A second copy of every conversion event, sent from Admaxxer’s server directly to Meta’s / Google’s / TikTok’s / Pinterest’s / Klaviyo’s server-to-server API — in parallel with the browser pixel. iOS ATT, Safari ITP, and ad blockers can’t interfere with the server-to-server path, so the conversions they would have blocked still arrive. The two paths are deduplicated by event_id so the conversion counts once.

Does server-side tracking replace the browser pixel?

No. Server-side runs in parallel with the browser pixel. Most conversions reach the ad platform through the browser pixel just fine; server-side recovers the subset that doesn’t (typically 20–40% on Meta/TikTok/Pinterest, less on Google). The two paths share an event_id and the ad platform deduplicates them.

How much recovery should I expect?

Typically 20–40% across Meta + TikTok + Pinterest, with TikTok the highest (~40%) because the TikTok in-app browser is the most restrictive. Google Enhanced Conversions for Web is lower (10–25%) because Google has first-party cookies on most of the web. Klaviyo is 15–25%. Individual brands land inside these bands based on their iOS share, ad-blocker rate, and traffic mix.

Will I see duplicate conversions on Meta / Google / TikTok / Pinterest?

No, if Admaxxer is the only pixel firing for that conversion. Browser + server fire with the same event_id and the ad platform deduplicates automatically — this is the contract Meta, Google, TikTok, and Pinterest all publish in their server-API docs. If you do see duplicates, it’s almost always because a second pixel install (theme.liquid + GTM, or two Admaxxer workspaces, or Stape + Admaxxer in parallel) is firing the same conversion with a different event_id. See /documentation/troubleshoot/duplicate-payments.

Is server-side tracking GDPR / CCPA compliant?

Yes, when the visitor has granted analytics + marketing consent. Admaxxer honors the consent state captured by the browser pixel — if a visitor opted out, the server-side rail doesn’t fire either. PII (email, phone, name, address) is SHA-256 hashed server-side before the POST so it never crosses the wire in cleartext. The hashed payloads are what Meta, Google, TikTok, and Pinterest accept under their server-API specs.

How is this different from Stape / Elevar / Blotout?

Stape, Elevar, and Blotout are tag-management products — they let you wire arbitrary server-side tags via Google Tag Manager Server (Stape, Blotout) or a Shopify-specific GTM layer (Elevar). They charge $20–500/mo on top of your attribution tool. Admaxxer bundles the five most-used server-side endpoints (Meta, Google, TikTok, Pinterest, Klaviyo) into the analytics + attribution + AI agent stack from $9/mo, no add-on fee. If you need to fire a custom server-side tag to a platform Admaxxer doesn’t natively support, Stape is still the right tool for that specific need.

Why is my Meta Event Match Quality still yellow after I enabled CAPI?

Match Quality reflects identity coverage, not deduplication coverage. Server-side recovers the conversion volume; Match Quality is about which identifiers (hashed email, phone, last name, zip) are attached to that conversion. Admaxxer forwards every identifier the browser pixel captured — if Shopify checkout doesn’t collect phone, Meta can’t match on phone. Enable phone capture in Shopify checkout, and the Match Quality score will climb within 24 hours.

What if my conversion isn’t one of the defaults (Purchase, InitiateCheckout, AddToCart, Lead)?

Custom events are supported. On the integration page (/integrations/meta-ads etc.) you can map any Admaxxer event name to any platform event name — including custom Meta Conversions API events and custom Klaviyo metric names. The event_id contract is preserved across custom names.

Does server-side tracking work for non-DTC use cases (lead gen, SaaS, agencies)?

Yes. Lead-gen advertisers benefit the most from Google Enhanced Conversions for Web (offline conversion uploads to close the loop between an ad click and a CRM-marked qualified lead). SaaS brands using Stripe + Paddle + Lemon Squeezy + Polar + Dodo as their revenue source get server-side firing on subscription events automatically. Agencies managing multiple brands flip the toggle per workspace.

Turn server-side tracking on today

If your Admaxxer workspace is already connected to Meta / Google / TikTok / Pinterest / Klaviyo, server-side tracking is one toggle away on each integration page. The forwarding starts immediately; you don’t need to redeploy or change a single line of pixel code. Most brands see Meta Event Match Quality climb from yellow to green inside 48 hours.

Enable Meta CAPI · Enable Google EC · Enable TikTok Events API · Enable Pinterest Conversions API · Enable Klaviyo server-side