GA4 Custom Event Setup Guide: Auto / Recommended / Custom Layers Explained

Six months after launching GA4, you open the report and find that "(not set)" is climbing, your purchase event is being counted twice, and somehow the same product fires purchase with two different parameter structures — have you been here?

The root cause, almost every time, is that the initial implementation blurred the boundary between GA4's three event layers (automatic, recommended, custom). GA4 is flexible enough to measure anything, but that flexibility comes with a tradeoff: without a clear convention up front, the implementation will break within months.

This article is a complete guide for e-commerce operators on how to set up GA4 custom events in a way that survives six and twelve months without breaking. We cover the 3-layer boundary, the 12 recommended events, custom event naming rules, reserved parameter pitfalls, and the verification flow.

Key takeaways#

1. GA4 events have a 3-layer structure (automatic / recommended / custom). Each layer differs in source, editability, and parameter spec — mixing them carelessly guarantees breakage later
2. For e-commerce, lean on recommended events. Sending the 12 events (view_item / add_to_cart / purchase etc.) to spec is what keeps your standard reports, ecommerce reports, and BigQuery exports consistent
3. Lock down naming rules and parameter design before implementation. Trying to retrofit the "verb_noun / snake_case / no reserved prefix" conventions later is essentially a full re-design of your measurement data
4. Verification is a 3-layer process: DebugView (send confirmation) → Realtime (aggregation confirmation) → BigQuery (structure confirmation). Skip any one and you ship a system that looks instrumented but is silently broken

1. Why GA4 custom event setup breaks#

Survey data on Japanese marketers responsible for ad operations shows that only 11% of companies have reached the point of automating their GA4 reporting workflow[1]. The gap between "GA4 is installed" and "GA4 is genuinely useful" sits squarely in vague event design at the implementation stage.

Universal Analytics centered on page views and treated events as supporting data. GA4 inverts this: everything is an event, and even a page view is the page_view event. Without absorbing this design shift, "just make it work" implementations decay into the following typical failures within months:

• Two different purchase events exist — one tax-inclusive, one tax-exclusive — and revenue diverges by 10–15%
• Custom event names appear as Click_Button / click-button / clickButton and split across rows in the report
• An event name uses a reserved prefix (ga_ / google_ / firebase_) and is silently dropped — for six months
• The value parameter holds a string instead of a number, so revenue aggregates as zero forever

All of these trace back to shipping with the 3-layer boundary unclear. The job of this guide is to make that boundary explicit at the start, so the measurement foundation does not collapse later.

2. The 3 layers of GA4 events — automatic / recommended / custom#

GA4 events are classified into three layers by who sends them and how GA4 recognizes them. Without this layering, a "just send custom events" approach buries data that would have surfaced in standard reports as a recommended event.

The rule for telling them apart is simple: "who defined the spec" versus "who sends the data." Automatic = Google defines and sends; recommended = Google defines, your site sends; custom = your site defines and sends.

The most important fact for e-commerce operators: most behaviors that happen on an e-commerce site are already covered by recommended events. Product views, cart adds, purchase completes, even refunds — implement the official spec and the standard ecommerce reports work. Reserve custom events strictly for behaviors recommended events cannot express.

3. The 12 recommended events for e-commerce#

The recommended events worth implementing on an e-commerce site map to the user journey in 12 items. Each comes with "when to send," "required parameters," and implementation notes.

The most common implementation accident is the purchase event. If transaction_id is empty or duplicated, GA4's deduplication fails and revenue is double-counted. The Shopify thank-you-page case where purchase fires from both "thank you page view" and "app-side conversion tracking" is the most frequent failure mode in GA4 e-commerce setups.

Connecting recommended events to "revenue decomposition"#

Implementing the 12 recommended events correctly gives you revenue, order count, and AOV (Average Order Value) directly in GA4's standard ecommerce reports. But stopping there leaves a critical question unanswered: "which channel and which session is generating revenue most efficiently?"

The real value of recommended events shows up when you take the value from the purchase event and break it down by session, by channel, and by landing page. Comparing Revenue Per Session (RPS = Revenue ÷ Sessions) for Google Organic visits versus Meta Ads visits exposes CVR and AOV gaps and the combined investment efficiency in a single number.

Note that Revenue Per Session (RPS) is not yet a widely recognized industry metric, despite being mathematically equivalent to CVR × AOV. Most analytics tools, including GA4, do not surface it as a default metric — you have to construct it from the raw event data. This is precisely why a recommended event implementation is the foundation, not the goal: GA4 events are the raw material for revenue-first analysis.

4. Designing custom events the right way#

Behaviors that recommended events cannot cover (e.g., "hero CTA click," "scroll 50%," "whitepaper download") are implemented as custom events. The critical rule here: decide your naming rules and parameter design before implementing. Retrofitting conventions afterward is essentially a re-design of all your measurement data.

3 naming rules#

Lock these in at the design stage:

1. verb_noun: action as verb (click / view / download / submit), object as noun (cta / whitepaper / form). Compose click_hero_cta style
2. snake_case: underscores between words. Mixing clickHeroCta (camelCase) or click-hero-cta (kebab-case) splits them as separate events in GA4 reports
3. Avoid reserved prefixes: names starting with ga_ / google_ / firebase_ are silently disabled. If you want a project-specific prefix, use a 1–2 character custom prefix like rs_click_cta

3 parameter design rules#

1. Minimum necessary: technical limit is 25 per event, but realistically constrain to 5–7. Useless parameters add noise at aggregation time and consume your custom-dimension registration budget (50 per property)
2. Consistent typing: value is a number, item_id is a string, is_logged_in is boolean — keep the same parameter name typed identically across all events. Mixed types break aggregation in BigQuery
3. Custom dimension registration: parameters you want to use in reports must be registered as "custom dimensions" in GA4 admin. Unregistered parameters survive in BigQuery but are invisible in GA4 UI reports

Good vs bad examples#

5. Reserved parameters and measurement rule design#

GA4 has reserved event names and parameter names. Naming collisions with these cause silent failures: your custom values get ignored, automatic events get broken, or data simply does not get logged.

Reserved prefixes and reserved event names#

Event names starting with the following prefixes are unusable[2]:

• ga_ / google_ / firebase_

Additionally, these event names collide with automatic events and cannot be overridden:

• app_remove / app_update / first_open / in_app_purchase / session_start / user_engagement / screen_view

Reserved parameter names#

Parameter names also have reserved entries. A common collision: defining your own page_referrer / page_location / page_title mixes your values with GA4's auto-collected parameters of the same name, producing confused reports.

This collision is one of the causes behind growing "(not set)" rates that make traffic sources disappear. We have a separate breakdown of "(not set)" diagnosis in How to diagnose 5 causes of 'Direct / (none)' growth in GA4 and Telling apart GA4's 4 unknown traffic types: '(not set)' / '(other)' / 'Unassigned'.

6. Post-implementation verification — DebugView / Realtime / BigQuery#

Once you implement an event, always verify across three layers. Skip any one and you ship a system that "looks instrumented but is silently broken."

Layer 1: DebugView (send confirmation)#

GA4 admin's "DebugView" lets you confirm events are reaching GA4 in seconds. Enable the Chrome extension "Google Analytics Debugger" or check collect?v=2 requests in Chrome DevTools' Network tab.

Layer 2: Realtime report (aggregation confirmation)#

DebugView shows what GA4 received; the Realtime report shows what GA4 counted. The gap between the two is where silent failures hide:

• Visible in DebugView but not in Realtime → reserved prefix collision likely
• Visible in Realtime but not in standard reports → custom dimension not registered

Layer 3: BigQuery export (structure confirmation)#

Enabling the GA4 BigQuery integration exports raw data daily. You can confirm the actual stored parameter structure that the report UI hides, directly via SQL.

SELECT
  event_name,
  COUNT(*) AS event_count,
  COUNT(DISTINCT user_pseudo_id) AS users
FROM `<project>.<dataset>.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260423' AND '20260429'
GROUP BY event_name
ORDER BY event_count DESC

A weekly check for "unexpected event names" or "naming inconsistencies" surfaced by this query catches silent failures early.

When all three layers verify clean, your GA4 event measurement moves from "I think it is set up" to "it is verifiably set up." From there, you can take purchase.value, divide by sessions and channels, and stand up an RPS / AOV-based revenue decomposition as the foundation for revenue-first decisions. For how to build the broader KPI framework on top of GA4, see Marketing KPI design: 5 metrics that drive decisions.

References#

[1] Allies 「Survey on the use of Google Analytics 4」 October 2023 [2] Google 「[GA4] Recommended events」 March 2025 [3] Google 「[GA4] Automatically collected events」 February 2025 [4] Google 「[GA4] Event naming rules」 January 2025 [5] Google 「[GA4] BigQuery Export schema」 April 2025