Start with what the business needs to know
GA4 does not define what a lead is. Before creating events, describe the journey the company needs to understand: someone arrives, finds an offer, makes contact, receives a response, is qualified, and may progress to a proposal or sale. These stages may occur in different systems. The measurement plan should show which question each event helps to answer and who validates the step. For each topic, record the evidence and assign an owner before turning an observation into a decision; this reduces assumptions in the next review.
Without this map, any click can be given a business label and distort reports. A clicked WhatsApp button is an observable interaction; a conversation initiated depends on the destination; an opportunity requires business criteria. Document the differences before implementation. The tool can record events, but it does not automatically turn a technical action into a confirmed business outcome. When a topic changes, compare the recorded source and conditions with the observed outcome so the update does not rely on memory alone.
- Draw separate technical and operational steps.
- Record the question, event, and validation owner.
- Set criteria for contact and opportunity.
- State what GA4 cannot observe on its own.
Name what happened, not what you hope will happen
An event name should describe a reproducible action—for example, generate_lead only when the defined rule occurs, form_submit for a confirmed submission, or click_phone for a click on an identified phone link. Use the chosen convention consistently and let parameters provide context. Do not label a form opening or submission as a qualified lead when no one has reviewed the contact. For each topic, record the evidence and assign an owner before turning an observation into a decision; this reduces assumptions in the next review.
Parameters may record the form, page, service, or source when necessary, but they should not carry unnecessary personal data. Keep the taxonomy concise, with a description of the firing condition, value type, and deduplication rule. When an event's meaning changes, version or retire it instead of reusing the same name for incompatible definitions. When a topic changes, compare the recorded source and conditions with the observed outcome so the update does not rely on memory alone.
- Use stable, descriptive and documented names.
- Separate event, parameter and commercial criterion.
- Avoid sending free text or unnecessary personal data.
- Register changes, versions and deduplication rules.
Preserve source data without promising perfect attribution
UTMs and campaign identifiers help transport context, but do not rebuild every journey. Redirects, consent choices, browser blocking, multiple devices, and conversations started outside the website may interrupt the chain. Standardize source, medium, and campaign values; test whether they persist to the destination; and accept that some attribution will remain unknown. For each topic, record the evidence and assign an owner before turning an observation into a decision; this reduces assumptions in the next review.
Attribution should support a decision, not manufacture a convenient narrative. Compare GA4 reports with form records, conversations, and customer-service data, looking for discrepancies without forcing a match. If a system receives an imported conversion, identify the source of the log and the window used. An honest dashboard shows what is known, what is estimated, and what was not measured. When a topic changes, compare the recorded source and conditions with the observed outcome so the update does not rely on memory alone.
- Define a lowercase naming convention for UTMs.
- Test parameters in links, redirects and forms.
- Reconcile technical reports with customer-service and CRM records.
- Keep unknowns visible in the report.
Validate the implementation with a repeatable journey
The test should cover the complete journey in a controlled environment. Check consent, tag loading, firing condition, parameters, GA4 receipt, and destination registration. Test success, errors, browser returns, page refreshes, and duplicate submissions. Write down time and identifier to find the event without mixing it into real traffic. For each topic, record the evidence and assign an owner before turning an observation into a decision; this reduces assumptions in the next review.
After launch, repeat the check whenever the website, form, domain, consent banner, or campaign changes. Control access, record versions, and define who may change tags. Personal data should be processed according to purpose and appropriate basis; a technically correct implementation may still be inadequate if it collects more than necessary. When a topic changes, compare the recorded source and conditions with the observed outcome so the update does not rely on memory alone.
- Test success, errors, returns, and duplicate actions.
- Check firing conditions, parameters, the destination, and consent.
- Register evidence and implementation version.
- Revalidate after changes and restrict publishing permissions.
Reference sources
- Google Analytics — — accessed on 6 September 2026.
- Google Analytics — Recommended Events — accessed on 6 September 2026.
- ANPD — Information Security Guide for Small Agents — accessed on 6 September 2026.