What Is Tracking? Measurement Design, Cookies and Consent Explained
Published:
Last Updated:
Category: Privacy & Measurement Infrastructure
Authors: Shusaku Yosa
Tracking records activity or state on a website or app. Page views, link clicks and form interactions can help answer an improvement question, but the useful data depends on the decision you want to make. Start with that purpose before choosing tags or collecting extra fields.
An event count, a verified registration and the incremental effect of advertising are different measures. This guide focuses on collection design, with practical examples for defining success, checking duplicates and testing consent behaviour.
What tracking records and why
Viewing a guide, pressing an application button and having a submission accepted are separate events. Define the page and condition that should trigger each record. Giving an event a “conversion” label does not establish that the intended business outcome occurred.
For a question about form usability, useful observations might include the first interaction, an error and an accepted submission. You do not need the visitor’s name or free-text message in an analytics service to answer that question. Choose the minimum information necessary.
Tags, cookies, campaign parameters and server logs
These components play different roles. A tag manager controls tags and triggers; it is not interchangeable with an individual measurement tag or pixel.
Component | Main role | Do not assume |
|---|---|---|
Tag or pixel | Send data about a view or action | Firing proves a business success |
Tag manager | Manage tags and their conditions | It performs every analysis itself |
Cookie or identifier | Connect activity or state under defined conditions | One identifier always equals one real person |
UTM parameters | Classify campaign sources and related details | They are personal identity numbers |
Server logs and business records | Record requests or accepted processing | They directly establish reading or every browser action |
Google describes tags and destinations in its Google tag announcement. Whatever the collection method, review purpose, fields and permitted use. Do not present fingerprinting as a workaround for a person’s rejection or a browser’s privacy restrictions.
A campaign-parameter example for email
A fictional URL could be /guide?utm_source=newsletter&utm_medium=email&utm_campaign=autumn_guide. Keep source, medium and campaign naming consistent. Do not put an email address or authentication token in these values. Design internal navigation measurement separately rather than adding campaign parameters that confuse acquisition classification.
Email opens, clicks, site arrivals and accepted submissions are different observations. For email construction and rendering checks, see how to build and test an HTML email.
Design the measurement before implementing tags
A specification helps people agree what an event means. Include success conditions, deduplication and denominators, not just an event name.
Specification field | Fictional consultation-form example |
|---|---|
Decision | Find problems between form start and acceptance |
Event and trigger | form_start at the first interaction; submission_accepted after acceptance is confirmed |
Success condition | Server acceptance, not merely a button click |
Denominator | A fixed definition such as sessions containing a form start |
Required parameters | Only necessary details such as form type and page |
Excluded information | Name, email, free text and authentication details |
Consent and transitions | Expected behaviour before choice, after choice and across authentication or domains |
Duplicates and owner | Reload/retry rules, responsible person and validation date |
Retention and use | Approved purpose, period and access arrangements |
The event names are examples, not a claim about an existing product implementation. Check URLs, titles, input fields and campaign parameters for unintended personal information. Google’s PII guidance explains these collection risks.
Separate events, verified outcomes and attribution
Consider a fictional journey with two button clicks, two form starts, one successful submission display and one reload of that display. Counting the success page without deduplication produces two events. It does not establish two registrations or two people.
Observation | Count | Interpretation |
|---|---|---|
Button click | 2 | Recorded actions, not accepted submissions |
Form start | 2 | Starts, not necessarily different people |
Success-page display | 2 | May include a reload |
Deduplicated success | Unverified | Requires a success definition and deduplication check |
Registered people | Unmeasured | Requires appropriate validation against business records |
Attributing a result to an ad is also different from showing that the ad caused a result that would not otherwise have occurred. Google’s Conversion Lift explanation separates standard attributed conversions from incremental outcomes measured with a comparison group.
For a simple fictional calculation, attributed revenue of $2,000 and ad spend of $500 give ROAS of 4, or 400%. ROI uses a defined profit or return calculation instead. Neither the ROAS arithmetic nor a click event alone proves incremental revenue or profit.
Browser limitations and what consent mode does
Available identifiers vary by browser, settings and consent state. It is inaccurate to describe third-party cookies as universally removed across all browsers. On 22 April 2025, Chrome announced it would maintain its existing third-party-cookie choice approach rather than introduce a new standalone prompt. See the official announcement, and check current specifications for the browsers relevant to your site.
Consent mode adjusts Google tag behaviour in response to the consent state it receives. It is separate from obtaining a choice and storing it. Basic and advanced implementations behave differently when consent is denied, so observing a request alone does not establish whether an implementation meets its requirements.
Appropriate collection and use depend on the applicable context, including purpose, region and organisational policy. A banner or consent-mode installation is not itself a legal conclusion. Google’s privacy overview explains the technical roles.
Validate accept, reject and withdrawal journeys
Test the intended specification across the visitor journey. Check the next page and returning visits, not only the instant someone clicks a banner.
State | Record |
|---|---|
First visit, no choice | Defaults, tag behaviour and transmitted fields |
Accept | Update timing and subsequent behaviour |
Reject | Behaviour required by the selected implementation and policy |
Withdraw | State update and later collection |
Next page or return visit | Persistence, restoration and initialisation order |
Authentication or another domain | Continued arrival/success checks under the required conditions |
Consent mode does not itself save choices, so validate that responsibility in the wider implementation. Google documents defaults and updates in its implementation guide. Keep unresolved outcomes marked as unmeasured, then use the validated data for analysis.
