Meta Conversions API Implementation, Done Properly
Server-side event delivery with real deduplication, verified customer matching, and a match quality score you can actually defend.
Get My Free CAPI Audit →Not ready to write it all out? Book a 15-minute discovery call →
Two Ways CAPI Fails
Most Meta CAPI setups we inherit are doing one of two things wrong, and both cost money.
The first is under-reporting. The pixel fires, CAPI does not, or CAPI fires with a thin payload — no hashed email, no `external_id`, no click ID. Meta's Events Manager shows a low Event Match Quality score, the algorithm cannot connect conversions back to the people who caused them, and your cost per acquisition drifts upward for reasons nobody can explain.
The second is double-counting. Pixel and CAPI both fire, but `event_id` is missing, inconsistent, or regenerated on each side. Meta counts the same purchase twice. Your reported ROAS looks excellent. Your bank account disagrees. Worse, the algorithm optimises toward a phantom.
Correct CAPI is not "turn on the integration." It is a shared event ID between browser and server, a consistent hashing scheme, persistent identifiers, and a deduplication result you have verified in the diagnostics tab — not assumed.
What We Build
Event Architecture
- Full purchase funnel: PageView, ViewContent, AddToCart, InitiateCheckout, Purchase, Lead
- Shared `event_id` generated once and passed to both pixel and server
- `event_source_url` and `action_source` set correctly per event
- Server-side firing on the order-confirmation hook, not the thank-you page render
Customer Matching
The single biggest lever on Event Match Quality.
- SHA-256 hashing of email, phone, first name, last name, city, postcode, country
- Normalisation before hashing — lowercase, trimmed, E.164 phone format
- Stable `external_id` persisted across sessions and devices
- `fbc` and `fbp` capture, including first-touch persistence beyond browser cookie limits
- Client IP and user agent forwarded server-side
Deduplication
- Verified in Events Manager diagnostics, not assumed from configuration
- Documented before/after event counts
- Handling for partial-consent scenarios where only one source fires
Consent Compliance
- Consent Mode v2 integration
- Denied consent → no identifiable data transmitted, full stop
- Documented data flow for your privacy policy and any DPA request
Monitoring
- Event Match Quality tracked per event type
- Alerting on delivery failures
- Reconciliation against your order table
Common Mistakes We Find
Patterns from audits we have run. If you recognise two or more, the gap is probably costing you more than it appears to.
`event_id` generated independently on each side.
Browser makes one, server makes another, Meta cannot match them, and every purchase counts twice. Reported ROAS looks excellent right up until you reconcile it against orders.
Hashing without normalising first.
`John@Example.com ` and `john@example.com` produce entirely different SHA-256 hashes. Trailing whitespace, capitals, and unformatted phone numbers silently destroy match rates while the integration reports success.
Purchase firing on thank-you page render.
Every refresh, every back-button return, every bookmarked confirmation page fires again. Server-side firing on the order hook is the fix.
`fbc` never persisted.
The click ID is captured on the landing page and lost by checkout, so attribution breaks on exactly the journeys you most want to measure.
Unhashed personal data in the payload.
Sending a raw email address to the Conversions API is both a policy violation and a GDPR problem. We have found it in production more than once.
How We Work
Step 01 — Diagnose
We pull your current Events Manager data, identify duplication and match-quality gaps, and quantify the impact.
Step 02 — Design
Event map, identifier strategy, hashing scheme, consent logic.
Step 03 — Implement
Server-side firing, dataLayer alignment, deduplication wiring.
Step 04 — Verify
Diagnostics review until deduplication is confirmed and EMQ has moved.
Step 05 — Document
Full technical handover.
What Happens Next
Step 01 — You hear back within 24 hours.
A real reply from the person who would do the work, not an autoresponder or a junior scheduling a call about a call.
Step 02 — We look before we talk.
Send us access or a URL and we review your actual setup first, so the conversation starts with findings instead of discovery questions.
Step 03 — 30 minutes, findings first.
We walk you through what we found and what it is costing. You get that regardless of whether you hire us.
Step 04 — A written scope, or an honest no.
If it is a fit, you get scope, timeline, and cost in writing. If it is not, we say so and point you somewhere better.
No retainer required. No minimum term. No obligation at any step.
CAPI Event Coverage
Server-side deduplication, external_id matching, and Consent Mode — zero data loss post-iOS.
The tracking setup Propulse delivered gave us visibility we never had before. For the first time, our ad platform was seeing real purchase data — not just a fraction of it. The ROAS impact was immediate.
Is This Right For You?
We would rather tell you now than after an invoice. Here is who this work pays off for, and who it does not.
A good fit if:
- You are doing €25,000+ per month in online revenue, where a few percent of recovered attribution is real money
- You are running paid media and the reported numbers do not match your bank
- You sell across more than one market, currency, or storefront
- You have a developer or agency who can act on what we find
- You want to own the implementation afterwards, not rent it
Probably not a fit if:
- You are early stage and validating the product — fix demand first, measure it later
- You want someone to manage ad spend day to day; we build the measurement layer, we are not a media buying agency
- You need it live this week; proper implementation has a validation phase and we will not skip it
- You want the cheapest quote — we are not it, and the cheapest tracking build usually gets rebuilt
Most engagements start from €1,500. We confirm scope and cost in the discovery call, before anything is committed.
Tell us about your setup. We respond within 24 hours.
Not ready to write it all out? Book a 15-minute discovery call →
Common
Questions
Open Events Manager, select your Purchase event, and check the Overlap section. If Meta reports a low deduplication rate while both pixel and server events are active, you are double-counting. We audit this for free and show you the numbers.
Meta rates matching from poor to great. The score is driven almost entirely by how many identifiers you send and how well they are normalised before hashing. Email plus phone plus `external_id` plus `fbc` moves it substantially. We report yours before and after.
Under Consent Mode v2, denied consent means we do not transmit identifiable customer data. Events can still be sent without personal identifiers where your legal basis allows, but attribution quality drops — correctly so. We configure this to your legal advice, not around it.
Usually, yes. Most broken implementations need `event_id` alignment and a proper hashing pipeline rather than a full rebuild. The audit tells us which.
We start with whatever you already have. The official plugin handles basic event delivery, but its payload is usually thin — limited customer parameters, no persistent `external_id`, and deduplication that is easy to misconfigure. Where the plugin gets you most of the way, we extend it. Where match quality is the bottleneck, we build the server-side implementation properly. The audit tells us which, and we explain the reasoning before doing either.
A standard implementation starts around €1,500, covering event architecture, hashing and matching, deduplication, and consent handling for a single storefront. Repairing an existing setup is usually less, because the diagnosis narrows the work. Multi-market implementations scale with the number of storefronts. You get a fixed number after the free audit.
Yes. Meta recommends running both, because they capture different signals — the pixel sees browser-side behaviour, the API sees confirmed server-side events. Running both with correct deduplication gives better coverage than either alone. Running both without deduplication double-counts every conversion, which is the failure we find most often.
Usually one to two weeks for a single storefront, including validation in Events Manager. The implementation itself is fast; the time goes into confirming deduplication is genuinely working and that Event Match Quality has moved, rather than assuming it from the configuration.
It improves the data your bidding algorithm optimises against, which usually improves performance — but the size of the effect depends entirely on how much you were losing before. If your current setup is already sending well-matched events, the gain is marginal. If you are under-reporting or double-counting, the change can be substantial. The audit quantifies your gap before you commit.
Event Match Quality is Meta's score for how reliably it can connect your events to real people. It is driven by how many customer identifiers you send and how well they are normalised before hashing — email, phone, `external_id`, and click IDs each move it. A low score means the algorithm cannot learn what your buyers look like, so it optimises toward the wrong audience with your budget.
Ready to Build Something That Works?
Book a free 30-minute strategy audit. No pitch deck, no pressure — just an honest look at your setup and what to fix first.
Not ready to write it all out? Book a 15-minute discovery call →
