Most websites track visits. I’d rather track actions that lead to revenue. If I want event tracking to work, I need a short plan, a small set of high-value events, clean naming rules, the right setup method, and post-launch checks for duplicates and missing data.
Here’s the article in plain English:
- I start with 3–5 business questions
- I map each question to one event tied to a result
- I focus on primary conversions first, not every click
- I standardize event names, parameters, and required fields
- I choose between manual code, a tag manager, or platform-native tracking
- I test each event before launch and re-check it after site changes
A few points matter most:
- Track actions like purchase, lead form submit, and booked call confirmation
- Keep event names consistent, like
add_to_cartandbegin_checkout - Send money as numbers, such as $129.99
- Block raw PII like email addresses and phone numbers
- For many sites, 3–8 key events per property is enough
- If a required field is missing, the event should be stopped or flagged
This article is a simple checklist for getting clean event data you can use for reporting, budget decisions, and fixing funnel drop-offs.
Conversion Tracking with Google Tag Manager and GA4
sbb-itb-2ec70df
Quick comparison
| Area | What I focus on | What I avoid |
|---|---|---|
| Planning | 3–5 clear business questions | Fuzzy goals |
| Event selection | Revenue and lead actions first | Tracking every click |
| Naming | One naming pattern in snake_case | Mixed names for the same action |
| Parameters | Required fields with fixed types | Missing value, currency, or IDs |
| Setup | One clear delivery path | Duplicate tags and split setups |
| QA | Test before and after launch | Publishing without checks |
If I want reports I can trust, this is the checklist I’d use first.
Define the tracking plan
Start here before you touch implementation. Pick the 3–5 business questions your site needs to answer. Then tie each question to one measurable event and one business result.
That sounds simple, but it’s where a lot of tracking setups go off the rails. If the question is fuzzy, the event usually ends up fuzzy too.
Map business goals to measurable website actions
Match each business goal to the website action that proves it happened. If the goal is lead generation, use events like lead_form_submit or demo_request. If the goal is online sales, use add_to_cart, begin_checkout, and purchase. If the goal is booked calls, use booked_call only after the scheduling confirmation appears – not when someone clicks the calendar.
Start with actions tied straight to revenue or qualified leads. That’s the stuff that matters most.
A purchase event with a value parameter in USD tells you much more than a generic button click event. One shows business impact. The other just shows that someone tapped something.
Document triggers, parameters, and data types
For every event, write down exactly:
- when it fires
- which fields it must send
- the data type for each field
An event spec cuts out guesswork for developers and keeps reporting steady from month to month.
| Field | Example | Type | Required? |
|---|---|---|---|
transaction_id |
"TX-2026-08-11-12345" |
string | Yes |
value |
129.99 |
number (USD) | Yes |
currency |
"USD" |
string | Yes |
coupon_code |
"SUMMER10" |
string | No |
shipping_state |
"CA" |
string | No |
Mark a parameter as required only if the report falls apart without it. For example, value on a purchase event matters. So does transaction_id on a purchase event. Mark a field as optional if it adds context but doesn’t affect core KPIs.
If a required field is missing, the event should not fire, or the gap should be flagged right away as an implementation issue. Otherwise, bad data sneaks into reports and muddies everything.
Assign ownership and run privacy checks before implementation
Give each event two owners:
- a reporting owner
- a technical owner
Without ownership, events drift. Then reporting breaks, and nobody knows who should fix it.
Before implementation, review every parameter for PII. Analytics tools should never receive raw email addresses, phone numbers, or full mailing addresses. If you need to identify users across events, use a hashed user ID instead.
Document the privacy status next to each event, like: "No PII – hashed user_id only."
Once ownership and privacy are set, you can decide which events are worth tracking.
Select the events to track
Event Tracking Types: Primary vs Secondary vs Diagnostic
Start with your tracking plan and rank each event by business impact. For most businesses, 3–8 key events per property is enough to support solid reporting [1]. Each one should connect to a KPI that someone on the team actually uses.
When you track too many events, the data gets noisy. Trust drops. And simple business questions become harder to answer. A good filter is this: each event should help answer one of three things – what matters most, what explains conversion, or what helps diagnose a problem.
Track primary conversions first
Primary conversion events are the must-haves. These are the actions that point straight to revenue or qualified pipeline, like purchase, submit_lead_form, book_demo, start_subscription, and request_quote.
Here’s the test: if movement in an event would not change a revenue forecast or budget call right away, it likely isn’t a primary event.
Get these events right first. Don’t pile on extra tracking before the core actions are clean and stable. After that, bring in secondary events to show where people drop off.
Add supporting and diagnostic events only when they explain results
Secondary events like add_to_cart, begin_checkout, view_pricing, and start_free_trial help explain user behavior between entry and conversion. They’re useful for funnel views and cohort analysis, but they usually don’t belong on top-line dashboards.
Diagnostic events sit one level lower. Events like form_field_error, payment_declined, and checkout_error help you figure out why conversions move up or down. Add them only when there’s a clear business question behind them. For example, if checkout completion drops all of a sudden, or form abandonment starts climbing, these events can help pinpoint the cause.
Before a diagnostic event goes live, write a one-sentence business use case for it in the tracking plan. For example: track checkout errors by payment method to prioritize integration fixes. If you can’t write that sentence, leave the event out.
Compare primary, secondary, and diagnostic event types
| Event Type | Purpose | Examples | Reporting Priority |
|---|---|---|---|
| Primary | Measure direct business outcomes | purchase, submit_lead_form, book_demo, start_subscription |
Critical – top-line dashboards and bidding |
| Secondary | Measure key steps toward conversion | add_to_cart, begin_checkout, view_pricing, start_free_trial |
High, but supportive – funnel and cohort reports |
| Diagnostic | Explain why conversions rise or fall | form_field_error, payment_declined, checkout_error |
Targeted – troubleshooting and UX optimization |
Use this table to classify every proposed event before approval. It gives you a simple pecking order for what should be implemented first.
Standardize event names and parameters
After you pick the events to track, set the exact names and fields every team will use. If you skip this step, form_submit and submit_form end up as two different events in reports, even though they describe the same action. A shared standard turns your tracking plan from a rough outline into something the team can ship.
Use a consistent naming convention
Use snake_case: all lowercase, with words separated by underscores. Stick to object_action or category_object_action.
Examples:
product_viewedadd_to_cartbegin_checkoutpurchaseclick_cta_headerform_submit_lead_capturevideo_play_product_demo
Two simple rules avoid a lot of mess. First, never generate event names dynamically. That means no dates, campaign IDs, or other changing values added to the event name. Second, never use reserved platform names like scroll, page_view, or form_submit as custom event names in GA4. That can lead to conflicts or odd behavior.[2][3]
If something changes from one event to another, put that change in a parameter, not in a new event name.
Align shared parameters across events
When shared fields use the same names and formats across events, your team can build a dashboard once and use it again and again. That saves time and cuts down on cleanup later.
Standardize these fields across all related events:
| Parameter | Type | Example Value |
|---|---|---|
page_location |
String | /pricing, /checkout |
page_category |
String | home, product, blog, checkout |
button_text |
String | "Get started", "Add to cart" |
form_name |
String | contact_us, newsletter_signup |
value |
Number | 49.99 |
currency |
String | USD |
user_type |
String | new, returning |
For money fields, keep the value numeric: 1499.00, not $1,499.00.[4] That matches how major ad platforms and analytics tools expect conversion values for reporting and optimization.
Mark required fields versus optional fields
Use the same spec to show which fields must fire and which ones simply add extra detail. This split keeps reporting steady and makes QA much easier.
Required parameters are the fields your reports depend on. For example, value and currency on a purchase event, or form_name on a form_submit_lead_capture event. Optional parameters like utm_campaign, experiment_variant, or scroll_depth add context, but a missing one usually won’t break a report.
In the tracking plan, include a column for each field:
Required = YesRequired = No
Also list the data type and an example value. Required fields should be validated in every environment, including staging and production. Optional fields can roll out over time. That helps cut broken reports and the usual back-and-forth between analytics and engineering.
With names and parameters set, the next step is picking the implementation method that works for your team.
Choose the implementation method
Once your event names and parameters are set, the next step is picking how each event will go live. In most cases, teams use one of three paths: manual code, a tag manager, or platform-native tracking.
Each option comes with a tradeoff. Some give you tighter control. Others make updates easier. And some are fine at first, but can get cramped once your setup grows.
Manual code for precise control
Manual code gives developers tight control over custom interactions, complex user flows, and async actions. It works well when an event needs exact timing, a specific payload structure, or consent-based logic.
The downside is simple: every change needs engineering time. So while this method is often the best fit for more complex setups, it can slow down routine tracking updates.
Tag manager for centralized updates
A tag manager lets you update tracking without touching site code every time you need a small change. A common setup is to push the event into the data layer and then let the tag manager fire the tag.
That can save a lot of time. But it also means governance matters.
If a tag manager isn’t managed well, it can lead to duplicate tags, trigger conflicts, and mismatched parameter mapping. Keep one source and one delivery path for each destination. [5]
A few habits help keep things clean:
- Limit publish access
- Document each rule
- Test in preview before going live
One risk deserves extra attention. If the same measurement ID is loaded through both a hardcoded script and a tag manager container, your reports can show duplicate events. [6]
Compare manual code, tag manager, and platform-native tracking
| Implementation method | Implementation speed | Level of control | Maintenance effort |
|---|---|---|---|
| Manual code | Slower | Highest | Medium to high |
| Tag manager | Faster | Medium to high | Lower for routine updates, but requires governance |
| Platform-native tracking | Fast for simple use cases | Lower to medium | Usually lowest initially, but can be limiting as needs grow |
Choose the simplest method that still gives you reliable control over the event. In plain English:
- Manual code fits complex behavior
- Tag manager fits faster updates
- Platform-native tracking fits simple, platform-based events
Next comes the part that saves a lot of headaches later: testing every event before publishing.
Validate, publish, and maintain
Test every event before publishing
Once your event plan is in place, test every trigger and payload before you publish anything. Before launch, fire each event in DebugView or another real-time view and check three things: it fires once, it fires at the right moment, and it includes the expected parameters.
Take form submissions as an example. That event should fire on a successful submission – not on the button click and the submission unless you meant to track those as two separate actions.
DebugView shows events as they come in and lets you inspect their parameters.[7] That matters more than it might seem. One small payload syntax mistake, like a missing comma, can block ecommerce events.[7] Browser developer tools help confirm the payload actually left the page the way it should.[10]
Test on desktop and mobile too. Page layouts shift. Sticky bars get in the way. Cookie banners change timing. And on checkout pages or lead forms, mobile behavior often doesn’t match desktop behavior at all.
Watch for duplicates, missing values, and setup drift after launch
Publishing isn’t the finish line. After launch, keep an eye on event volume and parameter quality. Look for trend changes that point to duplicate firing, blank values, or broken triggers. If an event suddenly drops to zero, there’s a good chance a site update broke something.
Site changes often disrupt event collection.[9] A redesign, a new form builder, added checkout steps, or even updated CTA labels can quietly throw off tracking. That’s why it helps to re-test high-value events after every major release and add a tracking check to your deployment checklist.
If purchase events start duplicating, check for a reused transaction ID or a second firing tag.[7][8]
Conclusion: Build a tracking setup your team can rely on
Build a tracking setup your team can rely on by starting with clear goals, focusing on high-value events first, using consistent names and parameters, and re-testing after every major site change.
FAQs
Which events should I track first?
Start with events that connect straight to business goals and revenue, like purchases or demo requests. Once those macro-conversions are in place, track 3 to 5 high-priority micro-conversions that signal user intent, such as form submissions, video plays, whitepaper downloads, and newsletter sign-ups.
That approach keeps data collection consistent, scalable, and centered on the metrics that matter most.
How do I prevent duplicate event tracking?
Use consistent event names and parameter formats. Then test and review real-time event data so you can spot duplicates or missing parameters early, before they turn into a reporting mess.
For high-frequency events, use throttling, debouncing, or event delegation. The goal is simple: one interaction should not fire the same event over and over.
If duplicate events still slip through, filter them during preprocessing. A common way to do that is to check event timing and remove events that happen within a short threshold, such as about 100 milliseconds. At the same time, keep valid duplicates when they reflect a real action, like refreshes.
What fields are required for a purchase event?
Include user identification such as a user ID or session ID. Add a timestamp in U.S. date and time format, ideally with millisecond precision. You should also log the conversion details that prove the purchase happened, like the event name or goal, the dollar amount, and the purchase context.
It also helps to collect supporting metadata for cleaner attribution and reporting, including:
- Device and browser data
- Page context, including the full URL and page title
- Referrer
- UTM campaign parameters
That extra context makes it much easier to tie each purchase back to the right visit, campaign, and page.
