Create a bullet-proof measurement plan for GA4 and GTM

Setting up GA4 and GTM without a plan is a mistake. If you don’t plan and write down what you’re tracking and why, you’ll end up with events scattered all over the place, inconsistent naming, and data that isn’t useful for making business decisions.

A good measurement plan bridges the gap between business goals and the actual tracking setup, clarifying what to track, how to set it up, and how to ensure it continues to work as tracking needs change.

Why do measurement plans fail?

Most GA4 implementations don’t fail because of technical problems; they fail because of poor initial planning. Usually, these are the common problems:

• Wanting to track everything

  You might believe that if you track every click and scroll, you’ll have a full picture, but you won’t. Instead, you’ll get a lot of noisy data that distracts you from what you really need to know. In GA4, sites with around 50-60 custom events, on average, use only five to make business decisions. The rest just make the reports messier and more difficult to analyze.

• No alignment between business goals and events

  If you don’t connect tracking to results, your metrics won’t answer important questions. You will find out how many people clicked the “Download Guide” button, but you won’t know whether it resulted in qualified leads, because no one planned for that to be measured the right way.

• Missing documentation

  Imagine this: six months after launching your tracking, someone asks: “What exactly does the cta_click event track?” No one can recall, and to make things worse, your GTM container has three similar events with slightly different names. Without proper documentation, every update becomes a hassle, and each new team member has to start from scratch to understand what’s already there.

Now that we’ve covered what to avoid, let’s go through each step of building a solid, long-lasting tracking plan.

1) Define and organize business outcomes

Before you even open GTM or GA4, you should define what success looks like for your business. For each business result that matters to you, you need to specify:

• Outcome: what you’re trying to achieve (e.g., more sales, qualified leads, product engagement).
• Action: the specific user behavior that proves it happened (e.g., order completed, form submitted, feature used).
• Context: the parameters you’ll need to analyze that action in reports.

To do so, first, gather all essential information and decide how to organize your measurement plan.

A. Organize by stakeholder or growth stage

You can structure your measurement plan in various ways based on your team’s workflow. Two common methods are:

• By department or stakeholder

  Different teams need different data, so gather requirements from each of your company’s core departments:

  • Business stakeholders: metrics for business development and strategic decisions.
  • Marketing department: campaign performance, lead quality, channel attribution.
  • UI/UX & design team: user behavior patterns, feature adoption, usability insights.
  • Engineering department: technical performance, error tracking, load times.
  • Conversion Rate Optimization (CRO) department: conversion funnel metrics, A/B test results, optimization opportunities.
  • Customer success: retention rates, satisfaction scores, support ticket patterns.
  • Sales department: lead quality, pipeline metrics, conversion timing.
  • Analysts: cross-functional metrics, trend analysis, predictive indicators.

• By growth framework

  Alternatively, organize your measurement plan around growth stages. This approach is effective for product-focused businesses:

  • Acquisition: grow monthly visitors, increase new user signups.
  • Activation: newsletter signups, account creation, first meaningful action.
  • Engagement: product page visits, feature usage, session depth.
  • Revenue: purchases, upgrade conversions, cart behavior.
  • Retention: repeat customer sales, subscription renewals, loyalty metrics.

B. Map outcomes to trackable actions

We briefly discuss this in our article “How Google Tag Manager fits into the GA4 setup”, but let’s go into more detail. After gathering requirements from stakeholders or mapping your growth stages, translate each business objective into this format:

C. How to identify what actually matters

If you’re struggling with this exercise, ask yourself: “If I had perfect data about this action, what questions would I answer?” Then work backward. If you wouldn’t ask questions about specific actions or parameters, simply don’t track them.

D. Distinguishing key events from regular events

Key events (GA4 term for conversions) should only be used for actions that clearly generate business results. Marking too many actions as key events dilutes your attribution data and makes campaign optimization more difficult.

A qualified lead form submission? That’s a key event. A PDF download that doesn’t indicate purchase intent? That’s just a regular event. A completed purchase? Definitely a key event. You get the idea.

2) Establish coherent naming conventions

Now that you know what to track, decide on how to name it. Inconsistent naming turns your analytics setup into a liability because it causes:

• Duplicate tracking (someone may recreate an event they didn’t know existed).
• Fragmented data (similar events have different names).
• Analysis barriers (analysts can’t trust that they’ve found all relevant events).

So, establish conventions now before you start designing your event structure. Here’s what you should remember:

A. GA4 event naming rules

Google enforces certain rules, such as:

• Event names must start with a letter (not a number or symbol).
• Use only letters, numbers, and underscores (no spaces, hyphens, or special characters).
• Maximum 40 characters per event name.
• Case sensitive: Form_Submit and form_submit are different events.

B. Best practices

Beyond Google’s guidelines, follow these conventions for consistency:

• Always use lowercase: form_submit instead of Form_Submit.
• Use snake_case: add_to_cart, not addToCart or add-to-cart.
• Start with a verb when possible: click, view, submit, complete.
• Be descriptive but concise: newsletter_signup is better than user_subscribes_to_newsletter_email_list.

C. Parameter naming rules

Parameters follow similar conventions:

• Use lowercase with underscores (snake_case): form_id, lead_type, page_path.
• Be consistent across all events (if you use lead_type, never send leadType or lead_source for the same information).
• Avoid prefixes like ga_, or google_.
• Don’t start parameter names with just an underscore.
• Maximum 40 characters per parameter name.
• Never send Personally Identifiable Information (PII) like email addresses, phone numbers, or full names in parameters. This violates privacy regulations and Google’s policies.

D. GTM naming conventions for tags, triggers, and variables

Your GTM container needs organization just as much as your GA4 events. We recommend this structure:

• Tags: [Platform] – [Event/Action] – [Optional Context]

  Examples:

  • GA4 event – form_submit – contact.
  • GA4 event – purchase.
  • GA4 event – video_complete.

• Triggers: [Trigger Type] – [Description]

  Examples:

  • Form Submission – Contact Form.
  • Click – All Download Links.
  • Page View – Thank You Pages.

• Variables: [Type] – [Description] or DLV – [dataLayer Variable Name]

  Examples:

  • URL – Query Parameter: utm_source.
  • DOM – Product Name.
  • DLV – transactionId.
  • Constant – Currency: USD.

3) Design your event structure before even touching GTM

At this point, you need to determine how to structure the events you’ll include in your measurement plan.

A. When to use GA4’s recommended events vs. custom events

GA4 provides a list of recommended events, such as purchase, add_to_cart, sign_up, generate_lead, and view_item. These events automatically populate standard reports and integrate with Google Ads. If an event you need exists in GA4’s recommended list, use that exact name and send the suggested parameters – you’ll spend less time building custom reports, and your data will integrate better with other tools.

Create custom events only when:

• No recommended event matches your action.
• Your business has unique tracking needs that recommended events don’t cover.
• You need granular tracking of specific features or workflows.

B. How specific should event names be?

You could track form submissions as:

• form_submit (very general).
• contact_form_submit (moderately specific).
• homepage_contact_form_submit (very specific).

Each approach has pros and cons: very general names keep your event count low but require more parameters to distinguish actions, while very specific names make some queries easier but increase your event count and complicate cross-form analysis.

Our recommendation: start with fairly specific event names that clearly describe the user action, then use parameters to provide additional context. For example:

• Good: form_submit with parameters for form_id, form_name, page_location.
• Better: contact_form_submit, newsletter_signup, demo_request (different user intents).
• Avoid: homepage_hero_contact_form_submit_desktop (too specific, context belongs in parameters).

C. What context do you need in each event?

Parameters are where GA4 shines and where most setups go sideways. Beyond naming rules, you need to understand parameter scope. GA4 has three types:

• Event parameters describe a specific action. They answer “which product?” or “what value?” for a particular event. Examples: form_name, product_id, button_text, video_title.
• User properties describe the person who performs that action. They answer “who is this user?” and persist across sessions. Examples: is_logged_in, subscription_tier, user_type, signup_date.
• Item parameters describe product-level attributes in e-commerce events. They only make sense within an items array. Examples: item_id, item_name, item_brand, price, quantity.

Use event parameters for most tracking; reserve user properties for attributes you’ll use for audience building; item parameters are specifically for e-commerce implementations.

D. Planning for future analysis

Before you commit to your parameter strategy, consider these limits:

• GA4 allows you to send up to 25 parameters with each event.
• You can register 50 custom event-scoped dimensions and 25 custom user-scoped dimensions per property.
• You can register up to 50 custom metrics per property.
• Custom dimensions and metrics aren’t retroactive, so you only get data from when you create them.

This means you should plan which parameters you’ll register as custom dimensions. Start with the parameters you already know you’ll report on, since you can always add more later.

4) Document your plan

You’ve designed your events and parameters. Now it’s time to document everything so others can understand and maintain your work. In your measurement documentation, include:

A. Event specifications

Every event you track should have:

• Event name (exactly as it appears in GA4).
• Description (what user action triggers it).
• Trigger (page load, click, form submit, etc.).
• Parameters (name, description, variable source, registered as dimension?).
• Business purpose (what question does this event help answer?).
• Indication if it’s a key event or not.
• Priority level.
• Implementation status.

B. Parameter definitions

For each parameter:

• Parameter name (exactly as sent to GA4).
• Scope (event, user, or item).
• Data type (text, number, currency).
• Description (expected values or format).
• GTM variable source.
• Which events include this parameter.
• Indication if it’s registered as a custom dimension or not.

C. Custom dimensions record

Track which parameters you’ve registered as custom dimensions in GA4, including:

• Dimension name.
• Parameter name (must match exactly).
• Scope.
• Date registered.
• Reports/analyses that use it.

D. Priority levels

Assign priority levels (like the ones we suggest below) in your documentation, so your team knows what to implement first and what can wait:

• High priority includes vital business metrics that directly measure revenue or business outcomes: purchase events and revenue tracking, as well as primary key event actions (lead forms, signups, bookings).
• Medium priority covers supporting metrics that give context but aren’t essential for launch: engagement indicators (scroll depth, video plays), secondary conversion paths, and content interaction metrics.
• Low priority is reserved for nice-to-have metrics and exploratory tracking: detailed engagement metrics and experimental tracking for future analysis.

E. Implementation status

Your documentation should also include implementation status for each event. For example:

• QA: Quality assurance complete, ready for production.
• In progress: Currently being implemented or tested.
• Planned: On the roadmap, not yet started.
• Deprecated: It was tracking previously, but is no longer needed.

Here’s what a complete event specification could look like with all the fields we’ve covered:

F. Implementation notes for developers

If you’re providing specifications to developers, include technical details in your documentation.

For GTM implementations:

• Which GTM variables to create or reuse.
• Any dataLayer requirements.
• Testing steps to verify it works.

For direct implementations:

• Code examples showing the gtag call.
• Required parameters and their sources.
• Where in the user flow to place the code.

Be explicit about what you can’t source without a developer’s help. For example, if you can’t easily obtain revenue data on your own, specify that you need a dataLayer push with transaction_id, value, currency, and items array.

G. Keep your documentation updated and accessible

Store your measurement plan somewhere your entire team can access, like:

• Shared spreadsheet.
• Project management tool.
• Version-controlled repository.

Update the documentation whenever you modify tracking and include a “Last updated” field.

5) Implement gradually, not all at once

Trying to implement your entire measurement plan in one release will likely lead to frustration and chaos. Here’s how you can strategically phase your implementation:

A. Start with high-priority events

Now, your documented priority levels will guide implementation. Start with high-priority events – those critical business metrics that directly measure revenue or key outcomes. Get these working perfectly before moving to medium-priority supporting metrics, then low-priority ones.

B. Test before going live

Never publish tracking changes without testing. Use these tools and validation procedures:

• GTM Preview Mode

  Use this tool to walk through your user flow (submit forms, complete purchases, etc.) and verify:

  • The right tags fire at the right time.
  • Variables populate with expected values.
  • No tags fire multiple times accidentally.

• GA4 DebugView

  This tool shows events hitting GA4 in real-time. Open it (Admin > Data display > DebugView), then trigger events on your website and verify:

  • Event names match your specification.
  • All parameters appear with correct values.
  • Events appear once (not duplicated).
  • Item arrays include all required fields for e-commerce.

If something doesn’t work in GTM’s Preview Mode and GA4’s DebugView, it won’t work in production, so this is your chance to fix it.

6) Maintain and audit your plan

By now, your plan is well underway, but it still requires ongoing maintenance:

A. Quarterly review checklist

Every three months, review these tracking points:

• Event accuracy check

  Open DebugView and trigger your key events. Check whether they still fire correctly and whether the parameters are populating.

• GTM version review

  Check your GTM version history: are versions named clearly, and do descriptions explain what changed? If not, go after that information.

• Unused event cleanup

  Create a GA4 Exploration that displays all events from the past 90 days. If there are events firing that you no longer use, remove them.

• Documentation sync

  Does your measurement plan document align with what’s actually implemented? Make all necessary updates.

• New tracking needs

  If your business has launched new features, forms, or products that require tracking, add them to your backlog.

• Privacy and compliance check

  Review a sample of events in DebugView. Look for email addresses, phone numbers, or names in parameters – if you find PII, you have a critical issue.

• Access control review

  In GA4, check Admin > Account > Account access management. Remove users who have left or no longer need access. Ensure at least two people have Admin access.

• Data retention verification

  Go to Admin > Data collection and modification > Data retention. Confirm it’s set to 14 months (maximum). This only needs to be checked quarterly because it rarely changes.

B. Regular audit strategy

Schedule regular audits beyond quarterly reviews to catch duplicate tracking and errors:

• Monthly data spot checks

  Check key metrics and compare month-over-month. Unexplained spikes or drops usually indicate tracking issues.

• After major website updates

  Any time your website’s code, structure, or platform changes, retest all tracking. Website redesigns break more tracking than anything else.

• Before critical periods

  Test thoroughly before Black Friday, product launches, or campaign periods. It’s never a good idea to discover tracking issues during your busiest revenue week(s).

• After implementing consent changes

  Whenever you update cookie banners or consent management, test with consent denied in DebugView. Confirm that only non-identified pings fire, not full tracking.

C. Red flags

Watch out for these warning signs:

• Data that doesn’t make sense

  If revenue suddenly doubles but orders stay flat, you have duplicate tracking. Or if form submissions drop to zero overnight, your trigger probably broke.

• Events with weird values

  If you see “form_id = undefined” or “page_location = [object Object]”, your variable sources broke. GTM probably updated, and your variables need fixing.

• Declining data quality

  If you notice more “(not set)” values in your reports over time, parameters are failing to populate, so investigate.

• Suspicious traffic patterns

  Unusual spikes from unexpected countries, sessions lasting 0-1 second, or 100% bounce rates indicate bot traffic. Review your traffic sources and consider using IP filtering or third-party bot detection tools.

• Team confusion

  If someone asks, “What does this event track?” and nobody knows, your documentation needs updating.

D. How to handle new feature launches

When your product launches new features, make sure to:

• Update your measurement plan first: don’t let developers start tracking before you write down the specification.
• Follow your naming conventions: don’t come up with new patterns or rules.
• Reuse existing events where possible: if it’s another form, use form_submit with different parameters.
• Add new third-party tools to your unwanted referrals list: this prevents false attribution. To do it, go to Admin > Data collection and modification > Data streams > select your stream > Configure tag settings > List unwanted referrals.
• Test before launch: new tracking should go live with the feature, not weeks later.

7) Common issues caught in real implementations

Here are some of the most common issues we observe and how to fix them:

Final thoughts

The key to effective tracking that doesn’t break is treating your measurement plan as a top priority and as something that evolves over time. The tips we’ve outlined here connect business outcomes to real-world implementation, so follow them closely to ensure a smooth and successful process.

Once you’ve developed your measurement plan and are ready to implement it in GTM, read our “How Google Tag Manager fits into the GA4 setup” guide for step-by-step instructions on creating tags, triggers, variables, and testing your implementation.