Open the events report on almost any real GA4 property and you'll find the same mess: a row for learn_more_a, another for learn_more_b, a lead_form_header sitting two rows below lead_form_footer, and a handful of half-named variants from a tag someone shipped in a hurry. Each one fired honestly. Each one counts something a person actually did. And yet when your client asks the only question that matters, "how many leads did we get?", there is no number to point at.
That's the problem with events as GA4 stores them. They are atomic by design: one name, one count, one row. Nobody set out to fragment your conversions. It happens because forms get duplicated across templates, A/B tests spawn suffixed events, and three different people tagged the same button over two years. The data is fine. The shape is wrong.
Why a Single "Leads" Number Doesn't Exist
Consider a lead-gen site with a contact form in the page header and a second copy in the footer, plus two "Learn more" call-to-action variants from a campaign test. You end up with four events doing one job:
lead_form_header: submissions from the top-of-page formlead_form_footer: submissions from the footer formlearn_more_a: the control CTAlearn_more_b: the variant CTA
Every one of those is a legitimate signal of lead intent. But GA4 reports them as four separate rows, four separate counts, four separate trend lines. To get a "Leads" total you're adding them up by hand in a spreadsheet, and you're redoing that addition every time someone ships a fifth variant. The number your client actually cares about is the one number GA4 refuses to give you.
Why GA4 Makes This Hard Natively
You might expect GA4 to have a grouping dimension for this. It doesn't. There is no built-in "event group" the way there's a default channel grouping for traffic. Events are the grain, and the platform has no native concept of "these five names are really one conversion."
The closest tool is marking events as key events. You can flag all four of the events above as key events, which is useful, but they still report as four separate rows. Marking them does nothing to merge them; it just promotes four fragments instead of one. Key-event status is a label on each event, not a relationship between them.
GA4 does ship grouping for other things. Default channel grouping rolls raw source/medium pairs into Organic Search, Paid Social, and so on. Content grouping lets you bucket pages. Both prove the pattern works. Neither extends to events. The one dimension where fragmentation hurts most is the one with no grouping layer.
The Workarounds, and What They Cost
There are two common ways teams try to solve this, and both have a real bill attached.
Rename and standardise upstream. The "do it properly" answer is to fix the tagging: collapse lead_form_header and lead_form_footer into a single generate_lead event with a form_location parameter, retag every variant, and ship it. It's the cleanest end state, but it's a development project, it has to clear QA, and, the part people forget, it does not backfill. Your historical data keeps the old fragmented names. You get a clean number going forward and a seam in every year-over-year comparison.
Rebuild it per report. The faster answer is to stay in GA4 and stitch the events together in each report: a calculated metric that sums the four counts, or an Explore segment that ORs the event names together. This works until you build your next report, where you do it all again. The logic lives inside one report, invisible and unshared. Add a fifth event and every calculated metric and segment you ever wrote silently undercounts, with nothing to warn you.
| Approach | Where the grouping lives | Cost |
|---|---|---|
| Rename / standardise upstream | In the tagging, before data is sent | Dev work and QA; no history backfill; a seam in year-over-year |
| Per-report Explore or calculated metric | Inside one report, not reusable | Rebuilt every report; fragile; silently undercounts when a new event appears |
| Rule-based grouping (reporting layer) | A named rule over the raw events | Define once; no re-tagging; full history; raw events stay intact |
Both workarounds are answering the wrong question. They treat fragmentation as something you fix at the source, when the fragmentation isn't really a tagging fault. It's a reporting need: you want to view four events as one conversion without throwing away the fact that there were four.
Grouping events into a conversion is a reporting-layer job, not a re-tagging job. The raw events are correct; what you're missing is a view that reads them as one.
What Rule-Based Grouping Looks Like
The reporting-layer answer is to define a conversion as a rule over a set of event names, and let the report apply that rule at read time. "Leads" becomes a named thing that means lead_form_header OR lead_form_footer OR learn_more_a OR learn_more_b. The total is computed when the report renders, from whatever the raw events currently say.
Two properties make this better than either workaround. First, it's defined once and reused everywhere, so your scorecard, your trend chart, and your breakdown table all read the same definition, change the rule in one place and every view updates. Second, it works on history. Because the rule runs at read time over events that were always being collected, a "Leads" group you define today reports correctly for last quarter too. There's no seam and nothing to backfill.
Grouping is additive, never destructive. The underlying events, learn_more_a, lead_form_footer, and the rest, stay exactly as GA4 recorded them. The group is a view layered on top, so you can always drop back to the individual events to see which one is actually driving the total.
That last point matters more than it sounds. A grouped "Leads" number tells you the headline; the raw events tell you the story. If leads jump 30% this month, you want to know whether it was the footer form or the campaign variant that moved, and you can only answer that if the components were never thrown away.
In adop.tools
This is exactly what the conversion groups feature does. You define a named conversion, such as "Leads", as a rule over a set of GA4 events, and from then on the breakdown tables and scorecards show the grouped total while the raw events stay intact. There's no re-tagging and no lost history: the rule is applied to the data you already have, so the group reports correctly across your full date range. When you need the detail, the individual events are still there to drill into.
Where to Start
Don't begin in the tag manager. Begin with the question, "what conversions does this client actually report on?", and write down the short list: leads, signups, purchases, key downloads. Then, for each one, list the GA4 events that already represent it, fragments and all. That mapping is your grouping definition. Most sites need three to six groups to turn a sprawling events report into the handful of numbers anyone actually asks about.
Renaming events upstream is still worth doing for the worst offenders, and over time it makes the raw layer cleaner. But it's a slow, forward-only fix. Rule-based grouping gives you the clean conversion number today, across all your history, without waiting on a tagging release, and it keeps every underlying event for the day you need to know which fragment moved.