CDPs, ESPs and the customer record nobody owns

Here is the conversation that leads to a CDP evaluation. Marketing cannot segment on lifetime value because the email platform only knows what the app synced. Support cannot see a customer’s subscription because that lives in another tool. Finance has a different count of customers than the store does. Somebody suggests a single view of the customer, and a procurement process begins.

None of those four symptoms is a storage problem. They are all the same problem: four systems each hold a partial customer record, none is designated as authoritative, and the fields they join on do not agree. Buy a CDP and you have five systems, one of which is now authoritative by assumption rather than by decision — and it derives everything it knows from the four that disagreed.

That is not an argument against CDPs. It is an argument for doing the cheap part first, because the cheap part is also the hard part, and no product does it for you.

Almost every "single customer view" project fails on the join, and the join is almost always email.

Email is a poor identifier for a commerce business. A guest checkout produces an order with no customer account. A customer who buys with a work address and then a personal one is two people to your stack. Two people in a household sharing an address are one person. Someone changes email provider and becomes a new customer with no history, which is how a loyal buyer ends up in a win-back flow.

Shopify gives you a tool for the specific case of duplicate customer records: the customerMerge mutation. Two things to know before using it at volume. It does not guarantee which of the two records survives — the documented priority runs through an explicit override field, then which record has an email, then account state and marketing consent — so use customerMergePreview and read resultingCustomerId before you commit. And it returns a job rather than a result, because it is asynchronous, with no documented rollback. Merges are one-way. Write the audit trail yourself before you run a batch of them.

The useful discipline, CDP or not, is to define your identity key deliberately and write it down: normalised email as the primary, with a documented rule for guest orders and a documented rule for what you do when a customer tells you two addresses belong to them. A CDP will ask you for exactly this configuration on day one, which is worth knowing in advance — you can do the work without buying the tool, and you cannot buy the tool instead of doing the work.

The part of this that is a legal exposure rather than a marketing inconvenience: consent has to travel with the profile, and in a multi-system stack it usually does not.

On the storefront, Shopify’s Customer Privacy API defines four consent purposes — preferences, analytics, marketing, and sale of data — and provides checks for each before you process anything. Its guidance is unambiguous on the point teams get wrong: consent should only be recorded from a visitor interaction such as accepting or declining a banner, and never set automatically on the visitor’s behalf. Any pixel or tag that decides for itself that consent exists is a compliance problem regardless of how the data is later stored.

For marketing state, Shopify holds email and SMS marketing consent on the customer record. If your email platform holds its own subscription state and the two drift, you will eventually send to someone who unsubscribed in the other system. That is not a hypothetical failure — it is the normal end state of a two-way sync nobody reconciles.

Deletion is the test of whether you have a coherent architecture. When a customer asks to be erased, you must be able to name every system holding their data and remove it from all of them. Shopify enforces this on App Store apps: they must implement the customers/data_request, customers/redact and shop/redact topics, complete the action within 30 days unless legally required to retain the data, and do so whether or not the app collects personal data at all — with shop/redact arriving 48 hours after uninstall. A bespoke integration you built yourself carries the same obligation with no reviewer to check it, which makes it the place this quietly goes wrong.

Adding a CDP adds a copy of every profile. If your deletion process is a person remembering to check four dashboards, make it five before you sign.

This is the option nobody presents at an evaluation, so here it is. Shopify holds orders, customers, consent state and customer segments. A competent email platform holds engagement and runs flows off Shopify events. Between them you can build the segments that produce nearly all of the revenue attributed to "customer data" work: first-time versus repeat, high value, lapsing on the interval that matches your product’s repurchase cycle, bought category A and not category B, abandoned checkout, subscribed and never purchased.

If nobody at your company can currently build those six segments, buying a CDP will not be the thing that fixes it. The constraint is that the sync between the two systems is incomplete or that nobody owns segmentation — and both are cheaper to fix directly.

We would put the honest threshold roughly here: one storefront, one email platform, one helpdesk, fewer than a handful of tools reading customer data, and a team without a dedicated data person. Below that line, get the Shopify-to-ESP integration right and stop. It is less impressive and it is the correct answer.

If you do one thing after reading this, do this instead of a vendor demo. Write a single page that names, for every system holding customer data: what it holds, what identifies a customer in it, which direction data flows, and who is accountable for it being right. Most teams cannot complete that page, and the gaps in it are the actual project.

Then pick the authoritative system for each domain — Shopify for transactional truth, one system for consent, one system for identity — and make every other system a consumer of it rather than a peer. Reconcile on a schedule: counts of customers, counts of subscribed contacts, counts of records changed since the last sync. Discrepancies found by a job are cheap; discrepancies found by a customer receiving mail they unsubscribed from are not.

Do that and one of two things happens. Either the problem is solved and you have not bought anything, or the page you wrote is now the requirements document for a CDP evaluation that will go considerably better than it would have last month.

• Integrations and custom apps
• ERP integration
• Loyalty and retention