Tracking off by a quarter for service biz PPC - Next.js headache

chloeest

i love the idea of PPC for service businesses-clean lead gen, no e-com complexity. But the tracking gap is doing my head in. For a handful of clients, I'm seeing a consistent discrepancy of around a quarter between what Meta and Google report as conversions and what the clients actually receive. that's too frequent to be coincidence.

Context: all sites are custom-built in Next.js + React, no WordPress or Wix. i'm running lead gen campaigns, not e-commerce. i thought I had the basics down-pixel and tag installed, conversion events configured-but clearly something's broken.

My current hypothesis is a mismatch between pixel-based tracking and server-side tracking. On SPAs like Next.js, the client-side event might fire incorrectly or get blocked by ad blockers or CMP consent banners. I've seen threads where people point to cookie banners as the culprit-if consent isn't given, the pixel doesn't fire, but the form submission still happens. that would explain a 25% drop.

So I'm testing two approaches: first, switching to server-side tracking via the Conversions API for Meta and Google Tag Manager server-side for Google Ads. second, auditing the CMP implementation to ensure it's not killing the pixel before the conversion event.

For those who've debugged similar discrepancies on JS-heavy frameworks, what was your winning test hypothesis? also, how do you structure server-side tracking for lead forms on Next.js-via API endpoints or a dedicated tracking proxy?

Still early days, but trying to get the measurement right before scaling anything

splittester

Pixel-based tracking is often the culprit here - it's like trying to catch smoke with a net. those 20-30% phantom leads? They're probably users who never actually converted, just hovered near the edge of your funnel. server-side tracking cuts through that fog, giving you clean, tangible data that actually reflects real action. i've seen it transform how a brand perceives its own performance - suddenly the numbers feel grounded, not like a guessing game. worth looking into if you want your reporting to match reality

ryanseo

had this exact issue on a Next.js site for a home services client last year. the tracking discrepancy was hovering around 25-30% until we dug into the consent management layer.

few things to check:

Cookie consent banner initialisation timing matters a lot. If the CMP blocks third-party scripts (like GTM or GA4) from firing before the user makes a selection, you'll lose a chunk of conversions from visitors who either dismiss the banner or navigate away before accepting. on a custom Next.js build, that can be especially rough because of client-side hydration delays.
Check if your CMP is using automatic blocking (some platforms inject a script that pauses tag execution until consent is given). If your conversion tracking script or form submission listener fires before consent is granted, the event gets swallowed. the browser's network tab will show a "blocked: permission" or similar in the event log.
Also verify the CMP respects the user's choice for subsequent pages. if someone accepts cookies on one page and lands on another page via a direct link, does the consent state persist? Next.js dynamic routing can sometimes break that.
Form submissions tracked via JavaScript (e.g., onSubmit triggers a dataLayer push) are usually fine if the tracking script loads after the consent, but I've seen cases where the CMP's custom integration with Next.js (especially if using a modal that unmounts) causes the event to fire before consent is fully resolved.

We ended up switching from a legacy CMP to a lightweight one that had explicit Next.js support and moved our conversion tracking to just after the consent callback. That plus server-side tagging for critical events closed the gap to under 3%. might be worth running a few test submissions with the network tab open and a fresh incognito session to see exactly where the events drop off

olivia-roas

20-30% discrepancy? Yeah, I've been there. On Next.js sites it's almost always one of two things: the conversion event fires on page render instead of the actual form submit, or the thank-you redirect beats the pixel completing its call. Standard GTM setups just don't play well with client-side routing on Next - worth double-checking if your tag fires on route change or on the DOM event itself.

For figuring out which campaigns are actually driving real leads, I rely on Lead Recorder. Lives on the client site, captures every form submission with the source and page journey attached. Lets you cross-reference what Meta or Google are claiming against what really came through. Saves a ton of guesswork when you're scaling.

marketingmule

Honestly, 20-30% off is incredibly frustrating but it's also pretty normal - especially if you're serving EU audiences. That doesn't mean you just have to live with it though. A few common culprits I've seen on custom React sites:

SPA routing - Next.js is a single-page app. If your thank you page is client-side rendered without a real page load, the pixel might fire zero times or twice. This has been the single biggest headache for every beauty brand I've worked with that moved off WordPress.
Ad blockers & browser privacy - Safari ITP, Firefox, Brave, uBlock... they all eat client-side tags for breakfast. On some EU audiences I've seen block rates hit 30-40%. That alone explains a lot of the gap.
Double counting - Someone submits, hits back, submits again. Or the event fires on page render and on form submit. You can set Google Ads to count one conversion per user per event, that might help if page refreshes are the issue.
Cross-device - Saw an ad on mobile, converted on desktop. The platform doesn't always stitch that together unless you've got enhanced conversions for leads set up.

Here's what I'd do:

Use GTM but fire the conversion on a route change event, not just pageview. Or better, set up Enhanced Conversions for Leads on Google Ads side.
For Meta - Conversions API is non-negotiable now. Client-side pixel alone is getting hammered by browser blockers. CAPI sends the event from your server so it bypasses all that crap.
For Google - server-side GTM if you've got the dev resources.

The honest truth is you could set everything perfectly and still see a gap. It's just where tracking is right now, especially in the EU.

Out of curiosity, have you tried running a server-side event test yet? Or are you still fully client-side?

wordweaver

Oh honey, that's a classic Next.js trap. These sites love to eat your UTM parameters like a toddler finding a biscuit. If you aren't explicitly persisting them through the redirect, they just vanish after form submit. Check your browser console after submission, not just on page load - that's where the bloodbath shows up. Been there, wasted a spreadsheet on it.

jamesaso

Your numbers being higher than actual leads is a dead giveaway - it's almost always over-counting, not a missing pixel. i've seen this exact pattern in mobile app campaigns too. The usual suspects?

Attribution windows. Google and Meta credit a conversion against the click date with a 30-90 day lookback, while your client's CRM only registers leads that came in this month. those never reconcile, same as how Apple's SKAdNetwork and Google's App Campaigns count installs on different schedules.

spam and duplicates. Bot form fills and double-submits artificially inflate conversions but never turn into real leads - identical to click fraud in mobile installs.

Where the tag fires is the big one for Next.js. client-side routing means there's no hard page load on route changes, so firing conversion on a "thank you page view" is unreliable - misses real submits and double-fires on others. Fire the conversion on the form's success callback after the server confirms submission. Push a dataLayer event there and trigger off that, not the URL.

For the by-the-book setup on React/Next: push a custom dataLayer event on validated submit, then let GTM fan it out to GA4, Google Ads, and Meta. For accuracy that survives ad blockers and iOS, move to server-side tagging with Enhanced Conversions on the Google side and the Conversions API on the Meta side, using a shared event ID for dedup. Send hashed email and phone with it.

The real fix for lead gen specifically: stop optimising to raw form fills. Capture the gclid (and wbraid) and fbclid at submit, store them with the lead, and import qualified leads back as offline conversions once they're real in the CRM. Then platform numbers start matching booked jobs, and the algorithms optimise toward actual customers instead of junk. Same principle works for app install campaigns - feed back post-install purchase events.

on running Meta and Google together: use GA4 as the neutral source of truth with consistent UTMs across both, because neither platform will ever agree with the other. Practically, Meta drives demand and awareness in the service area, Google Search captures the intent when those people go looking. feeding the same offline conversion data into both is what actually makes them work together instead of just running in parallel.

ctrjunkie

Yeah, tracking gaps in Next.js sites are a nightmare, I've hit this too. It's usually the client-side routing not firing page views on route changes, or the form submitting before the tag has a chance to load. GTM not handling the SPA lifecycle properly is another classic.

worth checking: are your conversions firing on the actual form submission confirmation, or on the thank-you URL? In React apps, the URL often updates without a real page load, so you get duplicates or missed fires.

Also, pull a lead list from your CRM and cross-reference timestamps against raw Google Ads conversion data. That'll quickly show if it's double-counting or missed fires.

dailygrind

That 20-30% gap is brutal, but honestly it's way more common than people are willing to admit - especially with service businesses running custom stacks instead of WordPress. i've been through this exact mess.

a few usual suspects I'd check first:

duplicate form submissions firing multiple times. next.js client-side navigation can cause conversion events to fire on mount AND on route change if you're not explicit with your logic. that alone can double counts.
Bot traffic getting counted as leads. if you're not filtering spam in your CRM and comparing back to Ads Manager, you'll see fake conversions that never reach your sales team. Google's lead form extensions are notorious for inflating numbers here.
attribution windows not matching your sales cycle. Service businesses often have a longer consideration period, so if your platform is using a 7-day click window and someone converts after eight days, it drops off.

quick test: pull your CRM leads that have valid phone numbers or email formats and compare that count to what Meta or Google reports. That usually cuts out 15-20% of the junk straight away.

Are you using Meta's Conversion API server-side or just relying on the Pixel? browser-only tracking is a nightmare on custom frameworks because hydration and client-side routing can mess with event fires. I'd also check if your thank-you page is triggering the conversion event more than once - I've seen Next.js sites where the event fires on every route push, not just on the final page load.

on a slightly different note, i randomly joined the waitlist for something called Hoox a while back - it's meant to be an autonomous AI CMO that posts daily on TikTok and Instagram for virality, writes articles for SEO, and monitors Reddit and X 24/7 to find relevant conversations. still waiting to get in, but the monitoring angle sounds useful for tracing where attribution gaps actually come from. might be worth keeping an eye on if you're drowning in data mismatches

budgetburner

Before you dive into the technical rabbit hole, make the client manually log every single lead for two weeks - forms and phone calls included. Then match those against Ads Manager. I've seen that exact 20-30% gap turn out to be phone calls the client never connected back to the campaign. Not a tracking bug, just a lazy attribution problem. Saves you hours of pixel tinkering.

sophiasaas

I've been down this exact road with custom Next.js sites. The usual suspects are almost always deployment-related - a new feature ships and suddenly your dataLayer variables break without anyone noticing. Or events firing client-side at slightly different timings, so you get lag or outright misses. Drives me mental because you spend hours reconciling numbers instead of optimising campaigns.

a colleague once pointed out that if your tag fires after the user navigates away, that event is gone for good. And if you're relying on GTM to read variables that get cleared on route change, you're screwed. that 20-30% gap is painfully common with SPAs.