Eight Names for the Same Click

Eight Names for the Same Click

A visitor clicks a call-to-action button on a B2B SaaS website. Depending on which company's container you're looking at, that interaction gets tracked as cta_click, click, button_click, link_click, menu_click, nav_click, navigation_click, or internal_link_click. Eight names for the same action. GA4 treats each one as a completely separate event with its own entry in reports, its own row in BigQuery, and its own count in the event summary.

This matters because GA4 event names are the foundation of every report, every audience, and every conversion. When the same action has different names across tags in the same container (or even across containers in the same organization), the data fragments. A report filtered to click misses every interaction tracked as button_click. An audience built on cta_click excludes users whose clicks were captured under a different name. The data exists but it doesn't aggregate, which means the numbers in any single report are always an undercount.

The fragmentation problem

Click tracking is the most visibly fragmented category, but it's not the only one.

Form submissions appear under at least four names: form_submit, form_submission, demo_form_submit, and form_start. The first two are literally the same event with different naming conventions (underscore-delimited verb vs. noun). A container with both form_submit and form_submission tags is tracking the same action twice under different names, or different teams added form tracking independently and never coordinated the event name.

Demo and sales conversions split across demo_request, contact_sales, contact_us, and demo_form_submit. These may represent genuinely different actions (a demo request form vs. a general contact form), but in many containers they're aliases for the same form submission on different pages. The person who set up tracking on the demo page used demo_request. The person who tracked the contact page used contact_us. Nobody checked whether the other event already existed.

Scroll tracking appears as both scroll (the Enhanced Measurement default name) and scroll_depth (a common custom implementation). Video engagement splits between video_start, video_play, and video_begin. Even page views appear under page_view, pageview, and virtual_pageview depending on who implemented them and when.

Why this happens

GA4 has no enforced naming schema. Any string is a valid event name (within the character limits and restrictions). Google recommends snake_case and provides a list of recommended event names, but the recommendation isn't enforced at the tag level. GTM will happily fire an event named CTA_Click, ctaClick, cta-click, or 🔥click🔥. All four work. All four create separate events in GA4 reports.

The lack of enforcement means every implementation reflects the conventions of the person who built it. A developer adding tracking uses camelCase because that's JavaScript convention. A marketer configuring tags uses natural language with spaces (which GA4 silently replaces with underscores or drops). A consultant follows Google's recommended names. An agency uses their own internal naming standard. When multiple people contribute to the same container over time, the container inherits multiple naming conventions simultaneously.

GA4's case sensitivity compounds the problem. page_view, Page_View, and PAGE_VIEW are three different events. A container where one tag fires generate_lead and another fires Generate_Lead has two separate lead events in reports that should be one. This is invisible in the GTM interface because the trigger and tag configuration look correct. The duplication only surfaces when reviewing GA4 reports or BigQuery exports.

The parameter problem

Event naming fragmentation extends to parameters. Click tracking parameters across different containers include click_text, link_text, button_text, cta_text, clicked_text, and element_text. All capture the same data point (the text content of the clicked element) under different parameter names.

This creates a compounding issue. An event named cta_click with a parameter named click_text and an event named button_click with a parameter named button_text can't be compared in GA4 reports without manual transformation. They're not just different events; they carry their data in differently named fields. Any analysis that tries to aggregate click behavior across these implementations requires mapping both the event names and the parameter names to a common schema, which is post-collection cleanup work that shouldn't be necessary.

The GA4 parameter limit makes this worse. Each event can carry a maximum of 25 custom parameters. Containers that send redundant parameters (tracking click_text AND link_text AND button_text on the same event) waste slots that could carry more useful data. Some containers also send parameters that GA4 already collects automatically (page_location, page_referrer, page_title), consuming custom parameter slots to duplicate automatic collection.

What a naming convention looks like

Google's recommended events are the closest thing to a standard. For B2B SaaS, the relevant recommended events are:

• generate_lead for form submissions that capture lead information
• sign_up for account creation
• login for authentication
• purchase for transactions
• search for site search

For events that don't map to Google's recommended list (demo requests, content downloads, webinar registrations), the convention should follow the same pattern: snake_case, lowercase, verb-first or noun-first consistently.

A minimal B2B SaaS event taxonomy might look like:

The specific names matter less than consistency. A container where every click is cta_click with a click_url parameter is functional. A container where clicks are split across 8 names with 6 different parameter schemas is not, regardless of how reasonable each individual name seems in isolation.

The cross-container problem

Naming fragmentation within a single container is a data quality issue. Naming fragmentation across containers in the same organization is a reporting infrastructure issue.

A company with separate GTM containers for their marketing site, product app, and documentation hub needs the same events named the same way across all three containers for GA4 to aggregate them meaningfully. If the marketing site tracks demo_request and the product app tracks request_demo, GA4 treats these as separate events. Cross-property reporting requires either standardized naming at implementation time or post-collection transformation in BigQuery, which adds complexity and maintenance burden to every report.

Organizations that manage multiple containers typically discover this problem late, when a stakeholder asks for a unified view of conversions across properties and the data team realizes that the same conversion has three different names in three different containers. The fix at that point is retroactive: rename events across all containers and accept that historical data will have the old names. GA4 does not support renaming historical events within the interface.

Fixing event naming in an existing container

Changing event names in a live container requires care. GA4 audiences, conversions, and integrations reference events by name. Renaming button_click to cta_click means updating every audience that filters on button_click, every conversion that counts button_click, and every export or integration that references the old name.

The safest approach is to fire both event names simultaneously during a transition period: the new canonical name and the old name. This keeps existing audiences and conversions functioning while the new name accumulates data. After 30-60 days (enough for audience membership to cycle), remove the old event name and update any remaining references.

For containers where the fragmentation is severe (5+ names for similar actions, mixed casing across dozens of events), a naming audit before any changes is worth the time. List every event name, group by intended action, choose the canonical name for each group, and map the migration path. The audit typically reveals that 30-40% of event names are duplicates or near-duplicates that can be consolidated.

The result is a container where every event name is intentional, every parameter name is consistent, and every GA4 report shows complete data for the action it's measuring. That sounds like a baseline, but given the current state of event naming across the market, it's a genuine competitive advantage in data quality.