Give the first month a few answerable questions
A new website has no broken tracking to repair. It has decisions that will soon need evidence: which services attract suitable enquiries, where visitors struggle to submit a form, and whether paid campaigns bring work the business wants. Start by writing those questions with the person who will use the answers. A launch measurement plan should make the first reporting conversation useful without attempting to record every interaction.
Consider a hypothetical consultancy launching three service pages and an enquiry form. Its first question is which service produces accepted enquiries. Its second is whether people who begin the form can finish it. Its third is which campaigns bring qualified leads. These are separate questions with separate evidence requirements. A page-view total can help describe demand, but it cannot answer all three.
Separate an action from a business outcome
Write the moments that matter in plain language before choosing event names. Someone sees a service page. Someone interacts with the form. The application accepts a submission. A person reviews the resulting enquiry and marks it qualified. A button click only establishes that a click happened; it does not establish that a message reached the business. Decide which system can reliably confirm each moment.
For the consultancy, the website can report a successful submission after its application accepts the request. The CRM owns the later qualification decision. Keep those stages distinct even if the first release only measures the website. Record the planned connection and its owner, so a dashboard never silently relabels all enquiries as qualified opportunities. That distinction also makes a future CRM integration easier to scope.
Choose an event vocabulary that will survive a redesign
Google's event documentation separates automatically collected, enhanced measurement, recommended and custom events. Inspect what the initial GA4 configuration already collects before adding equivalent custom tags. When a recommended event matches the intended action, use its documented name and parameters. Google's recommended list includes generate_lead for an enquiry and qualify_lead for a later qualification; these are not automatically implemented just because a property exists.
Keep the site's own specification independent of a particular button colour or CSS selector. Describe the business action, the trigger condition and the necessary context. If the design team changes a blue button to a text link, the meaning of an accepted enquiry should remain stable. A developer can then choose a reliable application signal instead of reconstructing business logic from whatever happens to be visible on screen.
Documentation: Google Analytics: set up events · Google Analytics: recommended events
Make each event a small agreement
A useful specification row includes the business question, event name, exact trigger, required parameters, source of each value, repeat behaviour, consent conditions and acceptance test. Add an owner and implementation status. For the example enquiry, form_id might identify the audit form, service_interest might use an agreed short list, and submission_reference might be an opaque reference if the destination permits it and the analysis needs it.
Define the awkward cases beside the normal one. An invalid form should not produce a success event. A server rejection should remain a failed attempt. Repeated clicks while a request is pending should not become several accepted enquiries. A refresh after confirmation should not invent another submission. Specify what to do when service_interest is unknown rather than letting different developers choose blank, null and other independently.
Limit the information that leaves the application
Choose context from an explicit allowlist. A service category may be useful; the visitor's free-text message usually is not needed to count accepted enquiries. Google's guidance on personally identifiable information covers accidental collection through page URLs, titles and user-entered fields. Review confirmation URLs and search terms as well as the obvious event parameters. A clean event payload is insufficient if a page address exposes the same information.
Include the site's agreed consent behaviour in the specification. For each destination, record the expected behaviour before a choice, after each available choice and after that choice changes. Assign someone to resolve requirements the implementation team cannot determine alone. Use this matrix when testing the banner and tracking together, including return visits. A screenshot of the banner by itself cannot show whether the corresponding measurement behaviour matches the agreed specification.
Documentation: Google Analytics: avoid sending personally identifiable information
Design the test evidence before implementation
Write a test case for every critical outcome. Each case needs starting conditions, actions, expected application behaviour and expected measurement behaviour. For the consultancy, cover a successful enquiry, invalid email, application error, double-click, confirmation reload and a return visit with an existing consent choice. Repeat the important routes on a phone as well as a desktop. Add embedded or external booking paths if the launch actually contains them.
Record the event name and relevant parameter values at the collection point and at the destination. Google's setup guide points to Realtime and DebugView for checking incoming events. Use those tools as one part of the evidence, alongside the application result. A visible analytics event cannot prove that the business received the enquiry, while a delivered enquiry cannot prove that its analytics context was correct.
Documentation: Google Analytics: set up events
Prepare one report and one source register
Before launch, sketch the report that answers the original questions. For accepted enquiries by service, show the count, service definition, date basis and unknown category. For form completion, state whether the denominator is users, sessions or distinct attempts. If the first release cannot connect enquiries to CRM qualification, label that missing stage plainly. A smaller report with clear boundaries is easier to trust than a complete-looking funnel assembled from incompatible totals.
Keep a source register with account and property identifiers, container ownership, reporting timezone, access owner and links to definitions. Store credentials separately through the team's normal access system. Record the application release and tag-container version used for acceptance. These details make it possible to investigate a later change without asking the original implementer to remember exactly what shipped.
Treat launch as the beginning of verification
Agree what must pass before measurement is released: the critical business events, required context, consent scenarios and absence of obvious duplicates or prohibited fields. Keep a rollback route for the tracking change. After launch, repeat a permitted controlled journey on the real domain and inspect the received data. A staging result does not confirm that production uses the same configuration, domains or integrations.
Schedule an initial reporting review once the chosen period is sufficiently complete. Compare observed events with the expected business process, inspect unknown values and resolve questions the first real data exposes. The handover is an event specification, test evidence, report definitions and named ownership. With those pieces in place, the next campaign or website feature extends a working measurement system instead of starting another collection of disconnected tags.