Analytics Implementation Checklist (GA4 & GTM)

An analytics implementation checklist is a pre-launch control list for measurement planning, event design, consent behavior, QA, and ownership. It prevents teams from shipping tags before the business questions, data definitions, and reporting responsibilities are clear. The tool-side mechanics — limits, naming formats, debugging — live in the companion GA4 and GTM notes; this list is about what to decide, what to verify, and who signs off.

Before any tag ships

Write a measurement plan that maps business questions to specific events, parameters, and KPIs. Start from the question someone will actually ask, then work backwards to what must be collected. Anything that does not trace back to a question is data you will pay to maintain and never use.
How to verify: Pick five events from the plan and trace each one to a business question and to the report that answers it.
Pass when: Every planned event names the question it serves, its parameters, and the KPI it feeds, and no event in the plan is orphaned.
Agree on the primary conversions and how each is defined. Write the definition down, including the edge cases: does a refund reverse it, does a repeat submission count twice, does an internal user count at all. Most reporting disputes are definition disputes wearing a technical costume.
How to verify: Ask the stakeholders to answer the edge cases in writing: refunds, repeat submissions, internal users.
Pass when: Each primary conversion has a short written definition covering those cases, approved by its business owner.
Document a naming convention for events and parameters. Decide the casing, the separator, and the verb form once, write the convention where implementers will find it, and name who approves any new event name before it ships. The format mechanics — case sensitivity, character limits, a worked convention table — are in the GA4 and GTM notes.
How to verify: Look for the convention where implementers actually work: the container notes or the code repository.
Pass when: It states casing, separator, and verb form, and names the person who approves new event names.
Confirm who owns the implementation after launch. Name a person, not a team. An implementation with no owner degrades from the first site release onward, because nobody is accountable for checking whether a deploy broke tracking.
How to verify: Ask who is told when a release breaks tracking.
Pass when: One named person, with a backup, has accepted the role in writing.

Tracking design

Define the data layer structure and the values each page exposes. The data layer is the contract between the site and the tags, so treat it like one: written down, versioned, and reviewed by the developer who owns the page templates before each release. The push pattern itself is annotated in the GA4 and GTM notes.
How to verify: Inspect window.dataLayer on one page per template and compare it with the specification.
Pass when: Every key in the specification is present with its documented type, and the specification carries a version number.
Standardize event names across web and app where both exist. Divergent names make cross-platform reporting a manual reconciliation job forever. Agree the shared vocabulary before either platform ships, because renaming events after collection does not fix historical data.
How to verify: Export the event names from the web and app data streams and compare the lists.
Pass when: Shared actions use identical event and parameter names on both platforms.
Decide client-side versus server-side collection per event. Server-side collection survives ad blockers and browser restrictions and keeps credentials off the client, at the cost of infrastructure and the loss of some client context. Choose per event rather than adopting one model for everything.
How to verify: Read the collection column of the measurement plan.
Pass when: Each event says client-side or server-side, with the reason.
Map ecommerce or lead events to the platform schema. Decide in the measurement plan which events must use the platform's reserved names and shapes, and record that decision where implementers will see it — a custom name where a reserved one exists means building every report by hand.
How to verify: Compare the implemented ecommerce or lead events with the platform’s recommended-event reference.
Pass when: Every event that has a reserved name uses it, with the parameters the reference requires.

Integrate a consent management platform before deploying tags. Retrofitting consent onto live tags means a period of collection you may not be able to justify. The CMP is a prerequisite for the tags, not a later phase. The same consent record has to be readable per channel by every automated program downstream; the marketing automation planning template records which system owns it and which ones only read it.
How to verify: In a clean browser, load the site without making a consent choice and watch the network tab.
Pass when: The consent platform loads first, and no tag fires beyond what the default consent state allows.
Verify tags respect consent state and regional rules. Make the denied path and each regional default an explicit line item in the QA plan, with a named verifier, rather than an assumption. The mid-session change-of-mind test belongs on that list too; the procedure for running it is in the GA4 and GTM notes.
How to verify: Run the denied, granted, and mid-session change tests under each regional default.
Pass when: Each test has a named verifier and a recorded result, and tags follow the consent state in every case.
Confirm any PII handling and IP/identifier policies. Email addresses and names leak into analytics most often through URL query parameters on form submissions — check those specifically. Google’s policies forbid sending PII to GA4 at all. New properties redact email-like strings from web streams by default, but only on a best-effort basis, and URL query parameters are redacted only if you list them — so strip PII before it is sent rather than relying on either.
How to verify: Submit every form with test details, then search the collected page URLs and parameter values for “@” and for those details.
Pass when: No email address, name, or phone number appears in any collected value.

Quality assurance

Test events in preview and debug views before publishing. Preview catches configuration errors early, but it is not sufficient on its own: it bypasses consent and content security policy, so a tag that works in preview can still fail in production.
How to verify: Trigger each event in Tag Manager Preview, then confirm it in GA4 DebugView.
Pass when: Every planned event arrives in DebugView exactly once, with its parameters.
Validate parameter values, not just event firing. A green checkmark means the event fired, not that it carried the right values — make value checks part of the recorded sign-off evidence rather than a spot check. The specific failure values worth hunting for are listed in the GA4 and GTM notes.
How to verify: Inspect each parameter value in DebugView or in the outgoing network request.
Pass when: Values match their documented type and format: no empty strings, no “undefined”, no numbers sent as text.
Check cross-browser and mobile behavior. Safari's storage restrictions shorten cookie lifetimes considerably, which inflates returning visitors as new. Test on real iOS Safari rather than a desktop emulation of it. Which Safari protections touch which tags, and how to check them in Web Inspector, is in what Safari 27 does to marketing tags.
How to verify: Repeat the key journeys on a real iPhone in Safari, on Android in Chrome, and in one desktop browser.
Pass when: The same events fire with the same values in each.
Confirm conversions reconcile with the source system. Analytics conversions will run below the source system because of blockers and consent; the point is to know the size of the gap and that it is stable. A gap that changes suddenly is the alarm worth building.
How to verify: Compare a full day of conversions in analytics with the source system, and repeat a week later.
Pass when: Analytics is lower by a stable margin, and that margin is recorded as the baseline for alerts.
Record who signed off, and on what evidence, before the container publishes. Attach the debug screenshots and the container version number to the release ticket. When tracking breaks later, the first question is what was verified last time — make it answerable.
How to verify: Open the release ticket for the container version being published.
Pass when: It holds the version number, the debug evidence, and the name and date of the sign-off.

After launch

Document the container, events, and ownership. Write down what each tag is for and who asked for it. Undocumented containers accumulate tags nobody will delete later, because nobody can prove they are unused.
How to verify: Pick three tags at random and ask what each one is for.
Pass when: For every tag, the purpose, the requester, and the owner are written down.
Set a review cadence for new events and deprecations. Without one, event count grows and custom-dimension slots run out — the exact caps are tabulated in the GA4 and GTM notes, and reclaiming a slot does not retroactively repair the data collected under it.
How to verify: Look for the next review in the calendar, and for the output of the last one.
Pass when: A recurring review has an owner, and the last one produced a list of events kept, changed, and retired.
Monitor for data loss after site or consent changes. Alert on volume anomalies per key event rather than checking manually. Tracking usually breaks during an unrelated release, and the gap is discovered weeks later when someone opens a report.
How to verify: Open the alert configuration for the key events.
Pass when: A drop in any key event’s daily volume beyond the agreed threshold notifies a named person automatically.
Know what GA4’s AI Assistant channel counts before you report it. The default channel group sorts referrals from a Google-maintained list of assistants into AI Assistant, but Google’s own AI Overviews and AI Mode stay in Organic Search, and an assistant that sends no referrer arrives as Direct. A slide labelled “AI traffic” built from that one channel understates the thing it names.
How to verify: In GA4, open the channel group definitions and read the AI Assistant rule, then list a week of session sources that look like AI products.
Pass when: Every AI source you found is either in the channel or documented as outside it, and any report called “AI traffic” says that Google’s AI surfaces are counted in Organic Search.
Record which system answers which question before building an AI-search dashboard.
How to verify: Read the definitions attached to the AI-search dashboard.
Pass when: Each figure names its source system and what that system cannot see.

QA evidence: what proves each item passed

Each “How to verify” step above leaves something behind. This table names that artifact, where it is kept, and who signs it off: a role here, a named person on the ticket. Keep the evidence on the release ticket of the container version it verifies, or link it from there, so “what was verified last time” has one answer. Whoever built a change should not be the one who signs its QA.

Item	Evidence	Where it is kept	Signed off by
Measurement plan	A dated export of the plan with the five traced events marked, each showing its business question, KPI, and the report that answers it.	The measurement plan’s version history	Analytics lead
Primary conversions	The written definition of each primary conversion, covering refunds, repeat submissions, and internal users, with its business owner’s dated approval.	The definitions section of the measurement plan	The business owner of each conversion, usually the marketing owner
Naming convention, Owner after launch	A link to the convention where implementers work, naming its approver; the owner’s and the backup’s written acceptance of the role.	Container notes or the code repository; the acceptance on the release ticket	Analytics lead for the convention; the owner and backup accept in their own names
Data layer	A console capture of `window.dataLayer` on one page per template, next to the specification version it was compared with.	Release ticket	The developer who owns the page templates
Web and app names	The event-name exports from both data streams, with every difference marked and either fixed or explained.	Release ticket	Analytics lead and the app developer
Collection method, Reserved names	The plan’s collection column, with a reason on every row, and a side-by-side of the implemented events against the platform’s recommended-event reference.	Measurement plan	Analytics lead
Consent platform first	A network capture (HAR export or screenshot) from a clean browser before any consent choice: the consent platform loads first, and no tag request goes beyond the default state.	Release ticket	Developer
Consent states	The consent test log: one line per regional default and state (denied, granted, changed mid-session), each with its verifier, date, result, and capture.	QA test log, linked from the release ticket	The named verifier runs it; privacy or legal signs it
Personal data	The test details used on each form, and the search of collected page URLs and parameter values for “@” and for those details, showing no match.	Release ticket. The details are invented, so the capture holds no real personal data	Privacy or legal
Preview and DebugView, Parameter values	Per event: a Tag Manager Preview screenshot showing the tag fired once, and a DebugView screenshot with the parameters expanded so the values can be read.	Release ticket	Analytics lead, not the implementer
Browsers and mobile	DebugView captures of the key journeys from a real iPhone in Safari, Android in Chrome, and one desktop browser, each labelled with its device and browser.	Release ticket	Analytics lead
Reconciliation	Two dated comparisons a week apart: the analytics count, the source-system export count, and the gap. The stable gap is recorded as the alert baseline.	The baseline section of the measurement plan	Analytics lead with the source-system owner (CRM or ecommerce)
Sign-off	The release ticket itself: the container version number, links to the evidence in this table, and the signer’s name and date.	Release ticket, referenced in the container version notes	Implementation owner
Container documentation, Review cadence	A tag inventory giving purpose, requester, and owner for every tag; the next review in the calendar and the last review’s list of events kept, changed, and retired.	Container notes or the inventory sheet; the review notes	Implementation owner
Data-loss alerts	A screenshot of each alert rule showing the key event, the threshold, and the person it notifies.	The tracking runbook, or the release ticket that set the alerts up	Implementation owner
AI Assistant channel, System per question	The week’s list of AI-looking session sources, each marked inside or outside the channel, and the dashboard definitions naming each figure’s source system and what it cannot see.	The definitions attached to the dashboard	Analytics lead

Worked example: a demo-request form

One row of a measurement plan, filled in for a B2B site’s demo-request form, followed by the test cases that prove it works. The row is shown transposed: each column of the plan is a line here. Names follow the convention table in the GA4 and GTM notes.

Measurement-plan row

Plan column	Example
Business question	Which channels and landing pages bring demo requests, and is that changing week to week?
KPI	Demo requests per week, by session source / medium and by landing page.
Event name	`generate_lead`, the platform’s recommended lead event rather than a custom name, marked as a key event.
Parameters	`form_id` (text, `demo_request`) and `form_location` (text, the page template, such as `pricing`). Both are registered as event-scoped custom dimensions: two of the 50 slots on a standard property. No name, email, or company: those stay in the CRM. No `value`: what a lead is worth is decided in the CRM, not on the page.
Trigger	The site pushes `generate_lead` to the data layer once the server confirms the submission, never on the button click. In Tag Manager: the trigger `CE — generate_lead` fires the tag `GA4 event — generate_lead`, which reads `DLV — form_id` and `DLV — form_location`.
Collection	Client-side. The question needs session source and landing page, which only the browser has. The CRM records the same lead server-side on its own, and that record is what reconciliation compares against.
Conversion definition	One per confirmed submission. A submission the form rejects (validation or spam check) never pushes the event. Internal traffic is excluded by the property’s internal-traffic filter. Whether the lead is qualified is decided in the CRM, not in analytics.
Consent category	Analytics (`analytics_storage`). With consent denied, nothing is sent beyond what the default consent state allows.
Report or destination	GA4: the key event in the Traffic acquisition report, plus an exploration by landing page. The weekly demand-generation dashboard reads from both.
Source of truth	CRM leads created by the demo-request form. Analytics runs lower by a stable margin, recorded as the alert baseline.
Owner	Definition: the demand-generation manager. Implementation: the marketing operations lead, with the web developer as backup. Named people in a real plan.

QA test cases for `generate_lead`

Run these before the container version publishes. The filled table, with the capture each case produced, is the evidence for the Preview, parameter-value, personal-data, consent, and mobile rows above.

ID	Steps	Expected result	Tool	Pass / fail
TC-01	In Tag Manager Preview, open the pricing page and submit the demo form with valid test details.	`GA4 event — generate_lead` fires once, on the `generate_lead` custom event after confirmation, not on the button click.	Tag Manager Preview	☐ Pass ☐ Fail
TC-02	In the same session, open DebugView and select the event.	`generate_lead` arrives exactly once, with `form_id` = `demo_request` and `form_location` = `pricing`: no empty string, no “undefined”.	GA4 DebugView	☐ Pass ☐ Fail
TC-03	Submit with a required field left empty, then correct it and submit again.	No `generate_lead` for the rejected attempt; exactly one for the accepted one.	Tag Manager Preview, `window.dataLayer` in the console	☐ Pass ☐ Fail
TC-04	Submit with an invented name and email address, then search the outgoing requests and the collected page URL for “@” and for those details.	None of the test details appears in any URL or parameter value.	Browser network tab	☐ Pass ☐ Fail
TC-05	In a clean browser, refuse analytics consent and submit. Then accept through the banner without reloading and submit again.	Refused: nothing beyond what the default consent state allows, and no analytics cookie set. Accepted: the second submission sends `generate_lead` under the updated state.	Browser network tab and storage panel	☐ Pass ☐ Fail
TC-06	Repeat TC-01 and TC-02 on a real iPhone in Safari and on Android in Chrome.	The same event, with the same parameter values, on both devices.	Real devices, GA4 DebugView	☐ Pass ☐ Fail

For the failure patterns this checklist is designed to prevent, read the related article below.

Sources

Factual claims on this page were checked against these primary sources on October 10, 2026:

Google Analytics Help — Best practices to avoid sending PII — supports the policy against sending personally identifiable information.
Google Analytics Help — [GA4] Data redaction — supports email redaction on by default and query-parameter redaction by configuration.
WebKit — Tracking Prevention in WebKit — supports the expiry caps on cookies set by script in Safari.