The symptom

You switched on enhanced conversions in Google Ads and the Conversions API in Meta, in the same quarter, for a client who needed both. The setup guides were followed, both platforms report the integration as active, and the numbers moved by an amount nobody would have noticed without looking for it.

Meta shows an event match quality score somewhere in the middle, with no obvious reason why. Google Ads reports enhanced conversions as enabled next to an impact figure so small the client would be right to ask what changed. The gap between platform-reported conversions and the client's own back office sits where it sat before.

The instinct is to assume a configuration mistake and walk the checklist again. Usually there is nothing wrong with the checklist. Both features are doing what they document, on top of a foundation that is not handing them enough to work with, and rechecking the setup will not surface that.

Why it happens

Enhanced conversions and the Conversions API are enhancement layers. Neither collects anything by itself, and both read from what your setup already produces. That one fact explains most disappointing results, and it sits in the platforms' own documentation, just never phrased as a warning.

[IMAGE: two stacked layers, collection feeding enhancement, the same gap carried upward through both]

Enhanced conversions enhances a tag that already fires

Google's requirements are explicit. You record conversions with a regular conversion tracking tag, and you need to know the exact URL where that tag fires and the event that triggers it, per Google Ads Help. The feature then supplements that tag with hashed first-party data. Supplements is the operative word. A conversion the base tag never sees has nothing to supplement, so the conversions you are missing today stay missing at the same rate after you enable the feature.

The second requirement is quieter and breaks more setups: the customer data has to be available at the moment the tag fires, and Google notes you may have to carry it forward from earlier pages in the flow. Plenty of checkouts hand off to a payment provider and come back to a thank-you page that knows an order number and little else. The tag fires, the identifiers are absent, and the enhancement is empty.

Lead generation is stricter again. Per Google Ads Help, enhanced conversions for leads wants an identifying field on the form, auto-tagging enabled, a sitewide Google tag on every page carrying a form, and the full set of conversions for that event uploaded, including the ones Google Ads did not drive. That last condition is the one most often skipped, and Google states it is required.

The Conversions API is a second copy, not a replacement

Meta's own guidance is to use the Conversions API in addition to the pixel and send the same events through both, because the server copy covers what the browser copy loses to connectivity problems and page load failures, per Meta for Developers. Agencies who read the API as the modern replacement and strip out the browser side give up the redundancy that justified the build.

Deduplication is where the plumbing bites. Two copies of one purchase collapse into one event only when the event name is identical and the event id matches, or the external id and browser id both line up, and only inside a 48 hour window, per Meta for Developers. Get it wrong one way and the client reads inflated conversions, the other way and the server copy is thrown out.

The identifiers are the real bottleneck

Meta scores what you send out of ten, calculated from which customer information parameters arrive and how many events they match to an account. It measures your inputs, not the quality of your integration. A technically flawless connection sending an IP address and a user agent scores below a plainer one sending an email address, a phone number and a name.

The strongest identifier is also the most fragile. The click identifier, fbc, exists only because the click id in the landing page URL was captured, either by the pixel writing it into a cookie or by your own server storing it. Where that cookie is written in the browser, Safari caps cookies created by JavaScript to a seven day expiry, per WebKit. A cookie set from your own server escapes that cap and can hold for up to 400 days instead of 1-7. Same integration, very different amount of ad click history reaching Meta.

Underneath both features sits the browser layer they draw from, where ad blockers strip 30-40% of events and 15-30% of conversions go uncaptured on a standard setup. That is what an enhancement layer inherits, and it is the same reason conversions never reach GA4 in the first place.

Modeling is not the fallback it is assumed to be

The usual reassurance is that Google models whatever consent removed. It does, conditionally. Modeling requires correctly implemented consent mode or the IAB framework, plus 700 ad clicks over a 7 day period per country and domain grouping, per Google Ads Help. GA4 has its own thresholds, and Google Analytics Help is clear that meeting them still does not guarantee eligibility.

Read per country and domain grouping again and the picture changes for most agency portfolios. One large single-market client clears it comfortably. The same spend spread across five small markets often clears nothing, and the account-level view will not tell you which case you are in.

What good looks like

The fix is an order of operations, not a longer checklist: collection first, enhancement second, because the second multiplies whatever the first produces.

Start by establishing what the base tags capture today, measured against something outside the ad platforms, usually the client's own order or lead records. That one comparison tells you whether you have a collection problem or an identifier problem, and the answer decides everything after it. Then make the identifiers exist at the moment of conversion and survive the trip, which means collecting server-side and setting your own first-party cookies rather than trusting what a browser still holds a week later. Only then switch the features on, against a baseline you can compare to.

That sequence is what Archon Signal is built around: a server-side collection layer that captures events a browser-only setup drops, so the features layered on top have something worth enhancing. Agencies moving to server-side collection typically recover 15-40% more conversions, and that comes from the collection layer, not from a setting in an ad platform.

[IMAGE: event match quality score in Meta Events Manager beside the customer information parameters actually sent]

The ceiling on a well-built setup is roughly 95% of events, and it is a ceiling, not a promise. A consent refusal stays a refusal, and no server container gets it back. The goal is closing most of the gap you have now, not arriving somewhere without one.

FAQ

We followed the setup guide exactly and the impact is near zero. Is it broken?

Probably not. Check two things before touching the configuration again: whether the base conversion tag fires on the events you care about, compared against the client's own records, and whether identifying data is present on the page at the moment it fires. If either answer is no, the feature is behaving correctly and there is nothing for it to enhance. Also give it the training window, Google Ads Help says impact can take up to 30 days to appear.

Should we remove the Meta pixel now that the Conversions API is live?

No. Meta's guidance is to run both and send the same events through each, because the server copy exists to cover what the browser copy loses. Removing the pixel removes that redundancy and, on most builds, the browser identifiers your server events match on. Set up deduplication properly instead.

Can enhanced conversions replace server-side tracking?

They solve different problems. Enhanced conversions improves the matching of conversions that were already recorded, while server-side collection changes how many get recorded at all. If your gap is a matching gap, the feature helps on its own. If it is a collection gap, and on most setups it largely is, the feature can only improve the share you were already capturing.

Does a higher event match quality score guarantee better performance?

No, and the honest answer is that it depends on what was limiting you. The score reflects how well your events can be matched to accounts, so improving it removes a constraint on attribution. Whether that becomes measurable performance depends on volume, on how much of the gap was matching rather than collection, and on how long the platform has had the better inputs.

If you want to know which of the two layers is costing your clients conversions before you switch another feature on, request a free tracking audit and we will tell you what the base tags actually capture today.