The first time I install analytics on a site, I resist the urge to paste the first snippet I see. Ten quiet minutes spent naming the property, checking consent, and deciding who owns the tag can prevent months of doubled page views and mystery traffic. This walkthrough builds that clean foundation with Google Analytics 4 (GA4).

What GA4 actually measures

GA4 receives events from a data stream. A page view is an event; so are a file download, form submission, purchase, or your own carefully designed interaction. Reports then calculate users, sessions, engagement, and attribution from those events. “Visitors” is useful everyday language, but it is not a perfect count of individual humans: identity settings, cookies, devices, consent, blockers, and modeling all affect the result.

  • Account: the administrative container for one organization or business boundary.

  • Property: the reporting and configuration boundary for related web/app data.

  • Web data stream: the website source inside a GA4 property.

  • Measurement ID: the stream/destination identifier beginning with G-.

  • Google tag: the deployed tag that loads collection logic and sends data to configured destinations.

  • Event: a named interaction plus parameters; GA4 reporting is event-based.

Before opening Analytics

  • Use an organization-controlled Google account with multi-factor authentication; add a second administrator for continuity.

  • Write down the production domains, subdomains, payment/booking domains, staging hosts, and single-page application routes.

  • Identify the privacy regions you serve and have the appropriate owner approve the consent and disclosure design.

  • Choose one deployment owner: CMS integration, direct source code, or Google Tag Manager (GTM).

  • List the business questions you need to answer. Do not collect events or parameters simply because you can.

  • Plan separate production and test data boundaries when developer/staging traffic would pollute decisions.

Create the account and GA4 property

  1. Sign in at analytics.google.com.

  2. Open Admin. Under the Account area, select Create → Account if this business does not already have the correct account.

  3. Choose the account’s data-sharing settings deliberately instead of accepting them as analytics requirements.

  4. Select Create → Property, give the property a recognizable business name, and set its reporting time zone and currency.

  5. Complete the business details and intended-use prompts, then accept the applicable terms and data-processing agreement.

  6. Record the property name, numeric property ID, owners, reporting time zone, and purpose in your analytics runbook.

Property boundaries deserve thought

  • A property can contain web and app streams that belong in one reporting view, but unrelated businesses usually need separate governance boundaries.

  • Reporting time-zone changes affect future processing and can produce apparent gaps or spikes around the change.

  • A web stream URL describes the source; it is not a security allowlist that prevents another host from sending the measurement ID.

  • Do not create a new property for every campaign or environment without considering fragmented history and administration.

  • If an existing property already represents the same product, confirm with its owners before creating a duplicate.

Add a Web data stream

  1. In Admin, select the intended property.

  2. Under Data collection and modification, open Data streams.

  3. Choose Add stream → Web.

  4. Enter the canonical production URL and a human-readable stream name.

  5. Review Enhanced measurement before creating the stream; enable only the interactions appropriate for the site.

  6. Create the stream and copy the Measurement ID beginning with G-.

Review Enhanced measurement rather than forgetting it

  • It can collect page views and selected interactions such as scrolls, outbound clicks, site search, video engagement, file downloads, and form interactions.

  • Available behaviors and settings can change, so inspect the stream’s gear/settings screen instead of assuming every event is enabled.

  • Automatic form or search detection may not match a custom application and can create noisy events.

  • For an SPA, history-based page measurement may work with the router but must be tested route by route.

  • Disable overlapping automatic measurement before adding an equivalent custom/GTM event.

Choose one installation path

  • CMS or website-builder integration: best when the platform offers a maintained GA4 field or official integration and your needs are straightforward.

  • Direct Google tag (gtag.js): transparent and version-controlled for teams that own every page template.

  • Google Tag Manager: useful when a governed container manages analytics, advertising, consent integration, and releases across the site.

  • Server-side tagging: an additional architecture, not a magic privacy switch; it still needs a web tag/client, consent, security, cost, and careful data governance.

Path A: use the CMS integration

  1. Open the platform’s analytics integration—not an arbitrary “header scripts” plugin if a maintained native option exists.

  2. Enter the exact G-... measurement ID or complete its account-authorization flow.

  3. Check whether the integration also inserts GTM, consent logic, advertising features, or logged-in-user exclusions.

  4. Save/publish, then purge application, page, and CDN caches.

  5. Inspect the public page while signed out; admin sessions often suppress analytics.

  6. Continue to the verification section rather than treating a successful Save message as proof.

On WordPress, an official or well-maintained integration such as Site Kit can own deployment. Avoid editing a parent theme’s header: the next theme update can erase the tag, and theme changes can silently stop collection. If a plugin or GTM already owns the tag, do not paste another copy into the theme.

Path B: add the Google tag directly

In the Web data stream, open View tag instructions → Install manually and copy the snippet generated for that stream. Place it immediately after the opening <head> on every measured page through the shared layout/template. The shape below is illustrative; use the exact code and ID shown in your property.

site layout / document headhtml
<!-- Google tag (gtag.js) -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());
  gtag('config', 'G-XXXXXXXXXX');
</script>

What each line is doing

  • The asynchronous loader fetches gtag.js without making HTML parsing wait for the download.

  • dataLayer is a queue; calls made before the library finishes loading can be processed later.

  • gtag() pushes its arguments into that queue. It is not the network request itself.

  • The js command records initialization time; config connects configuration and automatic measurement to the destination ID.

  • Replace the placeholder in both locations with the same generated ID. Never ship G-XXXXXXXXXX.

  • Put the shared snippet in one global layout, not separately in every manually maintained page.

A consent management platform is usually safer than hand-building a banner because timing, regional behavior, withdrawal, accessibility, and policy records are easy to get wrong. If your team maintains its own gtag.js integration, Google requires the default consent command before commands that send measurement. The values below are a conservative illustration, not a legal determination.

consent initialization (illustrative)html
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
 
  gtag('consent', 'default', {
    ad_storage: 'denied',
    ad_user_data: 'denied',
    ad_personalization: 'denied',
    analytics_storage: 'denied',
    wait_for_update: 500
  });
</script>

Ordering is part of correctness

  • Default consent runs before config or event commands so tags know the initial state.

  • The four storage/user-data/personalization signals cover analytics and advertising behavior; set each from the choices your interface actually offers.

  • wait_for_update gives an asynchronous consent tool a short window to respond; an excessive value delays measurement and does not replace correct orchestration.

  • Basic consent mode blocks Google tags before consent; advanced mode can load tags with denied defaults and send limited cookieless signals. Choose deliberately.

  • Consent mode does not store the visitor’s choice for your interface; your solution must persist it and apply it on later pages.

consent preference handler (illustrative)javascript
function applyAnalyticsChoice(allowed) {
  gtag('consent', 'update', {
    analytics_storage: allowed ? 'granted' : 'denied'
  });
}

The update must reflect a real choice

  • Call the update as soon as the person confirms or changes preferences, before navigating away.

  • A withdrawal uses the same update path with denied; also provide a persistent way to reopen preferences.

  • Advertising signals need their own values rather than inheriting analytics consent implicitly.

  • Do not wire “close banner” to granted consent.

  • With GTM, use its consent APIs or a vetted CMP template; Google warns that queued gtag commands are not a substitute inside custom GTM templates.

Path C: deploy with Google Tag Manager

  1. Create or select the organization’s controlled GTM account and Web container.

  2. Install the container code once in the exact head/body positions GTM provides.

  3. In the container, create a Google tag and enter the GA4 tag/measurement ID.

  4. Configure the consent platform and required consent checks before broad firing.

  5. Select the initialization/all-page triggers appropriate to the reviewed design.

  6. Use Preview to test pages, routes, consent states, and events.

  7. Name the version with a ticket/change summary, publish it, and record the owner and rollback point.

GTM is a release system

  • Workspace changes do not reach production until an authorized user publishes a container version.

  • Preview success proves the draft workspace, so retest the public published site afterward.

  • Limit Publish and Approve permissions; audit custom HTML and community templates as executable third-party code.

  • Use environments/workspaces and naming conventions to prevent teams overwriting one another.

  • Do not hard-code gtag.js alongside a GTM Google tag for the same destination unless an expert has designed and verified the interaction.

Verify collection from browser to report

  1. Open a private browser window with extensions disabled and make the consent choice being tested.

  2. Use Google Tag Assistant (and GTM Preview if applicable) to confirm the container/tag, destination, consent state, and event sequence.

  3. In DevTools → Network, filter for collect and inspect requests without copying identifiers into public tickets.

  4. Open GA4 Admin/Reports → Realtime and confirm your device, page location, and events appear.

  5. Use Admin → Data display → DebugView while Tag Assistant or debug mode is active to inspect the event timeline and parameters.

  6. Repeat after accepting, denying, and withdrawing consent; test mobile and desktop, templates, error pages, checkout, and SPA navigation.

  7. Allow standard reports more processing time; Realtime/DebugView are the installation checks.

deployment smoke check (safe)bash
curl -sS https://www.example.com/ | grep -o 'G-[A-Z0-9]{6,}' | sort -u

A source check is useful but incomplete

  • The command fetches public HTML, extracts likely measurement IDs, removes duplicates, and makes no server-side change.

  • Replace www.example.com with a domain you are authorized to test.

  • No output may be correct when a CMP or tag manager injects the destination at runtime.

  • One output does not prove an event was sent, accepted, or assigned to the intended property.

  • Multiple IDs can be legitimate multiple destinations—or an accidental duplicate. Confirm ownership in Tag Assistant.

  • Do not paste full collection URLs, client IDs, or user identifiers into public logs.

Single-page applications need route tests

An SPA changes content without a traditional document reload. Depending on router behavior and Enhanced measurement settings, browser-history changes may generate page views automatically. Some applications need an explicit event after navigation settles. Never add a manual event until the automatic path has been observed, because two plausible solutions together create two page views.

router analytics adapter (only if automatic measurement is disabled)javascript
function recordVirtualPage(path, title) {
  gtag('event', 'page_view', {
    page_location: new URL(path, window.location.origin).href,
    page_title: title
  });
}

Treat this as a router contract

  • Call only after a successful route transition and after the document title/canonical state is current.

  • The full page_location should represent the route users see; never include secrets or personal data in URLs.

  • Disable the overlapping history-based page-view mechanism before sending manual page views.

  • Test redirects, back/forward, query strings, fragments, 404 routes, modal routes, and hydration.

  • A page_view event can appear while attribution or session behavior is still wrong, so inspect acquisition and session boundaries too.

Design useful events without collecting everything

  • Prefer automatically collected and Enhanced measurement events when their semantics match.

  • Use Google’s recommended event names and parameters for supported business interactions before inventing custom names.

  • Create custom events only for a real decision or product question, with an owner and written schema.

  • Register custom dimensions/metrics only when reports need the parameter; registration does not retroactively populate old data.

  • Mark the small set of genuinely valuable outcomes as key events after validation.

  • Never send email addresses, phone numbers, names, free-form personal content, authentication tokens, or other prohibited personal data.

  • Define event cardinality, currency/value semantics, deduplication, and failure behavior before release.

Cross-domain journeys and internal traffic

  • Configure cross-domain measurement when one user journey moves across separately owned domains that should share measurement continuity, such as site → hosted checkout.

  • Ordinary subdomains often do not require cross-domain linking, but hostname reports and cookie/consent behavior still deserve testing.

  • Add every true journey domain through the Google tag settings and test the linker behavior; do not add third-party destinations casually.

  • Review unwanted referrals so payment providers do not start false new sessions, but never exclude a source merely to improve a report.

  • Define internal traffic using controlled IP rules only when appropriate; put the data filter in Testing first.

  • An Active exclusion permanently affects incoming reporting data, so validate the testing dimension before activation.

Privacy, security, and retention

  • Publish an accurate privacy/cookie disclosure that explains purposes, providers, choices, and contact/deletion routes.

  • Use least-privilege Analytics and GTM roles; review access and offboard people regularly.

  • Choose retention, Google Signals/advertising features, data sharing, granular location/device collection, and product links deliberately.

  • Avoid user-provided personal data in event names, parameters, user IDs, page titles, URLs, and search terms.

  • A custom user_id must be a non-PII internal identifier with an appropriate legal/consent basis; do not use an email address.

  • Use the relevant user-data and data-deletion controls for privacy requests; deleting a stream/property is not a substitute.

  • Review Content Security Policy requirements from current Google documentation and your deployed products; do not weaken CSP with broad wildcards or unsafe-inline casually.

  • Keep a change log covering property, streams, tag versions, consent behavior, events, filters, links, and responsible owners.

Performance without losing control

  • Load one Google tag asynchronously and avoid duplicate containers/loaders.

  • Put consent logic early enough to establish state without a visually unstable or blocking banner.

  • Audit third-party GTM tags; the container is small compared with uncontrolled scripts it can launch.

  • Use performance monitoring to measure main-thread work, network cost, and interaction impact on real devices.

  • Do not delay analytics in a way that contradicts the selected consent implementation or loses essential navigation events.

  • Analytics does not improve search rankings by being installed; it helps teams evaluate behavior and outcomes.

When the Realtime report stays empty

  • Wrong property/measurement ID: compare the deployed G-... value with the selected web stream.

  • Tag never loads: inspect template coverage, cache/CDN output, CSP errors, consent blocking, JavaScript errors, and GTM publication state.

  • Request is blocked: test without privacy/ad-blocking extensions, then treat normal blocker loss as a measurement limitation.

  • Consent remains denied: inspect the default and update sequence in Tag Assistant; do not force granted to make a test pass.

  • Duplicate events: search CMS plugins, source templates, GTM, embedded widgets, and multiple Google tag destinations.

  • Only some pages work: compare their layouts, rendering mode, consent component, CSP, and route transitions.

  • DebugView is empty: enable debug mode through Tag Assistant/Preview and confirm you are viewing the correct property.

  • Internal traffic disappears: inspect test/active data filters and IP definitions.

  • Reports disagree: align date range, property time zone, identity/reporting settings, filters, thresholding/modeling, attribution, and metric definitions.

A small launch checklist

  • Correct account, property, reporting time zone, currency, and production stream.

  • One documented deployment owner and one intentional destination flow.

  • Consent banner/CMP tested for accept, reject, granular choice, revisit, and withdrawal.

  • Page views verified without duplicates on reload and SPA navigation.

  • Recommended/custom events validated with names, parameters, values, and no personal data.

  • Realtime, DebugView, Tag Assistant, and browser network checks agree.

  • Cross-domain, unwanted referrals, internal traffic, and filters tested where applicable.

  • Access, retention, product links, data sharing, privacy disclosure, and runbook reviewed.

  • Production retested after publish and caches/CDN refresh.

  • A named owner and monitoring date exist for the first week and future releases.

A healthier first report

Once the implementation is quiet and trustworthy, resist turning the dashboard into a scoreboard. Start with a question: Did people reach the useful page? Did the form work? Which acquisition source brought engaged sessions rather than accidental clicks? Analytics becomes valuable when event definitions connect to decisions—and when the team is honest about the data it cannot see.

Continue with the site measurement setup

Primary references