Server-Side Tracking Pipeline Audit

Audits the entire server-side measurement pipeline that backs every paid channel's modeled conversion data. Without server-side tracking in 2026, expect 30-40% conversion data loss from iOS ATT, ITP, and aggressive ad blockers — that's the gap between what's actually happening and what your bid algorithms can see.

This sub-skill is technical and deep. It's NOT the same as ads-attribution, which audits the attribution model sitting on top of these events.

Process

1. Collect server-side stack inventory: sGTM container info, Meta CAPI

integration method (Gateway / direct / partner integration), event schema documentation, hosting infrastructure (Cloud Run / GCS / AWS)

1. Read ads/references/conversion-tracking.md for cross-platform baseline
2. Test event flow: trigger known events → verify they appear in BOTH

client-side (Pixel Helper / Tag Assistant) AND server-side (Events Manager test events / GA4 DebugView)

1. Audit deduplication, hashing, and parameter completeness
2. Score health PASS / WARNING / FAIL per surface
3. Generate findings report

What to Analyze

Server-Side Google Tag Manager (sGTM)

• sGTM container deployed — hosted on Cloud Run, GCS, App Engine, or

custom infrastructure. Self-hosted preferred over Google-managed for cost and data residency

• Custom domain configured (tags.example.com) — first-party domain

avoids ITP / ad-blocker blocking that hits googletagmanager.com

• Client-side GTM forwards to sGTM correctly; cookies, IP, user-agent

preserved

• GA4 events flow via sGTM (no direct client → GA4 fallback)
• Conversion Linker tag enabled — preserves Google click IDs (gclid,

gbraid, wbraid) across cross-domain navigation

• Server-side privacy filters — strip non-essential PII before forwarding

to analytics; only hash + forward what's needed for matching

Meta CAPI / CAPI Gateway

• CAPI active — Conversions API server-to-server alongside the Pixel
• CAPI Gateway preferred over manual server implementation (auto-

hashing, parameter coverage, lower maintenance)

• All major events server-side: PageView, ViewContent, AddToCart,

InitiateCheckout, Purchase, Lead, CompleteRegistration

• Event Match Quality (EMQ) ≥8.0 for Purchase — confirm via Events

Manager → Overview → Data sources

• customer_information parameters sent server-side: em (email), ph

(phone), fn/ln (name), ct/st/zp (geo), external_id, client_ip_address, client_user_agent, fbc, fbp

• Hashing: lowercased + trimmed SHA-256 for PII fields BEFORE send
• action_source field set per event (website, app, physical_store,

email, system_generated)

Event Deduplication

• event_id generated client-side, included in BOTH the Pixel event AND

the CAPI / sGTM payload — Meta + Google both dedupe on this

• Dedup rate ≥90% measured in Events Manager → Diagnostics
• Timestamp alignment — server-side event timestamp within 5 minutes

of client-side counterpart

• event_name consistency — server-side uses the same canonical event

names as client-side (don't rename in transit)

Server-Side Hit Ratio

• Server-side ≥80% of client-side hits for Purchase / Lead — anything

lower means iOS / ITP / ad-blocker data loss isn't being recovered

• Server-side >100% acceptable — means server-side captures conversions

the client-side missed (good — that's what server-side is for)

• Hit ratio monitored over time — drops below 60% indicate broken

server-side firing or missing event_id

Pixel / Tag Debug Walkthrough

When deployed, validate every event end-to-end:

• Facebook Pixel Helper (Chrome extension) shows the Pixel firing

client-side with correct event_name + event_id + value + currency

• Meta Events Manager → Test Events shows the CAPI event arriving server-

side with matching event_id and customer_information parameters populated

• Google Tag Assistant confirms client-side gtag firing
• GA4 DebugView confirms server-side event arriving with event params
• Network tab shows client → sGTM forwarding (not client → Google direct)
• `window.dataLayer` populates expected variables before any tag fires

Custom Event Taxonomy

• Canonical event names documented (e.g., purchase not Purchase or

PURCHASE or order_complete)

• Standard params per event: value, currency, content_ids,

content_type, num_items

• Custom params namespaced (cx_segment, cx_funnel_step) to avoid

collision with platform-standard params

• Schema versioned — when the taxonomy changes, bump a version param

so downstream platforms can handle the cutover

Hash Quality & PII Handling

• Email: lowercased + trimmed + SHA-256 (no other normalization)
• Phone: E.164 format + SHA-256 (e.g., +15551234567)
• Name: lowercased + trimmed + SHA-256 per first / last separately
• City / state / zip: lowercased + SHA-256
• NEVER hash already-hashed values — double-hashing breaks matching
• NEVER send plain PII server-side — only hashed
• GDPR / CPRA / CDPA compliance: confirm consent state is read before

sending PII server-side, even hashed

Key Thresholds

Output

Server-Side Tracking Health Score

Server-Side Tracking Health Score: XX/100 (Grade: X)

sGTM Pipeline:               XX/100  ████████░░  (20%)
CAPI / CAPI Gateway:         XX/100  ██████████  (25%)
Deduplication:               XX/100  █████████░  (15%)
Server-Side Hit Ratio:       XX/100  ████████░░  (15%)
Pixel Debug (6 events):      XX/100  ███████░░░  (10%)
Hash Quality / PII Handling: XX/100  ██████░░░░  (15%)

Deliverables

• SERVER-SIDE-TRACKING-AUDIT.md: Full pipeline findings
• Test-event reproduction log (which events validated end-to-end on which

date, with screenshots from Events Manager / DebugView)

• EMQ improvement roadmap (parameter-by-parameter)
• Hit-ratio dashboard recommendation
• Pre-launch checklist for any new platform integration (Amazon Marketing

Cloud, Apple Ads, TikTok Events API)