First-party data and customer data platforms: when a CDP is worth it

The decision this piece informs: whether to invest in a customer data platform (CDP), and if so which kind, or whether the systems you already have can do the job.

• First-party data is what a brand collects in its own relationship with people: site and app behaviour, purchases, service contacts. Zero-party data, in Forrester's definition, is what a customer intentionally and proactively shares, such as preferences, purchase intentions and how they want to be recognised¹.
• Why it matters more now. Safari has blocked third-party cookies by default since 2020³ and Firefox gives every site its own cookie jar⁴. Chrome kept third-party cookies under user choice, and Google retired most of the Privacy Sandbox replacements in 2025⁵. Data from your own relationship is the part you control.
• A CDP, in the CDP Institute's definition, is packaged software that builds a unified, persistent customer database other systems can use². Packaged CDPs keep their own copy of the data; composable, or warehouse-native, approaches work on the company's warehouse.
• Worth it when several sources must be joined for valuable, named use cases and someone will own the result. Otherwise it is an expensive copy of your CRM.

First-party data is not free data. Collecting and using it still needs a lawful basis and clear information, and for many uses consent; reading or storing information on someone's device needs consent in the EU unless it is strictly necessary. The European Data Protection Board's guidelines, adopted in October 2024, bring tracking pixels and similar techniques within that rule⁷ (see first-party data and consent management).

The practical test is the value exchange: what does the person get for what they tell you? Good answers are concrete.

• Better service a saved size, a delivery preference, a reminder they asked for.
• Better relevance a preference centre that lets people choose topics and frequency, which is also zero-party data¹.
• Recognition a loyalty programme that remembers what they bought; see CRM and loyalty.

Ask only for what a named use case needs, say why at the moment you ask, and record the consent with the data so every tool can read it.

Then keep the record usable. Decide the few fields every profile must have (an identifier, the consent state, the source and the date it was collected), validate them where they are entered, and set a review date after which unused data is deleted. A small, accurate profile serves more use cases than a large one nobody trusts.

The definition the CDP Institute has kept since 2016 has three parts that matter when you buy: the database is unified (one record per person from many sources), persistent (it keeps history, not just the current session) and available to other systems². In 2019 the Institute added the RealCDP checklist so buyers could test whether a product sold as a CDP could support the expected use cases². Ask vendors to show each step on your own data.

It also helps to know what a CDP is not. A CRM runs the relationship with people sales and service deal with, and its records are typed in by staff. A data warehouse serves analysis and reporting across the business. Older data management platforms assembled anonymous, mostly third-party segments for advertising. A CDP sits between them: it keeps known and anonymous profiles together, from many sources, ready for marketing to use.

The directory lists customer data platforms in their own category, among them Twilio Segment and Bloomreach; listings record what each vendor documents, not a recommendation. Readiness matters more than the label: in Gartner's 2025 survey of martech leaders, half said their organisation lacked the technical and data readiness needed for AI agents¹¹, and the same gaps slow any CDP.

Identity resolution decides which records belong to the same person. There are two broad methods.

• Deterministic records are joined on an identifier the person gave you, such as an email address, phone number, login or loyalty number. Accurate, and limited to people who identified themselves.
• Probabilistic records are joined by inference from signals such as device, location and behaviour. Wider, less accurate, and still personal data under European rules.

Most visitors are anonymous until they log in, subscribe or buy. A CDP keeps an anonymous profile, usually keyed on a first-party cookie or app identifier, and merges it with the known profile when the person identifies themselves. Browsers limit how long that works: since 2020, Safari has deleted script-writable storage after seven days of use without interaction with the site³. Plan on known identity for anything that matters.

Two practices travel well. First, set the rules in writing: which identifiers join records, which never do, and what happens when two records conflict. Second, when you match with partners, use privacy-preserving methods. The IAB Tech Lab's PAIR protocol, for example, lets an advertiser and a publisher match encrypted identifiers without either side decrypting the other's data, using commutative encryption⁹, and its clean room guidance sets out what such environments can and cannot guarantee¹⁰. Server-side collection helps too: data passes through a server the company controls, where personal data can be removed before anything is forwarded⁸.

Activation brings its own consent rules. For audiences in the European Economic Area, Google requires both its advertising consent signals to be granted before Customer Match lists are used for personalised ads; since March 2024, data without them is not processed for that purpose⁶.

Count the full cost on the other side: licences priced by profiles or events, the work of connecting every source, the people who will own identity rules and segments, and the cost of leaving. Work out the payback with the use cases' value, not the vendor's: what a better welcome journey or a win-back programme is worth, using retention and margin as in customer value and lifetime and the LTV:CAC calculator.

An illustrative business, not a real company: a chain of fitness clubs with an app, a website, club check-ins and email. It names three use cases. (1) A welcome programme built on the goals members choose at sign-up, which is zero-party data. (2) A win-back message for members who stop checking in, sent only with consent. (3) Excluding current members from acquisition ads.

• Identity members are known deterministically by member number and email; web visitors stay anonymous until they log in. No probabilistic matching is needed.
• Sources the membership system, the app, the club gates and email: four sources, so the first test is passed.
• Route the finance team already runs a data warehouse with two engineers, so the club starts composable for use cases 2 and 3, and keeps the welcome programme in the app's messaging tool.
• Consent consent is recorded in the membership system and synchronised with every profile; the exclusion audience is sent only for members whose consent allows it.

• Buying the platform before the use cases. A CDP with no named use case becomes a third copy of the customer file.
• Collecting everything "in case". Data without a purpose is a liability under data protection law and a cost in the warehouse.
• Treating first-party as consent-free. Device access, profiling and ad matching each have their own consent rules^6, 7.
• Probabilistic matching presented as certainty. Report match rates by method, and never send an inferred identity a message meant for a known one.
• No owner of identity rules, so that every tool merges records differently.

1. Write three use cases with their value, the sources each needs and the consent each requires.
2. Map today's customer data: which system holds what, keyed on which identifier, with which consent field.
3. Decide the identity rules: which identifiers join records, and which never do.
4. Design the value exchange for each piece of zero-party data you will ask for, and a preference centre to keep it current.
5. Run the "Do we need a CDP?" test; if yes, compare a packaged and a composable route on your own data, using Compare.
6. Sketch where each use case sits on the customer journey map, and track results with the retention and loyalty objective in mind.

• Definitions: Forrester on zero-party data¹ and the CDP Institute on CDPs².
• Browsers and identity: WebKit³, Mozilla⁴ and Google's Privacy Sandbox update⁵.
• Consent and collection: the EDPB's guidelines⁷, Google's Customer Match consent rules⁶ and server-side tagging guide⁸.
• Matching with partners: the IAB Tech Lab's PAIR protocol⁹ and clean room guidance¹⁰; on readiness, Gartner's 2025 survey¹¹.
• Next in this track: consent, identity and cookies; before it, building a martech stack.