Data Collection and the Law: An Operational View

This is not legal advice and does not attempt to summarise any regulation. Requirements vary by jurisdiction, change frequently, and depend on facts about your business. Take advice from a qualified practitioner. For a concrete workplace example, this overview describes stealth monitoring and the questions it raises.

What follows is the operational half: what these obligations mean for how a measurement setup is built, and which questions belong to you rather than to a lawyer.

The principles that shape a measurement setup

Whatever the jurisdiction, a consistent set of ideas recurs, and they translate into design decisions.

Purpose limitation. Data collected for one stated purpose should not be quietly used for another. In practice this means the purposes you declare in your notice constrain what you can build later, so vague purposes are convenient at the point of writing and limiting afterwards.

Data minimisation. Collect what the purpose requires. This is the principle most directly at odds with default analytics configurations, which collect everything available in case it is useful.

Storage limitation. Data should not be kept indefinitely. Most analytics setups have never had a retention period set, and default retention is a choice someone made by not making one.

Transparency. People should be able to find out what is collected and why, in language they can understand.

Accountability. You should be able to demonstrate compliance, which means the decisions need recording rather than merely being correct.

What this means for how you build

Decide what you collect deliberately. Go through your event and property list and ask what question each one answers. Anything that answers none is collected because a default was left on, and it carries obligation without value.

Set a retention period, per data type. Event-level data does not need the same retention as aggregate reporting. Aggregating older data and deleting the detail satisfies most analytical needs and reduces exposure.

Keep personal data out of places it does not belong. Email addresses in URLs, names in page titles, identifiers in UTM parameters. These end up in analytics tools, server logs, referrer headers sent to third parties, and error reports — and once there, removing them is difficult. See UTM parameters.

Enforce consent at collection, not at reporting. A setup that collects everything and filters later has collected everything. If you use server-side infrastructure, the consent state must reach it and gate the forwarding. See server-side tracking.

Know where the data goes. Every vendor receiving your event stream is a recipient. A list of who receives what, maintained, is both an operational necessity and something you may be asked to produce.

Be able to delete. A deletion request should be executable across every system holding the data, including the warehouse, the analytics tool, and every vendor. If you cannot, that is a design problem to solve before it is requested.

The measurement consequences

This is where the legal and the analytical meet, and it is the part usually handled badly.

Consent refusal produces a biased sample, not a smaller one. Your metrics describe the consenting population. See consent.

Retention limits break long-horizon analysis. If event data is deleted after fourteen months, a three-year cohort curve cannot be built from it. Aggregate before you delete — retain the cohort summaries even when the underlying events go.

This is the single most important operational point in this article, and it is usually discovered a year too late.

Deletion requests create gaps in historical data, which can subtly change historical figures if reports are recomputed. Snapshot your reported numbers so that a figure quoted six months ago can still be reproduced.

Different jurisdictions produce different coverage, so a global metric mixes regions with very different visibility. Reporting a blended conversion rate across regions with different consent regimes is comparing incomparable things.

What belongs to you and what belongs to counsel

Counsel decides: whether a lawful basis exists, what the notice must say, whether a transfer mechanism is required, whether a particular processing activity is permitted, and what the retention period must be.

You decide and own:

• What is technically collected, and whether each item is necessary
• Whether the consent state actually reaches every collection point
• Whether the retention setting is implemented as agreed
• Whether personal data is leaking into fields that should not contain it
• Whether deletion is executable across every system
• Whether the vendor list is current

The failure mode in most organisations is that the legal side is settled and the technical side does not implement it. A policy stating a fourteen-month retention while the tool is set to fifty is not a legal failure; it is an operational one, and it is yours.

An audit worth running annually

• [ ] Every collected event and property listed, with the question it answers
• [ ] Anything answering no question, removed
• [ ] Retention period set per data type and verified in the tool, not just in the policy
• [ ] Aggregates retained beyond the raw retention period, so long-horizon analysis survives
• [ ] Consent state verified as reaching every collection point, including server-side
• [ ] Fields checked for leaked personal data — URLs, page titles, campaign parameters, custom properties
• [ ] Current list of every vendor receiving data, and what each receives
• [ ] Deletion tested end to end, across every system
• [ ] Reported figures snapshotted so historical reports remain reproducible

The framing that helps internally

Compliance work is usually presented as constraint, which makes it something to be minimised.

The more accurate framing is that most of it is good measurement practice anyway. Knowing what you collect and why, setting retention deliberately, keeping a vendor list, and being able to delete are all things a well-run analytics function does regardless of any regulation.

And minimisation improves data quality. A smaller, deliberate event schema is easier to maintain, easier to document, and less likely to drift than one that accumulated by default. See documenting metric definitions.

The summary

The legal questions belong to counsel; the implementation belongs to you, and the common failure is a correct policy that was never implemented.

Aggregate before you delete, or retention limits will remove the possibility of long-horizon analysis without anyone noticing until it is needed.

Enforce consent at collection, including server-side, or you have collected the data whatever the reporting layer does.

Check for personal data in places it should not be — URLs, titles, campaign parameters — because those propagate to places you do not control. For the EU legal framework, see the European Commission data-protection overview.