We Built a CDP in 6 Weeks for a Client Doing $2M/Year

A head of growth called us last September. "We need a CDP. Segment or mParticle. Something enterprise." They'd just raised their Series A and were scaling fast. Stack was Shopify, Klaviyo, Facebook/Google ads, a Snowflake warehouse their data team had just set up, and Google Sheets for "the single customer view."

Marketing couldn't segment customers by lifetime value. Email campaigns were blasting everyone because they couldn't identify repeat buyers vs. one-time purchasers. The ad teams were retargeting customers who'd already bought. And the data team was spending 15 hours/week pulling CSVs for other teams.

We asked: what do you actually need to do that you can't do today?

Turns out, four things:

1. See a unified customer profile (purchases, emails opened, ads clicked)
2. Build segments for marketing (high-LTV, at-risk, new customers)
3. Send those segments to ad platforms for better targeting
4. Stop manually pulling CSVs

That doesn't require a $50k/year CDP license. It requires clean data, identity resolution, and reverse ETL. We proposed building it in their existing warehouse instead of buying another tool.

Week 1: Event Instrumentation

They were already using Shopify's native tracking, but it was incomplete. We added custom pixel events for product interactions (view, add to cart, wishlist), server-side purchase events (more reliable than client-side), email engagement events from Klaviyo webhooks, and ad click IDs captured at landing and passed through to purchase.

The key decision was server-side for purchases. Shopify's client-side pixel misses 18% of purchases due to ad blockers, iOS restrictions, and page abandonment. Server-side captures 100% from the order confirmation.

Week 2: Identity Resolution

This is where most "CDP" projects fail. This client had customers with Shopify account email, Klaviyo subscription email (sometimes different), PayPal email (often different), guest checkout emails (never linked to account), and multiple device cookies.

We built a simple identity graph in the warehouse:

• Same email = same person. Same phone = same person.
• If a Shopify customer ID exists, that's the master. Otherwise, use the most recent verified email.
• For name/address, take the most recent. For LTV, sum across all records.

The graph wasn't perfect. We estimated 12% of profiles had some uncertainty (work vs. personal email, shared devices, etc.). But it was good enough for marketing segmentation, which was the actual goal.

Week 3: Customer 360 Model

We built a dbt model that created one row per customer. Total orders, total revenue, first and last order dates, days since last order, first and last touch channels, email opens and clicks in the last 30 days, and computed segments (VIP, At Risk, New, Regular).

This model refreshed every 4 hours. Marketing could query it directly, or we could send it to destinations.

Week 4: Reverse ETL

We used Hightouch (already in their stack) to sync segments to Facebook Custom Audiences (VIP customers for lookalike targeting), Google Customer Match (at-risk customers for retention campaigns), Klaviyo lists (new customer welcome series), and Slack (daily VIP order alerts for the customer success team).

The first sync sent 8,400 records to Facebook. The custom audience was ready in 20 minutes. The lookalike campaign launched the same day.

Week 5: Activation

Marketing launched three campaigns using the new segments:

1. VIP lookalike: Target prospects similar to high-LTV customers. Result: 4.2x ROAS vs. 1.8x for broad targeting.
2. At-risk winback: Email + ad campaign for customers 90+ days inactive. Result: $47K revenue recovered in 30 days.
3. New customer nurture: Suppress recent purchasers from acquisition ads, send them educational content instead. Result: 23% lower CAC for new customer campaigns.

Week 6: Documentation and Handoff

We documented the identity resolution logic (so future data hires understand it), the event schema (so new events can be added consistently), the segment definitions (so marketing knows what "At Risk" actually means), and the data quality checks (so they know when something breaks).

What Worked

Starting with the use case, not the tool. If we'd implemented Segment, we'd have spent weeks configuring connectors and still wouldn't have solved the identity resolution problem. The warehouse approach gave us full control.

Server-side first. The client-side tracking we added in Week 1 was mostly supplementary. The core data (purchases, emails, ad clicks) came from server-side sources. This made the data more complete and more privacy-resilient.

Simple identity resolution. We didn't build probabilistic matching or ML-based clustering. We matched on email and phone. It was good enough for 88% of customers. The remaining 12% were handled with conservative rules (don't merge if uncertain).

Reverse ETL on day 1. The data is useless if it doesn't leave the warehouse. We set up the syncs before the models were perfect, then iterated.

What Didn't

Guest checkout was harder than expected. 34% of orders were guest checkout. Linking these to returning customers required matching on email + shipping address, which was messy. We ended up creating "probabilistic" profiles that needed manual review.

Klaviyo data was incomplete. Their webhook events missed some email opens (image pixel blocking). We supplemented with Klaviyo's API, but this added latency. The email engagement metrics were directionally correct but not exact.

The data team was skeptical. They'd been burned by "quick fixes" before. It took until Week 3 (when they could query the customer 360 model) for them to buy in. Next time, we'd involve them in the architecture decisions on day 1.

The Results

Bottom Line

This client didn't need a CDP. They needed clean data, identity resolution, and a way to get segments to their marketing tools. We built that in 6 weeks for 120 hours of consulting time — less than one year of a Segment license.

The "CDP" is now just their warehouse + dbt + Hightouch. It scales with their data team. They own the logic. They can add new sources and destinations without vendor approval.

If you're considering a CDP, ask what you're actually trying to do. The answer might be simpler than the sales demo suggests.