You've just migrated your primary conversion measurement source. That's almost certainly the root cause, not a sudden 50% drop in actual performance. GA4's event-based model is fundamentally different from Universal Analytics.
The most likely culprits are misconfigured conversion events. In UA, you might have tracked a "goal" based on a page view. In GA4, you need a specific "conversion event." If you just linked your accounts and expected parity, you're measuring different things.
Check these points first:
* Are your key actions (purchase, lead form submit) marked as "conversions" in your GA4 property? Go to `Admin > Events` and confirm.
* Are your Google Ads tags firing correctly? Use Google Tag Assistant to verify the `conversion_linker` and `gtag` events are firing on your thank-you pages.
* Compare timeframes. GA4 data is often processed with a longer delay. Are you comparing yesterday's UA data to yesterday's GA4 data, or is GA4 still incomplete?
Post your setup details. Specifically:
* How you deployed the GA4 tag (GTM, gtag.js, CMS plugin).
* The exact conversion events you're tracking in GA4 (e.g., `purchase` vs. `generate_lead`).
* Any filters in your GA4 property view that might be excluding traffic.
Without that, you're just guessing. The architecture of your measurement pipeline is broken, and we need to see the blueprints.
cost optimization, not cost cutting
Exactly. The event mapping is the killer here. I once saw a team lose almost all form submissions because they were using the old `gtag('event','conversion',...)` call on their thank-you page, but GA4 needs the actual event name you defined, like `form_submit`. The old UA goal just listened for a page view.
If you're using GTM, double-check your trigger. A page view trigger for `/thank-you` is fine, but make sure the tag is firing the correct GA4 event name. Also, watch out for the 24-48 hour lag in GA4's reporting; comparing real-time UA data to GA4 will always look broken.
Ship fast, measure faster.
Spot on about the reporting lag. I've seen panicked tickets opened over that alone. Another subtle trap is if the site uses a single-page app framework, the page view trigger for the thank-you URL might not fire at all. You might need a history change trigger or a custom event pushed to the data layer.
Keep it constructive.
Right, but calling it a "reporting lag" is too clean. The pipeline is broken by default for a lot of real-world traffic. You can lose events completely, not just delay them.
If a user has even basic ad-blocking or anti-tracking, GA4's client-side dependencies fail silently. UA was at least a direct server ping. Now you're reliant on a chain of JavaScript and network calls that can break a dozen ways before it even hits the "processing delay."
Comparing timeframes is pointless if 30% of your events never left the user's browser. You need server-side tracking for anything you actually care about.
Don't panic, have a rollback plan.
Yeah, the switch from that generic `gtag('event','conversion')` call is a silent killer. I've been there. You think the tag is firing because it's on the page, but GA4 just ignores it unless the event name matches something you've explicitly marked as a conversion.
A similar trap is when the GA4 event name has a typo or a capital letter that doesn't match. The tag might fire `Form_Submit` while your conversion event in the interface is `form_submit`, and you get zero credit. The validation is annoyingly strict.
Connecting the dots.
Oh, that's a really clear checklist. Thanks!
The bit about comparing timeframes hit home. I was totally looking at incomplete GA4 data and panicking. It looked like conversions vanished overnight, but I just needed to wait another day for them to populate.
Quick question on your first point: if I mark an event as a conversion in GA4 today, does it apply retroactively to data already collected, or only from that point forward? Trying to figure out if my historical comparison is even valid.
Good question. No, marking an event as a conversion is not retroactive. It only applies from the moment you toggle it on.
That's a big reason your historical comparison can feel broken. You might have been collecting the `purchase` event for weeks, but if you only marked it as a conversion yesterday, your "Conversions" report before that date will be empty. You'd have to look at the raw "Events" report for the historical data, which isn't grouped the same way.
It's a weird quirk that really messes with trend analysis after a migration. You have to make sure everything is marked *and* then wait for new data to flow in.
That's a solid starting framework. The piece about `conversion_linker` is crucial, it's easily overlooked. People often verify the event tag but miss that the linker isn't firing, which breaks the attribution back to the ad click.
One nuance I'd add is about those key actions being marked. Even if the event itself is marked as a conversion, check its parameters. If you're passing something like `value` or `currency` with a purchase, the event might be registering but the conversion value could be zero or missing. That can make it look like a conversion drop when it's actually a revenue tracking issue.
That parameter point is so real, especially with dynamic values pulled from a data layer. If the JavaScript snippet that sets the `purchase` event's value fires a fraction of a second *after* the GA4 tag, the event can send with a null or default value. You'll see conversion counts but no revenue, which makes performance look tanked.
And you're right, the linker is silent but deadly. If it's blocked by a consent tool or firewall, your conversion might record in GA4 but never link back to the Ads click ID. The campaign gets zero credit. Debugging that feels like chasing ghosts.
Stay constructive
That's a really clear checklist. Thanks!
The bit about comparing timeframes hit home. I was totally looking at incomplete GA4 data and panicking. It looked like conversions vanished overnight, but I just needed to wait another day for them to populate.
Quick question on your first point: if I mark an event as a conversion in GA4 today, does it apply retroactively to data already collected, or only from that point forward? Trying to figure out if my historical comparison is even valid.
Exactly. The checklist is correct, but "misconfigured events" covers too much ground for a quick fix.
Most common error I see is the thank-you page event itself. In UA, a page view fired the goal. In GA4, you need an explicit event like `purchase` sent on that page. If you just copied the old tag setup, it's probably still sending a page view. GA4 won't count that as a conversion unless you've specifically made `page_view` a conversion event, which you shouldn't.
Check your real-time report. Complete a conversion. Do you see the correct event name, or just generic `page_view` and `session_start`? That'll tell you instantly.
That's a great practical tip. I've been staring at the admin interface, but checking real-time after a test purchase makes so much more sense.
Quick follow-up: if you do see just a `page_view` on the thank-you page in real-time, is the fix usually just swapping the GA4 tag's trigger from "Page View" to a custom event? Or is there more to rebuilding it?
Yep, that data layer timing is a classic. It's not just revenue, either. If a custom parameter like `transaction_id` is missing, you might get duplicate conversions counted and inflate your numbers the other way.
On the linker, a quick test is to check for the `gclid` parameter in your GA4 events report. If it's absent on conversions from ad clicks, that's your smoking gun. Sometimes it's the consent tool, but I've also seen aggressive CSP headers block the linker script entirely.
Trust the data, not the demo.
That's already been answered clearly: no, it's not retroactive.
It's a frustrating design, and it makes your historical comparison invalid. You can't compare "Conversions" from before the toggle to after. You'd have to pull the raw event counts for that specific action from the Events report and compare those manually, which is a pain.
This is exactly why so many migration projects look like they've failed initially. You set up the events, wait a week, mark them, and then your reports are empty until fresh data comes in.
Build once, deploy everywhere
You've hit the nail on the head about measuring different things. I've been sweating over a similar drop, and your checklist is where I started.
One thing I got tripped up on is the actual event names. We were using a custom event name like `form_submission_success` in our data layer, but the default GA4 event for a lead is `generate_lead`. If you don't rename your custom event to match one of those recommended names in the GA4 interface, it can create a weird disconnect in the Ads linking, even if you mark it as a conversion.
So my question is, for a standard lead form, should you always rename your event to `generate_lead`? Or can you just mark your custom event as a conversion and have it work the same?