Conversions API
A Conversions API (CAPI on Meta, Conversions API on Google) sends conversion events from your servers directly to the ad platform — not from the shopper’s browser. This is the modern, privacy-resilient way to report conversions. Active Reach handles both ends.
Why server-side reporting matters
Browser-only tracking (the pixel) loses events to:
- Ad blockers
- iOS privacy restrictions (ITP)
- Browser cookie expiry
- Network failures on the user’s device
Server-side reporting bypasses all of that. The shopper’s purchase happens, your server logs it, Active Reach forwards it to Meta + Google directly. The platforms then attribute the conversion to whichever ad caused the visit (using their own server-side matching).
The two work together — most setups keep the pixel as a primary signal and use the API as a deduplication-safe backup that catches everything the pixel misses.
What gets forwarded
| Event | Sent to Meta | Sent to Google |
|---|---|---|
transaction.purchase | Purchase | purchase |
cart.added | AddToCart | add_to_cart |
product.viewed | ViewContent | view_item |
checkout.started | InitiateCheckout | begin_checkout |
payment_info.added | AddPaymentInfo | add_payment_info |
user.signed_up | CompleteRegistration | sign_up |
Lead events from lead forms are also forwarded automatically.
How attribution works
The platform needs to know which ad / click caused the conversion. Active Reach attaches matching parameters automatically:
| Parameter | What it does |
|---|---|
fbc (Meta click ID) | Captured from the URL when the shopper arrived from a Meta ad; persisted in a cookie |
fbp (Meta browser ID) | Set by the Meta pixel; read server-side to forward |
gclid (Google click ID) | Same idea, Google side |
| Hashed user identifiers | Email and phone are SHA-256 hashed and forwarded for cross-device matching |
The hashing happens server-side before the event leaves Active Reach. Raw PII never reaches the ad platform; the platform unhashes against its own user graph.
Consent Mode v2
Active Reach implements Google Consent Mode v2 automatically. When a shopper hasn’t consented to advertising cookies:
- The event is still forwarded, but flagged with the consent state
- Google uses the event for conversion modelling (not for direct attribution to a user)
- Meta uses limited data per its own consent rules
When the shopper has consented, the event includes full identifiers for direct match.
You configure your consent banner at Settings → Privacy → Consent. Active Reach reads the consent state from the shopper’s session and tags every forwarded event accordingly.
Deduplication
When both the pixel (browser) and the API (server) report the same conversion, the platforms deduplicate using an event ID. Active Reach generates a stable event ID per business event and:
- The pixel fires with that event ID (when the pixel is reachable)
- The API forwards with the same event ID
The platform sees both, recognises the ID, and counts the conversion once. You always get the more reliable signal — if the pixel made it, the platform uses pixel-side context; if not, the API result is the truth.
Connecting CAPI / Conversions API
Connect your ad account
If you haven’t already, link Meta and / or Google at Ads → Settings → Ad accounts. The OAuth flow grants the permissions needed for both campaign management and Conversions reporting.
Provision conversion actions (Google)
Google requires you to define each conversion action you want to report. Active Reach provisions a standard set automatically: purchase, add_to_cart, view_item, begin_checkout, add_payment_info, sign_up. You can add custom actions at Ads → Conversions API → Custom actions.
Map your events
Active Reach maps standard Aegis events to standard platform events automatically (see the table above). To forward a custom event, map it at Ads → Conversions API → Event mapping.
Verify
Trigger a test event (use the Send test button in the conversions admin). Both platforms have a dashboard that shows server-side events in real time:
- Meta: Events Manager → Test Events
- Google: Google Ads → Tools → Conversions → Diagnostics
You should see your test event appear within seconds.
Real-time vs batch
Conversion events are forwarded in two ways:
| Mode | Latency | Used for |
|---|---|---|
| Real-time | < 5 seconds | Purchase, payment-info, sign-up — high-value events the platforms need to see fast |
| Batched | Up to 1 hour | View, add-to-cart, browse — high-volume events that don’t need instant freshness |
The platforms charge slightly differently for late events (>7 days = lower match quality), so anything older than 1 day is forwarded with a event_time set to the original time, not the forward time.
Reading the diagnostics
Both platforms grade your conversion reporting. Aim for:
- Match quality — what % of events have enough identifier data to attribute. Target: above 7/10 on Meta, “Good” on Google.
- Event coverage — what % of expected events are arriving. Pixel + API combined should hit ~100%.
- Deduplication rate — what % of events were deduped (i.e. both pixel + API reported them). Higher is better — means redundancy is working.
Active Reach surfaces these at Ads → Conversions API → Health.
What’s next
- Retargeting cascade — uses the same conversion events for suppression
- DPA & Shopping — optimisation reads from CAPI signals
- Webhooks → security — for inbound platform webhooks (e.g. lead-form submissions)