Klaviyo CDP: What It Does, and Who Needs It

TL;DR. Klaviyo Data Platform is your account's data layer: it brings your data in through the vendor's integrations and APIs, attaches it to the right profile and makes it usable inside your flows. Advanced Klaviyo Data Platform is the paid upgrade on top. It changes something when the same customer exists in several systems that do not talk to each other: in-store till, subscription, customer service, marketplace. On a single-store brand connected to Shopify, the account already covers most of the need, and no unification layer repairs data that was missing upstream.

The most widespread error is buying a CDP to solve a segmentation problem. In most of the accounts we audit, the blockage sits upstream of the platform: checkout does not send the data you would like to segment on. An extra unification layer changes nothing about that.

What a CDP does, in one sentence

A CDP ingests data from several sources, attaches it to a single person, and makes that person addressable by your activation tools.

Three verbs, three separate projects: ingest, resolve, activate. An account can be excellent on the third and empty on the first, and that is the imbalance we run into most often in audits.

At Klaviyo, those three verbs are carried by the account's data layer, Klaviyo Data Platform (KDP): it gathers your data through the vendor's integrations and APIs, and you use it directly in your flows, with no extra sync and no extra tool. What you subscribe to on top, Advanced KDP, carries data warehouse sync, no-code data transformation and custom tracking.

Identity resolution: what sits in the account, what belongs to Advanced KDP

Klaviyo describes identity resolution as maintaining a unified customer record whatever identifiers are used across touchpoints and devices. The vendor's documentation ranks five identifiers by priority: the profile's Klaviyo ID, the external ID, the email address, the phone number, and the anonymous mobile app identifier, which stands for the iOS or Android guest profile. That deterministic merge already works on a standard account, with no add-on. What Advanced KDP adds is matching built on top: profiles that share the same phone number and whose email addresses differ by a single character, meaning a typo in the address.

Before subscribing to anything, list the matches you actually need and check, rule by rule, which ones are available in your account: the scope of these transformations moves, and an announced rule is not an active rule.

The classic scenario: a customer buys online with a personal address, comes back in store and gives another address at the till, then writes to customer service from a work address. You have three profiles. Each one receives your campaigns, each one holds a partial purchase history, and none of them triggers the right loyalty scenario.

The consequences show up immediately:

• Real pressure is three times what you think you are steering. Your reports show one campaign a week, the customer receives three. That over-solicitation gets paid in complaints, and Google's sender requirements ask you to stay under 0.30% complaints, with 0.10% as the recommended target.
• RFM segments are wrong, because customer value is split across records. The calculation framework is detailed in RFM segmentation.
• Exclusions stop working. A recent buyer on one profile is still a prospect on the other two, and receives a cart reminder after buying.

Matching relies on what your systems push into the profile: two profiles that share none of the five identifiers above stay two profiles. Hence the operational recommendation: have every source push the external ID, till included. It is the stable identity key Klaviyo describes as usable as the profile's primary identifier in place of the email address, and it is what makes matching predictable rather than dependent on whatever each system happened to send.

Where unification is worth a project

Physical retail. As soon as there is a till, there are purchases invisible to your online CRM, so win-backs sent to customers who buy in store every month.

Subscriptions. Subscription status, pauses and failed payments often live in a third-party tool. Bringing them into the profile changes the nature of the scenarios you can build.

Multi-store or multi-market brands, where the same customer exists on two stores and in two currencies.

Long-cycle catalogues, where the useful information (installation, warranty, servicing) sits in an ERP rather than in the order.

One simple test separates these cases from the rest: take ten customers at random and try to rebuild their full history by hand. If one tool is enough, unification is not what you are missing. If it takes three exports and a judgement call on duplicates, you have just done manually what unification automates, and you know how long it costs per customer.

That test has a second merit: it tells you which data is missing, which is the next question. A CDP bought without that list ends up ingesting whatever is easy to connect rather than whatever is useful.

In all these cases, the useful work looks like what is described in the Klaviyo events API and custom properties: you bring a piece of data in, you structure it, you segment on it. A good part of that runs on the account alone. Advanced KDP enters the discussion when you need to connect a data warehouse, transform without writing code, or track a custom event.

What does not work

Subscribing to an upgrade to compensate for a silent checkout. If your site does not send the category of the product viewed, no unification layer will manufacture it. The work is in the checkout flow.

Ingesting everything available. A property that feeds no segment and no scenario is a dead property. It costs maintenance and blurs the reading.

Counting on the CDP to settle conflicts with no rule. When two sources give two different shipping addresses, you need a written priority rule. The platform applies what you decide, it does not decide for you.

Installing it before settling retention. Unifying means concentrating, in a single profile, data from systems whose retention periods differ. A field an ERP purges at the end of its own cycle can survive indefinitely in the marketing profile if nobody planned for it. The CNIL points out that the retention period is set by the controller according to the purpose that led to collection, not left open-ended. The purge rule gets decided before ingestion, not after the first audit.

Subscribing to Advanced KDP on a single-store brand. One sales channel, a simple catalogue, a clean Shopify integration: the account already gives you the unification you need, see is Klaviyo a CRM. The money is better spent on the missing scenarios.

How to sequence it

1. List the scenarios you cannot build today. It is the only acceptable justification for a data project.
2. Trace each scenario back to the missing data, and the data back to the system that holds it.
3. Decide the identity key, the Klaviyo external ID, and have every source push it, till included.
4. Write the priority rules between contradictory sources.
5. Check cleanliness before ingestion, not after: the point is covered in email list hygiene.
6. Measure on the scenarios, not on the number of unified profiles. The only result that counts is flow revenue that did not exist before.

What it changes in reporting

A unified base moves two indicators in our framework. Revenue attributed to email has room to rise, since scenarios fire on complete people rather than on fragments of people. Revenue per recipient follows the same movement, once you stop sending three messages to somebody who expected one.

Conversely, unification often lowers the number of profiles displayed. That is normal, and it is good news: your base stops counting duplicates as distinct customers, and your rates become readable again. The reading benchmarks for these two indicators are detailed in lifecycle email KPIs.

The upstream framing, the data you own outright, is covered in ecommerce first-party data. If you want a team to carry this project, our CRM agency page describes how we run it, and you can review your email and CRM stack with Deliver.

FAQ

Is Klaviyo already a CDP without Advanced KDP?

Partly: an account connected to Shopify brings data in through the integrations and APIs, already unifies profiles and lets you segment on them. Advanced KDP adds profile matching that the native merge does not perform.

What does a CDP actually add in ecommerce?

Reconciling identities across the online store, the till, customer service and the app. Without it, one person exists as several profiles.

Do you need a unique identifier for it to work?

Not as a prerequisite: matching happens on the identifiers your systems have already pushed into the profile. But pushing the same external ID from every source remains the safest way to make that matching predictable.

Does a CDP repair dirty data?

No. It makes it visible faster. The work stays in the source systems.

When is Advanced KDP pointless?

On a single-store brand with one sales channel and a clean integration: the account already unifies what there is to unify.