First-Party Data

• Zero-party

  Volunteered by the person on purpose: preferences, a survey answer, the 'how did you hear about us' field. A subset of first-party in law, singled out because it is stated rather than observed. Self-reported attribution is zero-party data used for measurement.

• First-party

  Collected by you, on your properties, about people who interact with you. Site behaviour, form fills, call records, CRM stages, email engagement. This entry.

• Second-party

  Somebody else's first-party data shared with you under an agreement: a partner's attendee list, a publisher's audience for a sponsorship. Rare, and governed by the contract.

• Third-party

  Collected by a company with no direct relationship to the person, aggregated across many sites and sold in segments. Historically built on third-party cookies, which is why it is shrinking.

• Safari and Firefox block third-party cookiesSafari has blocked them by default since 2020 after years of Intelligent Tracking Prevention, and Firefox has blocked known trackers' cookies since 2019. Between them that is a large share of a European audience that no cross-site cookie can follow.
• Chrome kept them, under user controlGoogle announced their removal in 2020, delayed it three times and in 2024 dropped the plan, keeping third-party cookies behind Chrome's existing settings. The ecosystem had already moved: the ad platforms' own products now assume first-party signals.
• Apple's App Tracking TransparencySince iOS 14.5 in 2021, apps must ask before tracking across other companies' apps and sites. Most people decline, which is what broke Meta's view of iOS conversions and pushed the Conversions API to the front.
• Consent law covers every partyGDPR and the ePrivacy rules require consent to store or read non-essential identifiers on a device, whoever sets them. Third-party data was hardest to justify under that rule, so it went first. First-party data is easier to justify, not exempt.

1. A tag on your own domain. The site script records pages, referrer, UTM parameters and click IDs, and sets a first-party cookie or, better, a server-set identifier that browsers treat more generously than one set from JavaScript.
2. Forms with hidden fields. Name and email come from the visible fields; source, campaign and click ID ride along in hidden ones, into the CRM.
3. Calls and bookings. Tracking numbers and scheduling tools tie a phone call or a booked meeting to the visit that produced it.
4. The CRM and billing. Stage changes, deal values, closed-won dates. The half of first-party data that turns an attribution report from leads into revenue.
5. Email and product engagement. Opens, clicks, logins. Consented, addressable and entirely yours.

All of it under a consent management platform that records what the person agreed to. First-party collection is not consent-free: the exemption for 'strictly necessary' storage covers a login or a shopping cart, not a tracking identifier. The GDPR-compliant tracking use case and the guide to GDPR-compliant conversion tracking cover the setup that stays inside those lines.

Attribution is a join: the click that cost money on one side, the lead or deal that made money on the other. Both sides of that join are now first-party or nothing.

• The click side is first-party storageThe click ID and UTMs exist in the URL for one page. Everything after that depends on your own storage: a cookie on your domain, a server session, a CRM field. If that storage is weak, journeys are short and every model credits the last week.
• The deal side is your CRMNo platform sees the deal close. The value, the date and the stage live in your CRM, and only you can send them anywhere.
• The join happens on your serverMatching a visitor across visits, holding identifiers longer than a browser allows, and attaching the deal to the journey is work done on a first-party server. That is what server-side tracking is for, and what first-party tracking builds on.
• The platforms want it backGoogle's enhanced conversions and Meta's Conversions API match conversions on hashed first-party identifiers, email, phone and name, plus the click ID. Their bidding learns from what you send. A business with weak first-party data sends form fills; one with strong first-party data sends closed deals.

The Meta Conversions API is the most visible example: it exists because Meta can no longer collect the conversion itself and needs the advertiser's first-party record of it.

• Every lead record carries its journey. Source, campaign, click ID, landing page, first and latest visit, written automatically.
• Identifiers outlive the browser. The join key lives on a server and in the CRM, not only in a seven-day cookie.
• Consent is recorded next to the data. What was agreed, when, through which banner version.
• Outcomes flow back out. Qualified leads and closed deals go to the platforms as hashed conversions, so the spend optimises toward the CRM, not the form.
• One owner. The business, not an agency's account or a platform's pixel, holds the data and can move it.

First-party data is not a new kind of data; it is the data a business always had, now the only kind the browsers and the law leave standing. For attribution it is both halves of the join: the click captured on your domain and the deal recorded in your CRM. Collect it with consent, hold it on a server rather than in a browser, and send the outcomes back to the platforms. Everything else in modern measurement is a technique for doing those three things well.