Analytics Implementation Checklist

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.
• 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.
• 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.
• 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.

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.
• 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.
• 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.
• 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.

Consent and privacy

• 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.
• 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.
• 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. GA4 will drop data it detects as PII, so this is a data-loss risk as well as a compliance one.

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.
• 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.
• 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.
• 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.
• 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.

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.
• 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.
• 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.
• Record which system answers which question before building an AI-search dashboard.

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