Most CMOs have lived through at least one Single Customer View initiative that ran for years and never produced a customer view anyone trusted. The board paper that approved it talked about a 360 degree picture, a unified profile, and a single source of truth. Forty-eight months later there were seventeen sources of truth, three of them daily-refreshed Excel exports, and a steering committee that met monthly to discuss why the numbers in slide six did not reconcile with the numbers in slide nine.
This is not a story about incompetent teams. The teams who run these projects are usually senior, capable, and well-intentioned. The pattern is structural. Single Customer View projects fail for four predictable reasons, and the failure modes are independent enough that a project can be doing fine on three of them and still die.
The teams that ship a Single Customer View treat each of the four failure modes as an engineering problem with an engineering answer. Not a workshop. Not a maturity model. An answer that holds up when a query runs against it.
The project that has been in progress for years
The familiar shape: a steering committee, a 90-page requirements document, a vendor selection workshop, a six-month PoC, a phased rollout plan, a “first phase” that ships eighteen months in and produces a profile table no downstream team uses because it does not contain their fields.
Months later the project has acquired its own gravity. It has a programme manager whose entire role depends on it continuing. It has a vendor relationship with renewal terms tied to milestones the vendor wrote. It has a stakeholder list of forty-two names, each of whom can veto changes but none of whom can sign off on completion. The original sponsor has left or been promoted. The new sponsor is being briefed on a project whose original justification no longer applies.
Meanwhile the campaign team has built a parallel customer table in their email platform, the loyalty team has built another in their CRM, and the data team has built a third in the warehouse to serve finance. None of them match. The Single Customer View project is now competing with three working alternatives, and the working alternatives have the advantage of actually existing.
The exit from this state is not “more governance” or “another workshop”. It is a smaller, sharper definition of done, and a willingness to ship something narrow before something broad.
Why these projects fail (four patterns)
The first pattern is scope creep. A Single Customer View starts as a unified identity and a small number of facts: who this person is, what their consent state is, what they have done with the brand in the last 24 months. By month six it has acquired predicted lifetime value, propensity scores, next-best-action recommendations, and a real-time API. Each addition is individually defensible. Together they push the ship date past the patience of the business.
The second pattern is identity resolution treated as a tooling decision rather than an engineering problem. The team buys an identity graph product on the assumption that the product will resolve the identities. The product does what it can with the inputs it is given. The inputs are inconsistent: some systems hash emails, some store them in plain text, some store both for the same record, some are missing email entirely and rely on phone number, and a small but persistent share are records created by store staff who used their own details to test the POS terminal in 2019. No product solves this without the source systems being fixed, and the source systems are owned by teams who have no incentive to fix them for someone else’s project.
The third pattern is ownership ambiguity. The Single Customer View needs a single owner with the authority to say what the model is and is not. In most large organisations the answer is “marketing owns the use case, IT owns the platform, data owns the schema, and legal owns the consent rules”. That is four owners, which is no owner. Decisions get made by whichever group shows up to the meeting that week, and the decisions reverse the following week when a different group shows up.
The fourth pattern is governance bolted on at the end. Consent rules, retention policies, lawful basis tagging, and audit trails get treated as a compliance review at the end of the build rather than columns in the schema from day one. When the legal team eventually looks at the output, they find that the consent state cannot be reconstructed for half the records, the retention timer has nothing to count from, and the lawful basis for the largest activation segment is “we assumed implied consent because they bought something once in 2020”. The project then enters a remediation phase that takes longer than the original build.
What shipping actually means
Shipping a Single Customer View does not mean a final state. Data will shift over time, and is never truly complete, so a golden record isn’t the destination.
Shipping it means a thin, useful, correct version that two or three downstream teams are actively using. The fields are few. The identity resolution rules are documented and conservative. The consent state is current. The data is fresh enough to act on. The warehouse model is in production, version-controlled, and tested.
A useful threshold: an analyst can answer the five questions from Part 1 of this series using a single SQL query against a single model, and the answer reconciles to within one percent of the finance numbers without manual adjustment. That is the test. If the answer requires three joins across three systems and a spreadsheet, the project has not shipped. If the reconciliation gap is fifteen percent, the project has not shipped.
The teams that get there tend to invert the usual order. They start with one activation, say a single high-value retention campaign, and work backwards to the minimum viable identity, consent, and event model that campaign needs. They put that model into production. They prove that the model produces the right list, that the consent state is correct, that the suppression rules fire, and that the result reconciles to revenue. Then they add the next campaign and extend the model only where the new campaign requires it.
This approach offends the architecture instinct, which wants the model to be complete before anything depends on it. The architecture instinct produces the months long project that may never ship. The thin-slice approach produces something useful in weeks and something genuinely powerful in months.
Consent and lawful basis as part of the schema, not a layer on top
The most common cause of late-stage Single Customer View remediation is consent, not identity. Identity errors produce wrong segments. Consent errors produce regulatory exposure. The two are not the same risk level.
The fix is structural. Lawful basis is a column on the relationship between a person and a brand, not a flag in a separate consent platform that gets queried at activation time. Retention windows are timers attached to specific facts, not policies sitting in a Confluence page. Right-to-erasure is a cascade that propagates through the model, not a quarterly manual cleanup job. Source of consent is captured at the moment consent is given, not inferred later from the system the record happened to be created in.
The shape of this is engineering work, not a governance committee. Sakura’s view on engineered compliance, developed across regulated-industry engagements and formalised in the Praxis offering, is that consent should be machine-readable, queryable, and joinable to every downstream decision the marketing team makes. If a campaign brief asks for “all customers who opted in to product updates in the last 18 months and have not exercised right-to-object”, that should be one SQL clause, not a three-day exercise involving the privacy team.
Teams that build consent into the schema from the start ship faster, audit faster, and respond to regulator questions in hours rather than weeks. Teams that bolt it on at the end discover, usually under time pressure, that their largest activation segment cannot be defended.
The Single Customer View that ships is the one with fewer fields, one owner, conservative identity rules, and consent built into the schema; building that is the kind of substrate work Sakura’s Data & AI practice does under the covers, once the steering committee has decided what good looks like.
Data is a journey, not a destination.