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 modelled 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 CAPI node so the browser-only gap is caught, and the documented dedup relationship makes the event_id pairing auditable instead of tribal knowledge.

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.

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

Every Meta Conversions API concept that matters for digital marketing agency operations is a typed object in the tracking map. Health state per node, audit cadence, and graph relationships to every other tracking-system node it touches — so a broken tag or misconfigured property is findable in seconds across your full book of clients.

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
The deduplication relationship to its browser Meta Pixel — modelled explicitly so the event_id / event_name pairing that prevents double-counting is documented, not guessed
Audit coverage: the tracking-map audit flags a Meta Pixel with no CAPI node on the map (the classic browser-only footgun) so the gap surfaces on the report
Per-client visibility: every client's CAPI setup, its source server, and when it was last verified, in one queryable graph

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 dataset ID, deduplication setup, and health status — so the server-side half of Meta tracking is modelled, not assumed.

Coming (V2)

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 every Meta Conversions APIobject as a typed tracking node, the agency can answer questions like "which clients have a misconfigured Meta Conversions APIsetup?" or "which Meta Conversions APIconfigurations changed last quarter?" from a single graph query.

The V1 surface is intentionally manual — agencies enter the configuration at onboarding rather than auto-importing. This forces explicit verification at the exact moment the agency takes over the client's tracking, catching most of the commonGotchas listed above before they become production issues. V2 will add API-based sync where the underlying platform supports it; we won't add sync where the underlying API doesn't expose the right data.

When to use this in your client onboarding flow

The standard pattern for digital marketing agencies running Phloz: at every new client onboarding (see the client onboarding audit use case), spend 30 minutes documenting the client's Meta Conversions APIconfiguration as Phloz nodes — pixel IDs, tracking-code installations, conversion-action setup, the relationships to other systems. Verify each one fires by triggering a test event. Set the "verified at" timestamp on each node. Schedule a quarterly verification task on the agency engineer who owns tracking.

The 30 minutes at onboarding catches 90 percent of the tracking issues that would otherwise surface 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 modelled 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 CAPI node so the browser-only gap is caught, and the documented dedup relationship makes the event_id pairing auditable instead of tribal knowledge.
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 server-side and adjacent tools Phloz integrates with.

Start your free trial

14 days free · No credit card · Starter tier free forever