How to Build and Measure a First-Party Data Programme
Build a first-party data programme covering instrumentation, identity, permissions, activation, match rates, incrementality, data quality and operating cost.
First-party data can make customer operations more observable, more consistent and more responsive. It can connect transactions with service interactions, apply communication preferences across systems, create eligible advertising audiences and bring more customer outcomes into view.
None of that proves the programme increases revenue.
A useful first-party data strategy therefore starts with a decision or a measurement problem, not with a database, a tag, a platform or the promise of a unified customer profile. The organisation has to define what it wants to decide, which information is necessary, who may use it, and how commercial impact will be tested.
This guide covers the implementation sequence from collection through activation to incremental measurement. For information customers intentionally provide through quizzes, settings or preference centres, see the companion guide to customer-declared preference data.
What first-party data is
First-party data is information an organisation collects through its own relationships and interactions with customers, prospects, users or members. It typically covers account and contact information, orders, subscriptions, returns and payments, website and application events, customer-service interactions, loyalty activity, campaign responses, product usage, communication choices, survey and preference responses, and records of consent, objection and withdrawal.
The label describes the organisationβs relationship to the source. It is not a statutory category, and it grants no special permission to use the information. Where the information relates to an identified or identifiable person, data-protection obligations apply regardless of whether it was collected directly, inferred from behaviour or supplied deliberately.
What first-party data is not
First-party data is not automatically accurate, complete, current, consented for every purpose, available for indefinite retention, suitable for every model or audience, matched to one person with certainty, or proof that marketing caused an outcome.
A transaction system may be authoritative for completed purchases and incomplete for browsing. An analytics platform may record events but not subsequent cancellations. A CRM may hold an email address without recording whether it is current or eligible for a particular communication.
The useful question is not whether the organisation has first-party data. It is which data is reliable and permitted for this particular decision.
Why first-party does not mean unrestricted
First-party is a description of where data came from. It is not a legal permission category.
UK data-protection principles cover lawfulness, fairness, transparency, purpose limitation, data minimisation, accuracy, storage limitation, security and accountability, and they apply to directly collected data exactly as they apply to anything else. (1) The ICO also expects privacy and data protection to be considered from design onwards and throughout the processing lifecycle. (2) Marketing to individuals by electronic mail engages separate direct-marketing rules on top of that.
One 2026 change is worth stating precisely, because it is routinely misread. The Data (Use and Access) Act 2025 created narrow exceptions to the cookie consent requirement, which took effect on 5 February 2026. (3) They apply where the sole purpose is collecting statistical information to improve the service, or adapting appearance and functionality, and only where clear information and a simple free means of objecting are provided and no objection has been made. They do not cover advertising measurement, cross-service tracking, identifying or profiling visitors, or online advertising generally, all of which still require consent. (4) A measurement team reading statistical as a synonym for analytics will reach the wrong conclusion about its own advertising tags.
The wider rules are also in motion, and the ICO has advised government on possible changes to the consent requirements for lower-risk advertising. Nothing has changed yet. Treat the current position as the operating constraint and review it on a schedule; the future consumer-data landscape covers where policy may go next.
A first-party programme therefore needs controls for the purpose behind each field or event, the lawful basis and any relevant direct-marketing or device rules, which systems and teams may use the data, whether it may be shared with an advertising or technology provider, how corrections and objections propagate, when the information becomes stale, and when it should be deleted or anonymised.
Collecting information directly does not remove those questions. It makes the organisation more directly responsible for answering them.
For the legal implementation detail, see the GDPR and CCPA compliance guide. For the wider principles, see ethical consumer-data use and the relationship between privacy, personalisation and trust.
Start with the decision
A programme should begin with a specific operational or commercial decision. Which service messages must be sent after a failed delivery? Which customers are eligible for a replenishment reminder? Which conversions are missing from campaign reporting? Which product experience should a signed-in customer see? Did a known-customer audience increase contribution after media cost? Which records must be suppressed after a marketing objection?
Write the decision as a sentence. When a given situation occurs, a named owner will use specified fields to make a specified decision, subject to stated restrictions, and success will be measured against a stated comparison.
That exercise exposes vague objectives. Improving personalisation is not a decision. Recommending a compatible replacement to customers whose registered product is approaching the end of its expected life is a decision, and it can be tested.
It also exposes the limits of what any data programme can fix. I spent a decade on the vendor side of this, and the ceiling was always the same. We could collect enough data to prove precisely why a brand was underperforming, and then have no say whatsoever over its pricing, its brand image or its operations. Late deliveries and a stock system fed by wrong data produced dissatisfaction that no campaign could offset. That is a commercial observation rather than a legal one, and it is why the decision statement matters: if the decision sits outside what the data can influence, a better pipeline will not rescue it.
Identify the minimum required data
For every decision, identify the outcome being decided, the smallest set of inputs needed, the source of each input, how current each input must be, the permission or eligibility condition, the consequence of an incorrect value, and whether a less intrusive input would work.
The ICOβs data-minimisation guidance says personal data should be adequate, relevant and limited to what is necessary for the stated purpose. (5)
A useful data specification distinguishes required fields, without which the decision cannot be made safely, from optional enhancers that may improve relevance without being essential, prohibited inputs that create unjustified risk, derived fields that must retain their source and method, and sensitive or high-impact inputs that need enhanced review.
More fields do not necessarily produce a better model. They can increase error, maintenance cost and the consequences of misuse.
Instrument events and transactions
Event instrumentation turns customer and system activity into structured records. A workable event specification covers the event name and its business definition, the trigger, event time and processing time, source application, customer or session identifier, product or order identifier, value and currency where relevant, consent or permission state, schema version, deduplication key, expected volume and latency, and a named validation owner.
For transactions, reconcile the analytics record against the authoritative operational system. A purchase event fired from a confirmation page is not equivalent to settled revenue. Orders fail, get cancelled, get refunded and get partially returned.
Client-side and server-side collection
Server-side collection can move parts of event processing from the browser or application into infrastructure the organisation controls, which gives it more control over how events are shaped and routed. (6)
It does not remove the need for valid notices or permissions, make every event first-party in a legal sense, make blocked or unavailable events reappear, guarantee identity accuracy, or justify sending extra fields to an external platform.
Treat server-side collection as an architectural choice, not a privacy exemption.
Resolve customer identity carefully
Identity resolution connects records believed to relate to the same person, account, household or device. Start by defining the entity. An individual, an account, an organisation, a household, a subscription, a device, a browser and an anonymous session are different things and should not be used interchangeably.
Prefer explicit, deterministic links
Higher-confidence links include authenticated account identifiers, verified email addresses, order-to-account relationships, loyalty identifiers and customer-service account verification. Even these can be shared, reassigned, mistyped or outdated, so preserve confidence and provenance rather than treating a link as permanent truth.
Label probabilistic links
Where a relationship is inferred from devices, patterns or similarity, record the method, the confidence, the date calculated, the permitted use, the expiry and the circumstances in which the link must not be used. High-impact decisions should not silently depend on uncertain identity.
Avoid the unqualified single customer view
Different systems may legitimately hold different representations of a customer. The aim is a governed set of authoritative records and documented relationships, not the fiction of a complete profile.
The gap is usually wider than the deck admits. Working on loyalty programmes, the thing that struck me was how much of a customerβs buying sits somewhere the brand cannot see. The same products are sold through marketplaces, and the brand has almost no information about who bought there, while the same person may also be buying from a competitor. Teams still described what they held as a full view. It was a view of one channel. Naming that boundary is more useful than pretending it does not exist, because every decision built on the profile inherits it.
Propagate permissions and preferences
A permission is useful only if the systems making decisions can apply it. Represent consent, objections and preferences as governed records rather than loose CRM fields. A record may need the person or account identifier, purpose, channel, status, source, the version of the notice or wording shown, a timestamp, jurisdiction or market, an expiry or review date, a withdrawal timestamp, and the downstream systems notified.
Googleβs server-side consent-mode documentation illustrates the architectural principle. A consent solution collects the choice, which is then communicated to tags and to server-side processing. The documentation also states that the technical feature does not itself provide a consent interface. (7)
The same principle applies well beyond one platform. Permission must either travel with the data or be checked at the point of use.
A suppression or objection should normally take precedence over an activation preference. Do not overwrite an instruction not to send marketing email because another system later records a preference for email.
Validate quality and completeness
Data quality is fitness for a defined use, not a single global score. Measure validity, completeness, uniqueness, consistency, timeliness, accuracy, lineage and eligibility. The last of those is the one most often missing: whether the record is permitted for the intended use is a quality attribute, not a separate compliance exercise.
The ICO advises organisations to take reasonable steps to keep relevant personal information accurate, and to correct or erase information found to be incorrect or misleading. (8)
Reconciliation tests
Useful controls include analytics orders against order-management orders, recorded revenue against settled revenue, consent-state counts across the consent platform, CRM and activation systems, audience exports against accepted platform records, customer deletions against downstream deletion acknowledgements, event volume by application version, duplicate-conversion rates, and processing-latency distributions.
A dashboard showing total events without these checks can conceal serious failure.
Activate only eligible records
Activation means using data to make or influence a decision. It covers selecting a service workflow, suppressing an irrelevant message, creating a CRM segment, producing a recommendation, uploading an eligible advertising audience, sending permitted conversion records to a measurement platform, and prioritising customer-service work.
Before activation, run an eligibility check. Is the purpose defined? Is the field necessary for that purpose? Is the record current enough? Is identity confidence sufficient? Is the person eligible for this channel and use? Are objections and suppression rules applied? Is the destination approved? Can the activation be audited and reversed? Is there an appropriate comparison for measuring the effect?
Where a decision is significant and taken by automated means, the safeguards introduced in 2026 also apply, including telling people about the decision, letting them make representations and allowing them to seek human intervention. (3)
For zero-party data collection methods, the intended activation should also be explained at the point the information is requested.
Understand platform match rates
When an eligible customer list or conversion record is sent to an advertising platform, the platform may try to associate it with an account or user it recognises. A match rate is broadly the number of matched eligible records divided by the number submitted for matching, but the exact numerator, denominator, deduplication method and reporting window differ by platform. Record the platformβs own definition rather than comparing unlike percentages.
Match rate is affected by missing identifiers, invalid formatting, outdated contact information, normalisation rules, hashing implementation, duplicate records, whether customers use the same identifier with the platform, platform coverage, and eligibility filtering before upload.
Enhanced-conversions documentation, for example, describes using hashed first-party customer information to supplement existing conversion measurement and to match conversions with signed-in accounts. (9)
A higher match rate may improve observable coverage. By itself it does not prove that more people were reached, that advertising changed behaviour, that more incremental conversions occurred, or that incremental contribution exceeded programme cost.
Separate attributed from incremental results
Attributed conversions are outcomes assigned to an interaction under a defined rule or model. Incremental conversions are outcomes that would not have occurred without the treatment. They are not interchangeable.
Attributed outcomes describe what happened among matched or exposed customers. They do not establish what would have happened without the activity. Experimental or carefully identified causal methods are therefore needed whenever the question is incremental effect. Joint guidelines published by IAB and IAB Europe in November 2025 draw the same line, noting that attribution and return on ad spend describe what happened rather than whether marketing caused it. (10)
The experimental evidence on this is unusually direct. Gordon, Moakler and Zettelmeyer compared non-experimental estimates against 663 large-scale advertising experiments and found that the observational approaches tested did not reliably recover the experimental effects, despite unusually rich user-level data. (11) That is the sharpest available warning against treating a well-matched observational estimate as a causal one, and it holds in a setting with far better identity data than most first-party programmes will ever have.
A customer who saw an advert and later purchased may have purchased anyway. Better matching can increase the number of purchases associated with advertising without increasing the number caused by it.
Measurement hierarchy
| Metric | What it answers | What it does not prove |
|---|---|---|
| Collection volume | How many records or events arrived | That they are useful or accurate |
| Identifiable coverage | How much activity links to the chosen entity | That identity is correct in every case |
| Eligible population | How many records may be used for the activity | That they can be matched or reached |
| Match rate | What proportion the destination recognised | That activation changed outcomes |
| Audience reach | How many eligible people were exposed or contactable | That exposure was incremental |
| Attributed conversions | How many outcomes the attribution rule assigned | That the activity caused them |
| Incremental conversions | Estimated additional outcomes against a counterfactual | That those outcomes were profitable |
| Revenue | Gross value associated with outcomes | Contribution after variable costs |
| Contribution | Revenue less relevant variable costs | Long-term customer value |
| Customer lifetime value | Expected or realised value over a stated horizon | That the data programme caused it |
| Operating cost | Cost of collection, infrastructure, people and governance | Commercial benefit |
| Risk | Exposure to error, misuse, complaints or regulatory harm | A comparable financial return unless quantified |
Reading any one row on its own is the most reliable way to reach a wrong conclusion. The clearest case I saw was a conversion-rate uplift that everyone in the room was pleased with. The revenue impact behind it was worse than the baseline, because average order value had moved the other way and nobody had put the two figures on the same page. This is a commercial point rather than a compliance one: a metric that rises while the metric next to it falls is not a result, it is a question. Reporting standards should require the adjacent numbers, not just the flattering one.
Comparison methods
Depending on the decision, teams may use randomised customer holdouts, campaign conversion-lift tests, geographic experiments, matched-market comparisons, staggered roll-outs, switchback tests, controlled product experiments or calibrated marketing-mix models.
Every method carries assumptions. Googleβs Meridian documentation distinguishes experimental from modelled return, notes that they answer different questions, and warns that a result from one population, period or treatment does not transfer automatically. (12) Model fit is not the same as causal validity: a model can predict observed outcomes well and still attribute them incorrectly. (13)
Measure commercial outcomes
A first-party data business case should connect operational improvement to a commercial chain. More valid transaction records arrive within the required time. More eligible conversions become available for measurement. Campaign optimisation changes. A controlled comparison estimates additional orders. Incremental revenue is calculated. Returns, discounts, fulfilment and other variable costs are deducted. Programme operating cost is deducted. Uncertainty and risk are reported.
Commercial reporting should disclose the treatment and comparison populations, the test period, the primary outcome, the minimum detectable effect, the confidence or credible interval, exclusions, implementation failures, novelty effects, spillover or contamination, whether the figure is gross revenue, contribution or profit, and whether staff and infrastructure costs are included.
For broader methodology, see measuring marketing performance, measuring personalisation effectiveness and the personalisation KPI reference.
Measure operating cost and risk
A first-party data programme carries continuing cost: engineering and analytics labour, consent-management and governance work, cloud processing and storage, vendor licences, data-quality monitoring, identity services, audience and conversion integrations, security controls, incident response, rights-request handling, training, experimentation and technical debt.
Separate one-off implementation cost, recurring platform cost, recurring people cost, marginal activation cost, the cost of control groups or forgone treatment, and expected risk cost.
The mismatch I saw most often was not overspending on the wrong platform. It was buying a sophisticated capability and then using almost none of it. A noticeable share of brands I worked with paid for advanced messaging tooling and used it to send plain, straightforward messages, which is roughly like buying the best engine available and never leaving third gear. That is a commercial judgement, not a technical one: if the programme only ever needs the basic function, the licence is the wrong size, and the honest move is to shrink the tooling rather than manufacture sophistication to justify it.
A programme that improves reporting but costs more than the decisions it improves is not commercially justified.
Review retention and deletion
Do not retain every event because it might become useful. The ICO says organisations should justify retention periods, review information periodically, and erase or anonymise personal data when it is no longer required. (14)
Define retention by purpose, field or event class, source, legal or operational requirement, sensitivity, identity confidence, last useful date, deletion or anonymisation method, downstream systems, backup treatment and a named review owner.
Retention should also cover model features and audience derivatives. Deleting a source record while leaving an active segment, score or exported audience unchanged may not achieve the intended result.
Establish an operating model
A first-party programme is not owned by marketing technology alone.
The business decision owner defines the decision, owns the commercial outcome and approves scale, revision or closure. The data product owner owns schemas, lineage, service levels and documentation. Engineering implements collection, transformation, identity and deletion, and monitors reliability and latency. Analytics or experimentation defines metrics and counterfactual methods, and prevents attributed outcomes being reported as incremental. CRM and channel teams define activation rules and verify eligibility and suppression. Privacy, legal and governance review purpose, transparency, lawful basis, sharing, retention and rights. Security evaluates access, transport, credentials, external destinations and incident risk. Customer-experience or product teams assess whether the resulting interaction is understandable, useful and controllable.
There is a failure mode in that structure worth naming, because I created it myself. Moving from operational account work up to running a region, I finally understood why forecasting, CRM hygiene and knowledge sharing mattered, having found them invisible when I was doing the day job. What I gained in perspective I lost in proximity. Effort optimisation makes it easy for a leader to defer the process fixes that look small from above and are the entire working day of the people below. A first-party programme dies from exactly those deferred fixes.
Implementation sequence
| Phase | Owner | Output | Exit criterion |
|---|---|---|---|
| Define the decision | Business decision owner | Testable decision statement | Owner, outcome and comparison approved |
| Identify minimum data | Data product owner with privacy | Required, optional and prohibited field list | Every retained field has a documented purpose |
| Map sources and identities | Data architect | Source and identity map with confidence rules | Authoritative sources approved |
| Define collection and permission rules | Privacy and channel owners | Collection and eligibility specification | Rules can be implemented and audited |
| Instrument events and transactions | Engineering | Versioned production events | Test events reconcile with source systems |
| Validate quality | Data quality owner | Quality report and controls | Thresholds met for the intended decision |
| Propagate preferences and restrictions | Consent or governance owner | Enforced downstream state | End-to-end tests confirm enforcement |
| Activate eligible records | Channel owner | Auditable treatment population | Preflight controls pass |
| Define comparison method | Experimentation lead | Analysis plan | Plan approved before launch |
| Measure incremental effect | Analytics and finance | Effect estimate with uncertainty | Estimate and limitations reviewed |
| Measure cost and risk | Finance, operations and risk | Full programme cost | Cost and risk in the business case |
| Review retention and deletion | Information governance | Retention schedule and deletion controls | Deletion verified across destinations |
| Scale, revise or stop | Executive decision owner | Documented decision | Decision and review date recorded |
The most common sequencing error is choosing the comparison method after the results are visible.
Common mistakes
Starting with a platform
A platform cannot determine which business decision is worth improving.
Measuring only collection volume
More events can mean more duplication, more noise and more unnecessary processing.
Treating identity as certain
Record the entity, the confidence, the provenance and the expiry of every link.
Treating permission as a CRM checkbox
Permissions need purpose, channel, time, source and downstream enforcement.
Optimising for match rate
Match rate is an intermediate operational metric, not a commercial objective.
Labelling attributed revenue as incremental
Attribution assigns credit. Incrementality estimates a counterfactual difference.
Ignoring refunds and variable cost
Gross order value overstates commercial effect.
Retaining data just in case
A speculative future use is not a retention strategy.
Scaling before validating the pipeline
A test result is uninterpretable while event loss, duplication or suppression errors are uncontrolled.
Treating a winning test as permanently won
This is the one I argue about most. Almost everyone working in personalisation believes that if something tested better once, it will keep testing better. It will not, because the audience changes and behaviour changes underneath it. My own practice is to leave the test running against a smaller control group rather than declaring a permanent winner, and to re-run it roughly every six months where a live holdout is not possible. Treating an old result as a settled fact is how a programme quietly stops working while the dashboard keeps reporting the original uplift.
Frequently Asked Questions
In marketing terminology, information collected through an organisation's own relationship with a person is usually described as first-party data. The label does not decide whether the processing is lawful, fair or suitable for a particular decision.
Zero-party data describes information a person intentionally provides. Once collected, it can also form part of that organisation's first-party data. The useful distinction concerns how the information was obtained and what it can validly represent.
It can give an organisation greater control over how events are processed and routed. It cannot recover events that were never observed, override customer choices, or guarantee that a platform will match a record.
There is no universal target. Evaluate the rate against the eligible population, identifier availability, the platform's own definition, cost and the intended decision. A lower but properly governed rate can be preferable to a higher one produced by stale or ineligible records.
Not necessarily. It may improve audience eligibility or measurement coverage. Incremental revenue still has to be tested against a suitable counterfactual and compared with cost.
Build the minimum governed representation the defined decisions require. Completeness is contextual, and attempts to collect everything usually increase cost and risk faster than they increase useful insight.
Use incremental contribution attributable to the programme, less implementation and continuing operating cost. Report uncertainty, and distinguish programme-wide value from the performance of a single campaign.
Conclusion
A first-party data programme should improve decisions, not simply increase the number of records an organisation holds.
Its strongest early benefits are usually operational: better observability, faster data availability, more consistent suppression, wider eligible audience coverage, more reliable transaction reconciliation and clearer measurement boundaries.
Commercial impact is a separate question. It should be tested against controls or credible comparisons, reported as incremental contribution rather than attributed revenue, and assessed after operating cost and risk.
For the strategic context, including how permissioned portability and privacy-enhancing technologies may change what is available to measure, see the future consumer-data landscape. Treat this framework as the operational foundation beneath it, not as a prediction of guaranteed returns.
References
-
Information Commissionerβs Office. A guide to the data protection principles. Regulatory guidance. No reference number; relates to UK GDPR Article 5. No publication date shown; latest date displayed 23 March 2026. Carries a banner stating that the guidance is under review and may change following the Data (Use and Access) Act. United Kingdom. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/
-
Information Commissionerβs Office. Data protection by design and by default. Regulatory guidance. No reference number; relates to UK GDPR Article 25. No publication date shown; last updated 5 February 2026. No review banner shown. United Kingdom. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/data-protection-by-design-and-by-default/
-
UK Parliament. Data (Use and Access) Act 2025. Primary legislation. 2025 c. 18. Royal Assent 19 June 2025. The specific data-protection amendments discussed in this article took effect on 5 February 2026, and all DUAA data-protection provisions were in force by 19 June 2026. The separate transition to the Information Commission remained ongoing as at 28 July 2026. United Kingdom. https://www.legislation.gov.uk/ukpga/2025/18/contents
-
Information Commissionerβs Office. What are the exceptions? Chapter of the finalised Guidance on the use of storage and access technologies. No reference number. No separate date shown on the chapter; the parent guidance was published in draft on 20 December 2024 and finalised on 29 April 2026. United Kingdom. https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-the-use-of-storage-and-access-technologies/what-are-the-exceptions/
-
Information Commissionerβs Office. Principle (c): Data minimisation. Regulatory guidance. No reference number; relates to UK GDPR Article 5(1)(c). No publication or update date shown on the page; accessed 28 July 2026. Carries the under-review banner following the Data (Use and Access) Act. United Kingdom. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/data-minimisation/
-
Google. An introduction to server-side tagging. Tag Manager developer documentation. No reference number. No publication date shown; last updated 14 November 2024. Not UK law; Google develops the product described, so the page is not independent evidence of privacy compliance, measurement accuracy or commercial effect. https://developers.google.com/tag-platform/tag-manager/server-side/intro
-
Google. Implement consent mode with server-side Tag Manager. Tag Manager developer documentation. No reference number. No publication date shown; last updated 17 April 2026. Not UK law; Google operates the product and the related advertising services, and the page states that consent mode does not provide a consent banner or widget. https://developers.google.com/tag-platform/tag-manager/server-side/consent-mode
-
Information Commissionerβs Office. Principle (d): Accuracy. Regulatory guidance. No reference number; relates to UK GDPR Article 5(1)(d) and to the definition of inaccurate in the Data Protection Act 2018. No publication or update date shown on the page; accessed 28 July 2026. Carries the under-review banner. United Kingdom. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/accuracy/
-
Google. About enhanced conversions. Google Ads Help article number 9888656. No publication or update date shown on the page; accessed 28 July 2026. Not UK law; Google sells advertising and operates the measurement feature described, and the page does not establish incremental conversion, profitability or a lawful basis for any implementation. https://support.google.com/google-ads/answer/9888656?hl=en-GB
-
IAB and IAB Europe. Guidelines for Incremental Measurement in Commerce Media. Joint industry-association guidelines. No reference or version number. Published 3 November 2025; no update shown. Not UK law, and not peer-reviewed; issued by advertising-industry associations and focused on commerce media rather than all marketing measurement. https://iabeurope.eu/knowledge_hub/guidelines-for-incremental-measurement-in-commerce-media/
-
Brett R. Gordon, Robert Moakler and Florian Zettelmeyer. Close Enough? A Large-Scale Exploration of Non-Experimental Approaches to Advertising Measurement. Peer-reviewed journal article, Marketing Science, volume 42, issue 4, pages 768 to 793. DOI 10.1287/mksc.2022.1413. Published 2023. Not UK law. Interest disclosure: one author was an employee of Meta, and the two academic authors held limited part-time Facebook research appointments. The study uses Facebook advertising experiments, so its findings concern that setting rather than every channel or platform. https://doi.org/10.1287/mksc.2022.1413
-
Google. Calibrate treatment priors. Meridian developer documentation. No reference number. No publication date shown; last updated 15 May 2026. Not UK law; Google develops Meridian and sells advertising, so the page is useful for methodological distinctions but is not independent validation of any model or campaign. https://developers.google.com/meridian/docs/advanced-modeling/roi-priors-and-calibration
-
Google. Interpret the visualizations. Meridian developer documentation. No reference number. No publication date shown; last updated 15 May 2026. Not UK law; explains Meridian-specific outputs and does not establish that modelled contributions are correct for a particular dataset. https://developers.google.com/meridian/docs/post-modeling/interpret-visualizations
-
Information Commissionerβs Office. Principle (e): Storage limitation. Regulatory guidance. No reference number; relates to UK GDPR Article 5(1)(e). No publication or update date shown on the page; accessed 28 July 2026. Carries the under-review banner, and states that UK GDPR sets no specific time limits for particular categories of data. United Kingdom. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/storage-limitation/
Position as at 28 July 2026. UK data-protection guidance is unusually unsettled at the time of writing. Most of the ICO principle pages cited above carry a banner saying they are under review following the Data (Use and Access) Act 2025, and the ICO has advised government on possible changes to the consent rules for online advertising, which remain advice rather than law. The regulator is also mid-transition: the Information Commission has been established and is expected to take over the ICOβs functions later in 2026, so the issuing body named in these references may change. Platform documentation changes without notice. Verify the current status of any source before relying on it for a compliance or investment decision.
Written by
Δ°lkem Erul
Contributor
I have over nine years of experience in digital marketing, account management, and B2C loyalty. I've helped global brands grow, and now, as a co-founder of Herm.io, I work on smarter, safer shopping experiences for consumers.
More from Δ°lkemRelated Articles
How to Collect and Use Customer-Declared Preference Data
Design quizzes, preference centres and progressive profiling that collect useful customer-declared data with clear value, validation and customer control.
How to Measure Marketing Performance
Build a marketing measurement framework covering KPI hierarchies, definitions, attribution, experiments, MMM and decision-making.
The Future of Consumer Data: What Marketing Leaders Should Prepare For
Explore how first-party data, smart data, privacy-enhancing technologies, platform restrictions and changing customer expectations are reshaping marketing data.