Practical thinking on marketing measurement, attribution, data quality, and trustworthy decision systems.https://partnerwithpropel.com/en-ushttps://partnerwithpropel.com/blog/troubleshooting-meta-capi-what-we-covered-in-our-webinar/https://partnerwithpropel.com/blog/troubleshooting-meta-capi-what-we-covered-in-our-webinar/Why deduplication breaks, how event match quality affects your spend, why Meta over-reports, and the logging that makes the next problem faster to fix.Wed, 19 Aug 2026 00:00:00 GMTTimo and I ran a webinar on troubleshooting Meta's Conversions API. This is a recap of what we covered. We built the session around what people told us when they registered, so it wasn’t a "how to set up CAPI" walkthrough. Most of the room already had CAPI live and running, and the questions were about what to do when it breaks quietly and you can't tell whether the problem sits in Meta, GTM, or your server.  Three problems came up more than any others: events being counted twice, match quality quietly eroding, and Meta reporting more conversions than a company's own data. We took each in turn, then Timo covered what to put in place now so the next problem is faster to diagnose. #### Deduplication is the most common problem, and it usually comes down to the event ID Most companies send the same conversion twice on purpose: once from the browser pixel, once from the server. That's a good setup. The browser sees things the server can't, and the server sees a longer customer journey, lets you enrich the user, and isn't limited by consent or ad blockers the way the browser is. For it to work, Meta has to recognise the two hits as one event and drop the duplicate. It deduplicates on the event ID. There are other fields in the payload, but the ID is the one that matters, combined with the event name, and it has to be identical on both the browser and the server hit. The way this breaks in practice is organisational: one team sets up the client side in GTM, another sets up the server side, and each generates its own "unique" ID from timestamps or something else. Both are unique. Neither matches. The clean fix is to generate the ID on the client and pass it to the server, so the server picks up the same value and sends it back.  _The ID has to be generated once, upstream of both senders. Two teams inventing their own format is the most common way dedup quietly fails._ One more failure mode worth watching: timing. If the server event arrives long after the browser event, deduplication can fail. In our experience the safe rule is to send both as close together as possible; if you batch server events (say, a daily send from BigQuery), that gap alone can be enough to break the match. You can see the coverage percentage in Meta, but not which specific events were duplicated, which is exactly the thing you'd want when debugging.  So you need your own client-side logs to compare the two streams event by event. As a rule of thumb you want deduplication coverage near 100%, and you usually want more server events than browser events, because the server hit is the more complete and more reliable of the two.  A quick way to catch double-counting without any logging: in the events view, segment first conversions against all conversions on an event most users only fire once, like a sign-up. If sign-ups show more "all" conversions than "first" conversions, more sign-up events are firing than there are people signing up. That doesn't tell you where the duplication is, browser, server, or both, but it tells you to go look.  #### Low event match quality doesn't just weaken optimisation, it can cut your spend Event match quality is how well Meta can tie a conversion back to someone it showed your ad to. The more identifying information you pass, and the better its quality, the higher the score. Data teams tend to be relaxed about this, the same way they tolerate 75% quality on behavioural data, because they're used to messy data being fine. On CAPI it isn't just a data-quality number. It changes what the platform is willing to spend. Here's a case that made it concrete. A client changed their consent banner. Consent to advertising cookies dropped by around 40%, which meant that share of client events stopped carrying the click ID. Within about ten days, spend had roughly halved. The mechanism: Meta could now attribute far fewer conversions, so the CAC it saw went up, and to stay under the target CAC set in the campaign it pulled back budget on its own. Nobody had told marketing the banner was changing, so from their side it looked like the campaigns fell off a cliff for no reason. That's a hard thing to debug, because a consent change and a spend drop don't look connected, and it's not the usual "tracking looks a bit lower" symptom, it's a drop in real delivered volume. > Match quality isn't a dashboard number. It's part of what the platform bids with, so when it drops, your spend can drop with it. Two things follow. First, match quality is worth monitoring continuously, not checking once, because it can be fine one day and not the next. Second, it's per-event, so treat events differently. A page view fired server-side carries almost no identifying information and will score badly, and that's fine, because you shouldn't be optimising for page views anyway. Purchases and other high-value events are where you want the score to be strong. A useful gut check we use is to aim above 8 on the events that matter, while remembering it depends on how many events you have: if you convert rarely, matching as many as possible matters far more.  There's a subtler trap. A high score can mean you're matching the wrong people. Meta is better at matching consumer identities than business ones, so a B2B advertiser can end up matching the personal-Gmail signups, the least valuable ones, and missing the business buyers. A good score on the wrong conversions still costs you. The takeaway for what you send server-side: only add an event, or a field, if it brings something the client event doesn't. Usually that's more identifiers so Meta can match more, or a value you can only compute on your server, like a predicted LTV or a lead score. Mirroring every client event onto the server "just in case" adds cost and noise, not signal. #### Meta reports more than your first-party data, and that's mostly working as intended This is the discrepancy we get asked about most. Before blaming it, it helps to know that Meta's Events Manager and a tool like Google's conversion reporting are counting different things. Meta shows everything that was sent to it. Google shows what it was sent _and_ could attribute to a campaign. So they will never line up, and that's before you get into attribution windows. The bigger point is that Meta reporting more conversions than your own analytics is usually a feature, not a bug. The reason you send server-side events with all that identifying information is to help Meta find more good users, that's a campaign-optimisation job, not a reporting one. It is not claiming every one of those conversions for itself as a reported result. Comparing Meta's number to your GA4 or Amplitude number as if they should match is comparing two different jobs. The place this becomes useful rather than confusing is Meta's attribution-setting breakdown, where you can split conversions into post-click, post-engagement, and post-view. Your first-party tools, GA4, Amplitude, Snowplow, only ever see post-click. So anything that isn't post-click will never appear there, and chasing that gap is chasing something that can't reconcile by definition.  Post-view is worth reading closely, in context. On one client running the same setup across markets, the market where they had the strongest brand showed around 80% of Meta conversions as post-view, while other markets were the reverse, mostly post-click. That doesn't prove the post-view conversions weren't incremental, but a number that high, in a specific market, is a flag worth acting on. For that client we used it to prioritise an incrementality test in that market, because we needed a CAC we could trust rather than one leaning on "would these people have converted anyway". #### The fix for next time is logging what you send, not just what you track Most of the session was about problems people already had. Timo's point at the end was about making the next one more transparent: get visibility into the things the ad platforms don't give you visibility into. Concretely, that means logging not only your own tracking but everything you send to the ad platforms, with all the parameters, into a data warehouse like BigQuery. You can write it from server-side GTM, or from an event pipeline like RudderStack or Segment if you already run one. Once it's there, you can put tests and alerts on top, so if click IDs stop coming through or a parameter goes missing, you know immediately instead of discovering it in a spend report weeks later. A couple of debugging notes that came out of the questions. A 200 response from Meta means "received and looks OK on first pass", not "processed successfully", we've seen events return 200 and still have problems downstream, so inspect the payload you actually sent rather than trusting the status code. And logging the client side is genuinely harder than the server side: there's no direct path from client-side GTM into BigQuery, and routing it through GA to store it inflates your analytics and annoys the marketing team. It's cleaner on RudderStack or Segment, but plenty of teams are on GTM and GA4, so we're planning a proper guide on how to log client-side events for troubleshooting.  _Without the warehouse leg, a broken signal looks exactly like weak demand and you spend three weeks optimizing creative instead of fixing a parameter._ #### A few honest limits None of this gives you a perfect number. Match quality, deduplication, and attribution all leave gaps, and the point isn't to close them, it's to know where they are and stop them moving without you noticing. A lot of what we do on client audits is exactly that: go in deep, work out what's actually working, and hand back something the marketing team can read and trust, especially when data and marketing aren't speaking the same language about why the numbers moved. If you want to work through where your own CAPI setup is leaking, or which of these three problems you're most likely sitting on, book a call with us. You can watch the full session on demand [here](https://partnerwithpropel.com/workshops/meta-capi-troubleshooting/).https://partnerwithpropel.com/blog/why-meta-advantage-and-google-pmax-keep-sending-you-low-value-users/https://partnerwithpropel.com/blog/why-meta-advantage-and-google-pmax-keep-sending-you-low-value-users/Meta and Google target based on the conversion signal you send. What that means for CAC and pipeline quality, and how to point them at the right people.Thu, 30 Jul 2026 00:00:00 GMTIf you're running Performance Max or Advantage+ and acquiring users who don't convert, the instinct is to call it a funnel problem and go fix the landing pages or the nurture flow. That's usually the wrong fix for the wrong problem, and it's an expensive one. More often it's an acquisition problem, and it traces back to a decision you may not realise you've handed over. ### Why Meta and Google push you toward automated buying These campaign types can do things a manual setup can't. Take search on Google. With traditional responsive search ads you're capped at three enabled ads per ad group, each pointing to one landing page you picked, so a handful of fixed destinations and the headlines you wrote. Turn on Performance Max with Final URL expansion and Google can instead send someone to whichever page on your site matches their intent, and generate headlines and descriptions to fit that page. Someone searching for a specific product lands on that product's page, not a generic category one. That's the real appeal: ads get more relevant to each user across more of your site, with far less manual work, and relevance is what drives efficiency. Advantage+ does the equivalent on Meta, assembling and targeting combinations no manual structure could cover. The trade is control. You no longer pick the audience, the copy is generated, the platform chooses the landing page, and it decides who sees the ad. The most valuable decision, who to go and find, moves from you to the algorithm. That's a good deal when the algorithm is aiming at the right people. Whether it is comes down to one thing: the signal you give it.  ### The platform optimises toward whatever signal you send Meta and Google don't know what a good customer looks like for your business. They know what you told them to optimise for, and they go and find more of it. > WYSIWYG: what you send is what you get. Optimise for "leads" and treat every lead as equal, and the platform finds you the cheapest leads it can, because that's what you asked for. It's doing its job perfectly; the instruction was the problem. Pass a value that says this lead is worth 150 and this one is worth 5, and it has something better to aim at, so it starts finding people who look like your 150s. So the users who don't convert aren't leaking out of the funnel. They're exactly who you asked the platform to acquire. ### What a "funnel problem" actually costs you The misdiagnosis is expensive in two directions at once. First, the wasted spend keeps running. If your signal pulls in low-value users, every day the campaign runs it buys more of them. You're not paying once for a bad batch, you're paying continuously for the platform to get better at finding the wrong people. Second, you pour effort into fixing the wrong thing: rebuilding landing pages, reworking nurture, adding sales follow-up, all aimed at converting people who were never going to convert, while the acquisition instruction underneath stays broken. Put rough numbers on it to see the shape (illustrative, not a benchmark): you're spending 20k a month optimising for a flat "lead" event, and a large share of those leads have no real intent. A meaningful chunk of that budget is buying pipeline your sales team then spends time disqualifying. Worse, the CAC on your **good** customers looks fine on the dashboard because it's averaged across a pile of cheap leads, so the problem stays hidden. Fixing the funnel does nothing about any of that. Fixing the signal does.  ### Decide what a good user is before you optimise The fix isn't a setting. It's a decision you make before touching the campaign: what makes a user valuable, and what can you observe early enough to act on? That second part is where most teams are too optimistic. Almost no one can see a customer's real value at the moment they convert. | Your business | What you can see early | The catch | | --- | --- | --- | | Ecommerce | An actual purchase and its value | Closest to real value, but a first order isn't lifetime value; most mature teams pass a predicted LTV, not just order value | | Subscription / SaaS | A signup or activation | An activation isn't value on its own; you need a proxy that correlates with who stays and expands | | Long sales cycle | Little or nothing at conversion time | You're predicting from early proxies: lead quality, enrichment, first-session behaviour | The pattern across all three: you're almost always sending a **prediction** of value, not confirmed value. Ecommerce comes closest to the real thing, and even they increasingly model it. So the practical question isn't "what is this user worth", it's "what can I see early that reliably points to what they'll be worth", and you send that. ### Make the value explicit, not just the conversion Once you have that early proxy, pass it as value, not just a conversion. A conversion tells the platform "this happened." A value tells it "this was worth this much," which is what lets it separate your best users from your cheapest. | What you send | What the platform learns | | --- | --- | | A flat "lead" or "purchase" event, the same for everyone | Every conversion is equal, go find the cheapest | | "Lead, value 5" for a free-email signup, "Lead, value 150" for an enriched, qualified lead | These are worth ~30x more, go find people like them | You don't need full lifetime-value modelling to start. You need a defensible view of relative value, and you need to segment it, because the same event can be worth different amounts depending on the campaign and platform it came from. Flatten that and you've handed Meta or Google a blunter instruction than they can follow, and paid full price for it. ### Watch what your signal does to your traffic Whatever you optimise for, the platform pulls your traffic toward it, and that can narrow you in ways you didn't intend. One team we worked with optimised for people who called them, because calls closed well. It worked, traffic shifted toward likely callers. But it quietly missed everyone who would have booked directly without ever calling, a whole segment of good revenue the campaign stopped chasing. The signal was doing its job so well it steered spend into one narrow slice of the real market. So this isn't set-and-forget. Send the signal, then watch what it does to the mix of people coming in, and check you haven't optimised yourself into a corner.  ### What this looks like in your results Done well, it shows up in your numbers as one of two outcomes, both testable: - **Better users at the same spend:** higher-quality pipeline and more revenue per acquired customer, without paying more per acquisition. - **The same quality at lower spend:** you tell the platform who **not** to chase, hold acquisition quality steady, and cut the wasted budget. Run it as a pilot, compare against your own data, and you'll see which one you got, and roughly what it was worth. And keep the limits in view. None of this is exact; you're acting on early, incomplete information, so you'll live with gaps. The aim was never a perfect read on every user. It's a signal good enough to point Meta and Google at the right people, improved as you learn. If you want to work out what a good user looks like in your data, whether you can see it early enough to act on, and what better targeting would be worth to your numbers, book a call and we'll take a look together.