Practice Area

Composable martech and customer data platforms

Douglas Cirillo builds and runs composable martech and customer data platforms at audience brands. His definition of a customer data platform is the one he published in 2025: “The system that creates and activates real-time customer profiles across channels.” He has built that pattern in-house at Sotheby’s, Lindblad Expeditions, and A Place for Mom, and for A+E Networks while at Gangverk, in both of its modern architectures: packaged platforms like Twilio Segment, and warehouse-native activation with Hightouch running on Snowflake.

What is composable martech?

Composable martech is a stack built from best-of-breed tools, each chosen for one job and connected through defined interfaces, instead of a single vendor suite. The content platform, the data platform, the decisioning tools, and the analytics layer are separate components with clean contracts between them: documented schemas, stable interfaces, clear ownership. When one component stops earning its place, you can replace that component without rebuilding the whole stack, and you do not wait for a suite vendor’s roadmap to catch up with your business.

What does a customer data platform actually do?

A CDP collects customer data from the systems that touch the customer, resolves it into unified profiles, and activates those profiles back into the tools that run the experience: the site, the app, email, ads, and the CRM. The baseline work is unglamorous: event collection, identity resolution, schema governance, audience building, and syncs you can verify. Everything else is window dressing.

It comes in two architectures. In a packaged CDP, the platform holds the profile: managed pipelines, governance tooling, and, with the right products configured, identity resolution and activation. Segment is the common example, and it usually suits a team without deep data engineering. In a warehouse-native setup, the warehouse is the system of record and an activation layer like Hightouch syncs modeled audiences back out, on the warehouse’s cadence rather than in real time. That is the right answer when the warehouse and the data team are already strong. I have run both, and the choice is not ideological. It depends on where your source of truth lives and how fast you need value.

I wrote the longer version of this argument in What a Customer Data Platform Actually Is (and Isn’t). This page is the evidence underneath it.

How I build it

The principles stay consistent. The sequence depends on the business and the maturity of its data. Start with the use case, not the tool. My default sequence is the one I still use: data foundation first, then the experience on top of it. Stand up governance, instrumentation, and enablement as the operating work, because the platform fails at the seams between teams, not inside the software. You can’t activate what you don’t trust, and you can’t implement your way out of misalignment.

And treat the CDP as a product, not a project. It gets an owner, a roadmap, and schema discipline that does not bend for one campaign. Projects end. Products get measured against outcomes, and they are still standing when the team that launched them has moved on.

Where I have run it

Sotheby’s. I directed the implementation of Twilio Segment as Sotheby’s customer data platform, connecting customer interaction data to the BigQuery warehouse the team called Alpine. At scale, Segment was configured across 23 systems, with about 400 million API calls a month. The results from that tenure: organic traffic up 167%, search click-through up 48.7%, consignment ad spend cut in half. The model and the stack still stand and have evolved since I left. Read the case study.

A+E Networks. From Gangverk, I directed the complete redesign and replatform of History.com on a composable architecture: Contentful for content, Cloudinary for media, Vercel for delivery, Algolia for on-site search, and Hightouch activating customer data out of the Snowflake warehouse A+E already ran, with Amplitude as the measurement layer. That is the warehouse-first pattern in production, not on a slide. History.com relaunched in four months, and A+E adopted the architecture as its migration standard. Read the case study.

Lindblad Expeditions. We didn’t have a full-fledged data engineering team. But we needed to unify how product, marketing, and editorial understood behavior across web, email, mobile, and OTT. Segment let us establish shared schema, normalize identity, and activate audiences across tools, without months of delay. It created alignment, not just data. I led a 10-person team and a $5M portfolio there, and within about eight months bookings rose 30%, booking funnel completion rose 82%, and qualified leads rose 40%. Read the case study.

A Place for Mom. Search was the growth engine at A Place for Mom, and it was losing share. I diagnosed the decline as a platform and governance problem and led the rebuild: WordPress for content management, Segment for customer data, Databricks for the data foundation, Conductor for organic search intelligence, Algolia for on-site search and recommendations, Optimizely for experimentation, and Amplitude for analytics. SEO market share rose from 26% to 68%, and the model and the stack still stand. Read the case study.

At Gangverk, the practice scaled beyond my own builds. Consulting work included a Segment-sponsored engagement with TripAdvisor on customer data platform adoption. The firm’s client base grew from 1 to more than 60 while I carried revenue targets and hiring authority.

The point

Every one of these stacks was built with the people who would run it after launch. At Sotheby’s and A Place for Mom, the model and the stack still stand and have evolved. At A+E, the architecture became the company’s migration standard. At Lindblad, the rebuilt expeditions.com was named a Webby Honoree.