Warehouse-first CDP build: Segment, RudderStack, Hightouch

The CDP rebuilds I take over usually carry 300 to 600 event names in the schema, and fewer than 60 of them are read by any audience, model or report. So this engagement opens by deleting. What survives is the set of events with a named downstream consumer and a named human owner, and that set is what gets instrumented properly, versioned in your repository, and enforced at the point of collection. What gets built: A working path from tracking plan to first production audience, on Segment Connections with Protocols, on RudderStack, or on a warehouse-native collection layer feeding your own storage, with Hightouch or Census handling activation back out. There is no vendor I steer every client toward. The choice falls out of three answers: whether your mobile team will accept an SDK change inside their release train, whether your legal function will accept a US-hosted collection endpoint, and whether dbt is already in the building. The order of work: Consumers first. Before an event is defined I write down the audiences, reports and lifecycle triggers this stack exists to serve, and the name of the person who signs off on each. Anything absent from that list does not get instrumented. Then the schema, as a YAML tracking plan in your repository that fails a build when violated. Then collection, then identity stitching, then activation. Six to nine weeks for the standard scope, and the variable is your source systems. Consent as a column: In publishing and in insurance the field that decides everything is not the event, it is the lawful basis recorded beside it. Every profile carries per-purpose consent state and its timestamp as first-class columns, read from your CMP through its API, and every activation reads those columns before it sends a row. If your CMP cannot expose per-purpose state programmatically, that gets fixed before the CDP work starts, and you hear it from me in the first week rather than the last. One publishing detail worth stating: Registered-but-unpaying, metered-anonymous and subscribed are three different profile shapes, and most implementations flatten them into one customer table. Keeping them apart is what makes propensity and churn modelling possible a year later. The equivalent split in insurance is policyholder, insured party and household. Not included: SDK implementation inside your app release cycle. I write the spec and review the pull request, your engineers ship it. Tag manager cleanup as a standalone project. CMP selection or replacement. Marketing automation migration. Custom destination development beyond a single connector. Running the stack after handover, which is a separate arrangement. This is the wrong engagement if: A campaign date is fixed and you need the stack live in three weeks. You expect a CDP to produce data your source systems do not emit; it moves data, it does not create it. Your billing system and your CRM disagree about who a customer is and nobody has the authority to settle it, which is an organisational dispute and it will consume this project whatever the tooling. Or you want everything tracked on the reasoning that storage is cheap. Storage is cheap, trust is not, and a schema nobody trusts gets routed around inside two quarters. I have been hired twice to rebuild exactly that outcome. Handover: The repository, the tracking plan, the dbt models, destination configuration as code, a runbook for schema changes, and two working sessions with whoever owns it next. The test I hold this work to is whether your analyst can add an event next month without contacting me.