How to Set Up GA4: Accounts, Tags and Measurement Checks
June 4, 2026
Author: Shusaku Yosa
To set up Google Analytics 4, create or select the right account and property, prepare a web data stream, install a tag, and verify the events arriving at the destination. Creating an account alone does not start measurement. If a website already has analytics, identify its existing owner and implementation before adding another tag.
Plan ownership, measurement goals and the existing implementation
Write down the business question first. A publisher may need to understand article visits; a service business may also need to distinguish a form start from an accepted enquiry. Those questions require different evidence. Record the production hostname, test environments, authentication steps and any move to an app or another domain. Decide who can edit the website, who can publish tags and who will check the results.
Use access that the organisation can maintain and hand over. Inspect existing GA4 properties, CMS integrations, directly installed tags and Tag Manager containers. A new employee or agency should not create a second implementation simply because they cannot immediately find the first one. Inventory the current setup and request the appropriate access.
Understand accounts, properties, streams, Google tags and GTM
An account is a management layer; a property contains measurement settings and reports. A property can receive data through web and app streams, so it is not necessarily identical to one website or page. See Google’s account structure guide for the relationship.
Element | Purpose | Illustrative identifier or distinction |
|---|---|---|
Account | Manage properties and access | Different from the Google Account used to sign in |
Property | Organise measurement and reporting | Numeric property ID, for example 123456789 |
Web data stream | Receive data from a website | Measurement ID, for example G-EXAMPLE01 |
Google tag | Send data to configured destinations | Tag ID, for example GT-EXAMPLE01 |
Google Tag Manager | Manage tags and triggers | Container ID, for example GTM-EXAMPLE |
All identifiers in the table are fictional. The numeric property ID, G- measurement ID and GTM container ID serve different purposes. A Google tag can have multiple IDs and destinations, so check its actual configuration rather than identifying the destination from a prefix alone.
Create or reuse the right account, property and web stream
- Sign in to Analytics and check whether the organisation already has a suitable account and property. Create only what is missing.
- Create a property within the appropriate account, choosing a meaningful name, reporting timezone and currency for the business.
- Read the account data-sharing options and choose them according to the organisation’s purposes and policies.
- Create a web stream for the correct website. Review enhanced measurement so you understand which interactions may be collected.
- Record the destination identifiers and choose an installation route.
Follow the official setup guide while working, because navigation labels can change. Account creation and tag installation are separate steps. An automatically recorded form interaction is also not proof that a submission was accepted by the business system.
Choose a CMS, direct-tag or Tag Manager installation route
Route | What you need | Duplication check |
|---|---|---|
CMS integration | Supported integration, site access and the intended property | Check whether the CMS already emits a tag |
Direct Google tag | Access to templates and the publishing process | Avoid installing in both a shared template and individual pages |
Tag Manager | Access to the correct installed web container | Inspect existing tags and additional containers first |
For GTM, the current Analytics setup instructions use a Google tag, its Tag ID and an Initialization trigger. They include previewing with Tag Assistant and publishing the version. Do not send beginners searching for an old GA4 Configuration tag name as the current creation workflow. An Initialization trigger does not obtain consent; the consent implementation and order of operations still need checking.
Validate destinations and events with debugging and Realtime
Use one test device and begin with one page view and one deliberate action. Inspect the tags and destinations in Tag Assistant, enable debug mode, then check the event and relevant parameters in DebugView. The DebugView documentation explains that privacy controls or consent state can affect what appears. An empty debug stream alone does not identify the cause.
Symptom | Check first | Evidence to retain |
|---|---|---|
Duplicate page views | CMS, direct-tag and GTM overlap; manual page-view sending | Actual actions, received events and fired tags |
Wrong destination | Property, stream and tag configuration | The identifiers on both sides |
No visible events | Publication, page coverage, consent state and debug mode | Environment, time and test conditions |
Journey breaks after login | Hostname, app or domain changes and measurement coverage | Departure, destination and success verification |
Use Realtime to confirm recent collection, then revisit standard reports after processing. Google’s freshness guidance allows for processing over 24–48 hours and changing report values; it is not a promise that every report is complete within 24 hours. Keep a test log so a delayed report is not confused with an action that was never sent.
Review retention, filters, consent and verified success conditions
Choose retention for the analysis you need. User-level and event-level retention is different from the treatment of standard aggregated reports; review the retention scope before assuming a longer setting restores deleted history. Test internal-traffic classification before activating an exclusion, because an active filter has a permanent effect on incoming data. The internal traffic guide describes the testing and active states.
The following fictional specification illustrates the difference between an interaction and a business result. The accepted-enquiry row requires implementation against a real success condition; it is not an automatic promise of GA4 setup.
Action | Example condition | Validation needed |
|---|---|---|
Page view | A production page is displayed and measurement received | Separate test traffic and duplicate sending |
Form start | A person begins interacting with the form | Do not treat it as acceptance or send field contents |
Accepted enquiry | The system confirms it has accepted the submission | Separate failures, retries and reloads; count one acceptance consistently |
Test undecided, accepted and denied consent states against the intended design. Consent mode communicates consent choices to tags; it does not itself obtain the choice or make the organisation’s applicability decisions. Check URLs, titles and event parameters against Analytics’ prohibition on sending personally identifiable information.
Finally, distinguish key-event occurrences from registered people. Verify success, duplicate handling, production hosts and authentication or cross-domain journeys before reporting a business outcome. If those conditions remain unverified, label the outcome unmeasured. The setup and documentation references in this guide were checked on 11 October 2026.
Related guides for the next step:


