Privacy and consent in analytics

Privacy and consent in analytics are the rules deciding which facts about a person a product may record, on what legal ground it may record them and how long it may keep them.

Two pieces of European law do most of the work and they cover different moments. The General Data Protection Regulation, Regulation (EU) 2016/679, has applied since 25 May 2018 and governs what an organisation may do with personal data once it holds any. The ePrivacy Directive, Directive 2002/58/EC as amended by Directive 2009/136/EC in November 2009, governs the moment before that, which is whether anything may be written to somebody's device or read from it at all.

Both laws reach the identifier every measure in this module rests on before they reach anything else. An anonymous identifier written to a browser sits on somebody's device, so the ePrivacy rule applies, and it picks one person out of a crowd, so the data protection rule applies as well. Stitching, sessions and the whole event model sit downstream of a question about whether that identifier may be written in the first place.

This belongs in an analytics course because consent changes the numbers. A visitor who declines is still a visitor. They arrive, they read a pricing page, they sign up or they leave, and the product records none of it. Every funnel, every cohort and every retention curve is therefore computed over the people who agreed, and that group resembles the whole population in no reliable way.

The sections below settle which facts inside an event count as personal data. They then cover the lawful basis for collecting any of it and the four tests a consent has to pass, followed by minimisation and retention periods. The arithmetic of a declined consent rate is worked through on one product after that. The page closes on the regional differences and on the figure a team publishes beside every number it reports.

What counts as personal data inside an event property

Article 4(1) of the General Data Protection Regulation defines personal data as any information relating to an identified or identifiable living person, and it names an online identifier among the things that make somebody identifiable. A random string in a cookie is an online identifier. Nobody at the company knows whose it is, and that changes nothing, because the definition asks whether a person can be picked out of a crowd and never whether anybody holds a name for them.

Pseudonymous data is the term for a record somebody could trace back to a person by adding a second table, and the Regulation treats it as personal data throughout. Anonymous data is the term for a record nobody can trace back by any route the organisation holds, which is a far harder standard than a team usually assumes it to be. A daily count of signups is anonymous. A row per visit carrying an identifier stays personal data however random the identifier looks.

Most of the exposure a team creates for itself sits in the properties it writes rather than in the identifier it was given. An identifier is one opaque field with a known shape. A property holding free text can hold anything a customer typed, and nobody reviews it before it lands in the warehouse.

Every repair in that table costs a few lines of code at the point of collection and none of them costs a measure. That is the test worth applying to any property somebody proposes, which is whether a narrower field would support the same analysis. A search term is the clearest case, because almost every question a team asks about search is answerable from the result count, the filters and whether anybody clicked a result.

The lawful basis and the four tests a consent has to pass

Narrowing a property settles what is collected and leaves the question of whether anything may be collected at all. Article 6(1) of the Regulation lists six lawful bases, and an organisation has to hold at least one before it processes anything.

1. The consent of the person.
2. The performance of a contract with that person.
3. A legal obligation on the organisation.
4. Somebody's vital interests.
5. A task carried out in the public interest.
6. The legitimate interests of the organisation or of a third party.

Product analytics is usually argued between the first and the last of those six, and inside the European Union the argument is settled earlier by the ePrivacy rule. Article 5(3) requires consent before information is stored on somebody's device or read from storage already there, and it exempts only what is strictly necessary to deliver the service the person asked for. A session cookie that keeps somebody logged in qualifies. An analytics tag does not, so the basis for the processing afterwards never arises until consent has been given.

Article 4(11) then defines what a consent is, and it sets four tests at once. A consent is any freely given, specific, informed and unambiguous indication of a person's wishes, given by a statement or by a clear affirmative action.

1. Freely given. The person can refuse without losing anything they came for, so a banner that blocks the page until somebody agrees fails.
2. Specific. Each purpose is agreed on its own, so one control covering analytics, advertising and personalisation together fails.
3. Informed. The person is told who collects the data, for what and for how long, before they decide.
4. Unambiguous. Agreement comes from an action somebody took, so silence, a box already ticked and continued scrolling all fail.

The fourth test has been litigated and the answer is settled. In Case C-673/17 the Court of Justice of the European Union ruled on 1 October 2019 that a checkbox presented already ticked, which a visitor has to clear to refuse, cannot produce a valid consent for storing cookies. The Court added that the site has to tell a visitor how long the cookies last and whether anybody else gets access to them.

Regulators have since moved from the mechanics of the control to how much effort a refusal costs. On 6 January 2022 the French regulator CNIL announced fines of 150 million euros against Google and 60 million euros against Facebook, on the ground that accepting cookies on their French sites took one click while refusing them took several. The reasoning was that a person who wants to read the page will take the fast option, so an asymmetric design manufactures the consent it records.

Data minimisation and how long a record may be kept

A valid consent covers a stated purpose, and two of the principles in Article 5 then limit what the purpose permits. Article 5(1)(c) is data minimisation, which asks that personal data be adequate, relevant and limited to what the purpose needs. Article 5(1)(e) is storage limitation, which asks that data identifying a person be kept no longer than the purpose needs.

Minimisation is the principle a tracking plan already serves without anybody calling it that. A plan with a reason recorded against every event and every property is a written argument that each field is necessary, dated and owned. A plan without that column leaves an organisation unable to answer why it holds a field, which is the question a regulator asks first.

Storage limitation turns into a number a team has to pick, and the tools now pick a default. A standard Google Analytics 4 property offers two months or fourteen months for user and event data and nothing longer, with the longer settings reserved for the paid tier. CNIL, in guidance published on 11 June 2020, puts the life of a tracker at thirteen months in the case it exempts from consent.

Two consequences follow for measurement and both surprise people. A retention curve cannot run longer than the retention period, so a team on a fourteen month setting cannot produce a two year curve at any point in the future, however patient it is. The repair is to compute the cohort aggregates on a schedule and store those, since a monthly table of cohort sizes carries no identifier and falls outside the limit entirely. The second consequence is that a deletion request has to reach every copy, and the warehouse copy is the one teams forget, because it was built by a different group for a different reason.

How the consenting population differs from everybody who arrived

A retention period decides how long the recorded rows survive and says nothing about whose rows they are. The consenting group differs from the whole population in ways a team can predict, and the largest of them is under the control of whoever last edited the banner.

Midas Nouwens, Ilaria Liccardi, Michael Veale, David Karger and Lalana Kagal reported on this at the CHI conference in 2020. They scraped 680 consent designs from the five most common platforms across the ten thousand most visited websites in the United Kingdom and found that 11.8 per cent met the minimal requirements the authors derived from European law. They then ran a field experiment with 40 participants. Removing the refusal control from the first screen raised consent by 22 to 23 percentage points, and putting granular controls on that first screen lowered it by 8 to 20 points.

A swing of twenty points from a layout decision tells a product manager something the compliance conversation never reaches. The consent rate is a property of the banner, so a design change alters the composition of the recorded population without altering anybody's behaviour, and the change arrives with no release note in the product's own repository.

Three further differences run in a consistent direction. Browser and device matter, because a blocking extension stops the analytics script loading whatever the visitor decided, and blocker use is heaviest among technical people on desktop machines. Technical confidence matters, because a person who understands what the banner is asking refuses more often. Region matters, because a visitor in Berlin meets a banner and a visitor in Texas usually does not. The first two push the recorded population towards the less technical end and towards mobile devices. The third makes the capture rate a property of the country, so any comparison between two markets carries a legal difference inside it.

What a declined consent rate does to a funnel

Those three differences turn into arithmetic as soon as a team reads a conversion rate. One product shows the size of the effect with no bias inside either segment at all.

In one month the site receives 100,000 visitors. Sixty thousand of them arrive on a phone and forty thousand on a desktop machine. The banner is accepted by 72 per cent of the phone visitors and by 48 per cent of the desktop visitors, and the gap between those two rates comes from the layout, since the refusal control on the narrow screen sits behind a second tap. Signup behaviour is identical inside each group whether or not somebody consented.

Read the table by column and the damage is easy to locate. Each device column reports its true rate exactly, because consent was independent of signup inside each group. The combined column reports 5.54 per cent against a real 6.00 per cent, which understates the product by about eight per cent relative, and the recorded signup count of 3,456 is 57.6 per cent of the 6,000 signups that actually happened. Nothing is broken and no event failed. The phone segment converts at less than half the desktop rate and contributes a much larger share of the recorded rows than it does of the real ones, so the average tips towards it. Cutting the figure by device restores both true rates, which is the repair a later page in this course sets out in full.

The more expensive version of the problem arrives when a consent rate moves. Suppose a browser update makes the refusal control more prominent on desktop machines and the desktop consent rate falls from 48 per cent to 36 per cent. Recorded visitors become 43,200 on the phone and 14,400 on desktop, or 57,600 together. Recorded signups become 1,728 and 1,296, or 3,024 together. The reported signup rate falls from 5.54 per cent to 5.25 per cent, a relative drop of about five per cent, while every visitor behaved exactly as before.

A team without the consent rate in front of it will spend a fortnight searching the release history for that drop. A team with the consent rate charted beside the conversion rate sees the two move together and asks a different question in the first hour.

Regional differences in what consent requires

The browser change above landed on one segment because the rules themselves differ by place, and the two largest regimes run in opposite directions.

The European Union asks for consent first. Nothing is written to a device and nothing is collected until somebody has taken an affirmative action, which is why a European visitor meets a banner before the page settles.

California asks for a refusal afterwards. The California Consumer Privacy Act has applied since 1 January 2020, amended by the California Privacy Rights Act from 1 January 2023, and it lets a business collect while giving the person a right to stop the sale or sharing of their personal information. The amended law also recognises a preference signal sent by the browser, so a visitor can register the refusal once and have every site honour it.

France holds the best documented middle position, and CNIL set it out in the guidance of 11 June 2020. An audience measurement tracker escapes the consent requirement if it meets every one of a short list of conditions.

1. Visitors are told about it and can object to it.
2. Its purpose is limited to audience measurement or to testing two versions of a page.
3. Its data is never cross referenced with any other processing.
4. It works for the publisher of that one site and passes nothing to a third party.
5. The last part of the network address is truncated.
6. The tracker lives no longer than thirteen months.

CNIL notes that most commercial products fail at least one of those six, which is the reason the exemption is quoted more often than it is used. What the list gives a product manager is a specification. A tool configured to meet all six conditions records every visitor in France. The same tool configured for convenience records only the visitors who accepted the banner.

Recording the consent rate beside every figure

Rules that differ by country and by browser produce one recorded population per combination, so the consent rate stops being a compliance statistic and becomes a denominator the team has to publish.

Counting it costs nothing. The banner knows whether somebody accepted, refused or ignored it, and a server side count of those three outcomes needs no storage on anybody's device, so it survives the same rules that removed the rest. Splitting that count by country and by device gives the capture rate for each segment a team reports on.

Three habits follow from having the figure. The consent rate is charted beside the measures it is the denominator for, so a fall in one is visible against the other. Any comparison between two segments with different capture rates is labelled, because the gap between them carries a legal difference as well as a product one. And a change to the banner is recorded with a date and treated as a break in the history, in the same way as a change to the session timeout.

Every gap this page has described was opened by a decision somebody made deliberately, with a date attached and a reason written down. The pipeline carrying whatever survives the banner fails in ways nobody chose, on days nobody marked, and without producing an error anywhere. Whether the numbers coming out of it can be believed at all is the subject of the next page.