GA4 says form submissions doubled last month. The sales team says enquiries are flat. The ad agency brings one number, the web agency another, and the meeting is spent arguing about which is right. The cause is almost never Google Analytics itself. It's that nobody planned the set-up.
Here is how we build measurement you can rely on with GA4 and Google Tag Manager: the plan, naming, the data layer, form and ecommerce tracking, traffic sources, consent, integrations and debugging. At the end there's a checklist for your own set-up.
The measurement plan: what are you measuring, and why?
A good set-up starts with a spreadsheet, not a tag. Write down the business questions first: which channel brings people who ask for a quote, which product pages turn into sales, do people who download the brochure come back? Each question maps to one or more events, each event to a few parameters. Add an ownership column too: who built this event, who tested it, when it was last verified.
Take a manufacturer of commercial kitchen equipment in Leeds that sells through a dealer network. What matters to them is the quote form, the brochure PDF, WhatsApp and phone clicks, and searches in the dealer locator. Time on page and scroll depth change none of their decisions, so they stay out of the plan.
Naming rules
GA4 event names are case-sensitive: generate_lead and Generate_Lead count as two different events. Names must start with a letter, contain only letters, numbers and underscores, and stay within 40 characters. Parameter names are limited to 40 characters as well, and parameter values usually to 100. Parameter names beginning with google_, ga_ or firebase_ are reserved. Keep the convention simple: all lower case, words joined by underscores.
Wherever possible, use Google's recommended event names. generate_lead for enquiries, sign_up for registrations and purchase for sales slot straight into the reports and into Google Ads. Only invent a name for an action that has no recommended equivalent.
| Event | When it fires | Key parameters | Key event? |
|---|---|---|---|
| generate_lead | Quote form submitted successfully | form_name, lead_source, value, currency | Yes |
| qualify_lead | Lead marked as qualified in the CRM | lead_source | Yes, if the CRM is connected |
| contact_whatsapp | WhatsApp button clicked | button_location | No, for observation |
| contact_phone | Phone link tapped | button_location | No, real calls measured separately |
| file_download | Brochure PDF downloaded | file_name, file_extension | No |
| search | Dealer locator or site search used | search_term | No |
| view_item | Product page viewed | items, value, currency | No |
| add_to_cart | Product added to basket | items, value, currency | No |
| begin_checkout | Checkout started | items, value, currency | No |
| purchase | Order confirmed | transaction_id, value, currency, items | Yes |
contact_whatsapp and contact_phone aren't among Google's recommended events; they're our own names. When you use custom names, record the reason in the plan, so nobody spends a meeting two years from now debating contact_whatsapp versus whatsapp_click.
Key events: what used to be called conversions
In 2024 Google renamed conversions in GA4 to key events. A key event is one that matters to your business and that you want to follow separately in reports; you mark it on the Key events page under Admin. The word conversion now belongs to Google Ads: once you import a key event into Google Ads and bid on it, it becomes a conversion.
Don't make everything a key event. In a property with twelve of them, none stands out. Mark genuine business outcomes: purchases, qualified leads and, where relevant, sign-ups. Everything else still appears in reports as an ordinary event.
What does enhanced measurement do, and where does it mislead?
With enhanced measurement switched on for a web data stream, GA4 collects some events by itself: page views, scrolls near the bottom of the page (90 per cent depth), clicks to other domains, site search, YouTube video engagement, file downloads and form interactions. It's a decent start, but you need to know what the defaults miss.
- Scroll fires only at 90 per cent depth; other depths need their own trigger in Tag Manager.
- Site search is detected only when the URL carries a parameter such as q, s, search, query or keyword. If yours uses something else, add it in the settings.
- Video measurement works only for YouTube embeds with the JavaScript API enabled.
- Outbound clicks include WhatsApp links, which happens to be useful, but a dedicated event is cleaner.
- On single-page applications, page views depend on browser history changes; if that setting is off, a visitor can browse five pages while GA4 sees one.
Why can't you trust form interactions?
The form_start and form_submit events from enhanced measurement put every form on your site in the same bucket: search box, newsletter sign-up, login and quote form. A submission can also be counted when the form fails, for example with a required field left empty. Some forms work without reloading the page, never fire the browser's submit event and aren't counted at all. That's why we never make form_submit a key event. We measure real enquiries through the data layer instead, on successful submission only.
The Tag Manager container and the data layer
In Google Tag Manager, a container is a single snippet on your site, inside which tags, triggers and variables are managed. The basic GA4 structure is a Google tag that runs on every page, with your measurement ID starting with G-, plus a GA4 event tag for each important action. Make changes in a workspace, test with Preview, then publish with a descriptive version name. Version 47 tells nobody anything a year later; "Quote form generate_lead, form_name added" does.
Check who can access the container, and keep publishing rights to a few people. When you change agency, remove the old team's access; a container is a tool that can add any code it likes to your site.
Why is the data layer the sturdiest approach?
The data layer (dataLayer) is a shared space where your site tells Tag Manager that something has happened. The moment the form is saved successfully on the server, the developer sends an event such as generate_lead with dataLayer.push, along with details like form_name. In Tag Manager, a custom event trigger listens for that name and the GA4 tag fires only then. Redesign the page, change the button colour or label, and measurement keeps working.
Set-ups based on click classes, button text or the thank-you page URL also work, but they're fragile. When a designer changes the button from Send to Get a quote, tracking stops quietly, and you usually notice three months later.
The traps in form tracking
Tag Manager's form submission trigger has two settings. Wait for tags delays the submission briefly so tags can fire before the page changes. Check validation makes the trigger fire only when the form is actually sent; unticked, it fires on every attempt. Both help, but they don't solve every case.
- Forms that work without a page reload may never fire the browser's submit event; a data layer event is essential for those.
- Forms embedded in an iframe from a third-party service are invisible to the Tag Manager on your page; you need the service's own integration or a thank-you page redirect.
- With the thank-you page method, the event counts again whenever the page is refreshed or reopened from a bookmark.
- If enhanced measurement and Tag Manager both measure the same form, two different events appear and one can end up as a key event by mistake.
How should ecommerce events be set up?
GA4's ecommerce reports fill up when the recommended event names and the items array are sent correctly: view_item_list, select_item, view_item, add_to_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info, purchase, and refund for returns. In every event, items should carry the product ID or name, price and quantity. Send currency as an ISO code such as GBP or EUR.
transaction_id is required for purchase and does an important job: on web data streams, GA4 removes duplicate purchases from the same user with the same transaction ID. That protection has a trap. If transaction_id is sent as an empty string, GA4 can treat every purchase with an empty ID as a duplicate of the others. The reverse is also a problem: if different orders share the same ID, sales are undercounted.
On platforms like Shopify, much of this comes ready-made through Google's sales channel. Check anyway: is checkout completed on another domain, does the order confirmation page open after a 3D Secure redirect, are shipping and tax included in value? The answers explain the gap between revenue in GA4 and revenue in your accounts.
Traffic sources: UTMs, cross-domain tracking and internal traffic
GA4 learns where a visit came from largely through UTM parameters: utm_source, utm_medium, utm_campaign, utm_content, utm_term and utm_id. Values are case-sensitive, so utm_source=Instagram and utm_source=instagram become two separate rows. Google's own advice is to write every value in lower case.
- Keep a short dictionary of sources and mediums that everyone uses, for example instagram with paid_social, newsletter with email, linkedin with social.
- Choose medium values that GA4's default channel grouping recognises; an invented medium drops traffic into Unassigned.
- Never add UTMs to your own internal links; every click starts a new session with a false source.
- Keep auto-tagging on in Google Ads; campaign details arrive through gclid, so manual UTMs aren't needed.
Cross-domain tracking and payment pages
If your site and your checkout or booking pages sit on different domains, GA4 sees them as separate visits. The fix is under Admin, Data collection and modification, Data streams: choose the web stream, then Configure tag settings, then Configure your domains, and add both domains. GA4 then appends the _gl parameter when people move between them and recognises them as the same user. Both sides must use the same measurement ID.
A related problem: shoppers returning from a payment provider such as PayPal, Klarna or a bank's 3D Secure screen get their purchase credited to referral traffic. To prevent that, add the provider and bank verification domains to the list of unwanted referrals in the same tag settings.
Internal traffic
Your own team opening the site every day distorts the reports, particularly on smaller sites. Define internal traffic in the tag settings: when you enter your office IP addresses, GA4 adds traffic_type=internal to those visits. Then, in the data filters under Admin, try the internal traffic filter in testing state first and make it active afterwards. Data filters don't change historical data, and once a filter is active, excluded data can't be recovered.
Consent, Consent Mode v2 and data retention
Your cookie banner and your Google tag need to speak the same language. Consent Mode v2 carries four signals: ad_storage and analytics_storage govern cookie storage, ad_user_data governs whether user data can be sent to Google for advertising, and ad_personalization governs personalised ads. In a basic implementation, Google tags don't load until the visitor interacts with the banner. In an advanced one, tags load and send cookieless pings when consent is missing; in properties above certain data thresholds, GA4 uses those to model behaviour and conversions.
In Tag Manager, the tidy way is to run your consent management platform's template on the Consent Initialization - All Pages trigger, with the default consent state set to denied. Google's own tags have built-in consent checks. For other tags, such as the Meta pixel, switch on additional consent checks in the tag's consent settings under Advanced settings and select the relevant consent type, for instance ad_storage. For users in the EEA, the UK and Switzerland, Google already expects these signals, and PECR and the ePrivacy rules require consent for analytics and advertising cookies in the first place.
Data retention
Under Admin, Data settings, Data retention, standard properties have two options: 2 months or 14 months. The setting affects explorations and funnels, not the standard reports. So if 2 months is selected and you later want a user-level comparison with the same period last year, the data is gone. Choose 14 months on day one, and decide deliberately on the option to reset user data on new activity.
Google Ads, Search Console and BigQuery links
The Google Ads link is set up under Admin, Product links. Once linked, you can import key events into Google Ads as conversions and use GA4 audiences in campaigns. The common mistake is measuring the same form through an imported GA4 conversion and through the Google Ads tag, with both set as primary. One business outcome, one primary conversion.
The Search Console link brings organic queries and landing pages into GA4. A web data stream can be linked to one Search Console property only. After linking, the Search Console reports arrive unpublished in the Library; publish them from the Library section in the left-hand menu. Data appears about two days behind Search Console and covers at most 16 months.
BigQuery export sends GA4's raw event data to your own warehouse. Standard properties have a daily export limit of 1 million events, and a streaming export for intraday data is also available. Export starts on the day you link and doesn't backfill history, so set it up early, even before you need it. Bear in mind that storage and query costs can arise on the BigQuery side.
Debugging and server-side tagging
Before anything goes live, check each event in two places. Tag Manager's Preview mode (Tag Assistant) shows which trigger fired which tag, what's in the data layer and the consent state. GA4's DebugView lists, second by second, which parameters each event arrived with. One caveat: if the visitor has refused analytics cookies, events don't appear in DebugView. Test once in your own browser with consent given, then again with it refused.
With server-side tagging, the browser sends data not straight to Google or Meta but to a server container you control. The container runs on Google Cloud or another environment, and Google recommends serving it from a subdomain of your own domain. The payoff: you decide which data goes to which platform, less code runs in the browser, and server integrations such as Meta's Conversions API are fed from one place.
There's a cost. Hosting, maintenance and the technical know-how required can be a burden for smaller sites. Server-side tagging doesn't remove consent obligations either; data from a visitor who refused shouldn't be sent from the server. For most small and mid-sized businesses, the right order is to get the client side right first and move server-side as a second step.
Where to start
If you already have a GA4 property, we'd suggest this order:
- Write down the five questions the business wants answered and build a measurement plan that links each to an event.
- Cut the key events list down to real business outcomes, and take generic events like form_submit off it.
- Rebuild quote and contact forms to fire a data layer event on successful submission only.
- Set data retention to 14 months, activate the internal traffic filter and add payment providers to unwanted referrals.
- Test the cookie banner and Consent Mode in two browser sessions, once accepting and once refusing.
- Write the UTM dictionary and make sure the ads, email and social teams use the same values.
- Connect Google Ads, Search Console and BigQuery, and check that Google Ads isn't counting the same outcome twice as primary.
- Publish every change in Tag Manager with a descriptive version name and update the verification date in the plan.
At AYTE Digital we start measurement projects with a plan, build GA4 and Tag Manager around it and hand over only after every event has been tested. The property, the container and all the data stay in your accounts, and the set-up is documented so your team can read it later.
