Events & conversion configuration
Because everything in GA4 is an event, the quality of your reports is decided here — not in the dashboards. This module is the craft of event design: which of the four collection tiers an action belongs to, how to implement the ecommerce schema without losing revenue, how key events and parameters and custom dimensions actually work, and how to configure and verify it all in GTM and DebugView.
What you will learn
Why events are the whole game
Everything in GA4 is built from events, so the quality of your reports is capped by the quality of your event design. Get the events right — named consistently, carrying the right parameters, marked as key events where they matter — and every report, audience, and attribution model downstream just works. Get them wrong and no dashboard can save you. This module is where measurement is won or lost.
In the last module you learned that GA4 has one primitive: the event. This module is about wielding it well, because the platform gives you enormous freedom and almost no guardrails. GA4 will happily collect a misspelled event with a missing value and report it as confidently as a perfect one. The discipline you bring to event design is the discipline of the whole account.
The two platforms are much more different than they are alike.
Hold onto that. The instinct to port Universal Analytics events one-for-one is the single most common way good teams build bad GA4 accounts. The event model is genuinely different, and it rewards a fresh design rather than a translation.
The four ways data arrives
Events reach GA4 four ways, in rising order of effort and value. Automatically collected events (like page_view, session_start) need zero setup. Enhanced measurement events (scrolls, outbound clicks, site search, video, file downloads) switch on with a toggle. Recommended events are Google’s predefined names for common actions (purchase, sign_up) — you send them, Google supplies the schema. Custom events are ones you invent for your business. Know which tier an action belongs to before you build it.
The practical reason this matters: people constantly rebuild things GA4 already collects for free, and invent custom events where a recommended one exists. Both waste effort and fragment your data from every other GA4 account on earth. The skill is matching each action to the lowest tier that covers it.
Fired with no configuration the moment the tag loads: page_view, session_start, first_visit, user_engagement. These are the backbone of basic reporting and you cannot turn most of them off.
pageview tag in an account, delete it — it double-counts.A switch in the data-stream settings enables scroll depth (90%), outbound clicks, site search, video engagement, and file downloads — no code. Powerful, and easy to forget is even on.
For common actions Google publishes standard names and parameters: purchase, add_to_cart, sign_up, generate_lead. Use them and you unlock prebuilt reports, ecommerce features, and easier comparisons.
When nothing fits — a SaaS ‘invited a teammate’, a media site’s ‘finished article’ — you define a custom event with your own name and parameters. Maximum flexibility, zero prebuilt support.
Recommended events and the ecommerce schema
Recommended events are Google’s shared vocabulary for common actions, and for ecommerce they are non-negotiable. The ecommerce schema — view_item, add_to_cart, begin_checkout, purchase, each carrying a structured items array — powers GA4’s entire shopping-behavior reporting. Implement it to spec and the monetization reports light up; deviate from it and they stay empty no matter how much data you send.
This is the place to be a stickler, not a creative. The ecommerce reports are hard-wired to expect exact event names and an exact items parameter structure. A purchase event with price spelled cost, or items sent as a flat list instead of the nested array, produces a purchase count with no revenue — the most common and most painful ecommerce bug there is.
- Map the funnel to standard events
view_item→add_to_cart→begin_checkout→add_payment_info→purchase. Send each at the real moment it happens. - Build the items array to specEvery commerce event carries
items: an array of objects withitem_id,item_name,price,quantity, and optionalitem_category,item_brand. - Send currency and value on purchase
purchaseneedstransaction_id,value, andcurrency. Missing currency is why revenue silently shows as zero. - Verify against the Monetization reportsConfirm revenue, items, and funnel steps populate — not just that an event fired.
Businesses now get certain events out of the box, which gives them a lot more insight into what’s going on on their sites.
Key events: GA4’s word for conversions
A key event is simply an event you have flagged as important — a purchase, a lead, a signup. In March 2024 Google renamed GA4 “conversions” to “key events,” reserving the word “conversion” for Google Ads. Nothing about the calculation changed; only the label did. You create a key event by toggling an existing event on in the admin — which means the event must already exist and fire correctly first.
The terminology trips up everyone who learned GA4 before 2024, so be precise with clients: in GA4 you mark key events; in Google Ads you count conversions; the same purchase can be both, with one label on each side. This was a clarity fix, not a feature change, and old conversion settings migrated automatically.
Claim: In March 2024, Google renamed GA4 “conversions” to “key events,” reserving “conversions” for Google Ads; the calculation was unchanged and settings auto-migrated. Source: Search Engine Land. Context: The change aligned GA4’s vocabulary with Google Ads and removed a long-standing source of confusion between the two products.
Teams flag everything as a key event — ten, fifteen of them — and then wonder why their ‘conversion rate’ is meaningless and every channel looks great.
I keep the list ruthlessly short: the one or two actions that actually represent business value, plus at most a couple of genuine leading indicators. Everything else stays a plain event you can still analyze.
A key event is a vote about what matters. When everything is a key event, nothing is, and your optimization signals to Google Ads turn to noise.
Most teams fire generate_lead as a bare count. Then they wonder why Google’s bidding treats a tyre-kicker and a six-figure enterprise lead as identical — because, to the data, they are.
I attach a modeled value to non-purchase key events: close-rate × average contract value, or a tiered value by form type. Now generate_lead carries, say, value: 240, and value-based bidding has something real to optimize toward.
It is not fake revenue — it is a defensible estimate, documented in the measurement plan, that turns ‘count the leads’ into ‘chase the valuable ones.’
Parameters: where the meaning lives
Parameters are the key–value details attached to an event, and they come in scopes. Event-scoped parameters describe a single event (value, method). Item-scoped parameters live inside the ecommerce items array (item_brand). User-scoped properties describe the person across events (membership_tier). GA4 collects some parameters automatically, but the business-specific ones that make analysis possible you must send yourself — and decide their names before launch.
Think of the event as a verb and parameters as the adjectives and adverbs. “Purchase” tells you something happened; value: 49, currency: USD, coupon: SPRING tell you the story worth analyzing. An event with no useful parameters is a tally mark. An event with well-chosen parameters is a question you can answer ten different ways later.
Custom dimensions, metrics, and cardinality
Sending a custom parameter is only half the job: until you register it as a custom dimension (for text) or custom metric (for numbers) in the admin, it will not appear in standard reports as a breakdown. Registration is limited — roughly 50 custom dimensions on the free tier — so spend the slots deliberately. And beware cardinality: a dimension with too many unique values (like a raw URL or user ID) overflows into an ‘(other)’ bucket and corrupts the report.
Two hard-won rules live here. First, registration is retroactive only going forward — a parameter you forgot to register collected data, but you cannot break it out historically until the day you register it. So register the parameters in your measurement plan at launch. Second, high-cardinality dimensions are a silent data-quality killer: GA4 caps unique values per day, and everything past the cap collapses into ‘(other),’ which is why analysts who jam unbounded IDs into custom dimensions end up with reports they cannot trust.
The ~50-slot limit feels generous on day one and runs out fast. I treat it as a budget with a waiting list: each new dimension has to justify displacing the marginal one.
For anything high-cardinality — user IDs, transaction IDs, full URLs — I keep it as a parameter for BigQuery and refuse to register it as a reporting dimension, because cardinality limits will wreck the report anyway.
The slots are for low-cardinality business attributes you actually segment by: plan type, content category, logged-in state.
Edit the list above — results update live.
Runs entirely in your browser. Flags non-snake_case, reserved ga_/google_/firebase_ prefixes, over-length names, and case-duplicate collisions (the silent conversion-splitter). Also available as a standalone tool.
Configuring events in GTM
In Google Tag Manager you build a GA4 event by pairing a trigger (when to fire — usually a custom-event trigger matching a data-layer push) with a GA4 event tag (what to send — the event name plus parameters mapped from data-layer variables). The data layer publishes the fact; the trigger catches it; the tag forwards it. Once the GA4 Configuration/base tag is in place, every new event is a tag-and-trigger pair, no site code required.
The clean pattern is always the same three pieces, and naming them precisely keeps a container maintainable as it grows to dozens of tags. Your site pushes event: 'generate_lead' with details into the data layer; a GTM trigger listens for exactly that event name; a GA4 event tag reads the data-layer variables into named parameters and sends it. Build it once as a template and the rest of the account is repetition.
// 1. Site pushes the fact
window.dataLayer.push({
event: 'generate_lead',
form_id: 'contact-footer',
lead_value: 25.00
});
// 2. GTM trigger: Custom Event = generate_lead
// 3. GA4 event tag: name = generate_lead
// params: form_id = {{dlv.form_id}}, value = {{dlv.lead_value}}The site never knows about GA4. GTM is the broker. Swap, rename, or add a destination tag any time without touching site code.
The slow way to populate content_group is a tag (or rule) per section: one for /blog, one for /pricing, one for /docs… thirty brittle rules that someone forgets to update at the next redesign.
Instead I use a single GTM RegEx Lookup Table variable: page path in, content group out, all the mappings in one place. Every event reads that one variable.
One variable to audit, one place to change when the site moves, zero duplicated logic — and the data layer stays clean.
Modify and create events without code
GA4’s admin has two underrated tools that let you reshape events with no developer at all. Create event builds a new event from an existing one when a condition is met (e.g. a purchase over $500 becomes high_value_purchase). Modify event rewrites incoming events — rename them, fix a bad parameter, or correct a legacy name. Both are powerful escape hatches, and both apply only going forward.
These earn their keep when you inherit a messy implementation you cannot get developer time to fix. Inconsistent legacy names? A modify-event rule can normalize Purchase to purchase at collection. Need a conversion for a specific high-value subset? Create-event spins one off without shipping code. Just remember the limits: they act on data arriving from now on, they cannot retro-fix history, and stacking too many rules makes an account no one can reason about.
Modify- and create-event rules are seductive because they fix problems in minutes without a developer. I use them constantly — as triage, with an expiry date.
The trap is letting the patch become the architecture: two years later the ‘real’ logic lives in a stack of admin rules nobody documented, and a new analyst has no idea why the data looks the way it does.
So every rule I create gets a note in the measurement plan and a ticket to fix the root cause in the data layer. The rule buys time; the data layer is still the answer.
- Define it in the plan firstName the event in snake_case (
request_demo), list its parameters and types, and decide if it’s a key event. No code until this line exists in the sheet. - Push it to the data layerOn the real action, have the site push
{event:'request_demo', form_id:'...', value: 240}. The site publishes the fact and nothing more. - Catch it with a triggerIn GTM, create a Custom Event trigger matching
request_demo. - Map it in a GA4 event tagAdd a GA4 event tag, name it
request_demo, and map data-layer variables to parameters. - Register and mark itRegister the parameters you’ll segment by as custom dimensions; if it’s a key event, toggle it on in Admin.
- Verify in DebugView, then publishWatch it arrive with correct parameters and key-event status; only then publish.
Same six steps for every custom event — plan, push, trigger, tag, register, verify.
Watching events arrive in DebugView
DebugView is where event configuration gets verified, parameter by parameter, in real time from your own device. Enable debug mode (GTM Preview does it automatically), trigger the action, and watch the event appear in seconds — then click it to confirm every parameter name and value matches your plan. An event you have not watched arrive in DebugView is an event you do not actually know is working.
This is the same discipline from Module 1, now aimed specifically at events. The failure mode is trusting that because a tag ‘published successfully’ in GTM, the data is correct. Publishing only means the tag exists. DebugView proves the event fires at the right moment, with the right name, carrying the right parameters in the right format — the only definition of ‘working’ that survives contact with reality.
- Turn on debug modeGTM Preview connects your session to DebugView automatically; otherwise use the GA Debugger extension.
- Fire the real actionSubmit the actual form or complete a test purchase — don’t simulate it abstractly.
- Open the event in the timelineIn Admin → DebugView, click the event and read every parameter. Confirm names and values against the measurement plan.
- Confirm key-event statusIf it should be a key event, verify the key-event marker and (for ecommerce) that value and currency arrived.
Where event tracking goes wrong
Event tracking fails in a handful of predictable ways: rebuilding events GA4 already collects, inventing custom events where recommended ones exist, breaking the ecommerce items schema, forgetting to register parameters as custom dimensions, and over-marking key events. Each is cheap to avoid with a measurement plan and a DebugView pass, and expensive to unwind once weeks of malformed data have piled up.
A custom page_view or scroll tag layered on top of automatic collection and enhanced measurement double-counts everything.
A custom completed_purchase instead of the recommended purchase locks you out of ecommerce reports and cross-account comparison.
Sending products as a flat list, or misspelling price, yields purchase counts with zero revenue.
items to spec and verify revenue in the Monetization reports, not just an event count.Custom parameters collect silently but never appear as report breakdowns until registered as custom dimensions — and only from that day forward.
Ten key events make conversion rate meaningless and pollute the signals sent to Google Ads.
Your event-configuration checklist
Event configuration is done when this list is true — not when tags ‘published successfully.’ Tick only what you have personally verified in DebugView against the measurement plan.
Prove it. Earn your passcode.
Ten questions, CASE method (Context · Analysis · Strategy · Execution). Pass at 90% to unlock this module’s completion passcode — retake as many times as you like.