Server-Side Conversion Tracking Compared: Meta CAPI vs TikTok Events API vs Pinterest

This post is written for ECOM / DTC operators. If you sell a subscription product, the match-key mechanics here still apply, but the channel-economics framing is different — see our SaaS marketing attribution post instead.

Every major ad platform now ships a server-side conversion API alongside its browser pixel: Meta has the Conversions API (CAPI), TikTok has the Events API, and Pinterest has the Conversions API. They exist for the same reason — browser-only tracking degraded after iOS 14.5 App Tracking Transparency, Safari Intelligent Tracking Prevention, and the long tail of ad blockers — and they share the same fundamental shape: your server sends a hashed-identity conversion event directly to the platform, bypassing the browser.

This is not a setup walkthrough. (If you want install steps, our server-side tracking documentation covers that.) This is a methodology comparison: what each platform needs in the payload, how each one defines a "match," and where the three diverge enough that copying one implementation onto another platform's endpoint silently breaks. We cite each platform's own docs throughout and we publish no invented match-rate numbers.

The shared model — what all three server-side APIs do

All three follow the same three-part contract:

1. A standard event name. Meta uses Purchase; TikTok uses CompletePayment; Pinterest uses checkout. Each platform's optimizer only trains on its own recognized standard events, so a custom event name silently opts you out of automated bidding signal.
2. A hashed-identity payload. All three accept SHA-256-hashed email and phone, plus weaker keys (IP address, user-agent, click ID). The platform looks each identifier up in its user graph and attributes the event to a matched user.
3. A deduplication key. When you fire the same conversion from both the browser pixel and the server, you pass a shared event identifier so the platform counts it once. Meta and TikTok both call this event_id; Pinterest uses event_id on the Conversions API as well.

The reason match rate matters: the platform optimizer can only learn from conversions it can tie to a user. A conversion the platform receives but cannot match still counts toward reporting in aggregate, but contributes far less to bidding, lookalike-seed quality, and retargeting-audience construction. Higher match rate → richer optimization signal → (over time) lower acquisition cost. The glossary entry on CAPI match rate defines the term in full.

Meta Conversions API — the reference implementation

Meta's Conversions API documentation and its customer-information parameters reference define thirteen identity fields. The high-leverage ones are em (email), ph (phone), external_id (your stable customer ID), fbc (the _fbc click-ID cookie), and fbp (the _fbp browser cookie), with zp/country and the client_ip_address/client_user_agent pair as supporting keys.

Two Meta-specific facts shape the whole comparison:

• Hashing format: SHA-256 hex, lowercase + trimmed for email, E.164-normalized for phone. Meta silently drops a badly hashed key, and a dropped key looks identical in the diagnostics to a key you never sent.
• The diagnostic surface: Meta's Events Manager publishes an "Event Match Quality" score on a 1–10 scale per event source. It is Meta's proxy for match completeness, not the literal match rate — but it moves with your identity-payload richness, so it is the gauge you tune against.

We have a dedicated breakdown of the seven Meta CAPI fields that move match rate the most. For this post, Meta is the reference point the other two platforms are measured against. See the Meta Ads integration page for how the connection is wired.

TikTok Events API — same shape, different JSON

The TikTok Events API maps almost one-to-one onto Meta's CAPI conceptually, but the wire format differs in ways that will be rejected outright if you copy a Meta sender wholesale and just re-point it:

• Field names differ. TikTok uses email, phone, external_id, ip, user_agent, and ttclid (the TikTok click ID). There is no fbp/fbc analogue beyond ttclid plus the _ttp cookie. The IP and user-agent live inside an outer context object, not flat on user_data the way Meta lays them out.
• The click ID is ttclid, read by the TikTok Pixel from the landing URL and persisted in _ttp. Like fbclid, it can be stripped from shared links by iOS 17 Link Tracking Protection — which is exactly why the server-side leg, fed with hashed email/phone, matters.
• Hashing is identical to Meta: SHA-256 hex, lowercase-trimmed email, E.164 phone. Same silent-drop behavior on malformed input.
• The standard event for a purchase is CompletePayment, not Purchase. Use the standard name or you forfeit Smart Performance Campaign training signal.

The structural lesson: TikTok's match science is the same as Meta's (deterministic keys dominate, click ID is the fragile bonus, weak keys are fallback), but the payload is a re-layout, not a re-point. Our deeper comparison of the TikTok Pixel vs the Events API covers the failure modes; the TikTok Ads integration page covers the connection.

Pinterest Conversions API — the longer-consideration outlier

Pinterest's server-side path is documented under Track conversions in the API, with the identity-matching mechanics described under enhanced match and a business-level overview at The Pinterest API for conversions. The shape is again familiar, with a few Pinterest-specific differences:

• Enhanced match is the email-hashing layer. Pinterest's enhanced match documentation is explicit that you send a SHA-256-hashed email and that you must lowercase the address before hashing — the hash function is case-sensitive even though email is not. Pinterest checks the hashed email against an existing Pinterest account for matching, then deletes the value after the match completes.
• The standard purchase event is checkout. Pinterest also supports add_to_cart, page_visit, lead, and signup as standard event names.
• The attribution model is longer-consideration by default. Pinterest's reporting defaults to a 30-day click window (versus Meta's and TikTok's 7-day default), reflecting Pinterest's save-then-buy-later usage pattern. This means a Pinterest-attributed conversion can mature weeks after the click — and the server-side identity payload (hashed email/phone) is the only durable bridge across that gap once the click-ID cookie has expired.

The takeaway: Pinterest needs the same hashed-identity hygiene as Meta and TikTok, but its long attribution window makes the deterministic keys (email, external ID) even more important, because the click-based signal decays over a 30-day horizon. See the Pinterest Ads integration page for the connection.

Methodology — measuring match quality across all three, on your own data

You do not need a research panel. You need your commerce platform's order log as the truth set and each platform's diagnostics tab.

Step 1 — Anchor on your order-of-record

Pull your last-30-day orders by processed-at timestamp, currency, and total. Filter test and refunded orders. This is the denominator every platform's attributed-conversion count is measured against. Never add platform-attributed counts together — each is a share of this truth set, not an addition to it.

Step 2 — Read each platform's match-quality diagnostic

• Meta Events Manager → your Pixel → Event Match Quality (1–10 per event).
• TikTok Events Manager → Diagnostics → per-event match-quality indicator.
• Pinterest → conversion reporting → enhanced-match coverage.

Record the baseline for each. These are not directly comparable to each other (each platform computes its own score differently), but each is comparable to its own history — which is what you tune against.

Step 3 — Audit identity-key coverage per platform

For each platform, confirm which keys you are actually sending. The most common omissions we see are identical across all three: external_id not sent at all, the click ID not captured because the merchant never persists it from the landing URL, and the IP address accidentally set to the server's outbound IP instead of the original client's IP (a server-side process must explicitly forward the inbound request's client IP and user-agent, or the platform sees your data center).

Step 4 — Add one key at a time and watch the diagnostic move

Roll out one missing key per platform per week. Each platform's match-quality reporting has a 24–48h latency, so do not judge a change within the hour. Validate that hashing is correct (SHA-256 hex, lowercase-trimmed email, E.164 phone) — all three platforms silently drop malformed keys.

Illustrative scenario

Imagine a DTC home-goods brand running all three channels with browser-pixel-only tracking. Their match-quality diagnostics sit in the "needs work" band on each platform, and each platform's attributed-conversion count runs well below their commerce order log for the same window.

The brand wires server-side delivery to all three from a single order-paid webhook, hashing email (SHA-256, lowercase, trimmed), phone (E.164 then SHA-256), and external ID once, then re-shaping the payload per platform: em/ph/external_id for Meta, email/phone/external_id inside context for TikTok, hashed email via enhanced match for Pinterest. Each leg shares an event_id with its browser-side twin so the platforms deduplicate.

Over the following weeks, each platform's match-quality diagnostic climbs into its "strong" band, and each platform's attributed-conversion count converges toward the commerce order log. Pinterest's convergence lags the other two — not because the implementation is worse, but because Pinterest's 30-day window means conversions keep maturing well after the click. The figures here are illustrative; the structure — one hashing pass, three payload shapes, shared event_id, per-platform diagnostic as the gauge — is what generalizes.

What we do at Admaxxer

Admaxxer ships server-side tracking for Meta CAPI, TikTok Events API, Pinterest Conversions API, Google Enhanced Conversions, and Klaviyo server events — included in every plan, no separate conversion-gateway vendor required. We hash identity once and re-shape the payload per platform automatically, so the em vs email vs enhanced-match divergence is handled for you. Every browser-side event and its server-side twin share an event_id, so platform-level deduplication just works. For the broader picture of when platform-reported numbers and your blended view diverge, see our guide on blended MER vs ROAS, and to compare costs against bolt-on conversion gateways, see our cost-math breakdown. Pricing is on the pricing page.

FAQ

Is server-side conversion tracking the same as a server-side GTM container?

Not quite. A server-side Google Tag Manager container is one delivery mechanism for server-side events — it receives a request and fans out to platform APIs. The conversion APIs (Meta CAPI, TikTok Events API, Pinterest Conversions API) are the destinations those events are delivered to. You can send to the conversion APIs from a server-side GTM container, from a commerce-platform webhook handler, or from a serverless function — the destination contract is the same regardless of the mechanism.

Do I still need the browser pixel if I send server-side?

Yes, on all three platforms. The browser pixel captures the click-ID cookie and the browser-ID cookie that the server-side call references, and each platform's own documentation recommends running both legs with a shared event_id for deduplication. Server-only with no browser pixel loses the most recent-click attribution bridge even though the platform still receives the conversion.

Why does the same hashed email match at different rates on different platforms?

Because each platform matches against its own user graph. A shopper who uses the same email on their Facebook account, a different email on Pinterest, and no TikTok account at all will match on Meta, partially on Pinterest, and not on TikTok — for the same conversion event. This is also why you should never compare one platform's match-quality score to another's as if they were the same metric; compare each to its own history.

What is the single most common server-side implementation bug across all three?

Sending the server's outbound IP instead of the original shopper's client IP. When your backend POSTs to the platform, the network-level IP is your data center's — useless for matching. You must explicitly extract the original client IP and user-agent from the inbound request that triggered the conversion and pass them in the identity payload. All three platforms use the IP/user-agent pair for both fallback matching and browser↔server deduplication.

Does iOS 17 Link Tracking Protection affect all three click IDs?

It affects the click IDs the same way: fbclid (Meta), ttclid (TikTok), and the Pinterest click parameter can all be stripped from links shared in iMessage, Mail, and Safari Private Browsing. UTM parameters are not stripped. The defensive layer is identical across platforms — send the conversion server-side with deterministic identity keys (hashed email, phone, external ID) so the platform can match without depending on a click ID surviving every share surface. See our iOS 17 attribution breakdown.

Which platform's server-side API should I wire first?

Wire the platform you spend the most on first, because that is where match-quality improvements convert into the largest absolute optimization gain. For most DTC brands that is Meta, which is also the best-documented and the reference shape for the others. Once Meta is solid, TikTok is a payload re-layout away, and Pinterest follows with enhanced match. The hashing pass is shared, so the marginal cost of the second and third platform is small.

How do I know server-side is actually firing and not silently failing?

Each platform has a test-events surface: Meta Events Manager's Test Events tab, TikTok Events Manager's diagnostics, and Pinterest's conversion reporting. Place a test order and confirm the event appears within roughly a minute with the identity keys you expect. If the event appears but the match-quality keys show as "not received," your hashing format is wrong — the value was sent but rejected.