How UK GDPR and PECR change what an attribution claim can say

What to take away

Where an attribution claim meets a lawful basis under UK GDPR

An attribution claim is a sentence that says a channel, campaign or touchpoint caused a result. In the UK that sentence is a data processing outcome, not just a marketing opinion. The claim rests on personal data: device identifiers, hashed emails, IP addresses, order references and the joins between them.

UK GDPR governs how you collect and use that data. It sits alongside the Data Protection Act 2018, which fills in UK specific detail on exemptions, enforcement and the role of the Information Commissioner's Office.

That means every claim needs a lawful basis before the model runs. The ICO's A guide to lawful basis sets out six options and requires you to choose one, document it and not swap it later without a reason.

For attribution work the realistic candidates are legitimate interests, consent and, in narrow cases, contract. Public task and legal obligation rarely fit a commercial attribution claim, and vital interests should not appear at all.

Most UK teams start with legitimate interests. It is flexible, but it is not a free pass. You need a legitimate interests assessment that names the interest, shows the processing is necessary and balances it against the individual's rights.

If a person's data is used to score them, retarget them or build a cross site view, the balancing test gets harder to pass. Consent is often the cleaner route for anything that touches advertising identifiers.

Consent under UK GDPR has to be freely given, specific, informed and unambiguous. A pre ticked box on a sign up form does not meet that standard, and neither does a privacy notice that mentions analytics somewhere in paragraph nine.

The lawful basis has to match the claim you eventually publish.

This is where claim wording starts to matter. A claim that says a channel drove a rise in sales implies a causal link. A claim that says the channel was associated with a rise is weaker but easier to defend.

A worked example shows the gap. The overstated wording reads: paid search drove the rise in first orders. To defend that sentence, the lawful basis entry would have to show the model measured cause, which a last click model cannot do on its own.

The defensible wording reads: first orders were associated with paid search. That sentence fits a model that shows correlation, and the legitimate interests assessment can carry it.

The ICO does not police marketing language directly, but if your wording overstates what the data can support, you create a gap between the claim and the processing record.

The practical test is simple. Compare the claim against the lawful basis entry. If the entry cannot explain why the data was processed to produce that claim, the claim is exposed. That exposure matters most when the claim is used in a pitch, a board pack, a public report or a regulator response.

Attribution also depends on joining data across systems, which is a separate processing purpose. The join itself may need its own basis, its own notice and its own retention rule. Teams that treat the join as a technical detail rather than a processing decision tend to fail the first accountability review.

The row level approach to personal data and device tracking survives scrutiny because it forces you to name each field, its source and its purpose before any claim is written. It is also the point at which most teams discover they have been using identifiers they cannot lawfully join.

Mapping personal data and device tracking sets out that method row by row.

Consent records PECR requires before an analytics tag fires

PECR is separate from UK GDPR and it applies to storage and access technologies on a user's device. Cookies, local storage, pixels, SDK identifiers and device fingerprinting all fall inside its scope.

The Privacy and Electronic Communications (EC Directive) Regulations 2003 set out the statutory rules on cookies, traffic data and electronic marketing, and those rules still bite in the UK after Brexit.

Under PECR, consent is normally required before a cookie or similar technology is stored on or retrieved from a user's device. There are limited exceptions, such as storage that is strictly necessary to provide a service the user requested. Analytics and attribution tags rarely qualify as strictly necessary, because they serve the business rather than the user's immediate request.

The ICO's Guidance on the use of storage and access technologies is explicit that consent must be unambiguous and involve a clear affirmative action. Analytics cookies that profile users, link sessions or feed attribution models need consent. So do pixels that pass conversion events to ad platforms, even when the data is hashed.

Consent records are the evidence that this happened. A consent record should show what the user was told, what they chose, when they chose it, how they chose it and which tags fired as a result. It should also show the consent management platform version, the banner text and the tag configuration at that moment.

A consent record that only logs a yes or no is weak. You need the context around the choice. If the banner changed, the record should show which version the user saw. If the tag list changed, the record should show which tags were active.

If the user withdrew consent, the record should show when the withdrawal took effect and which downstream systems were told.

This is the part UK teams most often get wrong. They log consent at the point of collection but not at the point of use. An attribution model that runs weeks later may be using data collected under an older banner, an older tag list or an older privacy notice.

Withdrawal is equally important. PECR consent must be as easy to withdraw as to give, and the withdrawal has to be honoured across the whole attribution stack. That includes the tag manager, the analytics platform, the ad platform, the CRM and any data warehouse where the rows are stored.

If withdrawal only stops future collection but leaves historical rows in the model, the record is incomplete.

Tag governance is the operational side of this. Each tag should have an owner, a purpose, a lawful basis, a consent category and a retention rule. Tags that cannot be mapped to a purpose should be removed. Tags that fire before consent should be blocked at the tag manager level, not just hidden in the banner.

A versioned disclosure process helps here, because it keeps the banner text, the tag list and the privacy notice aligned as they change. Without that versioning, a consent record from six months ago may describe a setup that no longer exists, which makes the record hard to rely on.

The documentation sequence from claim wording to retention schedule

The order of documentation matters. If you write the claim first and find the lawful basis afterwards, you will end up bending the record to fit the claim. Run the sequence in this order, from the processing decision to the published sentence.

Each step produces a document, and each document should be findable without asking the person who wrote it. That is the difference between a documentation set and a folder of files. The ICO's Accountability and governance guidance treats records as evidence that you can demonstrate compliance, not just intend it.

Retention is the step most teams leave vague. A retention schedule for attribution data should distinguish between raw event data, joined profiles, model outputs and published claims. There is no single UK period.

A typical schedule keeps raw events for 30 to 90 days, joined profiles for a shorter period and aggregated outputs for no longer than 14 months. The figure has to be justified by the purpose and written into the schedule before the data is collected.

Deletion is proved by a log that names the record, the system, the date and the operator, plus a periodic check that the rows are gone. A schedule without that proof is a promise, not a record.

When the claim is published outside the organisation, a second layer of rules applies. The ASA can challenge misleading advertising claims, and the CMA can take an interest in claims that affect consumer choice.

Neither body enforces UK GDPR, but both can ask what evidence supports a public statement. That is another reason to keep the claim wording tied to the record.

Data protection, advertising, consumer and statistical rules can all touch the same attribution claim, and the boundaries are not always obvious. Which UK rules may reach an operation of this kind is worth mapping early, because it saves rework when a claim is challenged.

What the ICO expects in an accountability record for attribution

Accountability under UK GDPR means you can demonstrate compliance, not just claim it. The ICO guidance points to records of processing, data protection impact assessments, policies and training as the core evidence. For attribution, those general expectations translate into a specific record set.

A workable accountability record for an attribution claim should name the claim, the lawful basis, the consent evidence, the data fields, the retention period, the processors involved and the person who approved it. It should also record any objection or withdrawal that affected the model, and what was done about it.

The record is easier to keep as a table. A short version looks like this.

The record should be written so that someone outside the team can follow it. That means no internal shorthand, no unexplained acronyms and no references to a spreadsheet that only one person can open. If the record depends on a system, the record should say which system and where the evidence sits inside it.

A data protection impact assessment is expected where processing is likely to result in a high risk to individuals. Attribution that profiles people, combines data sources or tracks them across sites can meet that threshold. The DPIA should describe the processing, assess the risks and set out the measures that reduce them.

The ICO also expects records of processing activities, sometimes called a ROPA. For attribution, the ROPA entry should cover the purposes, the categories of data, the recipients, the retention periods and the security measures. It should line up with the lawful basis entry and the consent record, not contradict them.

Processor contracts are part of the same picture. If an analytics platform, a tag manager or a data warehouse provider handles personal data on your behalf, the contract needs the UK GDPR processor terms.

Transfers outside the UK need their own assessment and safeguards. In practice that means an adequacy finding, the International Data Transfer Agreement or the UK addendum to the EU standard contractual clauses, plus a transfer risk assessment. The record should name the safeguard used and where the signed copy sits.

When the ICO receives a complaint, it will usually ask for the record before it asks for the model. If the record shows a clear lawful basis, a working consent mechanism and a retention rule that is followed, the conversation is shorter. If the record is missing or inconsistent, the claim becomes the least of the problems.

The risk has a price. The ICO fined British Airways £20 million in October 2020 and Ticketmaster UK £1.25 million in November 2020, both over failures to protect customer data. Neither case concerned attribution, but both show the scale of a penalty when the evidence of compliance is thin.

Mapping UK attribution rules from tracking evidence to publication checks is a useful way to see where each record fits. It also shows where a gap in one record creates a gap in another, which is usually how accountability failures start.

Subject access and objection rights that reshape attribution data

A subject access request is a request from an individual to see the personal data an organisation holds about them. The ICO's Subject access requests guidance explains the right of access, the time limits and the exemptions.

For attribution teams, a SAR is the moment the model stops being an abstraction and becomes a disclosure exercise.

Attribution data is often spread across systems. A single individual's data may sit in the tag manager logs, the analytics platform, the CRM, the ad platform and the data warehouse. A SAR response has to cover all of it, which means the team needs a way to find and assemble those rows quickly.

That is harder than it sounds. Joined profiles may not carry a customer identifier, and hashed identifiers may need a lookup table to resolve. If the lookup table is not maintained, the team may be unable to fulfil the request, which is itself a compliance problem.

The right to object is the second pressure point. Where processing relies on legitimate interests, an individual can object, and the organisation must stop unless it can show compelling grounds that override the individual's interests. For attribution, that may mean excluding the person from the model, deleting their rows or both.

Objections also affect historical data. If a person objects and their data remains in a model that produces current claims, the objection has not been honoured. The record should show what was removed, when and from which systems.

The right to rectification matters too. If a person corrects their details, the attribution rows that depend on those details may need updating. That can change historical model outputs, which is uncomfortable for teams used to treating past reports as fixed.

Withdrawal of consent under PECR adds a further layer. Consent withdrawal should stop processing that relied on consent, and it should be reflected in the consent record and the attribution stack.

Teams that plan for these rights build attribution models that can be edited, not just reported. That usually means keeping the join between identifiers and profiles explicit, so rows can be found and removed. It also means documenting what happens to a claim when the underlying data changes.

Records a UK marketing analytics team must hold, item by item

This is the minimum record set for a UK attribution operation that makes claims. It is not a legal checklist, but it maps to the ICO's accountability expectations and to PECR consent duties.

Each item should be findable by someone who did not create it. If a record lives only in someone's inbox, it is not a record. If it lives in a system, the system should be named in the accountability record.

The claim sign off sheet is the item most teams lack. It ties the published sentence to the evidence behind it, and it gives the team a way to withdraw or amend a claim if the data changes. Without it, claims drift away from the lawful basis that justified them.

The SAR and objection log is the item most teams underestimate. It shows that rights are being handled, and it gives the team a way to spot patterns. If the same objection keeps appearing, the model or the notice may need changing.

Two practical habits keep the record set alive. First, review the lawful basis register and the tag inventory on a fixed cycle, not only when something breaks. Second, keep the claim wording and the record in the same document, so a change to one forces a look at the other.

Common questions