Two of these make your conversions far too high. Two make them too low. One makes the number meaningless while keeping it accurate.
They share a property that makes them unusually expensive: the interface shows the key event as correctly configured in every case. Nothing errors, nothing warns, and the resulting number is plausible enough that it gets used for months. Here they are, with the symptom that identifies each one.
Symptom: Conversions roughly equal to sessions, or a conversion rate near 100%.
page_view is the usual culprit, sometimes scroll or session_start. Someone marks it while exploring the interface, it is never unmarked, and from then on every pageview is a conversion. It is easy to spot once you look, because the magnitude gives it away immediately: real conversions are a fraction of sessions, not equal to them.
What it costs: If that key event is imported into Google Ads and Smart Bidding is optimising against it, you are bidding to maximise pageviews. The reporting damage is annoying; the bidding damage is expensive.
Symptom: An event marked as a key event that never appears in conversion reporting.
Google documents that a key event whose name runs past 40 characters is not reported as a key event. Not truncated, not partially counted: it does not arrive as one. The setting in the interface still shows it as marked, which is what makes this so durable. Everything looks configured and nothing is counted.
What it costs: A conversion you believe is being measured and is not, usually discovered during a quarterly review when someone asks why a campaign has no results.
Symptom: Conversions consistently lower than the orders or leads in your own systems.
Key events count once per event by default, which is what Google recommends. But key events created from Universal Analytics goals, either in an automatically created GA4 property or through the goals migration tool in Setup Assistant after April 2023, default to once per session instead. On those properties a visitor who buys twice in one session is recorded as one conversion. Nobody picked that setting, it arrived with the migration.
What it costs: Quiet, permanent undercounting, worst on the events you care about most. It is the mirror image of fault one: your numbers look respectable, they are simply too low, so nothing prompts anyone to check.
Symptom: A key event with no data at all, in a property that is otherwise healthy.
Someone marks an event name in anticipation of the tag being built, and the tag is never built, or ships with a different name. GA4 will happily hold a key event for an event that has never been received, because marking a name and collecting it are separate acts.
What it costs: Nothing is broken, so nothing alerts. The conversion simply never records, and the absence looks like poor performance rather than a configuration gap.
Symptom: A long list of key events, most of which nobody could name a decision for.
Every meaningful event gets marked over time, because marking one is a two-second action with no apparent cost. The result is a conversion number that aggregates things of wildly different value, and reports where the important outcome is buried among newsletter sign-ups and PDF downloads.
What it costs: Dilution rather than error. The number is real and tells you nothing, which is arguably worse, because people keep making decisions with it.
Fault three is worth isolating, because it was applied to properties rather than chosen by anyone. If your GA4 property was created automatically from Universal Analytics, or you used the goals migration tool in Setup Assistant after April 2023, your migrated key events default to counting once per session rather than once per event.
On an ecommerce site that means a visitor who buys twice in one session is one conversion. The number is lower than reality, consistently, and because it is lower rather than absurd, nothing about it invites a second look. Check the counting method on every key event that matters, and note that changing it applies to future data only, so expect a visible step up on the day you fix it.
Tracking Auditor checks every one of these against your live property: trivial key events, names over the limit, counting methods that deflate purchases, key events with no tag sending them, and the overall count. A free audit every month.
Run a free audit →If the conversions exist but disagree with Google Ads, that is a different problem and mostly by design: why those two numbers never match. If an event is being recorded twice, see why GA4 events fire twice. The full process for verifying conversions end to end is in the conversion tracking audit guide, and event naming and quality in the GA4 event audit guide. More symptoms are indexed at Fix GA4.
Almost always because something trivial is marked as a key event. page_view is the common one, and the giveaway is magnitude: if conversions are roughly equal to sessions, you are counting pageviews. Check Admin, then Events, and unmark anything that is not a business outcome. The second possibility is an event being sent twice by both Enhanced Measurement and a GTM tag.
Two likely causes. Google documents that a key event whose name is longer than 40 characters is not reported as a key event, and the interface still shows it as marked, so nothing looks wrong. The other is that the event name was marked as a key event but no tag ever sends that name, which GA4 permits because marking a name and collecting it are separate things.
Once per event counts a key event every time it fires. Once per session counts it a maximum of once within a session, so a visitor who triggers it five times is recorded as one. Google's own example uses exactly that: five triggers produce five key events under once per event, and one under once per session.
Once per event for most key events, which is also what Google recommends. The exception matters: key events created from Universal Analytics goals, in an automatically created GA4 property or via the goals migration tool in Setup Assistant after April 2023, default to once per session. Many properties are running that setting without anyone having chosen it.
No. Google states that changes to the counting method apply to future key events only and do not apply to a key event's past data. Expect a step change in the reported number on the day you change it, and annotate it so nobody reads the step as a performance shift.
Few enough that you could say what decision each one informs. There is no technical problem with a long list, but a conversion count that aggregates purchases, newsletter sign-ups and PDF downloads is a number nobody can act on, and it will still be used to make decisions.
The 40-character behaviour is from Google’s documentation on data collection and configuration limits. The counting method defaults, the five-trigger example and the note that changes apply to future data only are from Google’s page on changing the counting method of key events. Both checked on 21 October 2026.