# 7. Getting the Data

*The question: What data can we use, where does it come from, and are we allowed to use it?*

> **Questions this chapter answers**
> - First, second, third party, public, inferred: what is each one actually worth, and what does each one cost us in risk?
> - When our systems disagree about a customer, which one wins?
> - Is buying enrichment data still a good idea, and how accurate is it?
> - What happened to third-party cookies and mobile tracking, and should we care?
> - How do we know we are allowed to use a fact for the thing we want to use it for?

## The short answer

Customer data arrives by six routes: what the person told you (declared), what you saw them do (observed), what a partner shared (second party), what you bought (third party), what is public, and what a model concluded (inferred). Each route makes a different kind of claim. Declared data is strongest about what a person wants. Observed data is strongest about what they did. Purchased data is a vendor's estimate, and you inherit the vendor's consent problems with it. Inferred data is a hypothesis, never a fact until confirmed.

The common mistake is not collecting too little. It is flattening all six routes into one column, so that a guess, a stale purchase, and a sentence the customer wrote last week look equally true to the system that reads them.

So carry the route with the value: source, time, confidence, and permitted purposes on every fact you personalize with. Then rank conflicts with a Signal Ladder: gate by purpose, prefer the source with authority over that kind of fact, let freshness override authority for things that change, and abstain when nothing clears the bar.

Build on what customers give you and what you observe in your own relationship. The web's tracking layer changes on other companies' schedules, and bought and inferred data are evidence to check, not truth to copy.

## Six answers to one question

Open one contact record at Larkspur Systems (a fictional company, a composite of many real ones): Maya Okafor, at a regional utility contractor, also fictional. Ask the record one question. What is her job?

- The CRM says **Fleet Manager**, typed by a sales rep in 2022.
- A webinar registration form says **Director of Operations**, which Maya selected from a dropdown in March 2025.
- Enrichment vendor A says **Operations Manager**, with no date on the value.
- Enrichment vendor B says **VP, Operations**.
- The signature on a support email three weeks ago says **Director, Field Operations**.
- An AI summary of her support threads, written by Larkspur's own pipeline, says she is **"likely the economic buyer for the renewal."**

Six sources, six answers, each true or believed at some moment. No typos, no duplicates. The record simply cannot say where each answer came from, how old it is, or which one Larkspur may quote back to her. The newsletter template reads the CRM field. Maya gets an email addressed to a Fleet Manager, a job she left two years ago.

Here is the sentence this chapter turns on: **where a value came from is part of the value.** Strip the source off and you do not have a cleaner fact. You have a rumor with a column name.

## Every signal arrives by a route, and the route decides what it can claim

The six routes are not a legal taxonomy. They describe what kind of claim each piece of data makes.

| Route | What it is | What it is good for | How it fails |
|---|---|---|---|
| **Declared** (zero party) | What the person deliberately told you: preferences, forms, stated goals | What they want; how to contact them | Goes stale; answers the question you asked |
| **Observed** (first party) | What they did with you: purchases, usage, tickets, replies | What happened, in context | Circumstance read as character |
| **Partner** (second party) | Another company's first-party data, shared under agreement | Gaps you cannot observe | Consent given to someone else, for something else |
| **Purchased** (third party) | Vendor-assembled records and enrichment | Coverage, firmographics, cold start | Unknown age and method; inherited consent risk |
| **Public** | Company sites, filings, announcements, profiles | Current account events | Public is not permitted; wrong-entity matches |
| **Inferred** (derived) | What a model or rule concluded | Choosing what to do | Fluent, confident, and sometimes about nobody |

![Six data routes shown as cards, each with what it is good for and how it fails. Declared data (zero party) is good for what the person wants and fails by going stale; observed data (first party) is good for what happened and fails when circumstance is read as character. These two are grouped as the routes to build on. Partner, purchased, public, and inferred data are grouped as enrichment and evidence to check: partner data fills gaps you cannot observe but carries someone else's consent, purchased data gives coverage and cold start with unknown age and method, public data shows current account events but public is not permitted, and inferred data helps choose what to do but is sometimes about nobody.](/images/handbook/ch06-six-routes.svg)

*Figure 7.1. Six routes, six kinds of claim: build on what customers declare and what you observe, and check everything else.*

Forrester's definition of zero-party data is "data that a customer intentionally and proactively shares with a brand" [1]. The definition is useful. I disagree with the way the category is often sold, as the clean answer to everything else. Intentional is not the same as current or complete. Maya's dropdown choice was intentional in March 2025. It was also the closest option on a list somebody else wrote.

### Declared data records what people say they want

When a person hands you something on purpose (a preference, a stated problem, a timeframe), they do it for a reason: a better answer, a faster service, a discount. When relevant, it is the strongest material you have, because the person chose it. It records what they say they want, not what can be worked out about them.

Its limits are real. A declared answer answers a question somebody asked, framed the way they framed it. And its purpose travels with it: disclosed for one purpose, it is not automatically available for every other.

### Observed data records what people do, in the situation they were in

Observed data moves the question from *what did they say they want* to *what do they repeatedly behave as though they want*, and the answers often differ. What people say answers a question. What they do responds to the situation they were standing in. That is also the limit: behavior is evidence of circumstances as much as of character. A customer who stopped using a reporting module may be unhappy, or may have hired an analyst who exports everything. The observation is a fact. The meaning is an inference, and should be stored as one.

Observation is also eroding at the edges you do not own. Since 2021, Apple's Mail Privacy Protection has loaded remote email content in the background and hidden the recipient's IP address, so senders cannot reliably tell whether a message was opened [2]. Observations from inside your own product, support desk, and billing system are the ones that hold.

### Inferred data is a claim about a person, not a fact about them

Inference is anything a system concludes that the person never told it: a statistical model lending someone what their group tends to do, or a language model reasoning about who wrote a set of emails. The methods differ in cost and in how often they are right. They produce the same thing: an understanding of a person with a confidence attached. How deep does it go? Three degrees, each a different kind of thing.

The first is estimating attributes nobody stated. In 2013, researchers predicted personal attributes from the Facebook Likes of about 58,000 volunteers, accurately for some and weakly for others [3]. A decade later, language models inferred private attributes from ordinary forum posts with up to 85% top-1 and 95% top-3 accuracy on the benchmark tested, at about 1/100th of the cost and 1/240th of the time of human labelers [4]. What changed was not mainly accuracy. It was price.

The second degree is explanation. Given a few true things, a capable model proposes a theory: what this person is responsible for, what is weighing on them this quarter, whose opinion they defer to. Larkspur's "likely the economic buyer" is this kind of claim.

The third degree is simulation. A 2024 Stanford-led study interviewed 1,052 people for two hours each and built an agent of each; on General Social Survey questions the agents matched participants' answers at about 85% of the consistency participants showed with themselves two weeks later [5]. That is the top of the data range: long, consented interviews. A CRM record and a few emails do not get anyone there.

Now the ceiling. Inference about personality, mood, beliefs, or intent is uncertain, carries demographic bias, and fails often, and fluency makes a weak inference sound like a finding. **Fluency is not validity.** So the rule is structural: inferred values live in their own labeled lane, used to choose what to do and never asserted to the customer until something first-hand confirms them.

## Bought data arrives with its supplier's consent attached

Purchased enrichment is still useful: firmographics you would never collect yourself, and a starting point for accounts you have never talked to. Two things about it deserve more attention than procurement usually gives them.

The first is accuracy. Nearly every enrichment accuracy comparison I could find was published by a company that sells data. As of September 2026 I have not found an independent, method-disclosed study of B2B enrichment accuracy that I would cite. Run your own bake-off instead: send each vendor a sample where you know the truth, and measure accuracy per field, not in aggregate.

Decay is real, but the usual number is not: "B2B data decays 22.5% a year" has no primary source I can trace. Job tenure is a defensible proxy: in January 2026, median tenure among US wage and salary workers was 4.1 years, and 20.6% had been with their employer a year or less [6]. Every job-linked field inherits that churn. A purchased title with no date is a guess about when it was true.

The second is consent. When you buy data, you inherit the question of how your supplier got it. In May 2026 the FTC settled with a Kochava subsidiary over location data; the order requires a supplier assessment program "designed to confirm that consumers have provided consent" [7]. Read it as a direction of travel: buyers are increasingly expected to know the provenance of what they buy. California came at it from the other end. Through the Delete Act's DROP platform, consumers could send one deletion request to every registered data broker from January 2026, and brokers had to start processing them on August 1, 2026, at least every 45 days, at $200 per day per unprocessed request [8]. Bought data about Californians now expires on a schedule. (As of September 2026; not legal advice.)

Enrichment is worth more as a cross-examiner than as a filler: **use it to challenge the data you hold, not only to add more of it.** Chapter 8 turns that into trust rules. In the personalization engine I built, the cross-examination runs on headcount and revenue: a provider value that is implausible, looks like a bucket artifact, or contradicts current research is hidden rather than used, because a missing number does less damage than a confident wrong one.

## The tracking layer shifted, and did not collapse

In January 2020 Google announced a path toward making third-party cookies obsolete in Chrome [9]. In July 2024 it said it would not deprecate them [10]; in April 2025 it dropped the planned cookie-choice prompt [11]; in October 2025 it retired most replacement technologies, including Topics, Protected Audience, and the Attribution Reporting API [12]. As of September 2026, Chrome still allows third-party cookies by default, while Safari and Firefox block them [13].

Cookies did not die. The replacement did.

On mobile, Apple's App Tracking Transparency has required apps since iOS 14.5 (April 2021) to ask permission before tracking users across other companies' apps and websites [14]. Reported opt-in rates range from single digits to around half, depending on the denominator [15].

The lesson is not about cookies. It is about dependency. Identifiers rented from a browser, an operating system, or an ad platform change on someone else's schedule. Build the model of the customer on what customers declare to you and what you observe in your own relationship, and treat everything else as enrichment.

## Provenance and consent are part of the data

A lawyer cares enormously how a fact was obtained. The model reading your customer record does not care at all. By the time a declared preference, a purchased title, and a model's guess reach a prompt, they are indistinguishable unless the record tells them apart. So provenance and consent belong inside the data, not in a separate system nobody queries at read time.

In practice, each fact you personalize with carries a small provenance envelope:

```yaml
property: job_title
value: "Director, Field Operations"
route: observed              # declared | observed | partner | purchased | public | inferred
source: support_email_signature
source_ref: ticket-88213
observed_at: 2026-09-02
method: extracted            # entered | selected | extracted | vendor | model
confidence: high
corroborated_by: [public_profile_2026-08]
permitted_purposes: [service, account_management, marketing]
allowed_surfaces: [internal, seller, email]
review_after: 2027-03-01
```

Three pairs do most of the work. `route` and `method` tell a fact from a guess. `observed_at` and `review_after` let freshness be computed rather than assumed (Chapter 11 builds the freshness policy on top). `permitted_purposes` and `allowed_surfaces` turn consent from a checkbox elsewhere into a filter applied before any fact reaches generation, so a confidential support note can shape a strategy without ever being quoted.

![A provenance envelope drawn around one value, job_title "Director, Field Operations", with three pairs of fields beneath it. Route and method (observed, extracted) tell a fact from a guess. Observed_at and review_after (2026-09-02 and 2027-03-01) make freshness computed rather than assumed. Permitted purposes and allowed surfaces say which use and which surface the value may serve, acting as a filter before generation.](/images/handbook/ch06-provenance-envelope.svg)

*Figure 7.2. The Provenance Envelope: three pairs of fields turn source, freshness, and consent into part of the value.*

Law points the same way. Under the GDPR, when personal data was not obtained from the person, you must tell them its source [16], and where you rely on consent you must be able to demonstrate it [17]. Neither is possible for a value whose source was discarded at import. (Not legal advice; Chapter 19 and the dated companion notes cover jurisdictions.) Inferences need their own flag, too: the Court of Justice of the EU has held that data "liable indirectly to reveal" a special category, such as health or sexual orientation, falls under the stricter rules for that category [18]. An inference can be sensitive even when every input was ordinary.

## The Signal Ladder: what overrides what

Provenance says where each value came from, not which one wins. For that, rank conflicting values on four dimensions, in a fixed order.

1. **Purpose is a gate, not a weight.** First remove every value that is not permitted for this use on this surface. A value can win on every other dimension and still be unusable here.
2. **Authority depends on the kind of fact.** For preferences (topics, channels, frequency), the person's own declaration has authority. For circumstances (current role, employer), the person's own recent artifacts have authority: a signature, a reply, a changed login domain. For transactions (what they bought, what they use), your system of record has authority. For facts nobody stated, inference may fill in, but only to decide, never to assert.
3. **Freshness can override authority for things that change.** A declared title from 2025 loses to an observed title from last month. A declared channel preference does not lose to an inferred one, however recent.
4. **Confidence breaks ties, and corroboration raises it.** Two independent sources agreeing beat one source alone. Two vendors that resell the same upstream file are one source.

When nothing clears the bar, abstain. Hide the value, fall back to account-level or segment-level framing, or ask. A specific but false message is worse than a general but useful one.

Run Maya's record through the ladder. Every title is permitted for account management. Job title is a circumstance, so her own recent artifact has authority: **Director, Field Operations**, three weeks old, corroborated by a public profile. The CRM value becomes history, not deleted. The vendor values are set aside until they agree with something first-hand. The "economic buyer" inference stays in its lane: it may route the renewal conversation to her, and never appears in a sentence she reads.

![The Signal Ladder as four numbered rungs, each paired with its result for Maya's job title at Larkspur (fictional). Rung 1, purpose is a gate: every title is permitted for account management. Rung 2, authority by kind of fact (preference, circumstance, transaction, inferred): title is a circumstance, so her own recent artifact rules. Rung 3, freshness can override authority for things that change: her support email signature is three weeks old. Rung 4, confidence breaks ties: it is corroborated by a public profile. The winner is "Director, Field Operations"; the CRM value is kept as history, vendor values are set aside, and the "economic buyer" inference routes the conversation but is never asserted. When nothing clears the bar, the system abstains: hide, fall back, or ask.](/images/handbook/ch06-signal-ladder.svg)

*Figure 7.3. The Signal Ladder applied to Maya: purpose, authority, freshness, and confidence, in that order, or abstain.*

## What this does not do

A ladder does not fix identity. If the support email came from a different Maya Okafor, the freshest, most authoritative value belongs to the wrong person. Resolving who a record is about comes first (Chapter 9).

Permitted is not appropriate. A fact can clear every purpose gate and still feel invasive in a message (Chapter 19).

More routes do not mean more depth. The usual response to thin personalization is another data vendor, yet the facts that would change what Larkspur says to Maya were already inside Larkspur: a ticket, a signature, a usage log. Depth comes from the fact that changes the message, not from the number of facts on file.

Nor is the envelope a finished product, including mine. In the personalization engine I built, account research is increasingly stored as structured fields so each one can be trust-filtered and rendered on its own; attaching confidence, provenance, and freshness to every one of those fields is the step still in progress. The envelope in this chapter is the design I am building toward, not a description of a system that already carries it everywhere.

And be wary of confident claims. "Third-party cookies are dead" is wrong as of September 2026. "Only 4% allow tracking" is a real number with a narrow denominator. "Our data is 95% accurate" is usually a vendor measuring itself.

## At scale

With 250,000 contacts, conflicts stop being edge cases: even a small share of multi-valued fields means thousands of silent decisions per send. The ladder makes them consistent rules, and the envelope makes each one explainable afterward.

Scale also changes the economics of verification. Re-checking a field by hand was rationed to top accounts. Re-checking it by extraction from the customer's own emails and tickets is cheap enough to run on every record, on a schedule. The constraint moves from the cost of checking to the discipline of storing what the check found.

And many teams means many writers: marketing imports a vendor file, sales edits the CRM, a support agent extracts a title. Without a shared envelope, the last writer wins. With one, the ladder wins.

More sources also means one of them is always failing. In the engine I built, research runs across several providers and tolerates partial failure: if one source errors and two succeed, the record is built from the two instead of failing, and a provider that keeps failing is skipped for the rest of the batch rather than called again on every record (Chapter 22 shows what happens without that). The consequence for this chapter is provenance. A record assembled from two of three sources should say which one was missing. **An unanswered source is not a source that agreed**, and corroboration counted across sources that were never asked is not corroboration.

Intake needs the same distinction between kinds of absence. The engine rejects a lead whose required fields are invalid, such as an unusable email, and accepts one with no title, with a warning: a missing title and an invalid email are not the same class of problem. Reject what breaks identity or permission, warn on what only reduces depth, and never fill a gap with a default that looks like data. The load date in the failure story below was exactly that kind of default.

## Failure story: The Undated Purchase

A composite, at a company much like Larkspur. Before a renewal campaign, marketing operations loads a vendor enrichment file to fill blank titles and refresh old ones. The vendor's titles carry no date, so the import job stamps each value with the day it was loaded. One contact's support-email signature, six weeks old, read **Director, Customer Experience**. The vendor file said **Dispatch Manager**, a role she had left more than a year earlier. Stamped with the load date, the purchased title looked fresher than her own signature, and the freshness rule meant to protect the record did the damage: the vendor value won. The campaign invited her to a workshop "for managers who run dispatch every day." She forwarded it to her successor with one line: "I think this is yours."

The vendor's value was true once. It became wrong when the import gave an unknown age a date it never had. `observed_at` is when the world was seen, not when the file arrived. A purchased value without one ranks as undated, below any first-hand artifact, and waits for corroboration.

## Patterns

**Signal Ladder.** *Problem:* sources disagree about one property. *Forces:* they differ in authority, age, and permission; templates read one field. *Solution:* gate by purpose, rank by per-property authority, let freshness override for volatile properties, break ties by corroborated confidence, abstain when nothing qualifies. *Tradeoffs:* needs provenance everywhere; authority rules take real thought.

**Provenance Envelope.** *Problem:* facts lose their source at import. *Forces:* schemas were designed for dashboards; the new reader is a model. *Solution:* every personalization-relevant value carries route, source, method, time, confidence, purposes, and surfaces. *Tradeoffs:* larger records; import pipelines must keep what they used to discard.

A third pattern, **Enrichment as Cross-Examination**, belongs with these two; Chapter 8 defines it in full.

## Leader questions

1. For our top five personalization fields, can we say where each value came from, and when?
2. Which suppliers could show how their data subjects consented, if a regulator asked?
3. When two systems disagree about a customer, which wins today, and is that written down?
4. How much of our targeting depends on identifiers a browser or platform controls?
5. Where are AI conclusions about customers stored, and can anyone tell them from facts?

## Build checklist

- [ ] Tag every source feeding customer records with its route.
- [ ] Store route, source, method, timestamp, and confidence on every value used in personalization.
- [ ] Enforce permitted purposes and allowed surfaces before context reaches generation.
- [ ] Write per-property authority rules (preference, circumstance, transaction, inferred).
- [ ] Keep inferences in a labeled lane; never overwrite a fact with one; keep superseded values as history.
- [ ] Bake off enrichment vendors per field; keep supplier consent attestations and review them yearly.
- [ ] Define the abstention path: hide, fall back to account or segment framing, or ask.
- [ ] Record which sources were asked and which answered; never count a failed source as agreement.
- [ ] At intake, reject what breaks identity or permission, warn on missing depth, and never default a gap into data.

## Metrics to watch

- **Provenance coverage:** share of personalization values with a known source and timestamp.
- **Conflict rate per property:** share of records with competing values, and how many the ladder resolves.
- **Abstention rate:** how often a value is withheld for lack of trust; watch the trend.
- **Enrichment agreement:** per-field agreement between each vendor and first-hand evidence.
- **Inference leakage:** customer-facing claims whose only source is an inference (target: zero).

## Reader Q&A

**Is first-party data always better than third-party data?** For what happened in your relationship, yes. For firmographics about an account you have never spoken to, a vendor may be all you have. That is why authority is defined per property type.

**Can we use publicly available information freely?** Public is not permitted. Under the GDPR, public personal data is still personal data, and you still owe notice of the source [16]. Check with counsel.

**How do we store an AI's conclusions about a customer?** As inferences: with the model, the inputs, the time, and a confidence, in a lane the generator is not allowed to quote from without confirmation.

## For your AI

```yaml
chapter: 7
concepts:
  - name: Data Route
    definition: "How a value entered the record: declared, observed, partner, purchased, public, or inferred. The route determines what kind of claim the value makes."
  - name: Signal Ladder
    definition: "Precedence for conflicting values: gate by purpose, rank by authority for the property type, let freshness override authority for volatile properties, break ties by corroborated confidence, abstain when nothing qualifies."
  - name: Provenance Envelope
    definition: "Per-value envelope carrying route, source, method, time, confidence, permitted purposes, and allowed surfaces."
  - name: Inferred Lane
    definition: "Separate, labeled storage for model or rule conclusions, usable for decisions but not asserted to the customer without first-hand confirmation."
  - name: Enrichment as Cross-Examination
    definition: "Using purchased and public data to challenge held values, not only to fill blanks. Pattern defined in Chapter 8."
decision_rules:
  - if: "a value is not permitted for the intended purpose or surface"
    then: "exclude it before ranking, regardless of authority, freshness, or confidence"
  - if: "the property is a preference (topic, channel, frequency)"
    then: "the person's own declaration has authority over observed or inferred values"
  - if: "the property is a circumstance (role, employer) and a first-hand artifact is fresher than the declared or stored value"
    then: "the fresher first-hand value wins; keep the older value as history"
  - if: "the only source for a customer-facing claim is an inference"
    then: "do not assert it; use it only to choose the action, or confirm first"
  - if: "a purchased value conflicts with first-hand or corroborated public evidence"
    then: "surface the conflict and do not use the purchased value in customer-facing content"
  - if: "no candidate value clears the trust bar"
    then: "abstain: omit, fall back to account or segment framing, or ask the person"
  - if: "a research source failed or was not consulted for a record"
    then: "record it as not checked; do not count it toward corroboration"
  - if: "an intake record is missing a non-essential field such as title"
    then: "accept it with a warning; reject only values that break identity or permission, and never fill the gap with a default"
assessment_questions:
  - "Which sources feed your customer records, and which route does each represent?"
  - "Do stored values keep their source and timestamp after import?"
  - "Where are AI-generated conclusions about customers stored, and are they labeled?"
  - "Can each data supplier document how consent was obtained?"
  - "Which personalization depends on third-party cookies or mobile advertising identifiers?"
  - "Which regions' customers are in scope, and has counsel reviewed notice-of-source and consent records?"
patterns: [Signal Ladder, Provenance Envelope]
related_patterns: [Enrichment as Cross-Examination (Chapter 8)]
anti_patterns: [The Undated Purchase, Flattened Routes, Rented Identity]
maturity_dimension: understanding
as_of: "2026-09"
```

## References

1. Khatibloo, F., et al. (Forrester, 2018), zero-party data definition, as quoted in *Frontiers in Big Data* (2022). https://www.frontiersin.org/journals/big-data/articles/10.3389/fdata.2022.943372/full
2. Apple Support, "Use Mail Privacy Protection on iPhone." https://support.apple.com/guide/iphone/use-mail-privacy-protection-iphf084865c7/ios
3. Kosinski, M., Stillwell, D., and Graepel, T. (2013). "Private traits and attributes are predictable from digital records of human behavior." *PNAS* 110(15). https://doi.org/10.1073/pnas.1218772110
4. Staab, R., Vero, M., Balunović, M., and Vechev, M. (2024). "Beyond Memorization: Violating Privacy via Inference with Large Language Models." ICLR 2024. https://arxiv.org/abs/2310.07298
5. Park, J. S., et al. (2024). "Generative Agent Simulations of 1,000 People." arXiv:2411.10109. https://arxiv.org/abs/2411.10109
6. US Bureau of Labor Statistics, Employee Tenure news release (January 2026 data), released 2026-09-24. https://www.bls.gov/news.release/tenure.nr0.htm
7. FTC, "FTC to Ban Kochava Subsidiary from Selling Sensitive Location Data...," 2026-05-04. https://www.ftc.gov/news-events/news/press-releases/2026/05/ftc-ban-kochava-subsidiary-selling-sensitive-location-data-settle-charges-they-sold-location-data
8. California Privacy Protection Agency (CalPrivacy), "Data Brokers" and DROP. https://privacy.ca.gov/data-brokers
9. Google, Chromium Blog, "Building a more private web: A path towards making third party cookies obsolete," 2020-01-14. https://blog.chromium.org/2020/01/building-more-private-web-path-towards.html
10. IAPP, "Google ends third-party cookie phaseout plans," 2024-07-22. https://iapp.org/news/a/google-ends-third-party-cookie-phaseout-plans
11. Google, "Next steps for Privacy Sandbox and tracking protections in Chrome," 2025-04-22. https://privacysandbox.google.com/blog/privacy-sandbox-next-steps
12. Google (A. Chavez), "Update on Plans for Privacy Sandbox Technologies," 2025-10-17. https://privacysandbox.google.com/blog/update-on-plans-for-privacy-sandbox-technologies
13. MDN Web Docs, "Third-party cookies." https://developer.mozilla.org/en-US/docs/Web/Privacy/Guides/Third-party_cookies
14. Apple Developer News, App Tracking Transparency requirement with iOS 14.5, 2021. https://developer.apple.com/news/?id=ecvrtzt2
15. Flurry Analytics, iOS 14.5 ATT opt-in rate reports, 2021. https://www.flurry.com/blog/ios-14-5-opt-in-rate-att-restricted-app-tracking-transparency-worldwide-us-daily-latest-update/
16. GDPR (Regulation (EU) 2016/679), Art. 14(2)(f): information on the source of personal data not obtained from the data subject. https://eur-lex.europa.eu/eli/reg/2016/679/oj
17. GDPR, Art. 7(1): controller must be able to demonstrate consent. https://eur-lex.europa.eu/eli/reg/2016/679/oj
18. CJEU, Case C-184/20, *OT v Vyriausioji tarnybinės etikos komisija*, 2022-08-01. https://curia.europa.eu/juris/liste.jsf?num=C-184/20