Server-side

Meta Conversions API integration for digital marketing agencies

Browser-only Meta Pixel events lose 15–30% of conversions on iOS — ad blockers, ITP, and Safari's cookie limits eat the signal Meta's bidding depends on. The Conversions API recovers it by sending events server-to-server, but it's the single most error-prone thing an agency sets up: a missing deduplication key double-counts every purchase, a wrong dataset ID sends events into the void, and a low event-match quality score quietly starves the algorithm. Modelling the CAPI endpoint as a typed node — wired to its pixel and server — is what turns "we set up CAPI" into something an agency can actually verify.

How Phloz models Meta Conversions API

What Phloz records about Meta Conversions API on each client's tracking map, and what it doesn't. Only GA4, Google Tag Manager and Google Ads connect to Phloz (read-only, through a connected Google account); everything else is recorded by your team. Health states are set by the person who checks, the structural audit re-runs weekly, and graph relationships show what each node connects to — so a node marked broken or overdue for verification shows up in the cross-client tracking-health view.

  • Meta CAPI endpoint as a typed node: dataset (pixel) ID, the server that sends events (server-side GTM, a CAPI gateway, or a direct integration), and health status
  • An edge to its browser Meta Pixel (the same pixel ID) — Phloz doesn't record or check event_id deduplication, so note the pairing on the node and verify it in Events Manager
  • Audit coverage: the tracking-map audit flags a Meta Pixel with no Conversions API path recorded (the classic browser-only footgun) so the gap surfaces on the report
  • Per-client visibility: the client's CAPI setup, its source server, and when it was last verified, on one map

Common Meta Conversions API configuration gotchas

The configuration mistakes agencies most often make with Meta Conversions API, surfaced here as a checklist agencies can run at every client onboarding. Honest, useful, not gated behind a sales pitch — these are real and you should audit for them regardless of whether you use Phloz.

  • Missing deduplication: if the same purchase fires from both the browser pixel and CAPI without a shared event_id, Meta counts it twice and inflates reported conversions. Match event_id + event_name on both surfaces and verify in Events Manager's deduplication view.
  • Low event-match quality: CAPI events sent without enough customer-information parameters (hashed email, phone, IP, click ID) score poorly and barely help bidding. Pass every available match key — the score is visible per event in Events Manager.
  • Dropped fbclid / click IDs: the Meta click identifier has to survive from the landing-page URL through to the server event, or attribution breaks. A redirect or a stripped query string silently kills it — verify the click ID reaches the CAPI payload end to end.

At launch (V1)

The Meta Conversions API endpoint appears as a typed node linked to its Meta Pixel and the server that sends events, with pixel and dataset IDs, the endpoint type (Meta's CAPI Gateway or a custom server), a test event code, and health status — so the server-side half of Meta tracking is modelled, not assumed.

Not built yet

Read event-match-quality and event-received signals from the Meta API directly into the node, so a CAPI that silently stopped sending is flagged before optimisation degrades.

Why we built the integration this way

Most agency CRMs treat third-party tools as text fields: "GA4 Property ID" goes in a custom column on the client record. That works at one or two clients and breaks at five. With Meta Conversions API recorded on each client's tracking map — as its own typed node where Phloz has one, as fields and notes where it doesn't — the agency can answer "is this client's Meta Conversions API setup documented, and when was it last verified?" per client, and see every client ranked by tracking health.

Most of it is entered by hand at onboarding: only GA4 properties, GTM containers and Google Ads accounts can be imported from a connected Google account, and nothing syncs afterwards. The manual pass forces explicit verification at the exact moment the agency takes over the client's tracking — the cheapest moment to catch the gotchas listed above, before they become production issues.

When to use this in your client onboarding flow

The pattern we recommend: at every new client onboarding (see the client onboarding audit use case), spend 30 minutes documenting the client's Meta Conversions API configuration on the tracking map — IDs, tracking-code installations, conversion setup, the relationships to other systems. Verify each one fires by triggering a test event, then mark the node verified so the date is recorded. Add a recurring task (monthly, say) for the re-check, assigned to whoever owns tracking — the audit flags anything unverified for 30+ days either way.

Thirty minutes at onboarding costs far less than finding the same tracking issues during the first month of campaign optimisation — when finding them would mean a refund conversation. See the broader tracking infrastructure map use case for the agency-wide pattern.

Frequently asked questions

The three questions agencies ask most often about Phloz's Meta Conversions API integration. Honest answers — same data we'd give a friend evaluating the integration.

Do we still need the browser Meta Pixel if we run CAPI?
Yes — Meta recommends running both with deduplication. The browser pixel captures signals (like granular page behaviour) that are awkward to send server-side, while CAPI recovers the conversions the browser loses to iOS and ad blockers. The two are complementary, not either/or — which is exactly why the deduplication wiring between them has to be documented and verified, not assumed.
How does Phloz model the connection between the Pixel and CAPI?
As an explicit relationship on the tracking map: the Meta CAPI node links to its browser Meta Pixel (the same dataset) and to the server that sends its events. The audit engine flags a pixel with no Conversions API path recorded, so the browser-only gap is caught. Deduplication itself isn't checked — note the event_id pairing on the node and verify it in Events Manager.
Does Phloz send Conversions API events itself?
No — Phloz models and audits the CAPI setup, it isn't the server that emits events. The events come from your server-side GTM container, a CAPI gateway, or a direct server integration; Phloz tracks which one, whether it's healthy, and when it was last verified. That separation is deliberate: the tracking map stays the source of truth about the setup, independent of whichever tool moves the events.

Other integrations

Other server-side and adjacent tools, and how Phloz handles each.

Start your free trial

14 days free for new workspaces · No credit card · Starter tier free forever