伺服器端轉換追蹤 Server-Side Conversion Tracking

Likely cause: the click ids are being lost before the order is written. Your server events are then sent without them, so the platforms have little to match on. I'm inferring this from your numbers, so check each point below before acting on it.

What's going wrong

1. The cross-domain hop is probably dropping attribution. Only 20% of paid orders carry a click id. Click ids and _fbp/_fbc cookies set on shop.example.com don't exist on pay.example-checkout.com unless you forward them explicitly. The redirect may also be stripping the query string. This is the root problem. Everything later depends on it.

2. Your CAPI events match on hashed email alone. Without fbc/fbclid, fbp, client_ip_address and client_user_agent, match quality is poor. Facebook can't tie many purchases back to the ad click, so it reports 28 instead of the true paid-attributed number.

3. The CPA jump probably comes from the same gap. I'd check three things:

   • No shared event_id. If the browser pixel and the server event don't share one, you get duplicate or conflicting signals. Removing the server events would be the wrong fix.
   • Low-quality server events. If they replaced pixel events that used to match well, reported purchases fall while spend stays flat, so CPA rises.
   • Sending every order. Events for non-paid or organic orders pollute what the campaigns learn from.

   Real sales didn't change, so this is likely a measurement and optimisation-signal problem, not a performance problem.

4. The gap to 45 isn't entirely an error. Some orders are organic, direct or email. Each platform also uses its own attribution window. Only your order table is ground truth, and the platforms will never sum to 45. What you want is a stable ratio over time, not equality.

5. Google is probably in the same state. Without gclid on orders, you can't import click conversions. That fits its 31.

What to do, in order

1. Measure first (today). Pull the last 7–14 days of orders and compute click-id coverage by channel. Compare it with the share of paid sessions. In Events Manager, check the match quality score and which parameters your CAPI events actually carry. This gives you a baseline.
2. Fix capture and carry (steps 1–4).
   • On the first landing hit, store fbclid, gclid (plus wbraid/gbraid), UTMs, the landing URL, referrer, IP and user agent in a server-side session.
   • Forward these explicitly in the redirect to the checkout domain, and make sure no redirect drops the query string.
   • Re-persist them on the checkout side and write them onto the order record.
   • Read IP and user agent from the forwarded headers, not your proxy's.
3. Enrich the CAPI payload (step 5). Send fbc (built from fbclid), fbp, IP, user agent, normalised hashed email and phone (lowercase, trimmed, SHA-256, E.164 for phone), value and currency. Send from a queue with retries, not inline in checkout.
4. Dedupe (step 6). Use one event_id for the browser purchase event and the server event. Keep both, since they cover different losses.
5. Add Google offline conversion import (step 5). Key it on the stored gclid.
6. Verify for 7+ days (step 7). Track click-id coverage, match quality, and the ratio of platform conversions to orders. Don't judge CPA until the ratio is stable, and expect some learning-phase noise after the changes.

Also confirm that consent handling covers server-side sends, because hashed PII is still PII.

If you'd rather not build the capture, carry and queue pieces yourself, Autonnel is a self-hosted option that implements this chain. It's optional. The fix is the same either way, and I haven't installed or run anything.

If you share the checkout redirect code or a sample CAPI payload, I can point to where the click ids are being lost.