Most marketing teams never chose their tracking setup. They inherited it, from an agency, a departed ops hire, or three consecutive quarters of somebody adding one more tag before a campaign launch. Nobody has read half of it since. The question is not what else to track. It is what deserves to exist.
Collection Is Free. Reporting Is Rationed.
Google puts no limit on the number of distinctly named events a web data stream can send. The caps land later, on the things that make an event usable. A property gets 50 event-scoped custom dimensions, 25 user-scoped dimensions, and 50 custom metrics. Reporting surface is the budget, not collection.
The first half of that is in Google’s own documentation, stated plainly. For web data streams there is no cap on how many distinctly named events a property collects[1]. Event names have to stay under 40 characters and carry at most 25 parameters each, but the number of names is open-ended. You are not going to run out of room to track things.
The second half is where the budget actually lives. A property gets 50 event-scoped custom dimensions, 25 user-scoped custom dimensions, and 50 custom metrics[2]. Those are the mechanisms that turn a collected event into something a person can see in a report, segment by, or optimize against. Registration is the gate, and the gate is finite. Collection scales. Reporting does not.
Over-tracking is not neutral, either. Google treats any dimension carrying more than 500 distinct values as high cardinality, and it is careful to call that guidance rather than a hard limit[3]. When a report table passes its row limit, Analytics surfaces only the most common dimension values and condenses the less common ones under the (other) row. The values you care about can end up inside that condensation. Tracking more does not simply add noise. It can hide the signal you built the report to see.
That reframes the whole exercise. The job is not to instrument everything instrumentable and sort it out later. The job is to decide, in advance, which small set of events deserves a share of a fixed reporting budget. That decision is the measurement plan, and most teams have never written one down.
Does a Change in This Number Change a Decision?
An event earns its place only if a change in its value would change something someone actually does. That is the whole test. Demo requests, pricing-page engagement, consumption of a handful of key assets, and a return-visit threshold clear it. Most of what sits in an inherited setup does not.
Run the test literally. Pick an event, then ask what happens if the number doubles next month, and what happens if it halves. When the honest answer to both is “we would notice and move on,” the event is not measurement. It is decoration, and a team optimizing against decoration is data-decorated rather than data-driven.
A short keep list survives on most B2B SaaS marketing sites. Demo or contact requests, because they route to a human and set staffing. Pricing-page engagement, because it separates browsing from evaluating. Consumption of the few assets that reliably precede pipeline. And a return-visit threshold, because a second and third visit from the same account is the closest thing a marketing site gets to a live intent signal.
That last one carries more weight than the form fill, and the buyer research explains why. In its 2025 B2B Buyer Experience Report, 6sense found 94% of buying teams could already rank their vendor shortlist before engaging any seller[4]. Buyers now initiate first contact around 61% of the way through the journey, and the winning vendor sees roughly 16 interactions per person. (6sense reports about 4,000 responses plus a 766-person companion survey, 49% VP-level or higher, and does not publish field dates on the page.) The demo request confirms a decision made earlier, somewhere inside those 16 interactions. The events worth a slot are the ones that show the decision forming.
The other side of the ledger is familiar. Every button click. Every scroll tier. Hovers, tab switches, accordion opens. None of them are wrong, exactly. They just cannot name a decision, and there are only so many custom dimensions to go around.
How Do You Kill an Event You Inherited?
Three questions per event: who reads it, on what cadence, and what decision changed the last time it moved. An event with a named owner, a stated cadence, and one real decision behind it stays. Anything carrying a blank in any of the three columns goes, and it goes without ceremony.
Most of the kills turn out to be duplicates rather than bad ideas. A property with enhanced measurement enabled already emits page_view, scroll, click, view_search_results, video_start, video_progress, video_complete, file_download, form_start, and form_submit before anyone writes a single custom tag[5]. The stock scroll event fires once, at 90% vertical depth. Hand-built 25/50/75/100 tiers layered on top produce four more named events, four more rows in every report, and almost no information the stock event did not already carry.
The pattern repeats across the B2B SaaS properties I have audited. A Series B marketing team inherits several dozen distinctly named events from an agency engagement that ended two years earlier. Nobody currently on the team can say what a third of them were for. Two of them fire on components that no longer exist on the site. The setup is not malicious or incompetent. It is just sediment, and nobody was ever assigned the job of clearing it.
Deleting is not free either, which is an argument for being deliberate rather than an argument for hoarding. At the custom-dimension limit, Google requires a 48-hour wait after deleting a dimension before a new one can be registered. A team that fills all 50 slots with inherited leftovers cannot instrument next quarter’s launch on the day it needs to.
This test sits upstream of the 30-minute GA4 audit, which checks whether the events you have are firing correctly. It also sits upstream of the platform’s own defaults, which decide how a correctly firing event gets interpreted. Both of those assume the event should exist in the first place. The keep/kill test is where that gets decided.
Name Events So a Stranger Can Read Them in Two Years
Google documents four event categories: automatically collected, enhanced measurement, recommended, and custom. Work down that order. Google’s own guidance is to create a custom event only when no other event works for your use case. Custom events do not appear in most standard reports, so each one needs an exploration built before it means anything[6].
That hierarchy is the naming convention, and most teams skip straight past it to writing custom names. The reason to follow it is mechanical, not stylistic. A recommended name feeds reports and dimensions Google has already built. An invented name feeds nothing until somebody builds the exploration, and that somebody is usually not around two years later.
For whatever genuinely needs a custom name, pick one shape and never break it. Lowercase, snake_case, object then action: `demo_request_submit`, `pricing_plan_compare`, `doc_download`. The event-collection limits cited above cap names at 40 characters, which is more room than a disciplined convention ever needs. The real test is whether a marketer who joins in two years can read the name and know what fired, without asking anyone and without opening the tag manager. Inherited setups fail that test more often than they fail any technical one.
Do not encode values into the name. A property with `cta_click_pricing_hero_blue`, `cta_click_pricing_hero_green`, and two more variants has four events pretending to be one, and it is spending four name slots to store what belongs in parameters. Parameters are the right home for variable detail, up to 25 per event. Two constraints keep that honest. A parameter only becomes reportable once it is registered as a custom dimension, out of the same 50. And a parameter carrying hundreds of distinct values is exactly the high-cardinality case that fills the (other) row.
The Plan Is the Artifact, Not the Tags
A measurement plan is a short document, not a tag manager workspace. It lists every event that survives the test, who reads it, on what cadence, and which decision it triggers. In 2026, The CMO Survey found 66.5% of marketing leaders understand their tech roadmap while only 43.2% say their systems inform it.
Those two numbers come from the same page of the same survey, which is what makes the gap worth sitting with. The CMO Survey’s 35th edition was fielded 7-29 January 2026 and drew 308 responses from US marketing leaders[7]. 97% were VP-level or above and 65% were B2B, with tech and software the largest sector at 20.4%. 66.5% said they understand their technology roadmap. 60.5% said they test and iterate. Only 43.2% said they have the right systems in place to track customer engagement in a way that informs the marketing roadmap. Just 30.3% reported consolidated customer intelligence across all touchpoints.
Understanding a stack and being informed by it are two different capabilities, and the second one is not bought. It is written down. Picture handing a new hire one page: every event, its owner, its cadence, its decision. A team that can do that has closed most of the Analytics Trust Gap before a single tag gets audited. A team that cannot will keep adding events to a property nobody reads, which is how the sediment got there the first time.
Sources
- Google, GA4 Event Collection Limits – Official Analytics Help documentation; no limit on the number of distinctly named events for web data streams (the 500 figure applies to app streams, counted per app user); event names capped at 40 characters; 25 event parameters per event ↩
- Google, About Custom Dimensions and Metrics – Official Analytics Help documentation; per-property budget of 50 event-scoped custom dimensions, 25 user-scoped, 10 item-scoped, and 50 custom metrics; at the limit, a 48-hour wait applies after deleting a dimension before a new one can be registered; Google advises using predefined dimensions where possible and warns against registering high-cardinality values ↩
- Google, About the (other) Row – Official Analytics Help documentation; any dimension with more than 500 values should be considered high cardinality, stated on the page as guidance and explicitly not a limit; when a table passes its row limit, Analytics surfaces only the most common dimension values and condenses less common values under the (other) row ↩
- 6sense, The B2B Buyer Experience Report for 2025 – Roughly 4,000 responses plus a 766-response companion survey; 49% VP-level or higher; North America 46%, Continental Europe 20%, UK and Ireland 20%, APAC 14%; field dates not disclosed on the page; 94% of buying teams could rank their vendor shortlist before engaging a seller; first contact initiated by buyers around 61% through the journey; 16 interactions per person with the winning vendor ↩
- Google, Enhanced Measurement Events – Official Analytics Help documentation; enhanced measurement emits page_view, scroll, click, view_search_results, video_start, video_progress, video_complete, file_download, form_start and form_submit; the stock scroll event fires at 90% vertical depth ↩
- Google, GA4 Events – Official Analytics Help documentation; four event categories (automatically collected, enhanced measurement, recommended, custom); “Make sure you only create custom events when no other events work for your use case”; “Custom events don’t show up in most standard reports so you need to set up custom reports or explorations for meaningful analysis” ↩
- The CMO Survey, Spring 2026 (Duke Fuqua, Deloitte, AMA), 35th edition – Fielded 7-29 January 2026; 2,111 US for-profit marketing leaders invited, 308 responded (14.6% response rate); 97% VP-level or above; 65% B2B; largest sector Tech/Software/Platform at 20.4%; page 18 reports understand tech roadmap 66.5%, test and iterate 60.5%, right systems in place to track customer engagement in a way that informs the marketing roadmap 43.2%, consolidated customer intelligence across all touchpoints 30.3% ↩
Seeing these patterns at your company?
Book a free WebOps Diagnostic. I'll review your site before the call and share specific observations.
Book a Free Call →Frequently Asked Questions
For web data streams, Google puts no limit on the number of distinctly named events a property collects. Names cap at 40 characters and each event carries up to 25 parameters. The real constraints are downstream: 50 event-scoped custom dimensions, 25 user-scoped dimensions, and 50 custom metrics per property.
An event whose movement changes something a named person actually does. Demo requests change sales staffing. Pricing-page engagement separates browsing from evaluating. A return-visit threshold changes outreach timing. If a number could double or halve and nobody would act differently, the event is decoration, not measurement.
Ask three questions per event: who reads it, on what cadence, and what decision changed the last time it moved. An event with a named owner, a stated cadence, and one real decision behind it stays. A blank in any column is a kill. Pair this with the 30-minute GA4 audit, which checks whether the survivors fire correctly.
Use a recommended event whenever one fits. Google's own guidance is to create custom events only when no other event works for your use case, because custom events do not appear in most standard reports. Every custom name you invent commits someone to building an exploration before the data means anything.
Because a report table passed its row limit and Analytics condensed the least common values together. Google treats any dimension carrying more than 500 distinct values as high cardinality, explicitly as guidance rather than a hard limit. Over-tracking does not just add noise here. It can push the values you care about inside that condensed row.