Conversion forwarding

Conversion tracking tells us that a click turned into revenue. Conversion forwarding pushes that fact back out to the ad surfaces — Meta Conversions API, GA4 Measurement Protocol, and Mixpanel server-track — so the optimisation algorithms see it even when the browser pixel didn’t fire.

Why bother? Pixel-only attribution drops 20-40% of conversions to Safari ITP, ad-blockers, and consent banners. Server-side forwarding closes most of that gap because it runs from your backend after the purchase has already happened.

The flow is:

1. Capture the click_id Elido returned on the original redirect.
2. Persist it on your order / subscription record.
3. When the conversion fires, POST it to /v1/conversions with the click id.
4. Elido echoes the event server-to-server to whichever destinations you’ve wired.

1. Capture the click id

Every redirect response carries an X-Elido-Click-Id header. The SDKs surface it on the same response object; raw HTTP works too:

curl -sI https://elido.me/launch | grep -i click-id
# X-Elido-Click-Id: clk_01HYZ7T8WV6KQX3M

Stash that id on the destination page, ideally in a first-party cookie (elido_click_id, 90-day TTL) so you can read it back at checkout.

2. Wire your conversion endpoint

curl -X PUT \
  https://api.elido.app/v1/workspaces/1/conversion-forwarding \
  -H "Authorization: Bearer $ELIDO_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "meta_capi": {
      "pixel_id": "1234567890",
      "access_token": "EAA…",
      "test_event_code": null
    },
    "ga4_mp": {
      "measurement_id": "G-ABC123",
      "api_secret": "abc_def_ghi"
    },
    "mixpanel": {
      "project_token": "pm_…",
      "service_account": "sa@team.mixpanel.com"
    }
  }'

You can wire any subset; missing surfaces are skipped silently.

3. POST conversions

curl -X POST \
  https://api.elido.app/v1/conversions \
  -H "Authorization: Bearer $ELIDO_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "click_id":   "clk_01HYZ7T8WV6KQX3M",
    "event_name": "purchase",
    "event_id":   "ord_98231",
    "value":      89.00,
    "currency":   "EUR",
    "user": {
      "email":  "shopper@example.com",
      "phone":  "+4915123456789",
      "external_id": "cust_5128"
    }
  }'

event_id is your idempotency key — the same id submitted twice is deduped, both at Elido and on the Meta/GA4/Mixpanel side. Use the order id, the subscription id, or any stable identifier.

User identity fields are hashed (SHA-256) before forwarding to Meta and GA4. Mixpanel receives the raw external_id only.

4. What gets forwarded

UTMs are pulled from the click row that matches click_id, so the forwarded event always carries the original campaign context — even if the user wandered around the site for an hour before checking out.

5. Verify the round-trip

The dashboard’s Conversions → Forwarding tab shows one row per forwarded event with the destination, response code, latency, and the raw upstream payload. Failed forwards retry with exponential backoff for up to 24 hours.

For Meta specifically, set test_event_code and confirm events land in Events Manager → Test Events before flipping production traffic.

6. Edge cases

• Click lookup miss — if click_id doesn’t match a known click (typo, expired beyond retention, wrong workspace), the conversion is still recorded against the workspace but forwarded with empty UTM context. Useful for catch-all attribution.
• Refunds — POST the same event_id with event_name: "refund". Meta and GA4 treat this as a negative conversion; Mixpanel records a separate event you can subtract in your funnels.
• Multi-touch — Elido stores up to 30 days of clicks per user. Default attribution is last-touch within the window; set attribution_model on the workspace to first_touch or position_based for alternatives.

See also

• Conversion tracking — the inbound side (Stripe / Shopify webhooks)
• UTM templates — what’s actually attached to the forwarded event
• Webhooks — the broader pixel system