Here's how to implement server-side conversion tracking: capture the conversion event on your backend, format it to match each ad platform's schema, hash the customer identifiers, attach a shared event ID for deduplication against your pixel, then test and monitor the feed. Below is what each of those steps actually involves.
How do you capture the conversion event on your server?
The event needs to fire from a system you control, not the browser. For an e-commerce purchase, that usually means a webhook or backend hook triggered when an order is marked paid, not when the checkout page loads. Capture the order ID, value, currency, items, and customer contact fields (email, phone, name, address) at this point, since everything downstream depends on what you grab here.
How do you format the event for each ad platform's schema?
Each platform expects a different shape. At minimum:
Meta Conversions API needs event_name, event_time (Unix timestamp, GMT, under 7 days old), and action_source (website for browser-based, system_generated for backend-triggered). See Meta's Conversions API for the full parameter list.
TikTok Events API needs event, event_id, event_time (UTC), and event_source_url, plus the ttclid click identifier if you're capturing ad clicks. Full detail in TikTok's Events API.
Snap Conversions API tracks event type (Purchase, Add to Cart, Start Checkout, Sign Up) plus hashed identifiers. See Snap's Conversions API.
Google Enhanced Conversions needs at least one of a hashed email, hashed phone, or full address block, plus a gclid for click-based attribution. See Google's Enhanced Conversions.
Building one platform's schema correctly is a manageable project. Building four in parallel, and keeping all four current as each platform revises its own spec independently, is the part that turns into ongoing engineering overhead rather than a one-time task.
How do you hash customer identifiers before sending them?
Email, phone, and any other personal identifiers get hashed (SHA-256) before transmission, never sent in plaintext. Normalize first: lowercase the value, trim whitespace, format phone numbers to E.164. Skip normalization and the hash won't match what the platform computes on its own end, so the field silently contributes nothing to matching even though the event technically arrived. client_ip_address is the one Meta/TikTok/Snap field that stays in plaintext; hashing it breaks matching instead of protecting it.
How do you deduplicate against your pixel?
If you're running both a browser pixel and server-side events for the same conversion, both need to carry the same event_id. Meta, TikTok, and Snap all use this shared ID to collapse duplicate signals into one; without it, every conversion gets counted twice, which inflates reported ROAS and skews budget decisions. For the full mechanics of running both together, see running a pixel and a Conversion API at the same time and how event deduplication works.
How do you test and monitor it after launch?
Every platform provides a test-event tool (Meta's Test Events, TikTok's Events Manager test mode, and equivalents for Snap and Google), and it's worth using before sending production traffic. A minimal test Purchase event for Meta, for example, would include event_name: Purchase, event_time as a current Unix timestamp, action_source: website, a user_data block with at least a hashed em (email), and a custom_data block with currency and value. Send that through Meta's Test Events tool and you should see it appear within seconds, tagged with a match quality score; a score that's unexpectedly low almost always traces back to a hashing or normalization mistake rather than a platform-side problem. Run the equivalent shape through each platform's own test tool (TikTok requires ttclid or a hashed identifier to show a match; Snap and Google surface similar per-event diagnostics) before assuming the pipe is production-ready.
Passing the test-event check once isn't the finish line. Once live, match rate and delivery need ongoing monitoring, not a one-time check. The three failure points that account for most broken implementations are hashing errors (bad normalization), deduplication gaps (missing or mismatched event IDs), and missing identifiers (checkout not collecting enough contact fields to match against in the first place). A pipeline nobody is watching tends to degrade silently: match rates drop, events stop firing, or checkout changes break dedup logic, often weeks before anyone notices in the campaign data.
What does server-side conversion tracking cost to build and maintain?
A full multi-platform implementation typically runs 80 to 160 hours of engineering time across Meta, TikTok, Snap, and Google, before ongoing maintenance. That maintenance isn't optional: platform APIs change their schemas and validation rules on their own timelines, and each change needs a developer to adapt and retest. For teams weighing whether to build this in-house versus using infrastructure that already handles it, Journify runs this pipeline (capture, formatting, hashing, dedup, and monitoring, across Meta, TikTok, Snap, Google, and Amazon) as a live service, so the build and the ongoing maintenance both go away.
Frequently asked questions
Do I need a developer to implement server-side conversion tracking?
Yes, in some form. Even the initial event capture requires backend work, and each ad platform's API has its own authentication and schema requirements that need engineering time to implement correctly.
How long does it take to implement for one platform versus four?
A single platform is typically 20 to 40 hours of development work. Four platforms in parallel run 80 to 160 hours, since each has independent schema, authentication, and validation requirements.
What's the most common reason server-side tracking doesn't improve match rate?
Hashing errors from unnormalized data (unlowercased email, untrimmed whitespace, phone numbers not in E.164) are the most frequent cause. The event arrives at the platform but can't be matched to an existing user.
Can I run server-side tracking without a browser pixel?
Yes, but running both together with shared event IDs for deduplication generally produces better signal coverage than either alone, since each catches conversions the other misses.
For broader context on why this matters, see how signal loss affects Meta, TikTok, Snap, and Google differently and what a Conversion API actually is.
