50 Google Analytics 4 setup tips: From events to decisions

01Start with a measurement plan

Already collecting GA4 data and wondering whether you can rely on it? Use this list as a recurring setup audit, covering definitions, campaigns, data quality and decision-focused reports. Record the status, evidence and owner for each check. Sources were checked on 11 October 2026.

1. List three decisions. Decide what the data should change: campaign spending, page content or checkout flow. Give each decision an owner who can actually act on the result.

2. Define success precisely. An enquiry means an accepted submission, not an opened form. Specify the completion point so developers and sales staff count the same action and can reconcile it.

3. Separate outcomes from clues. A purchase or qualified enquiry matters differently from scrolling or downloading a brochure. Use supporting events to diagnose the journey rather than automatically treating them as commercial results.

4. Keep a measurement dictionary. Document each event name, trigger, parameters and owner. Store the dictionary with the website brief so a future supplier can interpret the reports without reverse engineering them.

5. Choose a reference system. Use the order system to establish how many purchases were paid. GA4 helps analyse behaviour and acquisition; it should not replace accounting or the complete customer record.

02Establish ownership and settings

6. Keep company ownership. Use company accounts and appoint a backup administrator. Give an agency its own access rather than sharing credentials that are difficult to withdraw when the working relationship changes.

7. Limit permissions to the job. Someone reading reports rarely needs to change collection settings. Review access regularly and remove former staff, previous contractors and accounts with no identifiable owner.

8. Plan the property structure. Decide which websites and apps belong to the same business journey. A different website language alone is not a reason to split reporting into another property.

9. Check the reporting time zone. Align it with business reporting and document differences from advertising accounts. An order close to midnight can otherwise appear under different dates in different systems.

10. Set currencies deliberately. Check both the property currency and the currency sent with purchases. For multiple markets, agree which reporting currency will be used to compare sales and costs.

03Check tags and consent

Google documents basic and advanced Consent Mode. The mechanism communicates choices to tags; it does not supply a consent banner or legal assessment.

11. Audit every tag installation. Check source code, the tag manager and ecommerce plugins. Independent installations can send the same event twice, so inspect the existing setup before adding another analytics plugin.

12. Test every page template. Check the homepage, product detail, enquiry form and order confirmation. A successful homepage test does not establish that measurement works throughout the customer’s journey.

13. Test refusal as well as acceptance. Start a fresh session, reject optional purposes and inspect tag behaviour. A dismissed banner is insufficient evidence; check consent state and actual network requests.

14. Distinguish basic and advanced Consent Mode. Advanced mode can send cookieless signals after refusal. Match the implementation to your assessed consent approach rather than selecting a mode solely because an advertising tool recommends it.

15. Test a changed choice. Grant consent and withdraw it later. Check that the relevant states update on subsequent pages too; testing only the first visit will miss this class of problem.

04Design events around real actions

Use the recommended event reference and Google’s key event definition. Distinguish GA4 key events from Google Ads conversions.

16. Prefer recommended event names. Use recommended events such as purchase or generate_lead when they describe the action. Introduce a custom name when a standard event does not fit the actual behaviour.

17. Measure accepted submissions. Trigger an enquiry event after a successful submission, not on a button click. Test invalid fields, server errors and rapid double clicks as separate cases.

18. Review enhanced measurement. Check which automatically collected interactions are useful. For custom forms and video players, verify the actual behaviour instead of assuming automatic measurement recognises a meaningful completion.

19. Check virtual page views. In an application that changes routes without reloading, measurement must follow actual navigation. Test back and forward controls and check that page_view is not duplicated.

20. Choose key events selectively. Mark actions that represent business success. If every interaction becomes a key event, the total becomes difficult to interpret and less useful for prioritising improvements.

05Keep parameters useful and private

Review Google’s documentation on custom dimensions and preventing personal information from entering Analytics.

21. Add parameters with a purpose. Service type may help analyse enquiries; placement may explain button use. Each parameter should answer a question. Do not collect an entire form just in case.

22. Register useful custom dimensions. Sending a custom parameter does not automatically make it a custom reporting dimension. Plan the registration and verify availability before signing off the measurement setup.

23. Avoid unnecessary unique values. Use meaningful categories instead of a different free-text value for every action. Excessively granular dimensions complicate reports; order identifiers belong in the relevant transaction fields and operational records.

24. Remove personal data from URLs. Check for email addresses, telephone numbers and user-entered search text. Personal data can enter measurement through a page address even when you never send it as a custom parameter.

25. Do not use email as User-ID. If signed-in journeys need linking, design an opaque internal identifier and handle sign-out correctly. Introduce it only for a defined purpose with appropriate privacy assessment.

06Connect visits to campaigns

Consult the traffic acquisition report documentation for session reporting. Align dimension scope before comparing figures.

26. Agree a UTM naming scheme. Set consistent source, medium and campaign values. Check newsletter links before sending so one marketing channel does not become several different rows because of inconsistent naming.

27. Keep UTM tags off internal links. Measure navigation within your website with events or placement parameters. Reserve campaign tagging for incoming traffic so acquisition labels do not become mixed with internal promotion.

28. Link the correct advertising account. Before connecting GA4 and Google Ads, verify account identifiers and permissions. Record who maintains the link and which events are used to create advertising conversions.

29. Test campaign redirects. Open a real tagged link and follow every redirect. Check that relevant parameters survive URL shorteners, language selection and the move to the final destination page.

30. Separate user and session acquisition. A user’s first source answers a different question from the source of the current session. Label the report’s scope so differences are not mistaken for broken tracking.

07Measure purchases and enquiries

Follow Google’s checks for ecommerce validation and cross-domain measurement.

31. Validate purchase items. Check currency, product identifiers, quantities and item details as well as the order value. Test discounts and multiple quantities; a simple single-item purchase may hide calculation mistakes.

32. Use a unique transaction_id. Send a stable identifier for each actual order. Reopening its confirmation must retain that identifier, while a different order must never reuse it.

33. Include refunds in the plan. Agree how returned orders enter the analysis. Comparing campaigns solely on initial purchases can hide differences between booked sales and revenue the business actually retains.

34. Check cross-domain journeys. If your checkout runs on another domain, verify cross-domain measurement. Test both directions and linker preservation; entering a domain in the settings is not a complete test.

35. Check payment-provider referrals. See whether a payment service is incorrectly credited with acquiring customers. Add unwanted-referral rules for a verified journey rather than excluding every external domain indiscriminately.

08Improve data quality carefully

Distinguish report filters from internal traffic data filters. Use DebugView to inspect collection.

36. Separate development traffic. A development site should not freely populate production reports. Choose a separate property or a controlled testing approach and document it in the team’s development procedure.

37. Test data filters before activation. Excluding internal traffic permanently affects newly collected data. Confirm the scope and consequences before activating a rule, especially where shared networks or VPNs are involved.

38. Use DebugView for a defined scenario. Follow your test device through the event sequence and inspect parameters. An event name appearing is not proof that its value or contextual information is correct.

39. Allow reports to process. Use Realtime and DebugView to check immediate collection. Assess regular reporting after processing; reinstalling tags in response to a short delay can create a second problem.

40. Reconcile comparable periods. Use matching dates, time zones and order definitions. Investigate differences such as consent coverage or cancellations rather than assuming analytics and operational systems must agree exactly.

09Build reports around questions

41. Start with one focused report. Combine visits, the main outcome and its value by channel. Resist adding every available metric: the team should know which decision the report supports.

42. Inspect landing pages. When a channel performs poorly, check where its visitors arrive. One campaign may send people to very different pages, making an overall average conceal a fixable problem.

43. Compare mobile and desktop. Look at both outcomes and journey stages. A large gap suggests checking forms, speed or the offer; the report alone does not establish which factor caused it.

44. Build a simple funnel. Choose verified stages such as product view, basket and purchase. Before diagnosing customer drop-off, ensure every stage is measured across the relevant website variants.

45. Read data-quality indicators. Check for thresholding, sampling or other reporting limitations before interpreting a chart. Avoid presenting a small observed group as an exact description of the entire customer base.

10Maintain measurement after launch

Check the data retention documentation. Make ownership of website measurement part of routine operational responsibility.

46. Choose a justified retention period. Decide how much history explorations require and compare that need with company policy. Longer retention is not automatically better and does not affect every report in the same way.

47. Plan exports around a real use. Consider BigQuery for custom analysis or combining datasets. Before enabling it, assign an owner, access rules, a budget and a question standard reports cannot answer.

48. Maintain a change log. Record measurement, campaign and website changes with deployment dates. When a chart jumps, this helps distinguish altered customer behaviour from a change in how activity was counted.

49. Include measurement in releases. Retest key scenarios after changing checkout, forms or the consent banner. Record the outcome, test order and observed events so verification has a traceable result.

50. Finish every report with an action. State the finding, proposed change, owner and review date. If reports consistently produce no decisions, change the question or presentation rather than adding more charts.

11Frequently asked questions

Want to apply this checklist to your project? Tell us what you measure, which systems you use and where you lose visibility.