How to Use GA4 for Conversion Tracking: A Step-by-Step Setup Guide

Open the Key Events screen in almost any GA4 property that's been live for more than a year and you'll find the same pattern: ten or twelve events marked as key events, several of them redundant with each other, none of them verified in DebugView before they went live, and a purchase count that doesn't match the order total in the CRM. GA4 makes it easy to mark something as a key event. It does nothing to stop you from marking the wrong things, counting them twice, or shipping the setup without ever confirming the data is right. Here's the workflow that avoids all three.

For a full breakdown of GA4's tiers and what's included at each, see our GA4 tool profile. If you're deciding between GA4 and a paid enterprise platform for this kind of tracking, our GA4 vs Adobe Analytics comparison covers where the two actually diverge on conversion measurement and data ownership. This post assumes you're on GA4 and want the setup done properly.

Step 1: Know What's Already Being Collected Before You Configure Anything

GA4 collects three different categories of events, and confusing them is where most setups go wrong before Step 2 even starts. Automatically collected events, like session_start and first_visit, fire with zero configuration the moment the base tag is installed. Enhanced measurement events, a set of about ten interactions including page views, scrolls, outbound clicks, site search, video engagement, and file downloads, are also collected with no code, but each one is a toggle in the data stream settings that can be switched on or off individually. Custom events are the ones you build yourself, either through recommended event names Google documents for specific industries or fully custom names, for actions enhanced measurement doesn't cover, like a pricing calculator submission or a demo booking.

Before building anything new, open Admin, go to your data stream, and check which enhanced measurement toggles are actually on. It's common to find file downloads or outbound clicks switched off on properties that later "can't track" exactly that kind of event, when the fix is a checkbox, not a new tag. Only build a custom event for an action that has no automatic or enhanced measurement equivalent already covering it.

Step 2: Choose GTM or gtag.js, and Don't Mix Implementation Styles on the Same Site

You have two ways to send events to GA4 beyond what's automatic: Google Tag Manager, which fires tags based on triggers you configure in a visual interface, or gtag.js, which means writing the JavaScript calls directly into your site's code. GTM is the better default for most teams because it puts event configuration in the hands of whoever owns analytics rather than whoever owns the codebase, and its Preview mode gives you a tag-by-tag view of what fired before anything goes live. gtag.js makes sense when a development team already owns the tracking layer and wants events versioned alongside application code rather than managed in a separate tool.

Pick one and use it consistently. The setups that produce duplicate or conflicting events are almost always the ones where a developer added a gtag.js call directly to a page that also has a GTM tag firing on the same trigger, and nobody realized both were live until the event count looked wrong. If GTM is your primary method, audit the site's source for stray gtag() calls before you build out new key events, not after.

Step 3: Build Custom Events With Parameters, Not Just an Event Name

When enhanced measurement genuinely doesn't cover the action, build the custom event with the parameters that make it usable, not just a bare event name. A demo booking event should carry the plan tier or lead source as a parameter. A form submission event should carry which form, not just a generic "form_submit" that gets fired identically from a newsletter signup and a contact request. An event name with no parameters tells you something happened; it doesn't tell you what to do differently because it happened.

In GTM, this means passing the relevant data layer variables into the tag's event parameters, not hardcoding a single static value. In gtag.js, it means adding the parameter object to the gtag('event', ...) call itself. Either way, name the event and its parameters before you build the tag, not while you're building it, so the same action isn't tracked under three slightly different names across different pages of the site.

Step 4: Mark Key Events Deliberately, Not by Checking Every Box

Google renamed "conversions" to key events in 2024; functionally, the process is the same, but the discipline required around it hasn't gotten any easier. In Admin, under Data Display, go to Events, find the event, and toggle "Mark as key event" on. A property can have up to 30 key events, and counting starts from the moment you flip the toggle, not retroactively, which is exactly why testing has to happen before you mark something, not after.

The mistake almost every account makes is treating that 30-event ceiling as a target instead of a limit. Marking page_view, scroll, and video_start as key events alongside purchase and lead_submit dilutes the metric that's supposed to represent an actual business outcome. A key event should be something that, if it happened, changed how you'd act: a purchase, a qualified lead form, a demo booked, a high-intent download. If an event doesn't clear that bar, it belongs in a regular report, not in the key events list a media buyer is going to optimize a campaign against.

Step 5: Verify Every Key Event in DebugView Before You Trust a Single Number

DebugView shows events from a single tagged device in near real time, filtered out from your regular reporting so test traffic never pollutes production data. This is the step that gets skipped more than any other in this workflow, and it's the one that catches the problems the previous four steps can still leave behind.

Enable debug mode with the GA4 debugger browser extension, GTM Preview mode, or a manual debug_mode parameter, then walk through the actual conversion path yourself: submit the form, complete the checkout, click through to the confirmation page. In DebugView, confirm the event fires exactly once per action, not zero times and not twice, check that every parameter you built in Step 3 is actually attached with the value you expect, and repeat the walkthrough on both desktop and a real mobile device, since a tag that fires correctly on one often doesn't on the other. Do this before you mark the event as a key event, not after launch when the only way to find a double-firing tag is a purchase count that doesn't match orders in your CRM.

Step 6: Close the Gaps That Cause Bad Numbers After Launch

Three problems tend to surface weeks after a setup that tested clean in DebugView, and all three are worth checking proactively rather than waiting for someone to notice the numbers look wrong. First, double counting: a refreshed confirmation page or a back-button-then-forward action can fire a purchase event a second time if the event isn't keyed to something unique. For ecommerce, attach a distinct transaction ID to every purchase event; GA4 uses it to deduplicate repeat firings of the same order automatically. Second, cross-domain gaps: if a user moves from your marketing site to a separate checkout or booking domain, GA4 can read that as a new session and lose the original source and campaign data unless both domains are explicitly configured for cross-domain measurement in the data stream settings. Third, data thresholding: if you have Google Signals enabled and you're looking at a report broken down by a narrow date range or a small segment, GA4 will withhold rows where the user count is too low to protect individual privacy, which reads as missing conversions in a report but usually isn't; widening the date range or removing the demographic breakdown often brings the numbers back.

What This Setup Actually Produces

Done this way, GA4 isn't producing a key events list that a media buyer has to mentally discount because half the entries are noise, it's producing a small, deliberate set of events that were verified in DebugView before they ever counted, parameters attached that make the data usable for something beyond a raw count, and known failure points, duplicate firings, cross-domain gaps, and thresholding, already checked rather than discovered three months in through a mismatch with CRM data. That's the difference between a GA4 property a team trusts enough to make budget decisions from and one everyone quietly cross-checks against Google Ads or the CRM before believing it.

If you're still weighing whether GA4's setup and reporting depth are enough for your measurement needs versus a platform built for stricter data ownership requirements, our GA4 vs Adobe Analytics comparison and GA4 tool profile cover the feature and pricing tradeoffs in more detail.