# Martech Therapy: CDP strategy and agentic AI
> Martech strategy, CDPs and agentic AI, from twenty years of building and fixing Martech stacks. Plus the Couch Confidentials podcast.
Public Ghost content for AI and LLM tooling. This file includes a bounded export of public pages first, then recent public posts.
Append `.md` to any post or page URL to get the content in Markdown (for example, `/example-post.md`).
## Pages
### This is me
URL: https://www.martechtherapy.com/about/
Last updated: 2026-07-25T16:40:31.000Z
Hi, I'm Matthew, founder of Martech Therapy, the no-nonsense place to fix what's broken in your marketing technology stack.
I'm a solo consultant with over two decades of experience helping companies get real value out of their [Customer Data Platforms](https://www.martechtherapy.com/tag/customer-data-platform/) and the rest of their Martech stack. I cut through the noise and give pragmatic advice that survives contact with reality, whether you're a pre-scale-up trying to get it right the first time or an enterprise dragging a legacy stack into the present.
I've worked globally with clients in retail, telco, publishing, and financial services, building data strategies that put the customer first and the tech second, where it belongs.
If you've ever wondered why your stack is so slow, expensive, or underused, how to avoid another failed CDP implementation, or whether it's too late to move to a first-party data strategy, then you're in the right place.
## How to work with me
I work under two roofs, and which one you need depends on where you're stuck.
Martech Therapy, this blog, is the advisory side: strategy, second opinions, CDP and Martech stack assessments, and the kind of honest read on your situation that's hard to get from anyone selling you software. This is where most engagements start, often with someone who suspects their stack is the problem but can't yet name which part.
Martech Foundry ([martechfoundry.com](https://martechfoundry.com/?ref=martechtherapy.com)) is the build side. When the diagnosis is done and something actually needs to get made, Foundry handles delivery: agentic AI, server-side tagging, identity work, and the precision apps that close the gap between what a vendor promised and what your stack does on a Tuesday.
If any of that sounds like your situation, the fastest way forward is a short call. [Book a time here](https://booking.akiflow.com/martechtherapy30?ref=martechtherapy.com) and tell me what's broken. No pitch deck, no discovery-call theatre, just a straight conversation about whether I can help.
Do you have any questions or need support with your Martech projects?
[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
## What you'll find here
This is where I write about Martech without the vendor gloss.
You'll find my long-running series on the rise, fall, and reboot of the CDP category, starting with [The CDP Reboot](https://www.martechtherapy.com/the-cdp-reboot-the-promise/). There's the six-part [Contextual CDPs](https://www.martechtherapy.com/tag/contextual-cdp/) series on AI, memory, and what customer state has to do once agents start acting on it. There's [The CDP RFP Dating Game](https://www.martechtherapy.com/the-cdp-rfp-dating-game/) on buying without getting burned, and [a three-part look at why the Magic Quadrant no longer reflects CDP reality](https://www.martechtherapy.com/is-it-all-a-magical-illusion/).
[Beyond the Gartner Magic QuadrantAI, peer reviews, and analyst reports all shape Martech buying. Here’s why evidence packs matter more than a single Gartner Magic Quadrant.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/beyond-the-gartner-magic-quadrant/)
Alongside the writing, I build free tools worth a few minutes of your time: a [stack decay scan](https://secondlaw.martechtherapy.com/?ref=martechtherapy.com), a [Martech stack builder](https://www.martechstackbuilder.com/?ref=martechtherapy.com), a [CDP simulator](https://cdpsimulator.martechtherapy.com/?ref=martechtherapy.com), and a [mock customer data generator](https://mockcdp.martechtherapy.com/?ref=martechtherapy.com) for testing your CDP and CEP without touching real data.
[Martech Stack Builder — Plan, Evaluate & Govern Your StackMap your vendor landscape, run AI-powered evaluations, manage procurement, and track costs — on one canvas. The planning tool for martech architects.Martech Stack BuilderMartech Stack Builder](https://www.martechstackbuilder.com/?ref=martechtherapy.com)
And if you want to learn rather than hire, there's my workshop.
[Martech Therapy — A 90-minute workshop for Martech decisionsA structured working session for teams overwhelmed by Martech. Remote, 90 minutes, one concrete next step.Martech Therapy WorkshopMartech Therapy](https://workshop.martechtherapy.com/?ref=martechtherapy.com)
## A bit more personal
I live in Delft, the Netherlands, with my wife, our four kids, and the dog. I love Star Wars, The Expanse, and a good customer data platform rant.
I'm endlessly curious about systems, whether it's a Martech stack or some piece of technology that didn't exist last year.
## Connect with me
Follow along wherever you spend your time:
- [LinkedIn](https://www.linkedin.com/in/matthewniederberger?ref=martechtherapy.com) for weekly insights and updates
- [YouTube](https://www.youtube.com/@martechtherapy?ref=martechtherapy.com) for short videos from the Martech frontlines
If you like what you're reading, subscribe to the free newsletter or drop me a message. I read everything.
### Tags
URL: https://www.martechtherapy.com/tags/
Last updated: 2026-07-25T16:40:31.000Z
_No content available._
### The cost of staying current
URL: https://www.martechtherapy.com/feature-release-calculator/
Last updated: 2026-07-08T19:52:30.000Z
A 20\-tool stack ships about 150 releases a quarter. Keeping one person current runs roughly 38 hours every quarter, near enough a full working week, four times a year.
Tools in your stack20
Releases worth tracking, per tool, each quarter7.5
People who need to stay current8
**tools** × **releases per tool** × **minutes per release** \= time to keep up. Everything below falls out of that one line.
150
releases hitting the stack **each quarter**
38
hours per person, per quarter, **just to keep up**
3.8
working weeks a year, **per person**
30
working weeks a year **across the team**
### What a year of that effort actually buys
600 shipped · \~90 adopted
adopted into someone's workflow read, judged, waved past
Of the **600** releases that cross your stack this year, roughly **90** earn a place in a workflow. The rest still had to be triaged. That filtering is the tax nobody budgets for.
▸ Assumptions — adjust if you want to push on them
Minutes to triage one release15
Share of releases actually adopted15%
Illustrative model. The three sliders are yours to set; the two assumptions are research-anchored starting points.
Grounded in published figures: Salesforce ships three seasonal releases a year, each with hundreds of features, plus monthly and weekly updates; HubSpot posts dozens of changes monthly; average B2B stacks run 12–20 tools (enterprise nearer 90); Pendo found \~80% of features are rarely or never used, so \~15% adoption is generous. Fifteen minutes per release is the blended average of a few high-touch evaluations and many quick glances.
### Free Context Audit Worksheet
URL: https://www.martechtherapy.com/context-audit-worksheet/
Last updated: 2026-08-23T07:29:54.000Z
I keep getting asked for the audit as something you can print, so here it is.
One page, blank, free, no form to fill in first.
It scores one thing: whether the context a live workflow depends on is actually usable at the moment the workflow needs it. Not what your architecture diagram says you bought.
What a running decision can reach.
## What it scores
Four properties, scored zero to two.
1. **Queryable** asks whether the workflow can get the right question answered fast enough to act on.
2. **Addressable** is about identifiers, and whether the answer comes back against the one the rest of your system uses.
3. **Current** means the freshness matches the decision, which is a different bar for a churn score than for a cart trigger.
4. **Accountable** is the awkward one. Can you reconstruct afterwards what the workflow actually saw when it acted?
I set those out in [what the context layer actually has to do](https://www.martechtherapy.com/what-does-the-context-layer-actually-have-to-do/), and turned them into this scoring method in [the context audit](https://www.martechtherapy.com/the-context-audit/), which has a worked example if you want to see one filled in before you start.
**Eight** points possible.
**Six** is functional.
**Four** is a sign there is real work to do.
And score three workflows rather than one. As I said in June, one score tells you about one workflow, and three start to show you a pattern.
## The third block, and why it isn't scored
The bottom section asks something the four properties do not. Not whether the context arrives, but which version wins when two systems both hold the same fact and disagree about it.
That one refuses to sit in the same table.
It belongs to a fact rather than a workflow, it doesn't change between workflows, and there is no version of it that scores cleanly zero to two. So it sits underneath as its own short grid, one row per fact, with room for the system it comes from, whoever decided that, and the date you checked. A provisional answer with a date on it counts. Waiting for someone with the authority to declare a winner mostly means writing nothing at all.
I worked through why in "[Which context wins when two systems disagree about your customer?](https://www.martechtherapy.com/which-context-wins-when-two-systems-disagree-about-your-customer/)".
## Download it!
[Free Context Audit WorksheetDownload the worksheet for free today.context-audit-worksheet.pdf78 KBdownload-circle](https://www.martechtherapy.com/content/files/2026/08/context-audit-worksheet-1.pdf "Download")
Look, it is a piece of paper with boxes on it. Print it, or work through it on screen if you prefer. If you want to formalize what comes out of it, freshness commitments and named owners are exactly what a data contract is for, and the [Open Data Contract Standard](https://bitol-io.github.io/open-data-contract-standard/?ref=martechtherapy.com) is a reasonable place to start.
Martech Therapy also runs this with teams as a half-day working session, three workflows and the people who own them in one room. If it is useful, [get in touch](https://www.martechtherapy.com/contact/).
Do you have any questions after reading this page?
Or need support with your Martech projects?
[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
### Privacy
URL: https://www.martechtherapy.com/privacy/
Last updated: 2026-08-21T19:35:29.000Z
Last updated: August 21, 2026
This explains what happens to personal data when you use martechtherapy.com, the tools published alongside it, or the LinkedIn application described below. It is written to be read rather than to be survived, so if something here is unclear, ask me and I will fix the wording.
## Who is responsible
Martech Therapy, single practicioner, e.g. registered in the Netherlands under Chamber of Commerce number 62437542, at Van Tijenstraat 44, Delft, Netherlands, is the data controller for everything described here.
Contact: privacy@tagticians.com
I run this myself. There is no support desk, and mail to that address reaches me directly.
## What this covers
- martechtherapy.com
- secondlaw.martechtherapy.com (Entropy Scan)
- cdpsimulator.martechtherapy.com (CDP Simulator)
- workshop.martechtherapy.com (Martech Workshop)
- martechfoundry.com
- The LinkedIn application described under "The LinkedIn application" below
## When you read something
The site runs on Ghost. Loading a page creates a server log entry containing your IP address, the page requested, the time, and your browser's user agent. Those logs exist so the site can be kept running and abuse can be investigated. They are held for 14 months and are not used to build a profile of you.
Analytics are collected through Posthog to count page views and see which articles get read. Cookie-based. This tells me what to write more of. It does not tell me who you are.
## When you subscribe
Subscribing to the newsletter stores your email address, the date you subscribed, and which emails you opened or clicked. That last part is how I judge whether an issue was worth sending. Email is delivered through Ghost, Google, and PostmarkApp.
Every email carries an unsubscribe link, and using it removes you immediately. You do not need to email me first, and I do not ask why.
## When you use one of the diagnostics
The Entropy Scan, the CDP Simulator and the Workshop tools ask you questions and give you a result. Your answers are stored so the result can be produced and, if you asked for it by email, sent to you.
Answers are used in aggregate to improve the diagnostics themselves, for example to see which questions confuse people. Aggregate means counts across everyone who has taken it, with no way back to an individual. Your individual responses are not published, sold, or shared, and they are not shown to any client of mine.
If you gave an email address to receive your result, that address is stored with your responses. If you did not, the responses are not linked to an identity.
## The LinkedIn application
I operate an application that uses LinkedIn's Member Data Portability API, made available by LinkedIn under the EU Digital Markets Act. It exists for one purpose: to help a writer check new drafts against their own published writing, so their voice stays consistent.
**It only ever runs on data belonging to the person who authorized it.** There is no route through the application to anyone else's LinkedIn data, and it does not read your connections, your feed, or anyone else's posts.
**What it requests.** Only these categories of your own LinkedIn data:
- Your own posts and reshares, including their text, date and link
- Articles you have authored on LinkedIn
- Comments you have written
The list of categories is fixed in the application's source code rather than configured at runtime, so it cannot request a category outside that list even by mistake. It does not request, receive, or store your messages, your connections, your contacts, your phone numbers, your private notes, your search history, or your advertising data, although the LinkedIn permission would technically permit some of these.
**Why.** Your own writing is measured for style: sentence length, how often you use contractions, how directly you address the reader, which phrases you repeat. Those measurements are compared against new drafts to flag where a draft does not sound like you. Nothing is published, and no content is generated and posted on your behalf.
**Where it is stored.** On infrastructure I control, at corpus.martechtherapy.com, reachable only over HTTPS and only with an access token. It is not stored on a third-party analytics platform, and it is not sent to any advertising network.
**What it is never used for.** Your LinkedIn data is not sold, not shared with third parties, not used for advertising or ad targeting, not used to train machine learning models offered to anyone else, and not used to build a profile of you for any purpose other than the style comparison described above.
**How to stop it.** You can withdraw authorization at any time from LinkedIn, under Settings, then Data privacy, then Permitted services. That immediately ends the application's access. To also have data already retrieved deleted, email privacy@tagticians.com and it will be deleted within 30 days.
**How long it is kept.** Retrieved posts are kept while the authorization stands, because the comparison relies on the full history. If authorization is withdrawn and deletion requested, everything retrieved is deleted. If authorization is withdrawn and nothing is requested, the data is deleted after 14 months.
## Who else processes data
To run any of this, some data passes through service providers who process it on my instructions:
- Ghost Pro for website hosting and newsletter delivery
- Posthog for site analytics
- Hostinger
- LinkedIn, as the source of data in the application described above
Each of these is bound by a processing agreement. I do not sell personal data to anyone, and there is no arrangement under which anyone pays me for access to it.
## Transfers outside the EEA
Some of those providers, LinkedIn, operate outside the European Economic Area. Where that happens, transfers rely on the European Commission's Standard Contractual Clauses or an adequacy decision.
## Your rights
Under the GDPR you can ask me to show you what data I hold about you, correct it, delete it, restrict what I do with it, or send it to you in a portable format. You can object to processing based on legitimate interests, and you can withdraw consent at any time where consent is what permits the processing.
Email privacy@tagticians.com and I will respond within 30 days. There is no charge, and I will not ask you to justify the request.
If you are not satisfied with how I handled it, you can complain to the Autoriteit Persoonsgegevens in the Netherlands.
## Legal basis
Site logs and analytics rest on legitimate interest in keeping the site running and understanding what gets read. The newsletter rests on your consent, given when you subscribed. Diagnostic responses rest on your consent, given when you started the diagnostic. The LinkedIn application rests on your explicit authorization through LinkedIn, which you can withdraw at any time.
## Cookies
Ghost and Posthog sets a session cookie for signed-in members and a cookie to remember newsletter preferences.
## Children
None of this is aimed at anyone under 16, and I do not knowingly collect data from them.
## Changes
If this changes in a way that affects what happens to your data, the date at the top changes and the change is described here. Material changes to the newsletter or the LinkedIn application will be sent to affected people directly rather than left for you to notice.
### What I do
URL: https://www.martechtherapy.com/what-i-do/
Last updated: 2026-09-02T08:20:55.000Z
Your CDP has been live for eleven months, and nobody can quite say what it's for. Two teams built against it. Neither trusts the profiles coming out. The vendor keeps scheduling quarterly adoption reviews, corporate for why isn't anyone using this.
Nobody involved was foolish. Every decision that got you here was reasonable at the time.
> This is the job, most days: telling someone that something they bought for good reasons has stopped paying for itself, while the people who chose it are still at the table.
### What does a Martech consultant actually do?
Depends who you ask, which is part of the problem.
What I do is narrower than most. I come in when there's a decision to make about your Martech stack and the people who have to make it are too close to it, or too invested in a previous answer, or simply don't have three uninterrupted weeks to go and find out. CDP selection. A stack that grew by acquisition and now has three places a customer record can live. An implementation that's been "nearly done" for two quarters.
I'm one person. No team behind me, no bench of juniors, no partner tier I'm steering you toward. That is a real limit and you should factor it in. It also means the person in your kickoff is the person doing the work.
### Do you advise, or do you build?
Both, though not on the same day.
Most of it starts advisory. I look at what you have, talk to the people who use it, and come back with something you can act on. Sometimes that's a selection recommendation. Sometimes it's a note saying the tool is fine and two teams disagree about who owns the customer record, which no software will settle for you.
Where it goes hands-on, it goes properly hands-on: segment implementations, CDP configuration, identity resolution logic, the integration work that vendors describe as one click and that never is. Twenty-two years of this, most of it before there were courses to take.
### How does CDP selection actually go?
Badly, usually, and for a predictable reason. The list gets built from vendor material, so every option sounds like it does everything.
So the first thing I do is take that list away and write down what the thing has to do. Not features. The four or five decisions your business makes about a customer that the system has to support. Then the list comes back and most of it falls off on its own.
If you want to see how your own list holds up before you call anyone, the Martech Stack Builder lets you map it yourself first.
[Martech Stack Builder — Plan, Evaluate & Govern Your StackMap your vendor landscape, run AI-powered evaluations, manage procurement, and track costs — on one canvas. The planning tool for martech architects.Martech Stack BuilderMartech Stack Builder](https://www.martechstackbuilder.com/?ref=martechtherapy.com)
Pricing is where it gets uncomfortable, because the models are not comparable. CDPs mostly charge for the data you hold. Engagement platforms charge for what you send. "Usage" means something different at every vendor, and the number in the proposal is rarely the number in year two. I'll model your real volumes against their real meters (dull work, and the single thing that most reliably saves money).
Honestly, if Gartner or Forrester matter to your board, I can tell you what those reports measure and where the quadrant stops being a useful guide to your situation. I read them. I just don't treat them as a shopping list.
### What does it cost, and how does that work?
Day rate or fixed scope, and I'll tell you which one I think fits before you ask.
Short diagnostic work is a fixed price, because you should know what a second opinion costs before you commit to one. Longer builds run on a day rate. I don't do retainers where the hours go unused. I'd rather scope something small first, so we both find out whether this works before anyone signs for a quarter.
Look, I'll also tell you when you don't need me. That happens more than you'd think. Call it self-interest → a bad fit costs me more in a month than the invoice was ever worth.
### When is it worth calling someone in?
The signal is a decision that's been sitting still.
Maybe you're three months into evaluating CDPs and the list keeps changing shape. Or the stack works, but nobody can explain what it costs per outcome. Or an implementation finished, adoption never came, and the retro has been rescheduled three times now. Those are the ones where a few weeks of outside attention actually moves something.
But if what you need is more hands on a plan you already believe in, hire hands. That is cheaper and it will work better.
### What happens in the first two weeks?
I talk to people. More than you'd expect, and deliberately including the ones who have to live with the system rather than the ones who chose it.
Then you get something short and written. A few pages: what I think is going on, what I'd do about it, and what I'm still unsure about. Genuinely, the things I can't answer after two weeks are usually where the real risk sits, and naming them early is cheaper than finding them in month four.
After that you decide whether there's more work, and plenty of the time there is not. The written brief was the deliverable.
### Who I work with
Scale-ups that bought enterprise tooling slightly before they needed it, or rather before they had the process to run it, and enterprises where the stack has outlived the strategy that justified it. European mostly, remote by default, on site when the conversation genuinely needs a room.
I work in English and Dutch. I've got opinions about vendors and I'll share them, including about the ones I like.
### So, is this you?
If you're somewhere in the middle of a Martech decision, and the middle is where you've been for a while, that's the conversation I'm useful in. Send me what you're looking at. If I'm the wrong person I'll say so, and I'll usually know someone who is.
You can reach me through the contact details on this site, or on LinkedIn, where I'm considerably more talkative 😉
Do you have any questions after reading this page?
Or need support with your Martech projects?
[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
### Talking to Data Engineering
URL: https://www.martechtherapy.com/talking-to-data-engineering/
Last updated: 2026-10-03T12:06:12.000Z
Marketing and data engineering use the same words for different things, and the cost of that shows up six weeks later as a segment refreshing daily instead of hourly.
This is a six-part field guide for closing that gap. Every part is one page you can print and take into a meeting.
## The six guides
**1\.** [**Same word, different meaning**](https://www.martechtherapy.com/helping-marketing-and-data-engineering-same-word-different-meaning/) · Published 14 September 2026
Twenty-four terms both sides use and define differently. [Download the one-page PDF](https://www.martechtherapy.com/content/files/2026/09/talking-to-data-engineering-01-same-word-different-meaning.pdf)
**2\.** [**How to write a data request someone can act on**](https://www.martechtherapy.com/how-to-write-a-data-request-someone-can-act-on/) · Published 24 September 2026
Six questions to read your own draft against, before you send it. [Download the one-page PDF](https://www.martechtherapy.com/content/files/2026/09/talking-to-data-engineering-02-how-to-write-a-data-request.pdf)
**3\.** [**What real time actually costs**](https://www.martechtherapy.com/what-real-time-actually-costs/) · Published 5 October 2026
Five speeds, what each one is for, and the correction window each step gives up. [Download the one-page PDF](https://www.martechtherapy.com/content/files/2026/10/talking-to-data-engineering-03-what-real-time-actually-costs.pdf)
**4\. Same customer, different records** · Week of 6 October
Two ways identity goes wrong, and which mistake each use can afford.
**5\. Who is allowed to say yes** · Week of 13 October
Consent, governance and the approval path that stalls things in week six.
**6\. Writing a goal a system can act on** · Week of 20 October
The four-part goal, and the guardrail everyone leaves out.
## Every term in the series
Every term from every guide, with what each side usually means by it, is collected and searchable in the [glossary](https://www.martechtherapy.com/glossary/).
### Glossary
URL: https://www.martechtherapy.com/glossary/
Last updated: 2026-10-12T18:30:22.000Z
Marketing and data engineering use the same words for different things. This collects every one I have run into, what each side usually means by it, and which guide goes into it properly. Search it, link to a single definition, or send someone the line that settles the argument.
Most of these came out of a six-part field guide sponsored by Databricks. They funded the work and reviewed it for factual accuracy, and had no say over any of the definitions. This page is not sponsored.
Search the glossary
Guide 1Guide 3Hello, I'm human37 terms
### Activation
Copy link
You mean
Launching a campaign, or putting an audience to use.
They mean
Delivering eligible records to a destination with the right identifiers, permissions, freshness and format.
From [Guide 1](https://www.martechtherapy.com/helping-marketing-and-data-engineering-same-word-different-meaning/)
### Agentic
Copy link
You mean
Agents that draft audiences, journeys and briefs inside your CDP or email platform, often with a person approving the launch.
They mean
An AI model that picks its own next step, uses tools, checks the result and repeats until a goal is met.
Needs first
Written goals, agreed tool access, and a decision on which actions need sign-off.
From [Hello, I'm human](https://www.martechtherapy.com/hello-im-human-closing-thoughts-on-2026/)
### AI-native
Copy link
You mean
Used for new products and for older ones with AI added, so the label alone tells you little.
They mean
A product designed around a model from day one. Take the AI out and the product stops making sense.
Needs first
Willingness to change the process along with the software.
From [Hello, I'm human](https://www.martechtherapy.com/hello-im-human-closing-thoughts-on-2026/)
### Audience
Copy link
You mean
Interchangeable with segment.
They mean
Often the exported copy of a segment, the version pushed to the destination, not the logic behind it.
From [Guide 1](https://www.martechtherapy.com/helping-marketing-and-data-engineering-same-word-different-meaning/)
### Batch
Copy link
You mean
The overnight update, or however the data gets refreshed.
They mean
A scheduled job with a window, a rerun path, and somebody who looks at it in the morning before anything downstream consumes it.
From [Guide 3](https://www.martechtherapy.com/what-real-time-actually-costs/)
### Brain
Copy link
You mean
Context brain, marketing brain, company brain, brand brain. Holds brand rules, approved claims, legal limits and what worked. When it "learns", it saves corrections. The AI itself is not retrained.
They mean
A store of documents, rules and past decisions that an AI looks up before it acts. Borrowed from the "second brain" note-taking idea.
Needs first
Someone who curates what goes in and removes what is stale, and reviewers whose reasons get recorded.
From [Hello, I'm human](https://www.martechtherapy.com/hello-im-human-closing-thoughts-on-2026/)
### Computed trait
Copy link
You mean
A useful number on a person, like lifetime value.
They mean
Something recalculated on a schedule, at a cost, for every person, forever.
From [Guide 1](https://www.martechtherapy.com/helping-marketing-and-data-engineering-same-word-different-meaning/)
### Consent
Copy link
You mean
The customer ticked the box.
They mean
A per-purpose permission that must travel downstream and be enforceable at query time.
From [Guide 1](https://www.martechtherapy.com/helping-marketing-and-data-engineering-same-word-different-meaning/)
### Context engineering
Copy link
You mean
Treated as a new discipline and role: getting the right data, content and permissions to each agent at the right moment.
They mean
Deciding everything an AI sees each time it acts: instructions, data, examples, tools and memory. Prompt engineering covered only the instructions.
Needs first
Business rules written down, and data clean and labelled enough to hand to a machine.
From [Hello, I'm human](https://www.martechtherapy.com/hello-im-human-closing-thoughts-on-2026/)
### Context layer
Copy link
You mean
CDPs use it for customer profiles, events and consent served to agents. Others use it for metric definitions and policies.
They mean
No settled meaning. Usually the service that supplies an AI with facts and rules at the moment it acts.
Needs first
One agreed source for each customer fact, with consent attached.
From [Hello, I'm human](https://www.martechtherapy.com/hello-im-human-closing-thoughts-on-2026/)
### Copy
Copy link
You mean
Downloading or exporting the data somewhere.
They mean
Any additional persisted version. Replication, materialised tables, caches, extracts, destination-side storage.
From [Guide 1](https://www.martechtherapy.com/helping-marketing-and-data-engineering-same-word-different-meaning/)
### Correction window
Copy link
You mean
Not a phrase you have used.
They mean
How long there is to catch a mistake before a customer sees it. It shrinks to nothing as the latency does, and it is the real cost of speed.
From [Guide 3](https://www.martechtherapy.com/what-real-time-actually-costs/)
### Customer
Copy link
You mean
A person.
They mean
An entity at a grain. Person, account, household or device, and which identifiers represent it.
From [Guide 1](https://www.martechtherapy.com/helping-marketing-and-data-engineering-same-word-different-meaning/)
### Data source
Copy link
You mean
The tool or application where you see the data.
They mean
The system that produced it. Which system, how it arrived, and which version counts.
From [Guide 1](https://www.martechtherapy.com/helping-marketing-and-data-engineering-same-word-different-meaning/)
### Deduplication
Copy link
You mean
Removing the doubles.
They mean
Identity resolution. A policy with thresholds. Too keen merges two people, too cautious splits one.
From [Guide 1](https://www.martechtherapy.com/helping-marketing-and-data-engineering-same-word-different-meaning/)
### Event
Copy link
You mean
Something a customer did that you can target on.
They mean
A timestamped record with a schema, written once. The schema can change, and that affects ingestion and everything downstream.
From [Guide 1](https://www.martechtherapy.com/helping-marketing-and-data-engineering-same-word-different-meaning/)
### Field
Copy link
You mean
A box in the segment builder.
They mean
A column with a type (what values are allowed), a nullability rule (can it be empty), and an owner.
From [Guide 1](https://www.martechtherapy.com/helping-marketing-and-data-engineering-same-word-different-meaning/)
### Forward deployed engineer
Copy link
You mean
A vendor's engineer inside your team who sets up the product and reworks workflows around it. Part builder, part consultant.
They mean
An engineer embedded with a single customer, adapting the platform to their problem. Now a common role at AI labs.
Needs first
Internal owners who learn alongside them, so the setup survives their exit.
From [Hello, I'm human](https://www.martechtherapy.com/hello-im-human-closing-thoughts-on-2026/)
### Freshness
Copy link
You mean
How recent the data is.
They mean
The age of the data at the moment it is read, which is a different number from how often the job runs and usually a worse one.
From [Guide 3](https://www.martechtherapy.com/what-real-time-actually-costs/)
### Golden record
Copy link
You mean
The truth.
They mean
The output of rules a person wrote, which can be changed.
From [Guide 1](https://www.martechtherapy.com/helping-marketing-and-data-engineering-same-word-different-meaning/)
### Governance
Copy link
You mean
The reason things take longer.
They mean
The reason the company has not had to disclose a breach.
From [Guide 1](https://www.martechtherapy.com/helping-marketing-and-data-engineering-same-word-different-meaning/)
### Harness
Copy link
You mean
Widened to mean a coordination layer across a team's tools, with shared business context and guardrails. Engineers would call that orchestration.
They mean
All the code around a model that turns it into an agent: the loop, the tools, what it sees and what it may do.
Needs first
Permissions for each tool, a log of what ran, and an owner for the rules.
From [Hello, I'm human](https://www.martechtherapy.com/hello-im-human-closing-thoughts-on-2026/)
### In-session state
Copy link
You mean
The site knows what I just did.
They mean
Data served fast enough to answer in the time a page has to render, often from a separate serving layer kept in step with the warehouse.
From [Guide 3](https://www.martechtherapy.com/what-real-time-actually-costs/)
### Integration
Copy link
You mean
Two tools are connected.
They mean
A direction of travel with auth, field mapping, schema handling, rate limits, retries, monitoring and an owner.
From [Guide 1](https://www.martechtherapy.com/helping-marketing-and-data-engineering-same-word-different-meaning/)
### Latency
Copy link
You mean
The delay before you see something.
They mean
Several delays that add up, measured at points you have not specified.
From [Guide 1](https://www.martechtherapy.com/helping-marketing-and-data-engineering-same-word-different-meaning/)
### Live
Copy link
You mean
It is working now.
They mean
It is in production rather than in a test environment.
From [Guide 1](https://www.martechtherapy.com/helping-marketing-and-data-engineering-same-word-different-meaning/)
### Lookalike
Copy link
You mean
Expanded reach, built from a seed audience.
They mean
A downstream black box they cannot inspect, explain or debug. Expect hesitation about depending on it.
From [Guide 1](https://www.martechtherapy.com/helping-marketing-and-data-engineering-same-word-different-meaning/)
### Micro-batch
Copy link
You mean
Near enough to live.
They mean
The same kind of job, run every few minutes. Depending on the setup, you can end up paying for the schedule rather than the volume.
From [Guide 3](https://www.martechtherapy.com/what-real-time-actually-costs/)
### Model
Copy link
You mean
A prediction, like propensity to churn.
They mean
The data model. Tables and how they relate. The worst offender on this page.
From [Guide 1](https://www.martechtherapy.com/helping-marketing-and-data-engineering-same-word-different-meaning/)
### Profile
Copy link
You mean
Everything known about someone, in one view.
They mean
A join, several tables stitched on a shared key, computed at a moment and already slightly stale.
From [Guide 1](https://www.martechtherapy.com/helping-marketing-and-data-engineering-same-word-different-meaning/)
### Raw data
Copy link
You mean
An unformatted export.
They mean
The untouched landing layer, preserved so downstream can be rebuilt.
From [Guide 1](https://www.martechtherapy.com/helping-marketing-and-data-engineering-same-word-different-meaning/)
### Real time
Copy link
You mean
Soon enough that it does not feel broken.
They mean
Sub-second streaming, an always-on architecture, and a cost line that never stops.
From [Guide 1](https://www.martechtherapy.com/helping-marketing-and-data-engineering-same-word-different-meaning/)
### Refresh
Copy link
You mean
The numbers change.
They mean
A pipeline run with dependencies, a schedule, and someone on call for it.
From [Guide 1](https://www.martechtherapy.com/helping-marketing-and-data-engineering-same-word-different-meaning/)
### Segment
Copy link
You mean
A group of people to message.
They mean
Needs to know if you mean the definition or the result. Those cost differently.
From [Guide 1](https://www.martechtherapy.com/helping-marketing-and-data-engineering-same-word-different-meaning/)
### Source of truth
Copy link
You mean
The dashboard you trust.
They mean
The designated system, governed dataset or semantic definition. There can legitimately be different ones per subject.
From [Guide 1](https://www.martechtherapy.com/helping-marketing-and-data-engineering-same-word-different-meaning/)
### Streaming
Copy link
You mean
Instant.
They mean
A pipeline that never stops, where a failure becomes an incident rather than a quiet rerun, and on always-on infrastructure the cost runs whether anything happened or not.
From [Guide 3](https://www.martechtherapy.com/what-real-time-actually-costs/)
### Sync
Copy link
You mean
The data shows up in the tool.
They mean
A job with failure modes, retries, and last night's failed records. Scheduled, change capture or event-driven.
From [Guide 1](https://www.martechtherapy.com/helping-marketing-and-data-engineering-same-word-different-meaning/)
Nothing matches that. Try a shorter word, or clear the filter.
### When does your Martech vendor's financial year end?
URL: https://www.martechtherapy.com/when-does-your-martech-vendors-financial-year-end/
Last updated: 2026-09-19T09:43:45.000Z
Vendors do not all run on the same calendar, and the difference matters if you are timing a contract.
Five of the companies below close their financial year on 31 January rather than 31 December, which puts their heaviest selling quarter between November and the end of January. Adobe is on a different timetable again. So the common assumption that December is when everyone gets flexible is right for some of them and wrong for others.
Two things worth doing with this. If you are negotiating now, check which quarter your signature date falls into, and remember that the end date of the contract is as negotiable as the price. If you already signed, look at where your renewal date sits in your vendor's year. If it lands in their final quarter, that was probably decided by somebody who knew this table and assumed you did not.
I wrote up what else is in these filings, and what each line predicts about being a customer, in [what your Martech vendor's filings tell you before you renew](https://www.martechtherapy.com/what-martech-vendor-filings-tell-you-before-you-renew/).
## The calendar
| Vendor | Financial year ends | Q1 ends | Q2 ends | Q3 ends | Q4 ends |
| ------------- | -------------------------- | ------- | ------- | ------- | --------- |
| Adobe | Friday nearest 30 November | 27 Feb | 29 May | 28 Aug | 27 Nov \* |
| Amplitude | 31 December | 31 Mar | 30 Jun | 30 Sep | 31 Dec |
| Braze | 31 January | 30 Apr | 31 Jul | 31 Oct | 31 Jan |
| DoubleVerify | 31 December | 31 Mar | 30 Jun | 30 Sep | 31 Dec |
| HubSpot | 31 December | 31 Mar | 30 Jun | 30 Sep | 31 Dec |
| Klaviyo | 31 December | 31 Mar | 30 Jun | 30 Sep | 31 Dec |
| Salesforce | 31 January | 30 Apr | 31 Jul | 31 Oct | 31 Jan |
| Shopify | 31 December | 31 Mar | 30 Jun | 30 Sep | 31 Dec |
| Snowflake | 31 January | 30 Apr | 31 Jul | 31 Oct | 31 Jan |
| Sprinklr | 31 January | 30 Apr | 31 Jul | 31 Oct | 31 Jan |
| Sprout Social | 31 December | 31 Mar | 30 Jun | 30 Sep | 31 Dec |
| Twilio | 31 December | 31 Mar | 30 Jun | 30 Sep | 31 Dec |
| Yext | 31 January | 30 Apr | 31 Jul | 31 Oct | 31 Jan |
\* Adobe's filed quarter ends for its current year are 27 February, 29 May and 28 August 2026\. The 27 November date is calculated from its stated convention rather than read off a filing, because that quarter has not been reported yet.
## Three things that will trip you up
**The year is named after the year it ends in.** Salesforce's "fiscal 2026" ran to 31 January 2026, so most of it happened during calendar 2025\. Put that next to a December company's 2026 and you are comparing periods that barely overlap.
**Adobe never falls on a month end.** It runs a 52 or 53 week year, so its quarter ends land on Fridays in late February, May, August and November. Its next 53 week year is 2027.
**Not every vendor is in here, and that is the point.** These are the listed ones. Most Martech companies are privately held and file nothing, so there is no table to look them up in. Databricks is the obvious example. For those, just ask in the next call. A financial year end is not confidential and the answer takes one sentence.
Semrush used to belong on this list. It stopped being a listed company in May 2026, so its disclosure ended with the year to 31 December 2025.
## How this was put together
Every date comes from the company's own filings with the US Securities and Exchange Commission, cross-checked against the period end dates of each filed quarterly and annual report. Nothing here is taken from a press release or a news story.
Checked September 2026\. I re-check this every quarter, because companies delist, list and get acquired, even though a financial year end itself almost never changes.
If you spot something wrong, tell me and I will fix it and say when.
Do you have any questions after reading this page?
Or need support with your Martech projects?
[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
## Posts
### “Open CDP & Local AI CDP” Oh my…
URL: https://www.martechtherapy.com/sovereign-cdp-open-cdp-local-ai/
Last updated: 2026-10-22T10:24:40.000Z
In a regulated company, the question that stalls an AI project on customer data rarely comes from marketing. It comes from risk and legal, and it's simple enough.
> Where does the customer data get processed, and where does the model run?
For a long time "in the vendor's cloud" was enough.
Then composable came along and "it never leaves our warehouse" became the better reply.
For banks, insurers and telcos, that reply is getting harder to approve too, because the warehouse belongs to somebody, and so does the model the agents call.
I'll be upfront about where I'm standing. I've spent a lot of time with composable architectures and what they cost to run. I haven't run a CDP on bare-metal Spark or hosted a language model next to one. So this is me reasoning from the architecture and from what two vendors are saying, and you should treat it that way.
## The line keeps moving down
Two launches, five weeks apart, push on the same boundary from different directions.
In September, Zeotap announced [Open CDP](https://zeotap.com/blog/zeotap-launches-open-cdp-the-first-fully-composable-cdp-that-runs-on-open-source-compute-and-the-customers-own-lakehouse-sovereign-by-design/?ref=martechtherapy.com). It runs their composable CDP on open-source Apache Spark over Iceberg tables in the customer's own object storage, governed through whatever catalog the customer already uses. Their case is that warehouse-native composable still rents a proprietary warehouse to do the work, which ties you to one cloud and bills every audience refresh as consumption. Composable, in their telling, stopped a layer too high.
In October, Meiro announced [Local AI CDP](https://meiro.io/blog/local-ai-cdp-for-sovereign-ai-inference/?ref=martechtherapy.com), which keeps the model, large or small, inside the same deployment as the customer data. Their case is that warehouse-native and zero-copy settle where data is stored, and leave open where inference happens. If your agents send customer context to an external model to pick the next best action, the data stayed home and the reasoning didn't.
Compute in one case, the model in the other. Both describe sovereignty as something the architecture delivers rather than something a contract promises, in close to identical wording.
[](https://storage.ghost.io/c/57/c5/57c5ffb5-ecd9-4bf6-b870-68986d981176/content/images/2026/10/who-is-a-sovereign-cdp-actually-for-sovereign-f1-the-line-moves-down.svg?ref=martechtherapy.com)
When I wrote about [Databricks CustomerLake](https://www.martechtherapy.com/databricks-customerlake-the-warehouse-cdp/) and [Snowflake recruiting Zeotap](https://www.martechtherapy.com/how-snowflake-recruited-zeotaps-composable-cdp/), the pull was toward wherever the data already lives. These launches push back on that pull. Zeotap is doing both at once, with a Snowflake Native App inside one platform and Open CDP as a way out of all of them.
## **Is a sovereign CDP cheaper?**
Not by default.
Zeotap does lead with total cost of ownership, and the metering point is real. Continuous audience computation on a warehouse bill is expensive and hard to predict. But predictable isn't cheaper. The invoice shrinks in one place and a workload appears somewhere else.
In [the inherited costs of the composable stack](https://www.martechtherapy.com/the-inherited-costs-of-the-composable-stack/) I wrote that every pricing model hides a workload. This is the next layer down, and the workload is of a different kind.
Someone has to keep the Spark cluster healthy and patched.
Someone has to decide whether the model you swapped in is good enough to choose which customer gets which offer, and spot when it stops being good enough.
And someone has to sit across the table from the auditor.
Look, that last one is the part I'd underline. Zeotap describes the benefit as the difference between a control "that can be evidenced to a regulator" and one that can't. I think it's the most honest phrase in either announcement. Evidence doesn't come from a slide. It comes from a person who understands the setup well enough to show it working, and to explain what happens when it isn't.
Both vendors also offer to run the whole thing for you, and for most buyers that's probably the sensible choice. But then the vendor holds the operational knowledge again, and what you have is residency plus a contract with a capable partner.
That can be enough.
Just know that's what you bought. It's the same question I asked about [forward deployed engineers](https://www.martechtherapy.com/what-is-a-forward-deployed-engineer-and-who-is-paying-for-the-one-in-your-team/): when the vendor's people step back, does the capability stay with you?
## Sign up for Martech Therapy
Subscribe
Email sent! Check your inbox to complete your signup.
New articles straight to your inbox when they're published.
## The one layer you can't swap
What strikes me about both launches is how much they promise you can replace. Zeotap frames openness as its retention story, arguing that customers stay precisely because every layer can be swapped out. Meiro says you can change the model in most configurations without rebuilding the stack.
The people are missing from that list.
If sovereignty moves accountability inside the building, then platform engineering, model evaluation and the ability to explain all of it to compliance become running costs you carry every year. They're also where I'd put the investment. Vendors and models are getting easier to replace. Someone who understands why your identity graph is configured the way it is, and can prove it to a regulator, isn't.
In readiness terms this is a capability question before it's a technology one. Buy the architecture without those skills and you'll probably end up on the managed option, paying for both.
## **Are sovereign CDPs a niche, or where the market is heading?**
This is where I'm genuinely unsure.
Both vendors aim at the same buyer: Zeotap names telco, retail and financial services, Meiro names banking, insurance and telco. Few buyers, large contracts, high event volumes and regulators who ask awkward questions.
If it stays there, *sovereign CDPs become a well-paid niche*, much like on-premise deployments always were (Meiro has offered those for years, so this is an extension for them, not a pivot).
There's another way to look at it.
Meiro's drivers aren't European. They point to the UK Treasury's AI adoption plan for financial services, Australia's prudential regulator and Saudi in-Kingdom residency rules.
Zeotap names DORA and the CLOUD Act.
Jurisdiction keeps coming up well outside Brussels. And agentic AI turns "where does the model run" into a question every CDP will be asked eventually, since nearly all of them now ship agents that read customer profiles.
My guess is both, in sequence.
Regulated sectors pay for it first. Whether it spreads depends less on the vendors than on whether a retailer or a travel brand, with no regulator asking, starts putting the question into an RFP.
There's a vendor side to this too.
For an independent CDP, deployment flexibility is one of the few things Databricks and Snowflake can't easily copy, since their business depends on your data living in their platform. So part of this is a market signal and part of it is the vendors hedging.
That doesn't make it less real. It does mean the marketing will run ahead of the demand for a while.
So I'll ask, because I don't know.
If you work outside banking, insurance or telco, has anyone in your organization asked where the model runs?
Or is it still a question for someone else's industry?
Do you have any questions after reading this article? Or need support with your Martech projects?
[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
### What your Martech vendor's filings tell you before you renew
URL: https://www.martechtherapy.com/what-your-martech-vendors-filings-tell-you-before-you-renew/
Last updated: 2026-10-19T06:43:59.000Z
A bank buying a [customer data platform](https://www.martechtherapy.com/tag/customer-data-platform/) has somebody, somewhere in the building, whose job is to check whether the company selling it can afford to still be there in three years.
A retailer buying the same platform on the same three-year term usually has no one doing that at all.
Same product, same paper, same length of commitment.
The difference is which industry you happen to work in, and whether anyone thought to open a document that's been sitting in public the whole time.
## Does anybody actually do this?
In one corner of the market, yes, and it is now the law.
Since January 2025, European banks, insurers and investment firms have been living under a rule called DORA, short for the [Digital Operational Resilience Act](https://www.eiopa.europa.eu/digital-operational-resilience-act-dora%5Fen?ref=martechtherapy.com). Before they sign with a technology supplier, they have to do proper homework on it. Where that supplier is going to run something the firm treats as critical, the rules sitting underneath DORA say that homework has to cover whether the supplier has adequate financial, human and technical resources.
In plainer words:
> Can this company afford to keep showing up?
Everywhere else, that check either doesn't happen or it happens somewhere in procurement and never reaches the person who actually has to live with the tool. I've sat through selections where we compared support response times to the minute and nobody asked a single question about the company behind the product.
💡
Avinash Kaushik shared an idea with me that I still apply. Switch off something you think people depend on. The safest option is often to send an automated report or notification to see whether people respond. Apply cautiously, but it is worth checking every so often who is really paying attention.
One honest limit before we go further 👇
*Everything below comes from filings*, which only listed companies have to produce, and most of Martech is privately held. If your vendor is private you can't do any of this. What you can do is ask the questions out loud in the deal, note when they last raised money, and treat a refusal to answer as its own kind of answer.
## The most useful page has nothing to do with money
Start somewhere easier than the accounts.
Start with the calendar.
Every one of these companies tells you exactly when its financial year ends, and they don't all end in December. Of the fifteen I checked, *six don't*. Braze, Sprinklr, Salesforce, [Snowflake](https://www.martechtherapy.com/how-snowflake-recruited-zeotaps-composable-cdp/) and Yext all close their year on 31 January, which means their big final quarter runs from November through to the end of January, and their other quarters finish on 30 April, 31 July and 31 October.
Adobe is on its own timetable entirely, which I personally find funny, closing on the Friday nearest to 30 November, with quarters that end in late February, late May and late August and never land on a month end.
So the received wisdom that December is when everybody gets desperate is right about nine of these companies and wrong about six of them, including some of the biggest names you will ever sit across from. Use it to your advantage 😉
***Figure 1** *. When each company's financial year and quarters actually end. Source: company filings, September 2026.*
I keep [the full list, with every quarter end date](https://www.martechtherapy.com/martech-vendor-fiscal-calendar/) on its own page and re-check it every quarter, because it is more useful as a lookup than as a paragraph.
Sprinklr writes the consequence down in its own annual report, in a sentence I'd print out and keep:
> A large percentage of our customers make their purchases in the fourth quarter of a given fiscal year and pay us in the first quarter of the subsequent year.
That's a vendor, in an audited document, confirming the thing every salesperson denies in the room.
## Your renewal date is probably not an accident
Here's the part I'd do first, before any of the rest of it.
Go and look at when your current contract expires. Actually do it.
Then look at where that date falls in your vendor's year. If your renewal happens to land inside their final quarter, that was very unlikely to be luck. Renewal dates *get set when you sign*, and the person setting them knew their own calendar while you were thinking about implementation timelines.
It works in both directions, which is why it's useful.
If you are buying now, the end date of the contract is negotiable in exactly the same way the price is, and almost nobody treats it that way. If you already signed, at least you now know which side of the table the clock is on.
Three things to keep in mind before anyone gets excited about squeezing a discount out of the last week of January.
A discount taken at quarter end is nearly always paid for somewhere else in the paperwork. Trust me on this. It comes back as a longer term, as an automatic renewal, or as a price that steps up in year two. That is the same problem I wrote about in [the dates and the rights](https://www.martechtherapy.com/the-martech-contracts-dates-and-rights/), and it's why the discount and the contract have to be judged separately.
Pushing to the actual final day is also how legal review gets skipped, and skipped legal review is how the clauses you hate end up in the document.
And the pressure is real in the final quarter and much weaker in the other three. This is one lever, not a season ticket.
## Want regular Martech insights in your inbox?
I publish weekly, unless I am on holiday. I am, after all, human, like you.
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
## Two dollars spent selling for every dollar spent building
Now the accounts, and only one line of them.
Every company splits out what it spends on sales and marketing, and what it spends on research and development, meaning the people who build the product. The gap isn't subtle.
For every dollar Braze took in last year, about 44 cents went to selling and about 23 cents to building. Klaviyo, 41 cents against 24\. Amplitude, 55 cents against 28, and its total costs came to slightly more than everything it earned. Sprinklr is the widest at 34 cents against 11, three dollars on winning the next customer for every dollar on the product the current ones already bought.
Check out the chart below for a better understanding.
A nice find is that Twilio is the other way round. 17 cents selling against 20 building, which is a useful reminder that infrastructure companies sell differently from application companies.
***Figure 2** *. Cents in every dollar of revenue spent on selling and on building, most recent financial year. Source: company filings.*
What that tells you as a customer isn't that anyone is doing something wrong. It tells you where your feature request sits in the queue. When the company spends twice as much finding the next customer as it does improving the product, the thing you asked for last spring is competing with next quarter's new logos, and it's losing.
The question that comes out of this is a good one to ask in a renewal:
> What shipped in the last twelve months that we actually use?
[The Martech Stack you bought twiceUnused features cost nothing. A second contract for a capability you already own costs what the invoice says, and no utilization survey will find it.Martech Therapy: CDP strategy and agentic AIMatthew Niederberger](https://www.martechtherapy.com/the-martech-stack-you-bought-twice/)
## The retention number you cannot compare
One more, quickly, because it gets waved at you constantly.
*Vendors love quoting retention*, which is roughly how much last year's customers are spending this year. Anything above 100% means the base is growing without new customers.
It sounds like a clean comparison between two suppliers.
It isn't, and they say so themselves.
Sprinklr's version leaves out professional services entirely. Twilio's includes usage. Braze's counts certain professional services inside the underlying figure. Braze's own filing warns that its metric "may not be comparable" to anyone else's, and Amplitude states in writing that it is "not aware of any uniform standards" for working these out.
So when two vendors put their retention figures side by side in your evaluation, you're looking at a comparison both of them have formally disclaimed. Ask how they calculate it. The reaction to that question is usually more informative than the figure.
## Twenty minutes, four things
None of this needs a finance background (I sure don't have one 😉), and you're not valuing anybody.
Search for the company name on the [SEC's EDGAR platform](https://www.sec.gov/edgar/search/?ref=martechtherapy.com), which is the free public database where American listed companies file. Open the most recent annual report, called a 10-K. Then look at four things and write them down.
***Figure 3** *. A reading list for the twenty minutes before a renewal conversation.*
Two small things you will run into, as examples:
- Semrush stopped being a listed company in May 2026, so its disclosure simply stops, which is a real thing that can happen to a supplier you depend on.
- Databricks has no annual report at all, because it is private, which is the clearest demonstration of where this method stops.
One trap worth knowing. The January companies name their year after the calendar year it ends in, so Salesforce's "fiscal 2026" is mostly what the rest of us called 2025\. Line that up against a December company's 2026 and you're comparing two periods that barely touch.
## What this does not do
To end, let me be honest with you.
It won't tell you whether a vendor is about to fall over. It won't tell you whether the product is any good, which still matters more than any of this. And *it isn't investment advice*, because none of this is about whether these are good companies to own.
It's about what happens to you as their customer.
What it changes is the conversation. You walk in knowing where you sit in their calendar, roughly where your request sits in their priorities, and which of their numbers you are allowed to take seriously.
And if your vendor is private, which most of them are, the whole method collapses into one question you can ask in the next call.
> When does your financial year end?
They will tell you. It was never a secret.
It just suited everybody that you never asked.
[](https://www.martechstackbuilder.com/?ref=martechtherapy.com)
Start tracking your Martech contracts, and never miss an opportunity to renew on your terms.
[SIGN UP FOR FREE ](https://www.martechstackbuilder.com/?ref=martechtherapy.com)
### Use cases should lead. Lead with what?
URL: https://www.martechtherapy.com/martech-use-cases-should-lead-lead-with-what/
Last updated: 2026-10-12T06:28:59.000Z
Some time ago I wrote about [why skipping the RFP isn't always an option](https://www.martechtherapy.com/why-skipping-the-rfp-isnt-always/). The piece opened on a comment Jay Calavas from [Tealium](https://www.tealium.com/?ref=martechtherapy.com) had left under one of my LinkedIn posts:
> "Skip the RFP and focus on use cases and measurable outcomes!"
I said he was right. Use cases should lead. I meant it, and would say it again tomorrow.
Then I sat down in the next selection and couldn't act on it.
I reached for the requirements template, because, look, it was there and the clock was running. The plan was that the use cases would come out of the workshops later, once everyone had seen the tools and knew what to ask for. They didn't come out of the workshops later.
They never do.
Why would they?
Nobody had the words yet. By the time anyone had the vocabulary to describe what they wanted, three sellers had already spent six weeks describing it for them, in their own words, on their own slides.
That's not a failure of nerve.
It's that following Jay's advice takes something everyone assumes is lying around somewhere, and it isn't.
[Why skipping the RFP isn’t always an option and how to avoid the biggest trapsFour practical steps that help teams protect themselves when the process can’t be avoidedMartech Therapy: CDP strategy and agentic AIMatthew Niederberger](https://www.martechtherapy.com/why-skipping-the-rfp-isnt-always/)
**The piece where I agreed with Jay and didn't notice the problem ☝️*
## The advice is older than my RFP series
Scott Brinker made the same case in February 2022, in a piece called "[It's not the size of your martech stack, it's your range of use cases](https://chiefmartec.com/2022/02/its-not-the-size-of-your-martech-stack-its-your-range-of-use-cases/?ref=martechtherapy.com)".
He put the definition in one sentence:
> "A use case is a specific customer experience, with certain functionality, delivered through a particular channel."
He was writing off the back of a Bain survey of a hundred consumer products companies, scored across thirty martech capabilities. The leaders had more than fifty use cases in wide adoption. The laggards had fewer than five. Those figures are four years old and I have not seen the survey itself, so take them as a picture of 2022 rather than a claim about today.
To be honest, a 2026 version would be worth having. Bain, are you listening?
The shape of the finding holds up regardless. What separated the companies doing well from the companies stuck came down to how many use cases they had running. Not how many tools they owned, which is the number everyone reports, and not what they spent, which is the number everyone defends.
Four years on, that one sentence of Brinker's is still the whole shared vocabulary the category has. A specific customer experience, certain functionality, a particular channel.
Now go and score three platforms against that. How far do you get?
## Look, I know there are hundreds of these
This is the part where you tell me the lists already exist, and you're right, they do. [Braze has one and calls it the Use Case Library](https://learning.braze.com/page/use-cases?ref=martechtherapy.com). Most of the large platforms run something similar, the agencies have their versions, the consultancies have theirs, plenty of them are genuinely useful, and I've cheerfully sent clients to more than one.
Every single one of them stops where the product stops. No surprise there.
That's not an accusation, and worth being careful here, because this is usually where a piece like this turns into a complaint. Braze wrote theirs for people running Braze. It's the correct thing for Braze to do, and a version scoped to everything Braze can't do would be a strange document to publish.
It be weird for my car manual would give me tips on how to brew a solid coffee.
To be fair, nobody's being sneaky. But a library written by a platform is a catalog of *reasons to buy that platform*, ordered to suit the buying, and that's a different object from a description of the work.
Put two of them next to each other and it shows up straight away. The same problem picks up a different name, a different scope, a different set of edges. One treats suppression as a setting inside the campaign tool. Another treats it as a question about how audiences get built. A third barely mentions it, because in their architecture it happens somewhere the marketer never sees.
All three descriptions are honest. But none of them can be laid against the other two. And laying them against each other is the entire job when you're choosing between them.
So you end up doing the translation by hand, under time pressure, in a spreadsheet, usually alone. Have you ever seen that spreadsheet survive the second round of demos? Call me when you do.
## What actually gets sent out
I've read a lot of these documents. The pattern's consistent enough to guess most of yours.
Six to ten lines, each about a sentence long. Improve retention. Personalize the homepage. Reduce wasted ad spend. [Build a single view of the customer](https://www.martechtherapy.com/your-cdp-is-more-than-just-a-platform/), which is less a use case than a wish with a budget attached.
Those are goals, and mostly they're good ones. A goal has no surface though, and you can't test a demo against a surface that isn't there. Ask a platform whether it can improve retention and there's exactly one available response. Yes, followed by forty minutes of screens. What else would they say?
So the seller does the only thing on offer and answers with features, because features are the part of their world you can show inside a meeting. The second one does the same. By the third demo you're [back in a grid with checkmarks in it](https://www.martechtherapy.com/the-cdp-rfp-dating-game/), which is precisely what everybody, me included, told you to avoid.
I used to file that under discipline. Teams knew they should lead with use cases, got busy, and reached for the requirements template instead. And I'd nod sympathetically about process. I was wrong about that. I mean, I did exactly the same thing the moment a deadline showed up (twice, since you ask), which should have told me something sooner.
The discipline's usually fine. What's missing is the thing the discipline was supposed to operate on.
## Five things that make a use case comparable
Here's the test I've landed on. It's less elegant than it should be.
A use case only becomes comparable to another one when it names the data that has to exist before anything can run at all. Then the tools, which everyone already writes down, and which matter least. Third, and this one is almost never filled in, who keeps it alive after launch. That field outlives the project and turns into somebody's Monday morning. Leaving it blank is not a small omission. Fourth, the order things have to happen in, which is where most of the interesting disagreement between two platforms actually lives, and where a demo will never take you unless you push. Then how the thing breaks. Not whether it breaks. How.
That last one is worth arguing about. Every use case has known failure modes, and they repeat across every company that has ever tried it, which is why implementations slip on the same rocks year after year. I have never once been handed a requirements document that mentioned one of them.
Write those five down for one use case and the conversation changes character entirely. You stop asking whether the platform can do personalization. You start asking [who owns the identity ruleset](https://www.martechtherapy.com/identity-resolution-a-practitioners-guide-to-who-owns-the-match/), what happens when someone withdraws consent halfway through a sequence, and which of your two teams gets the call [when an audience goes stale](https://www.martechtherapy.com/right-time-marketing-and-the-speed-of-context-decay/).
Those questions have answers you can compare. And the answers differ, which is the point.
Why did that take so long to write down? No idea, honestly. It had been sitting in plain sight in every project I've run.
Rather than list all five in the abstract, let me run one use case through them.
## One use case, all the way down
The one I want to use is called [cross-platform, consent-aware post-conversion suppression](https://www.martechcookbook.com/recipes/post-conversion-suppression-cross-platform?ref=martechtherapy.com). Dull name. What it means is you're not paying to advertise to people who've already bought from you.
Some of you will recognize it, because I scored a version of it back in June, in the Context Audit. That exercise looks backwards at a workflow already running and asks how good its context is. This one runs the other way, specifying the thing before it exists. Same workflow, opposite direction of travel, and it's worth seeing both.
[The Context AuditA follow-up to the follow-up. My last piece explaining “what the context layers has to do” argued that customer state has to be Queryable, Addressable, Current, and Accountable if agents are going to act on it in real time. It ended pointing at a one-page audit andMartech Therapy: CDP strategy and agentic AIMatthew Niederberger](https://www.martechtherapy.com/the-context-audit/)
Same workflow, scored after the fact rather than specified before it ☝️
Start with the problem, which is more specific than the line that usually stands in for it, which is that retargeting wastes money. You put suppression on Meta, it works, everyone's pleased. Google Display carries on. So does TikTok, so do the programmatic networks. Each of them wants a different identifier format, updates on a different schedule, and expires an exclusion on its own timetable. Then the part that catches people out: under GDPR, suppressing someone is itself use of their personal data for advertising, so consent has to travel alongside the conversion event rather than sitting in a different system entirely.
The outcome is a number. Thirty to fifty percent off retargeting spend on the converted segment, depending how many channels were leaking. You can put that in a business case. You can't put "reduce wasted ad spend" in a business case, which is roughly the difference this whole article is about.
Ingredients come next, and there are five: conversion events, a hashed email identifier, the mobile advertising ID, a consent state flag, and the jurisdictional context that flag sits in. Not one of those is a product, by the way. That matters, because if two of the five don't exist in your business today, no platform on the shortlist can rescue you, and you've just learned that before signing rather than after.
Equipment is the part everyone skips ahead to. You need identity resolution at a workable scale and consent state propagated into a handful of ad platform APIs. In a composable stack that usually lands as [a CDP, a reverse ETL layer and a consent management platform](https://www.martechtherapy.com/composable-cdp-translated-for-marketers/), with the warehouse as the source of truth. One paragraph. Genuinely, that's all the tool question deserves at this stage, and look at how much of every RFP it eats.
Then staff, and here's where it gets interesting.
Seven roles. Marketing ops for audience strategy, ad ops for the platform exclusion configuration and the logic that lets people back in, data engineering for the pipeline and the identifier transformation, whoever owns identity for the identifier strategy and decay, legal for consent posture and audit defensibility, privacy ops for consent propagation and right-to-be-forgotten, and analytics for holdout design. Six of those are critical. One is supporting.
Seven roles, sitting across different reporting lines, for the use case everyone describes as the easy one.
The technique field composes six patterns and sets a latency target of one to four hours, with the honest note that batch-only platforms won't hit it. And the gotchas, which is the field I'd read first if someone handed me this document cold, list three ways it goes wrong. Teams treat it as configuration when it's orchestration. Measurement gets fudged, because a before-and-after comparison quietly absorbs seasonality and whatever the ad platforms changed that quarter, and the holdout that would settle it deliberately wastes budget, so nobody wants to run it. And re-introduction logic gets forgotten, so the exclusion pool grows and grows until, a year later, your acquisition reach is worse and no one connects the two.
## The field that decides whether it ships
That staff list is the whole readiness question in one box.
Six critical roles across several reporting lines isn't a technology problem, and no platform solves it. If you can't put a name against each of those six today, the shortlist is beside the point, because the thing will stall in the gap between ad ops and privacy ops regardless of what you bought. This is where [Structure, Capability and Process](https://www.martechtherapy.com/the-cdp-you-werent-supposed-to-buy/) stop being a framework and turn into a staffing list, and it's the field that never appears in a requirements document.
The gotchas do similar work at the other end. Look at that last one again. An exclusion pool that grows for a year before anyone notices isn't a launch failure. It's a failure that arrives long after the implementation partner has gone home and the person who set the expiry rules has changed jobs. To be fair, no seller's going to volunteer that in a demo. But you can ask about it, and asking about it tells you more about who you're dealing with than any reference call will.
## Try it on one of yours
Take the use case at the top of your list. Seven boxes on one page: problem, outcome, ingredients, equipment, staff, technique, gotchas. Give it an afternoon.
What tends to happen is this. Problem and outcome take twenty minutes and feel productive. Ingredients take longer than expected and produce the first useful argument, usually about whether you actually have a consent flag or just believe you do. Equipment is quick, which surprises people. Staff is where you stall, and the stalling is the finding. Gotchas is where someone in the room says they've seen this before and describes exactly what happened.
Then do a second one, and a third. I mean, three is where it stops being a document and starts telling you something about the business, which is a thing I've said before about workflows and it turns out to hold here too.
## So I built the list I wanted
The Martech Cookbook came out of a conversation with someone whose analytics work I've followed for years. He said one thing about use cases that changed how the whole problem looked. The idea was his.
The version that exists is mine, and any dullness in it is mine as well.
It's a reference of Martech use cases [arranged by outcome rather than by tool](https://www.martechcookbook.com/browse?ref=martechtherapy.com). That's the only arrangement that makes comparison possible, since arranging by tool is what got everybody into this. Each entry names the problem, the outcome, the data, the equipment, the people, the technique and the ways it goes wrong. Kitchen words, because a recipe is genuinely the closest existing thing to a properly specified use case, and because the alternative was calling it a framework. 😉
Those entries are free and openly licensed. No form.
One thing to say plainly, since I've spent two years telling anyone who'd listen that nothing here is gated. There's a second tier on the Cookbook that asks for a business email, and [it feeds my Workshop](https://workshop.martechtherapy.com/?ref=martechtherapy.com). That's what it's for. Everything else I publish is open and stays open, this is the exception, and I'd rather name it here than have you find it yourself and wonder what else went unmentioned.
Anyway. Jay was right in 2025 and Brinker was right in 2022, and advice that has held up for four straight years while staying unusable deserves better than another article agreeing with it.
****The Martech Cookbook**
A free reference of Martech use cases, organized by outcome rather than by tool. Each one names what the use case needs, who keeps it alive, and how it is known to break. No form.
[Browse through the Martech Cookbook use cases >> ](https://www.martechcookbook.com/?ref=martechtherapy.com)
### What real time actually costs
URL: https://www.martechtherapy.com/what-real-time-actually-costs/
Last updated: 2026-10-06T06:49:37.000Z
SPONSORED
****Sponsored by Databricks.** [Databricks](https://www.databricks.com/?ref=martechtherapy.com) commissioned and funded this guide and reviewed it before publication for factual accuracy. They did not get to change the conclusions.
[Full disclosure at the foot of this post](#about-the-series).
Somebody says "real time" in a meeting and the room nods.
It is *the most agreeable phrase in martech*, because everybody in the room assents to something slightly different and nobody finds out until the CFO starts looking for you.
I wrote about the architecture of this in July, in [real-time from a warehouse](https://www.martechtherapy.com/right-time-marketing-and-the-speed-of-context-decay/):
> How quickly context goes stale, where the work should sit, and where nine different vendors draw their line.
That piece is for somebody choosing a platform.
This one is for somebody who already has one and has to say what they want out of it when they need it most.
The two are different jobs, and the second one is where the money actually goes, and where your CFO will focus on.
## What you are actually buying
Ask what real time costs and somebody gives you a compute number.
Compute is the easy part to price.
> **Compute**: the processing power, CPU, memory, and infrastructure used to run queries, transform data, and execute calculations
What you buy when you buy speed is the obligation to be right continuously.
A nightly job has a window inside it. Something breaks at two in the morning, somebody notices at seven, it gets fixed by eight, and no customer ever knows anything happened.
That window is not on the architecture diagram.
Nobody put it in the business case. Nobody has ever presented it to a board. And it is doing an enormous amount of quiet work.
Take the window out and every correction becomes visible. An upstream failure stops being a quiet rerun and becomes an incident. A wrong segment is wrong in front of a customer instead of wrong in a table for six hours. And somebody is now on call, at night, for a marketing audience.
I watched a team discover this about five weeks after go-live. They had asked for real time, they had got it, and it worked. Then a field changed upstream one evening, and because there was no longer a night in which anybody could notice, the personalisation on the site ran wrong until the first person opened a laptop the next day.
Nothing about the pipeline had failed. The pipeline did exactly what it was built to do, *faster than anyone could check it*.
That is the cost. It lands on people rather than on a line item, which is precisely why it does not come up in the meeting where the speed gets agreed.
I have started calling it the correction window, because it needs a name before anybody will argue about it. How long you have to catch a mistake before somebody outside the company sees it. Days at the weekly end, a whole night at nightly, minutes at micro-batch, and none at all at the top.
The one-page version
Five speeds, what each one is for, and the window you give up at every step.
[Download the PDF ](https://www.martechtherapy.com/content/files/2026/10/talking-to-data-engineering-03-what-real-time-actually-costs.pdf)
## Speed is only worth what the slowest step allows
The second thing, and the one you can act on after reading this article, or the guide.
Data that arrives in two hundred milliseconds, into a process where campaign approval takes two days, has bought you *nothing at all*. You paid for the pipe. The pipe is not what was slowing you down.
So before asking for anything to be faster, find out what the rest of the chain does.
How often does the destination platform ingest what you send it?
Plenty of them are hourly or daily whatever you feed them.
How long does an approval take in your team?
How often does the campaign actually go out?
Then hold those numbers next to the one you were about to ask for.
Paid media is the cleanest example. Somebody asks for a real-time audience sync into an ad platform that refreshes its own side once a day. The engineering is real, the bill is real, and the audience then sits in a queue for nineteen hours.
Everybody did their job properly and nothing arrived any sooner.
## Five speeds, and most things live at the bottom
The sheet lays 5 common speeds out: weekly or on request, nightly batch, micro-batch, streaming, and in-session state. Each one with an honest latency band, what it is genuinely for, what changes about the failure surface when you move up, and the correction window you give up to get there.
Two things are worth saying in prose rather than on a card.
The first is that most of what marketing runs day to day sits comfortably at the slow end: audiences, scores, reporting, and most planned campaigns. Nightly is not a compromise for these. It is usually the right answer, and it is cheap and predictable in a way the faster speeds rarely are.
The second is that a handful genuinely belong at the top, and those are worth arguing for. On-site recommendations, where the screen is the decision. Fraud and payment failures. Anything that has to change what a person sees before they leave the page.
The point of being disciplined about everything else is that *the budget still exists* when one of these comes along.
In between those two sits the speed almost nobody asks for by name, which is the one most requests actually want. Every few minutes. Not overnight, not sub-second, just often enough that within the hour is always true. Basket recovery lives there. Session audiences live there. It usually costs a fraction of streaming, and it covers most of what people describe as needing to be real time.
If you take one thing from this into your next planning meeting, that is the thing:
> The answer you are looking for is usually the one nobody has a word for.
## The one everybody gets wrong
Abandoned basket.
It is the example people reach for when they want to justify streaming, and it is almost never a streaming problem.
The email lands in an inbox.
The person opens it when they open it.
Within the hour is indistinguishable, from where they are sitting, from within the second.
What people mean is that it feels urgent, and they are not wrong that a basket cools. But it cools over hours, not milliseconds, and those are two different speeds with two different bills.
There is one part that does have to move quickly, and it is not the email. It is the purchase that should cancel it. A basket reminder that lands after somebody has already bought is the one customers tend to complain about, so the order has to reach whatever decides the send at least as fast as the send itself. That is a smaller and cheaper thing to ask for than streaming the basket, and it is the one worth asking about.
So the sheet has one question on it before anything else.
> What happens if this is an hour late?
For abandoned basket, honestly, very little.
Try it on your own list and see how often the answer comes back "nothing anybody would notice". That is the answer that saves money, and in most companies it is the majority.
## Don't miss the fourth guide.
Sign up for free and get these practical guides delivered directly to your inbox.
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
## Before the next planning meeting
Take one thing your team wants faster and finish this sentence about it before the meeting:
> When **\[something happens\]**, we need **\[a channel or a screen\]** to reflect it within **\[a time\]**, because **\[what the customer would see\]**.
If the last blank is hard to fill, you probably have your speed already. Then agree what should happen when the data arrives late or looks wrong, because at the faster speeds that stops being hypothetical.
The meeting itself tends to stall in the same four places:
1. Somebody quotes streaming for a nightly problem.
2. One request really does need the top speed.
3. Nobody knows how fast the thing goes stale.
4. Somebody says the platform already does real time.
Side 2 of the sheet has a sentence for each of those.
One number to take into the room with you:
> How often the destination system ingests.
It settles more of these than any argument will, and a daily platform makes everything upstream of it daily, no matter what you paid.
[Guide 2](https://www.martechtherapy.com/how-to-write-a-data-request-someone-can-act-on/) was about writing a request somebody can act on, and its third question asks when the data has to be there and why then. This is the guide that tells you what to put in that sentence.
Take it into the planning meeting
Two sides of A4\. Five speeds, sixteen decisions placed, and four sentences for the meeting.
[Download the PDF ](https://www.martechtherapy.com/content/files/2026/10/talking-to-data-engineering-03-what-real-time-actually-costs.pdf)
**Next in this series:** same customer, different records. All six live on the [Helping Marketing Talk to Data Engineering](https://www.martechtherapy.com/talking-to-data-engineering/) page as they publish, and every term across the series is collected in the [glossary](https://www.martechtherapy.com/glossary/).
---
## About the series
#### Series Sponsorship Disclosure
Databricks came to me in the summer of 2026, after the agentic CDP series, and asked whether I would write a set of practical guides for marketers. There are six of them, and you are on the third one.
Here is the arrangement in full. Databricks reviews each guide before publication and may suggest factual corrections. Anything they flag as factually wrong, I fix. Anything they would prefer I said differently, I do not. The conclusions, the structure and the tone are mine, and so is the decision about what goes in and what stays out.
The guides are educational resources, not product recommendations. None of the six guides names a Databricks product, and none of them concludes that you should buy one.
Would I have written something like this anyway? Probably, eventually, in pieces. Their support is why it happens now, as a series, with enough time to do it properly.
Nothing here is gated. No form, no email capture, and the PDF is a direct download.
If you think I have something wrong, or have overlooked an important perspective, please tell me. I would rather know.
Do you have any questions after reading this article or guide?
Or need support with your Martech projects?
[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
### Natural-language audience builders: my advice for vendors
URL: https://www.martechtherapy.com/natural-language-audience-builders-my-advice-for-vendors/
Last updated: 2026-10-02T09:38:02.000Z
I talk to a lot of martech product teams. Part of my advisory work is getting an early look at features before they go GA, sometimes months ahead… well, weeks, more often, and giving feedback while it can still change something. Most of those previews have little in common. Lately one pattern keeps showing up, across companies that don't know they're building the same thing.
A marketer types a question in plain language. An LLM queries the warehouse and comes back with insights, an audience, and sometimes a full activation plan. No SQL, no BI ticket, no waiting on a data engineer.
To be honest, it's impressive. As someone who started out as an analyst, I'd have loved it. My problem is with what it removes.
## What goes missing when marketers skip the BI ticket
Everyone hates the BI ticket, and for good cause. It's slow, and it sits in a queue. It's also, in a lot of companies, the only regular moment where a marketer and a data engineer talk about what a field actually means. That's where a definition like "active customer" gets challenged, or where a marketer finds out the loyalty table stopped updating after a migration. The data engineer usually has a question back, too:
> What's this audience actually for?
The interfaces I've seen leave a few questions unanswered.
Does a marketer need to understand the underlying data? I don't think they need the schema, but they do need to know which questions the data can answer at all.
Trust is the next problem, because an LLM presents a wrong answer with the same confidence as a right one.
And then there's what's missing.
An audience of 847 profiles looks complete whether it drew on every relevant source or skipped one.
## Why text-to-SQL accuracy depends on the data team
These tools are only as accurate as the modeling work the data team has done.
dbt Labs [benchmarked this](https://docs.getdbt.com/blog/semantic-layer-vs-text-to-sql-2026?ref=martechtherapy.com) earlier in the year. With a well-modeled semantic layer underneath, current models answered close to every covered question correctly.
Working from raw tables, accuracy dropped to about two in three.
On [BEAVER](https://arxiv.org/abs/2409.02038?ref=martechtherapy.com), a benchmark built from real enterprise warehouse query logs, the best agentic setups got around 11% right.
So your product's quality depends on the people your interface is designed to route around. When the audience is wrong, the marketer won't blame the schema. They'll blame your tool, probably somewhere near renewal.
There's a sales angle too.
In warehouse-native deals the data team usually sits on the buying committee, or at least has a veto. Telling them your product removes the need for them is an odd pitch. I mean, would you buy that?
## What I'd build into a natural-language audience builder
Very little of this slows the marketer down. Most of it is about what the interface shows next to the answer.
**Start by making answers inspectable.** Show which tables, definitions and joins produced the output, in language a marketer can follow, so someone can stop and say "hang on, that isn't how we count active." Alongside that, show coverage: which sources were included, which fields were sparse, and what the system couldn't map. A count without that context is how people get into trouble.
The second ask is to **let it decline**. "I need more detail" or "I can't answer that reliably with this data" should be a normal outcome, designed in from the start. I've seen at least one proprietary CDP build its natural-language segment assistant this way, returning a valid segment, a clarifying question, or a rejection. It's a small design choice that does a lot for trust.
The last one is about **people**. If a definition has an owner, name them. When the system is uncertain, offer the marketer a handoff to that person with the question, the generated query, and the gap already attached. Make it opt-in on both sides, because plenty of data engineers would prefer fewer messages, and that's their call. Then keep a log of the questions the system couldn't answer. That log is a ready-made backlog for the semantic layer, and each item cleared makes your product more accurate.
Look, it's rare for a feature to help the customer and your own roadmap at once.
## About that copy
One small request. Please stop putting "no dependency on data teams" on your website. It pitches the wrong thing to the people who often sign off on the purchase, and it promises marketers an independence the accuracy figures don't support. 😉
## The human side of the same problem
I've been working on this from the user end too. My [Talking to Data Engineering](https://www.martechtherapy.com/talking-to-data-engineering/) series, a sponsored set of guides, helps marketers have these conversations without a tool in between. This piece covers the product side of the same problem.
*Read the latest guide in the series here 👇🏻*
[How to write a data request someone can act onA request rarely gets refused. It gets built, exactly as written. Here are the six decisions to name before you send one. One page, free, no forms.Martech Therapy: CDP strategy and agentic AIMatthew Niederberger](https://www.martechtherapy.com/how-to-write-a-data-request-someone-can-act-on/)
## Will this idea really make a difference?
I genuinely don't know whether most data engineers want more contact with marketing. Some would welcome it. Others have spent years on the receiving end of vague requests and are perfectly happy with a queue between them. That's why the handoff has to be opt-in.
If you're building one of these interfaces and want an outside view before it ships, consider this an open invitation to get in touch with me. I'd much rather see it in preview than help untangle it after go-live.
Do you have any questions after reading this article?
Or need support with your Martech projects?
[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
### What is a forward deployed engineer, and who is paying for the one in your team?
URL: https://www.martechtherapy.com/what-is-a-forward-deployed-engineer-and-who-is-paying-for-the-one-in-your-team/
Last updated: 2026-09-28T08:22:18.000Z
At the Martech World Forum in London this month, Nate Wardwell from Hightouch talked about forward-deployed engineers and described them as a service Hightouch provides that is helping its customers. I wrote it up [in my recap](https://www.martechtherapy.com/martech-world-forum-london-2026-recap/) and left that question hanging.
Isn't that what independent consultants do?
I went and looked properly.
What I found wasn't really about job titles.
## What a forward-deployed engineer actually is
In short, someone the vendor employs, who sits inside your team and builds the thing. Not a trainer, not a support contact, not a consultant who writes a plan and hands it over. An engineer, in your standups, working in your systems, changing your configuration while the project is live.
Palantir is usually credited with inventing this, though I couldn't find a primary source for that. What's easy to find is everyone else adopting it. OpenAI has a Forward Deployed Engineering team. So does Salesforce, which says [it tripled the size of its own in six months](https://www.salesforce.com/news/stories/forward-deployed-engineers-making-ai-jobs-more-human/?ref=martechtherapy.com). Hightouch is hiring a Forward Deployed Analytics Engineer. Twilio has one, sitting in its go-to-market group rather than in Segment.
They're everywhere.
## Is a forward deployed engineer different from a solutions architect?
Here is the best thing I found, and it immediately settles the question of how new this is.
[Databricks](https://www.martechtherapy.com/tag/databricks/) is hiring a Senior Forward Deployed Engineer. The web address of that advert still reads `resident-solutions-architect`, and the reference number on it is the same one it has always had. The people managing these engineers now *report to a Director of FDE*.
The job didn't change. *The label did*. Definitely not new in Martech, am I right? Anyway, further down the advert, the embedding turns out to be travel to customers twenty percent of the time, which is one day a week.
***Figure 1** *. One posting on the Databricks careers site, read on 17 September 2026.*
Adobe and [Tealium](https://www.martechtherapy.com/are-mcps-the-usb-c-of-ai-tealium/) still describe their consultants as an extension of your team, which is the older phrasing for the identical offer. [Snowflake](https://www.martechtherapy.com/how-snowflake-recruited-zeotaps-composable-cdp/) calls its version a *Resident Solutions Architect*, dedicated to you and delivered remotely by default.
So no, the arrangement isn't new. Something else is.
## Why vendors give the implementation away
What's new is that the commercial logic has been written down, and it's unusually frank.
Joe Schmidt at Andreessen Horowitz published a piece in June 2025 called [Trading Margin for Moat](https://a16z.com/services-led-growth/?ref=martechtherapy.com). His advice to software companies is to *stop protecting their margin and grow gross profit instead*, to *sell implementation at cost*, and to keep sales targets off the people doing the implementing. His evidence is that ServiceNow floated on a 63.2% gross margin and reached 79% by 2024, while Workday went from 54.1% to 75%.
> Give the services away early, take the margin back later.
What the services buy, in his own phrasing, is control of where and how the data enters the system.
Read that again if you have ever sat in a CDP selection. The implementation isn't the cost of winning the deal. The implementation is the thing being bought.
## Do vendors actually make money on implementation?
Look, I wanted to know whether this was investor writing or something already happening in our category, so I spun up some agents to sift through SEC filings of the Martech companies that publish enough detail to tell.
Sprinklr does.
In the financial year ending January 2026, it earned $100,861,000 from professional services and spent $100,783,000 delivering them. That is a gross profit of seventy-eight thousand dollars on roughly a hundred million of implementation work. *A margin of *0.08%**.
The year before was minus 3.3%. The year before that, plus 0.7%. Subscription margin over the same period sat at 76.4%.
***Figure 2** *. Sprinklr's software business and its implementation business, gross margin by financial year.* ***Source** *: Sprinklr FY2026 Form 10-K.*
Three years hovering within a few points of zero isn't a exactly scheduling accident. It's a strategically calculated price. Somebody decided that implementation would be sold at what it costs to deliver, and the subscription would carry the business, and that is exactly the advice above showing up in an audited set of accounts.
To be fair to the argument, *this is a choice rather than a law*.
[Klaviyo's](https://www.martechtherapy.com/map-cep-or-cdp-klaviyos-james-fang/) filing says its product-led approach has limited reliance on professional services teams for implementation, and it doesn't break services out as a line at all. Braze combines its services costs with its hosting costs, so nobody outside can see the split.
Two different bets about how much help a customer needs before the product works.
[MAP, CEP, or CDP? Klaviyo’s James Fang on where marketing automation is headedKlaviyo’s James Fang on CDPs, MAPs, AI, and why the future of marketing automation is about consolidation and real business impact.Martech Therapy: CDP strategy and agentic AIMatthew Niederberger](https://www.martechtherapy.com/map-cep-or-cdp-klaviyos-james-fang/)
## Why OpenAI says the limit is your organization, not the model
In February, [OpenAI announced multi-year partnerships](https://openai.com/index/frontier-alliance-partners/?ref=martechtherapy.com) with BCG, McKinsey, Accenture and Capgemini. Each firm is building a dedicated practice certified on OpenAI's technology, working alongside OpenAI's own forward deployed engineers. Accenture is putting ChatGPT Enterprise in front of tens of thousands of its own people.
The sentence that stopped me is in OpenAI's announcement:
> The limiting factor for seeing value from AI in enterprises isn't model intelligence, it's how agents are built and run in their organizations.
A frontier model company saying the constraint is not the technology but the organization buying it. Not exactly rocket science in 2026, Sam.
I've been making that case about Martech for years and calling it [readiness](https://www.martechtherapy.com/tag/martech-readiness/). It's strange to see it arrive from that direction, and it took Salesforce roughly a decade to assemble the partner ecosystem OpenAI has put together in about twelve months.
## Sign up for free
Receive my independent Martech insights and thoughts directly in your inbox.
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
## Where an embedded engineer helps, and where it goes wrong
Peter Bendor-Samuel, who founded the analyst firm [Everest Group](https://www.everestgrp.com/?ref=martechtherapy.com), wrote the most useful skeptical piece I found on this. His distinction is that
> Embedded engineers make sense in systems that change continuously, where waiting for a release cycle would break the business, and are actively harmful in traditional systems built for stability, because changing production code in real time walks straight past testing, validation and release management.
I think he is right and I think *Martech inverts his risk*.
His warning assumes there is governance to walk past.
In most Martech stacks there isn't much.
No release process worth the name, no test environment anyone trusts, change control that amounts to a message in a Slack or Teams channel. So the embedded engineer ends up supplying the only controls you have.
That feels like a gift right up until the day they leave.
## What level of engineer are you actually getting?
Something to ask before any of the above, and almost nobody does.
These are laddered roles. Databricks runs forward deployed engineer, senior and staff as separate rungs. Salesforce advertises the job at more than one level in a single posting, and the experience line in that advert reads three or more years, or six to ten for the senior levels. Three years and ten years, same title, same advert.
Your contract will say a forward deployed engineer. It will rarely say which one.
The difference doesn't show up in whether the work gets built, because somebody three years in will build what you asked for and build it competently. It shows up in whether anyone tells you that what you asked for is going to collide with the thing running on the other side of the business.
That judgement comes from having watched a few stacks go wrong in similar ways, and there's no shortcut to it.
So name the level in the statement of work, and ask how many deployments the person actually turning up has finished. Not the pod. The person.
## Did the capability stay when they left?
The promise attached to all of this is **capability transfer**, and the vendors write it down themselves. Salesforce's own forward deployed engineer advert asks the person to co-build alongside customers, sharing best practices and enablement as they go, leaving teams more capable after each engagement than before.
That's a testable claim, and it's the only part of this you will control.
I would test it with the three things I always come back to.
1. Did anything about how your team is organized change?
2. Did the work simply route around your team to the visitor?
3. Is the capability still in the building after the engagement ends?
And is the process that now runs your stack yours, documented somewhere you can find it, or is it theirs. Ok, so four things.
There is an uncomfortable part underneath, and I want to state it without making it an accusation.
> The person embedded in your team has a **renewal** behind them.
Their employer's revenue depends on you *continuing to need the platform*, and possibly on continuing to need them. That's not a character flaw in a good engineer, most of whom I've found to be excellent.
It's how they're paid.
You already apply this instinct elsewhere. It's the same reflex as asking who published the page, which I [spent a month measuring](https://www.martechtherapy.com/can-you-trust-ai-to-research-martech-vendors/) across three thousand sources that AI assistants cite about buying a CDP. The sources you research with are mostly published by sellers.
Now the person who builds it works for one too.
## What forward deployed engineers mean for independent consultants
Back to my own question, since I am an independent Martech consultant.
If a vendor can put a capable engineer in your team and charge you roughly what that engineer costs, then every independent, every boutique agency and every systems integrator is quoting against a price that isn't really a price.
Honestly, in year one that is a hard thing to compete with, and I suspect it's part of why [Martech work has felt slower this year](https://www.martechtherapy.com/is-martech-work-slowing-down/) for a lot of people I talk to.
I don't think that's a scandal either, and on day one it's a decent deal for the buyer.
Year one is not the whole of it though.
I have seen what a vendor bills per hour for this kind of work. Two hundred and seventy five dollars. That is not a rate an independent needs to be frightened of, as long as nobody gets greedy, and an independent usually turns up having seen more than one stack, which tends to be the thing you are short of.
I'm biased here.
There's a hole in my own argument I should name.
If the services really are sold at cost, the vendor isn't earning anything on that engineer, which takes the rate argument away from me entirely. It also answers the question of what the engineer is there to protect.
> The money is in the subscription, so the engineer's job, structurally, is to make the subscription stick.
That's not cynicism about the individual, *it's where the margin sits*.
Which means my case was never really the rate. It's that I don't have a renewal behind me, making me more objective.
The part worth modelling is the second and third year.
***Figure 3** *. Illustrative, not data. The same two days a week of help, priced two ways, over five years.*
If the capability genuinely transfers, the help you buy should shrink every year, because *your team needs less of it*.
If it doesn't transfer, it doesn't shrink, and the line keeps climbing at the angle it started at.
That is most of the difference, and it has very little to do with the hourly rate.
The other cost isn't money at all. The person who knows how your stack works, why that field is there, which of your decisions were deliberate and which were a workaround nobody wrote down, is on somebody else's payroll. That knowledge leaves when the engagement does, and it doesn't leave a document behind.
The honest version of my own position is that hiring someone independent doesn't remove that problem. It moves it. I have my own incentives, and you should ask about them.
## What to ask before you accept a forward deployed engineer
Ask who pays the person, out loud, at the start, and not as a challenge.
It changes how you read the advice, the same way knowing the publisher changes how you read a page.
Then *put the capability transfer in the contract* instead of the kickoff deck, next to [the dates and the rights you already argue about](https://www.martechtherapy.com/the-martech-contracts-dates-and-rights/). What gets documented, who reviews it, what your team is expected to be able to do without them by a named date.
Back in London I asked whether this pattern means we are understaffed, underskilled, or buying tools that are still too complex to absorb.
I said I had no idea, maybe all three.
I have half an answer now.
Sprinklr's accounts say the vendors have already concluded that *the tools can't be sold without someone coming along to build them*, and they have priced that in. Which of the three that is, I still couldn't tell you, but it's no longer a question anyone is leaving open.
It has been settled already, in the margin line.
Do you have any questions after reading this article?
Or need ****independent support** with your Martech projects?
[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
### How to write a data request someone can act on
URL: https://www.martechtherapy.com/how-to-write-a-data-request-someone-can-act-on/
Last updated: 2026-10-03T12:01:09.000Z
SPONSORED
****Sponsored by Databricks.** [Databricks](https://www.databricks.com/?ref=martechtherapy.com) commissioned and funded this guide and reviewed it before publication for factual accuracy. They did not get to change the conclusions.
[Full disclosure at the foot of this post](#about-the-series).
A badly written data request rarely gets refused. It gets built.
That is the part people miss when they complain about the queue. You ask for *lapsed customers*, three weeks later you get lapsed customers, and the team who built it did exactly what the message said. Then the campaign underperforms and *nobody can point at the mistake*, because there was not one.
Lapsed meant a hundred and eighty days in the warehouse and ninety in your head. *The message never said which, so somebody chose*.
That is a different failure from the one in [guide 1](https://www.martechtherapy.com/helping-marketing-and-data-engineering-same-word-different-meaning/).
There, *two people used one word for two things* and found out weeks later. Here everybody understood the words perfectly well. The *request simply did not say enough* to be built from, and the person who picked it up filled the gaps so they could get on with their afternoon.
Popular meme from back in the day explaining the disconnect.
Guide 1 opened on this, which I have seen a version of in most Slack channels I have been let into:
> Can you sync the lapsed-customer audience to Braze in real time? Just needs the churn model score on each profile.
Raise your hand if this all seems very familiar to you.
Guide 1 asked what its words mean. This one asks *what is missing from it*. Six things, as it turns out, and every one of them is a decision that gets made either by you now or by somebody else later.
One thing this is not about before we truly dive in.
It is not about writing more, or writing more politely. The rebuilt version at the bottom of this piece is five sentences long. The point is which five.
Six questions, one page
Six questions to read your own draft against, plus three requests rebuilt.
[Download the PDF ](https://www.martechtherapy.com/content/files/2026/09/talking-to-data-engineering-02-how-to-write-a-data-request.pdf)
## Don't miss it when guide #3 drops.
Practical Martech insights delivered straight to your inbox.
Sign up for the newsletter below 👇🏻
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
## Who you mean
The message says "the lapsed-customer audience." That is a label, and labels do not survive the trip. Every system in the building has its own idea of lapsed, none of them is written down, and the one in your head is not any of them.
Write the condition instead of the label. Customers who have bought at least once and have no purchase in the last 90 days, from the orders table, where a later-refunded order does not count as a purchase.
That sentence is longer than it wants to be, and it took three attempts to get there, which is the part worth telling you about.
I wrote "lapsed customers" first.
Then "no purchase in 90 days, refunds excluded", which sounds specific and is not:
> It can mean the refunded order does not count, or that anybody who has ever had a refund is out of the audience entirely, and those are different groups.
Then somebody read the fixed version and asked whether people who have never bought anything at all qualify. Which they do, under that wording.
They have no purchase in 90 days.
They have no purchase in any days.
An audience built to win back lapsed customers would have gone out to a pile of people who were never customers.
Three passes on one sentence, each one finding a label hiding inside the last fix. That is not me being careless. It is what the whole thing is like, and it is why the answer is to write the condition down where somebody can argue with it rather than to think harder in private.
The exclusions are where this goes wrong without anyone noticing. Test accounts, employees, people who bought through a channel you do not own. Somebody has to decide about each of those, and if you do not, they will, using whatever seems reasonable on the day.
## The key that has to travel
"On each profile" tells them nothing about how the records get matched at the other end.
Write which identifier travels the whole way. Keyed on the hashed email, which is what our Braze setup matches on.
Note the "our". Most destinations can match on several things, so naming the one yours is configured for is a different claim from naming the one the product supports.
This is the one where the failure is quiet and expensive.
Records arrive, the job reports success, and the campaign reaches a third of the list because two thirds could not be matched on the key that was sent. The dashboard says it worked. Guide 1's entry on [customer](https://www.martechtherapy.com/glossary/#customer) is the same problem one step earlier, and guide 4 goes into what happens when the key is right and the matching is not.
## When, how often, and why then
"In real time" is the most expensive phrase in the message, and guide 1 already made the case for why. What it does here is worse than ambiguity: it gets priced.
Write the deadline, the cadence and the reason behind them. In place by 07:00 CET and refreshed daily, because the send goes at 09:00 CET.
Put the time zone in. It looks like pedantry right up until the team building it is in another one, and then it is the difference between a morning send and an afternoon one. If the job is new rather than recurring, say which morning it has to start, because otherwise "daily" begins whenever the work finishes.
A deadline with a reason attached can be negotiated. Somebody can come back and tell you that 07:00 costs four times what 23:00 costs, and ask whether the send could move. A speed with nothing behind it cannot be argued with, only quoted for. I wrote about where vendors draw that line in [real-time from a warehouse](https://www.martechtherapy.com/right-time-marketing-and-the-speed-of-context-decay/), and guide 3 is entirely about the cost.
## Where it lands, by what method, and in what shape
"Sync it to Braze" names a destination and stops. Arriving somewhere is not the same as arriving usable, and naming a destination is not the same as naming a route into it. Most tools of any size offer several, and they differ in cost, latency and who has to maintain them.
Write the route and the shape as well as the place. Into Braze via the existing scheduled sync, with the churn score as a number 0 to 100 and the other fields as in the attached list.
The churn score is worth its own sentence, because it was in the original message and it is the sort of thing that falls out of a request while the request is being tidied up. It is the only part of that first version that was specific, and specific things deserve to survive.
Export the destination's field list and attach it. It takes a minute, and it settles two days of exchange about names, types, and which fields are mandatory. Of everything in this piece, that is the cheapest minute available.
## How much, and how far back
The message says nothing about size. Almost none of them do, and this is the omission that turns a small job into a stalled one.
Write the numbers. Roughly 40,000 records, current state only, no history.
Volume is the obvious half. History is the half that costs, and the half nobody writes down. Forty thousand current records is a small job. Forty thousand records with three years of behavior behind each one is a different job with a different bill, and the request that produced both of those reads identically. If you do need history, say how far back and why, because a backfill is usually a one-off piece of work that has to be planned around everything else rather than a setting somebody flips.
Left out, the job gets scheduled as though it were free, and the conversation about whether it is affordable happens after somebody has already built it. That conversation goes much better before.
## What tells you it worked
Also missing, and also missing almost every time.
Write what you will judge it on. Judged on a purchase within thirty days of the send by somebody in the audience, which is already instrumented, and spot-check twenty records against the orders table before the first send.
I had written "30-day reactivation" there, which is a phrase I have said out loud in meetings for years and which means nothing reliable to anybody who has not been in those meetings. In the sentence about the measure. In a guide about not doing that.
Two things come of saying it. The people building it can tell you when your measure cannot be calculated from what you have asked for, which happens more often than you would like. And when it ships, there is a number rather than an argument. Without one, the work goes out, nobody can say whether it worked, and the next request starts from nothing. Guide 6 is about writing that measure so a system can act on it.
The spot-check is the cheap half of that sentence and it does something separate. A measure tells you whether the campaign worked. Twenty records read against the source tells you whether the thing you are measuring is the thing you asked for. Those fail independently, and the second one fails silently, which is why I would rather find out on twenty rows than on forty thousand.
## Three of these are yours, and three are a conversation
Six questions handed to one person reads like homework, and that is a fair reason to put the sheet down. So it is worth saying which ones are actually yours.
Who you mean, when it has to be there, and what will tell you it worked are yours alone. Nobody else can answer them, and nobody else should try. The identifier, the destination and the route into it, and the volume and history are the other three, and those are questions about somebody else's system that you are not expected to answer on your own. On the sheet they are marked shared, for exactly this reason.
That leaves three sentences you have to be able to write, which is a much smaller ask than six, and it is the honest version. If your request names the audience as a condition, the deadline with a reason, and the measure, the other three become a short conversation rather than three weeks of silence.
Some of these you cannot answer, and that is fine. You may not know how many records there are, or which identifier the destination keys on, because those are questions about somebody else's system.
Say so explicitly, and on the shared three that is the whole job. "I do not know what the volume looks like, can you tell me before we size this" is a request. Silence in the same place is an assumption, and it will be resolved by whoever picks the ticket up without either of you noticing it happened.
Naming the gap is worth almost as much as filling it. It tells the person reading that you know the decision exists.
## The same message, rebuilt
> Can you send customers who have bought at least once and have no purchase in the last 90 days, from the orders table, where a later-refunded order does not count as a purchase, to Braze, keyed on the hashed email our Braze setup matches on. It needs to be in place by 07:00 CET and refreshed daily, because the send goes at 09:00 CET. Via the existing scheduled Braze sync, with the churn score as a number 0 to 100 and the other fields as in the attached list. Roughly 40,000 records, current state only, no history. We will judge it on a purchase within thirty days of the send, which is already instrumented, and spot-check twenty records against orders before the first send.
Five sentences, and nothing in it that somebody would otherwise have had to guess.
## Before you send the next one
Take the request you were about to send and read it against the six. Mark the ones it does not answer, and fill those in, including the ones you think are obvious. Obvious is where this goes wrong, because obvious to you is a definition nobody else has seen.
It moves the argument from week six to this afternoon, which is the only place it is cheap.
And it works in the other direction too. If you are the one receiving a one-line request, the sheet is a reasonable thing to return with a note about which question it does not answer. That is a more useful reply than asking what they mean by lapsed, and it costs a good deal less than building it twice.
Keep it open while you write
Two sides of A4\. Six questions, the stall words, and three requests rebuilt.
[Download the PDF ](https://www.martechtherapy.com/content/files/2026/09/talking-to-data-engineering-02-how-to-write-a-data-request.pdf)
**Next in this series:** what real time actually costs. All six live on the [Helping Marketing Talk to Data Engineering](https://www.martechtherapy.com/talking-to-data-engineering/) page as they publish, and every term across the series is collected in the [glossary](https://www.martechtherapy.com/glossary/).
---
## About the series
#### Series Sponsorship Disclosure
Databricks came to me in the summer of 2026, after the agentic CDP series, and asked whether I would write a set of practical guides for marketers. There are six of them, and you are on the second one.
Here is the arrangement in full. Databricks reviews each guide before publication and may suggest factual corrections. Anything they flag as factually wrong, I fix. Anything they would prefer I said differently, I do not. The conclusions, the structure and the tone are mine, and so is the decision about what goes in and what stays out.
The guides are educational resources, not product recommendations. None of the six guides names a Databricks product, and none of them concludes that you should buy one.
Would I have written something like this anyway? Probably, eventually, in pieces. Their support is why it happens now, as a series, with enough time to do it properly.
Nothing here is gated. No form, no email capture, and the PDF is a direct download.
If you think I have something wrong, or have overlooked an important perspective, please tell me. I would rather know.
### Can you trust AI to research Martech vendors?
URL: https://www.martechtherapy.com/can-you-trust-ai-to-research-martech-vendors/
Last updated: 2026-09-21T05:17:33.000Z
I spent a day this week asking four AI assistants the *twenty questions a marketer asks when they are choosing a customer data platform*, and writing down every source each one used to answer.
Same questions, three times each, all in one day so nothing could move underneath me. About three thousand sources in total.
An article I wrote in August led me here. I'd asked whether [Martech work was slowing down](https://www.martechtherapy.com/is-martech-work-slowing-down/), and one answer that kept coming back was that buyers are handling more of the early stage themselves, *with an assistant rather than a person*. The claim that AI has replaced the analyst report as the first stop keeps getting made, including by me.
[](#free-resource)
📄 [Click here to download](#free-resource) the free research paper.
Nobody seemed to have checked what it was reading. Until now.
The questions were ordinary ones.
- What is a CDP, and do I actually need one?
- Is a CDP still necessary if we already have Snowflake?
- Which CDP should a mid-size European retailer choose?
- What are the hidden costs of implementing one?
- Which CDPs are strongest for identity resolution?
- What should I ask a vendor before signing?
Twenty of those, written the way somebody types them rather than the way a researcher, or someone like myself, would phrase them, and frozen before the first run so the identical set can rerun some time from now.
Here is what the research told me.
More than half of what these assistants cite when you ask about buying a CDP *was published by a company that sells CDPs*, or by something a CDP vendor owns.
**Fifty-four percent**, give or take.
And that's the *polite version* of the figure.
For roughly one source in five, I couldn't work out who owned the site at all, and I left every one of those out rather than guess. If any of them turn out to belong to a vendor, the number only goes up.
***Figure 1** *. 53.8% is a floor, not an estimate. The hatched block is the 18.7% whose owner could not be established.*
## What I got wrong about cdp.com
I started this expecting cdp.com to be the villain.
It's a [Treasure AI](https://www.treasure.ai/?ref=martechtherapy.com) property (Treasure AI being the CDP vendor that used to be Treasure Data, yes, they renamed too), and it reads like a neutral encyclopedia for the category. It's also the *single most quoted site in the whole study*, cited more than twice as often as Gartner.
So I went looking for what they were hiding.
*Nothing*, as it turns out.
It says who owns it *in the footer of every page* and again on the About page.
A vendor explaining its own category in public is a normal thing for a vendor to do, and the fact that it has become the category's default reference book says more about the rest of us not writing one. And kudos to the marketing team.
That leaves the genuinely hidden material at about half a percent. One site, quoted fifteen times.
## The one source that doesn't disclose who pays it
That site belongs to a company called **Spotlight**, on a subdomain called research, and what it publishes is summaries of [Forrester Wave reports](https://www.martechtherapy.com/the-forrester-wave-halo-measures-your-reference-program/).
Spotlight's own website describes its business as influence orchestration, for more than 190 technology vendors including Adobe, ServiceNow, Workday and SAP. *Companies pay them* to make sure their name shows up wherever a buyer is likely to look, and the site lists *AI assistants* as one of those places.
So a firm that's paid to get its clients onto your shortlist runs a research site, and the assistants quote it back to you as a source. There's a disclaimer on the pages, but it's about Forrester and [Gartner](https://www.martechtherapy.com/beyond-the-gartner-magic-quadrant/) endorsement, *not the client list*.
Is that a scandal?
Not really. Spotlight publishes what it does, openly, and I'm describing a business model rather than accusing anyone. This is the service working exactly as it's sold, and that is sort of the problem.
Three other sites have the same shape, and I left all three out because I couldn't establish who runs them and my rule was that nothing goes in the vendor pile on suspicion. Between them they were quoted 42 times. All three registered their web address in March this year, none names a company anywhere on the site, and all three have their ownership records hidden.
If any of those turn out to belong to a vendor during my next evaluation run, that half a percent stops being a rounding error.
## Why the neutral question returns worse sources
Two questions went into the set expecting to be the worst offenders. Both name a company directly.
- What do customers complain about with Twilio Segment?
- Is Treasure Data any good?
To be fair, these are, theoretically, questions users could ask, and by no means my judgement of those companies.
They turned out to be the cleanest questions I asked. Naming a company got **29% vendor-published sources**. Not mentioning a company, and every other type of question got **55%**.
***Figure 2** *. Asking about a named company returned 29% seller-published sources. Asking the even-handed question returned 55%.*
Ask about one company by name and the assistant goes looking for people with opinions about that company. Ask the fair-minded, even-handed version, what are the best customer data platforms, and it goes to the category's literature instead. The category's literature comes almost entirely *from the people selling* into it.
I wouldn't build a policy on two questions, and the pointed phrasing is tangled up with the naming in a way I can't separate here. The direction is still worth knowing. The question that *feels most neutral* is the one that brings back the most interested evidence.
## Why ChatGPT cites more vendor material than the others
OpenAI's ChatGPT *cited vendor-published sources about 81% of the time*, the highest of the four. Perplexity sat in the mid-forties, the lowest. That gap is bigger than anything else in the data.
That's not a matter of taste, because every search got logged. Really, a lot got logged. That's what you get [when you used to be an analyst](https://www.martechtherapy.com/your-agentic-cdp-will-optimize-what-you-measure/). 😉
In well over half its searches, ChatGPT told the search engine to look inside one specific website and nowhere else, and the websites it picked were nearly always vendors. Segment. Hightouch. Tealium. Adobe's own help pages. None of the other three did this even once, apart from Gemini on a handful of occasions.
So it's not stumbling onto vendor material because the internet is full of it. It has decided in advance that *the vendor's own site is the best place to look*, and gone there.
For a question about how a product works, that instinct is probably right. For "which one should I buy" it's closer to asking the salesperson.
## The risk is highest for first-time buyers
So who does this actually land on?
The people asking the most basic questions, which is the opposite of where you would want it. And you can quote me on this.
Sites that are vendor-owned without looking it *make up over a fifth of the sources* at that stage, against under a tenth once someone is comparing named products. They show up most when the question is a beginner's one.
- What is a CDP?
- Do I need one?
Analyst material and review sites *barely register* at that stage.
Worse, half the time there are no sources at all.
On the beginner questions, **fifty percent* of the responses came back with nothing cited*, answered from memory with no working shown. Once someone is at the shortlist stage, that *drops to *six* percent*.
So the person least able to judge what they're being told gets the most interested sources and the least chance of seeing where any of it came from. The person who already knows enough to name three vendors gets the sourced version.
***Figure 3** *. Out of every 25 sources cited, where they came from, by how much the buyer already knows.*
## Ask the same question twice and the sources change
*Every question ran three times* on the same day. Around seven out of every ten sources changed between two identical runs.
Across all four, only twenty sites out of more than four hundred were common to every one. [Bill Widmer ran a bigger study at Orbit Media](https://www.orbitmedia.com/blog/ai-citation-sources/?ref=martechtherapy.com) on different questions and found the same spread, so it is **not a quirk** of my setup.
***Figure 4** *. The same question, asked twice on the same day. Around three sources in ten survive.*
Honestly, this is the one that changed my mind, and it cuts against a lot of confident writing about AI search, some of it mine. If you asked an assistant which CDP to buy and screenshotted the reply, you didn't capture what AI thinks. You captured one run. Ask again after lunch, or the next morning, and most of the ground under it has moved.
## What this does not prove
It doesn't mean the recommendations were wrong.
Look, I want to be exact as I can about this, because the jump from "these sources are interested" to "therefore the advice is bad" is a short one and I haven't earned it.
A vendor's own documentation is often the most accurate description of **their product**. Checking whether the recommendations hold up is a much bigger job and I haven't done it.
What has changed isn't the accuracy. It's whether you can see the working.
When I read five sources myself, I notice that two of them are a vendor's glossary and I mark them down. That discounting still happens with an assistant, but it happens somewhere I can't see, and nothing is left behind to show it happened. The AI assistant's black box.
I wrote something like this about agentic CDPs in July, that the old arrangement worked because [a human sat between the bad number and the decision](https://www.martechtherapy.com/your-agentic-cdp-will-optimize-what-you-measure/). That piece was about a number that couldn't be right.
This time it's about who wrote the page.
Unfortunately, ot shows up in procurement before it shows up in accuracy. At some point someone asks where the shortlist came from, the same way they eventually ask [what the contract actually lets you do](https://www.martechtherapy.com/the-martech-contracts-dates-and-rights/). A couple of years ago you could answer that.
> Now the honest answer is that an **assistant suggested it**, from sources you never opened, about half of them **written by companies selling into the category**.
## Where AI vendor research helps, and where it stops
Quite far, actually, and I don't want the numbers above to talk anyone out of using these tools. If buyers really are taking the early stage on themselves, this is what that stage is now made of, so it's worth knowing where it holds up. It holds up for *the first two jobs*.
Learning the category is one. What a CDP is, [why composable and packaged differ](https://www.martechtherapy.com/composable-cdp-translated-for-marketers/), [what identity resolution means](https://www.martechtherapy.com/identity-resolution-a-practitioners-guide-to-who-owns-the-match/). The material is interested, but on the basics *interested* and *accurate* mostly overlap, because nobody gains from teaching you the category wrong.
Drawing up a long list is the second. The assistants *surface roughly the same names the analysts do*, so if you want eight vendors worth a look rather than one worth signing, you'll get there.
But there are exceptions. [Contact me](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com) if you want to know which ones.
It stops being reliable on the third job, which is the one everyone actually wants it for. *Does any of them fit us?* That turns on things nobody publishes:
- What your data really looks like rather than what your diagram says?
- Which of your teams will still be there in a year?
- Whether a vendor has ever worked in a stack shaped like yours?
So the assistant falls back on the category's literature, and the law of averages AI has been built on, written by the people with something to sell, and it answers confidently, *because it always does*.
Three things I'd do, none of them overly dramatic.
Ask for the sources and spend two minutes on who publishes them, which is the whole defense and almost nobody does it. Treat the beginner-stage material as the least sourced you'll encounter, not the most. And if the decision is worth six figures, ask the question more than once, because a single reply is one sample from something that moves seven sources in ten between the moment you started reading this article and now.
And on the third job, the fit question, *get someone in the room who has done it before*. Not because AI is untrustworthy, but because the thing you need at that point was never written down anywhere for it to read.
The data, the questions and the ownership table all go up alongside this, and I'll run the identical set next time to see what moves. If you think I've classified something wrongly, the table has the evidence and the dates in it, and I'd rather be corrected than cited.
In the end, I am still not sure whether fifty-four percent is bad. It might just be what a young category looks like when the people doing the work haven't written enough of it down. What do you think?
## Free resource
[Download my free research paperThis companion paper includes more insights than the article.martech-therapy-research-what-ai-cites-companion.pdf246 KBdownload-circle](https://www.martechtherapy.com/content/files/2026/09/martech-therapy-research-what-ai-cites-companion.pdf "Download")
## Never miss free Martech insights
Sign up today and receive my newsletter, and research papers directly in your inbox.
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
Do you have any questions after reading this article?
Or need support with your Martech projects?
[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
### Same word, different meaning
URL: https://www.martechtherapy.com/helping-marketing-and-data-engineering-same-word-different-meaning/
Last updated: 2026-09-14T10:15:53.000Z
SPONSORED
****Sponsored by Databricks.** [Databricks](https://www.databricks.com/?ref=martechtherapy.com) commissioned and funded this guide and reviewed it before publication for factual accuracy. They did not get to change the conclusions. [Full disclosure at the foot of this post](#about-the-series).
A client of mine moved from head of IT to head of Martech at a national UK company. Technical background, ran engineering teams for years, nobody's idea of a novice. The first honest thing he said to me was that he *didn't know how to talk to data engineering*.
That surprised me, and then it stopped surprising me.
He had the vocabulary, and the vocabulary was the problem, because every word he needed already meant something slightly different on the other side of the table, and nobody had told either party.
Here is a request I have seen a version of many times, usually in Slack:
> Can you sync the lapsed-customer audience to Braze in real time? Just needs the churn model score on each profile.
Nothing about that is unreasonable.
It also contains six words that mean something different to whoever receives it than they did to whoever wrote it.
Sync, audience, real time, model, profile, customer.
This page is those words.
I've now watched this happen enough times to stop treating it as a people problem. Most Martech projects don't stall on disagreement, because disagreement is visible and someone escalates it. They stall on the false kind of agreement, where two people leave a meeting *certain they decided the same thing*.
Six weeks later the segment refreshes daily instead of hourly, the profile is missing the field the campaign was built on, and nobody can point at where it went wrong.
So where did it go wrong?
In the first half hour, when somebody said "real time" and we all nodded along.
Before I continue, a quick word on where this came from.
I wrote about [CustomerLake when Databricks launched it in June](https://www.martechtherapy.com/databricks-customerlake-the-warehouse-cdp/), and that turned into a run of conversations with their team. We kept arriving at the same observation from different directions:
> The marketers who end up living with these architectures often cannot describe what they need in terms the people building them can act on
That gap is not specific to Databricks, and it is definitely not new. So they offered to fund a set of guides about it, and I said yes.
One caveat before the list.
These are not standard definitions, because *there are no standard definitions*. They are the interpretations I run into most often. Treat them as prompts for a conversation rather than as a glossary, and use them to establish what each word means in your company.
## Six words, two meanings each
There are twenty-four of these on the sheet. Six need more than a line, because they are the ones I have watched cost people whole quarters.
The rest are on the printable version.
Take it into the meeting
Two sides of A4\. Twenty-four terms, what each side means, and the misreadings that run both ways.
[Download the PDF ](https://www.martechtherapy.com/content/files/2026/09/talking-to-data-engineering-01-same-word-different-meaning.pdf)
## Don't miss it when guide #2 drops.
Practical Martech insights delivered straight to your inbox.
Sign up for the newsletter below 👇🏻
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
### Real time
You usually mean *soon enough* that it does not feel broken. They hear *sub-second streaming*, which means infrastructure running continuously and a bill that arrives whether or not a campaign is using it.
Nobody has said a number yet.
There are several useful speeds between a nightly batch and true streaming. When people are pushed to say what they actually need, fifteen minutes is often enough, and sometimes daily is.
So *name the moment rather than the speed*.
What has to be acted on before it goes stale, and what does it cost you when it is an hour late? A cart abandonment email that arrives the next morning is worthless. A loyalty tier that updates overnight is fine. Those two need different architectures, and the gap between them is most of the budget.
I wrote about where vendors draw that line in [real-time from a warehouse](https://www.martechtherapy.com/right-time-marketing-and-the-speed-of-context-decay/) and guide 3 will be entirely about this topic.
### Model
You mean a prediction. Propensity to churn, likelihood to convert, next best offer or action. They mean the data model, which is the tables and how they relate to each other.
Most of the words here surface eventually, because somebody asks a follow-up question and the confusion turns up while it is still affordable.
This one does not.
Nobody asks a follow-up, because nobody thinks one is needed.
So you asked for a churn score, and three weeks later they walk you through an entity relationship diagram.
Say score or prediction when you mean the first.
Say schema when you mean the second.
Try not to say model at all in a room where both meanings are live and egos present.
### Segment and audience
Worth taking together, because you use them interchangeably and data engineering does not.
On segment, what they need to know is whether you mean the *definition* or the *result*. A saved query and a materialized table are different objects with different costs, and which one you meant changes what gets built. And budget often plays a deciding factor.
Audience is usually narrower on their side. It often means the *exported copy*, the version pushed to the destination, rather than the logic that produced it.
So "the audience is wrong" tells a data engineer almost nothing. It might mean the logic is wrong, which is yours. It might mean the export is stale, which is theirs. Those go to different people and take different amounts of time.
Say which one you think it is, and what made you think so.
### Customer
You mean a person. They mean an entity at a particular grain, which might be a person, an account, a household or a device, and they need to know which identifiers represent it.
It sounds pedantic until the first time it goes wrong.
In B2B, the customer is usually the account, so treating it as a person sends five people at the same company the same renewal notice.
In streaming, the customer is often a household with five profiles and one bill, so treating it as a person builds someone's recommendations out of their teenager's viewing.
Ask which grain before you ask for anything else. I have saved myself whole weeks with that question, and I still forget to ask it.
Guide 4 covers what happens when the grain is right, and the matching is not. I went further into that in [the identity resolution guide](https://www.martechtherapy.com/identity-resolution-a-practitioners-guide-to-who-owns-the-match/).
### Source of truth
You mean the dashboard you trust. They mean the designated system, governed dataset, or semantic definition that everything else derives from, which is usually not a dashboard.
There can legitimately be more than one.
Identity, consent, revenue and campaign performance can each have a different source of truth, chosen on purpose, and none of them is wrong.
So when your number disagrees with their number, ask which system each of you is reading from, and whether that system is the designated one for the thing you are arguing about. Usually you are both reading correctly, from different places.
### Governance
You mean the reason things take longer. They mean the reason the company has not had to disclose a breach.
Both are true. There is no misunderstanding here to clear up, only a difference in what the two of you are measured on.
Concede it early and out loud.
Say you know the constraint is not bureaucracy, and that you would rather work inside it than around it. It is true, and it changes how the rest of the meeting goes.
Guide 5 will be about who is actually allowed to say yes.
## Before the next meeting
Take the brief for whatever you're about to build. Find the three words in it that appear on this page. Ask each side to define them out loud, in a sentence, before anything else gets discussed.
That's it. Is it too obvious to be worth writing down? Probably, and I've watched enough projects lose a quarter to that exact obviousness to keep doing it anyway. It's the cheapest de-risking available to either of you, and the alternative is finding out in week six.
The one-page version
Twenty-four terms, what each side means, and the misreadings that run both ways.
[Download the PDF ](https://www.martechtherapy.com/content/files/2026/09/talking-to-data-engineering-01-same-word-different-meaning.pdf)
**Next in this series:** how to write a data request someone can act on. All six live on the [Helping Marketing Talk to Data Engineering](https://www.martechtherapy.com/talking-to-data-engineering/) page as they publish.
## About the series
#### Series Sponsorship Disclosure
Databricks came to me in the summer of 2026, after the agentic CDP series, and asked whether I would write a set of practical guides for marketers. There are six of them, and you are on the first one.
Here is the arrangement in full. Databricks reviews each guide before publication and may suggest factual corrections. Anything they flag as factually wrong, I fix. Anything they would prefer I said differently, I do not. The conclusions, the structure and the tone are mine, and so is the decision about what goes in and what stays out.
The guides are educational resources, not product recommendations. None of the six guides names a Databricks product, and none of them concludes that you should buy one.
Would I have written something like this anyway? Probably, eventually, in pieces. Their support is why it happens now, as a series, with enough time to do it properly.
Nothing here is gated. No form, no email capture, and the PDF is a direct download.
If you think I have something wrong, or have overlooked an important perspective, please tell me. I would rather know.
Do you have any questions after reading this article?
Or need support with your Martech projects?
[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
### Martech stacks, empires and vague rituals
URL: https://www.martechtherapy.com/martech-world-forum-london-2026-recap/
Last updated: 2026-09-10T11:59:26.000Z
On the flight home from [Martech World Forum in London](https://themartechweekly.com/martech-world-forum/london/?ref=martechtherapy.com), I did what any sci-fi fan waiting for Denis Villeneuve's final Dune film would do. I read Dune Messiah. As if my head didn't have enough to process after two days of Martech talks. 😉
Call it kismet, but Princess Irulan wrote this:
> "Empires do not suffer emptiness of purpose at the time of their creation. It is when they have become established that aims are lost and replaced by vague ritual."
Replace "Empires" with "Martech stacks" and read it again.
Is my passion for sci-fi now forever tainted by Martech? Apparently, yes 😐
Last year I shared a smörgåsbord of slide photos and let them speak for themselves. This year the program was about getting past the hype. So, ROI, value, and finding out what your stack actually contains.
And a lot of the speakers found themselves describing the problem Irulan wrote about.
[Martech World Forum, London, looking backAI was everyone’s “mot du jour” but it’s losing ground to calls for stronger foundations and more collaborationMartech Therapy: CDP strategy and agentic AIMatthew Niederberger](https://www.martechtherapy.com/martech-world-forum-london-2025-review/)
Last year's recap, if you want the smörgåsbord ☝️
## Schrödinger's stack
Juan Mendoza, CEO of The Martech Weekly, opened the event with an analogy. He called it *Schrödinger's stack*. The people who own a Martech stack can't really tell you what state it's in. Whether a capability is there and working, missing, or failing without anyone noticing, you only find out when someone opens the box.
His own research backs that up.
In The Martech Weekly's Enterprise Martech Outlook Survey 2026, **40.2% of enterprise Martech leaders* can't demonstrate a clear, measurable contribution from Martech to financial objectives or accepted proxies*. Most of that group, 33.9%, say the contribution is "accepted but not directly measurable."
And the chart files them under "Faith-Based Contribution" (yes, that's the actual label, I couldn't have made it up 😅).
Another of his slides listed what holds enterprise teams back.
Two lines could have come straight out of Dune Messiah.
One was "Good decisions from a decade ago," leaving teams "Stuck with a stack that's holding the business back." The other was "Philosophical ambiguity," where "No one is clear on *what the Martech stack is supposed to achieve*."
Nobody signs for a CDP without a purpose. A few reorganizations later, the people who had it have moved on. But the renewal still comes around every year.
One caveat.
It's TMW's own research, presented at TMW's own event. And some of the cohorts behind the splits are small, so I'd call them directional.
## Shoehorning
On day two, Lucy Spooner, Head of Customer Intelligence at Fortnum & Mason, shared the stage with Sonal Goyal, founder of [Zingg AI](https://www.zingg.ai/?ref=martechtherapy.com). Lucy walked through how Fortnum replaced, or rather rebuilt, its single customer view.
The old one was held by a third party. Lucy described it as a black box, where "whenever numbers were jumping around we didn't have the ability to go and deep dive." When Fortnum changed its till systems, the team "ended up just shoehorning our new data into our old formats." And the customer IDs were rebuilt every night, "which meant that everybody would get a new URN overnight."
Try running a control group on that. 🤦🏼♂️
Each of those was a sensible call when someone made it. Years later, it was simply how things were done.
The fix started with discovery. "I can't stress enough that phase one was so important," Lucy said, meaning the quality of the data, not just the fields and the volumes. They built the single customer view in-house, moved to a persistent ID, and connected it to their email tool so everyone worked from the same numbers. She mentioned presenting their data to the board the day before, then added:
> We wouldn't have done that a few years ago because we wouldn't have felt confident in it.
Shruti Ahuja, Head of Data & Digital Transformation at Virgin Media O2, covered how rituals survive a migration. One of her lessons:
> If old tools remain unofficially available, teams will revert during stress, maintaining double run-costs.
I mean, that's paying twice with better intentions 😉
And this one:
> Elegance in enterprise architecture is measured by what you remove.
Shruti Ahuja presenting at the Martech World Forum, London 2026
[The Martech Stack you bought twiceUnused features cost nothing. A second contract for a capability you already own costs what the invoice says, and no utilization survey will find it.Martech Therapy: CDP strategy and agentic AIMatthew Niederberger](https://www.martechtherapy.com/the-martech-stack-you-bought-twice/)
I wrote about the double spend two weeks ago ☝️
## Upkeep
Irulan covers lost purpose. Entropy covers the other side of it, which is upkeep.
*A stack that nobody maintains decays* even while the dashboards still load and the invoices still get paid. You rarely get one big failure. You get a slow pile-up, one workaround and one extra tool at a time.
[Extending Martech’s Law: why growth leads to decayMartech stacks rarely fail. They decay. Over time, more human effort is required just to keep the same outcomes. This article explores why ROI erodes quietly, how entropy shows up in real stacks, and why I built the Second Law of Martech scan.Martech Therapy: CDP strategy and agentic AIMatthew Niederberger](https://www.martechtherapy.com/extending-martechs-law-why-growth-leads-to-decay/)
More on entropy and Martech's Law
Fortnum's rebuild was as much maintenance as it was a build.
The data and analytics teams met twice a week, and the Director of Customer and the Director of IT sat in a weekly stakeholder meeting. Lucy called the single customer view "a continual journey," and they're still migrating it and adding data sources.
Keeping track of a stack starts with knowing what's in it, what each part costs, and when each contract comes up for renewal. I built [Martech Stack Builder](https://www.martechstackbuilder.com/?ref=martechtherapy.com) for exactly that. You map the stack, its vendors and its costs in one place, and contract and SLA management is now in open beta. End plug 😉
## Stepping aside
Maintenance is also a people job. Shruti put it plainly: "Transformation is Fundamentally a People Challenge," because "*human behavior, trust, and habits dictate final outcomes*."
Pete Markey, CMO at the University of Nottingham, made a related point in his conversation with Juan. He was talking about speeding up internal maturity and building skills. As a leader, he said, you sometimes just need to step aside and let the people who work for you do the job. His test for a use case was simple too, whether it adds value and makes the team faster and smarter.
> Stacks get defended by the people who built them.
To be fair, that's human. Whoever chose the current CDP has every reason to keep it looking like a good decision.
## Retiring a few rituals
Tony Byrne, Founder & President of [Real Story Group](https://www.realstorygroup.com/?ref=martechtherapy.com), drew on his new book, [MarTech 2030](https://www.lulu.com/shop/tony-byrne-and-scott-brinker/martech-2030/paperback/product-zmwvd4m.html?srsltid=AfmBOopHpMqXblk37HppXDkCUnsq44IGxXs56o1DqDZgCjfj5j1Jz-4O&page=1&pageSize=4&ref=martechtherapy.com), for his keynote.
He started by admitting he's wary of future-gazing altogether. He still remembers the keynote that sold Second Life as the future of marketing, and later the NFT ones. His words: "people don't always hold futurists accountable".
Then he named a few.
He called the big analyst firms and their quadrants "typically not your friend," which, having just written about [the Forrester Wave halo](https://www.martechtherapy.com/the-forrester-wave-halo-measures-your-reference-program/), I didn't mind hearing. His core advice was to "lighten at the edge".
Cap or cut spend on engagement platforms and "allocate those resources towards building your core", the way HSBC did. Large suites, in his view, "want to start at the edge and vacuum into their infrastructure". Nail, head... just spot on!
Jasmin Guthmann, Community Chair at [MACH Alliance](https://machalliance.org/?ref=martechtherapy.com), put the capability problem in two sentences:
> AI capability is what your tools can do. AI operability is what your enterprise can absorb, govern, scale and turn into outcomes.
Jasmin Guthmann presenting at the Martech World Forum, London 2026
Her boardroom checklist for any AI or Martech decision starts with "Can it interoperate?" and asks whether a new tool "Connects cleanly, or creates another island?"
## The next empire
This is where I got a bit uneasy. Almost every prescription at the event pointed toward a new center of gravity.
Matt Pilgrim, EMEA Partner Development Lead for Adtech and Martech at [Snowflake](https://www.snowflake.com/?ref=martechtherapy.com), explained data gravity. Applications, CDPs and AI models "increasingly come to the data not the other way around".
His example was Maya, a valuable customer who just bought skis and keeps looking at boots. The AI sends her 20% off. It doesn't know she has an open claim with the service team.
In Matt's words:
> Every fact that AI used was accurate, but a good prediction is not automatically a good business decision.
Matt Pilgrim presenting at the Martech World Forum, London 2026
[Which context wins when two systems disagree about your customer?Two systems calculate lifetime value differently and nobody has said which counts. I tried to score that in my context audit and broke my own rubric.Martech Therapy: CDP strategy and agentic AIMatthew Niederberger](https://www.martechtherapy.com/which-context-wins-when-two-systems-disagree-about-your-customer/)
What happens when two systems disagree about Maya ☝️
Data gravity was also the topic of the roundtable I hosted, and honestly, the discussion mostly repeated what Matt had shown on stage.
James Taylor, Head of Data & MarTech Platforms at HSBC, made the ownership case with a slide that simply said:
> Own your data, or your vendors will.
His list of outcomes for HSBC's own platform included "No vendor lock-in" and, my favorite, "Happy CFO". 😎
Another slide made the long-term case: building your own tooling needs sustained investment, and the payoff in total cost of ownership comes eventually.
James Taylor presenting at the Martech World Forum, London 2026
Fortnum is doing a smaller version of the same thing. The core is built in-house, and [Hightouch](https://www.hightouch.com/?ref=martechtherapy.com) is now being implemented for activation, which is pretty much Tony's lighten-the-edge advice in practice.
Everyone on stage worried about somebody else's lock-in.
Tony pointed at suites and HSBC at vendors in general. Snowflake flagged "Model family lock-in" on a slide where the recommended home for your context was a governed enterprise foundation, which is what Snowflake sells. It was also the event's global ecosystem partner, for what it's worth.
Look, I don't think any of them are wrong.
Jasmin made the point that groundwork laid today will most likely still be around in ten years, and I agree with her. Martech moves fast, but implementations have long shelf lives. Some of the warehouse builds going live this year *will still be running in 2036*.
## Where I'm unsure
Is the warehouse the next empire?
The data is centralized, access is decentralized, and costs scale with growth. That makes it useful, and also a candidate for the next single point of failure.
I don't know yet which of those wins out. Yet, I will remain positive.
Forward deployed engineers came up in the session by Nate Wardwell, Manager Analyst Relations and Partner Marketing at Hightouch. He described them as a service Hightouch provides, and one that's helping companies.
My question is a different one.
Isn't that what independent consultants do?
And if a vendor has to embed its own engineers before customers get value, what does that say?
To me it points at, and strong reaffirms, the distance between what the tools can do and what the companies buying them can absorb. That distance is [Martech's Law](https://www.martechtherapy.com/what-an-agentic-cdp-actually-is-and-why-marketers-should-care/).
Full disclosure, I'm an independent consultant, so I have a stake in the question. Understaffed, underskilled, or tools that are still too complex? No idea yet, maybe all three.
And then there's that HSBC slide.
Last year I argued that composable stacks look cheaper in year one and cost more by year three, once the operational work moves in-house. *HSBC is describing the opposite curve* for building your own tooling, expensive first and better later.
To be honest, the two might describe different things.
Or it really is a waiting game, and three years is too short to judge. When I wrote about [vibe coding](https://www.martechtherapy.com/the-dirty-truth-about-vibe-coding-in-martech/), I said building hands you the pager. HSBC's betting that carrying it pays off.
[The inherited costs of the composable stackIn Martech, every pricing model hides a workload. Suites sell convenience. Composable platforms sell control. Either way, you pay for someone to hold the complexity, the only question is who.Martech Therapy: CDP strategy and agentic AIMatthew Niederberger](https://www.martechtherapy.com/the-inherited-costs-of-the-composable-stack/)
The year-three argument
Anyway.
Irulan's warning was about empires once they're established, not while they're being built. Most of the stacks discussed in London are still being built, or rebuilt. So in five years, who checks whether anyone still remembers what the new one was for?
*Thanks to Juan and the whole Martech Weekly team for having me again.*
[](https://www.martechstackbuilder.com/?ref=martechtherapy.com)
Start building your Martech Stack designs today 👇🏻
[SIGN UP FOR FREE ](https://www.martechstackbuilder.com/?ref=martechtherapy.com)
### The Martech contracts dates and rights
URL: https://www.martechtherapy.com/the-martech-contracts-dates-and-rights/
Last updated: 2026-10-10T20:05:07.000Z
Last time I argued that [the cheapest money in a Martech budget is the capability you're already buying twice](https://www.martechtherapy.com/the-martech-stack-you-bought-twice/), and that the way to find it is to sort your invoices by capability instead of by supplier.
Say you do that. You find one. Now what?
Now the paper decides. And the terms that decide it aren't the ones I went through in the [pricing series](https://www.martechtherapy.com/cdp-cep-pricing-strategies-for-the-uninitiated/). Not the meters, not how a vendor counts a profile or an event.
But the dates, and the rights.
I've been handed a lot of Martech contracts over the years, usually late, usually with someone asking whether it's a good deal. Nobody's ever pleased to be in that meeting. Contracts are the vegetables of this job.
And it almost never is the question. The deal is mostly fine. What's rarely fine is whether anybody can do anything about it in the next eleven months.
[The Martech Stack you bought twiceUnused features cost nothing. A second contract for a capability you already own costs what the invoice says, and no utilization survey will find it.Martech Therapy: CDP strategy and agentic AIMatthew Niederberger](https://www.martechtherapy.com/the-martech-stack-you-bought-twice/)
**Where the duplicate spend actually comes from ☝️*
## Thirty days
[Common Paper](https://commonpaper.com/resources/2026-saas-contract-benchmark-report/?ref=martechtherapy.com) went through 16,140 signed agreements from 2,223 companies between June 2025 and June 2026\. 87% of them renew themselves. A thirty-day notice window is the standard, turning up in roughly 70%.
So a finding you make in month eleven is one you can't act on until next year. And the one you made in month six sat in a document nobody reopened.
Thirty days isn't a law of nature. Someone chose it, and they chose well. Long enough to look reasonable across a negotiating table, short enough that a marketing team without a renewal calendar will sail straight past it. Whoever drafted that has met a marketing team.
To be fair to the data, Common Paper sells standard-form contracts, so their sample leans toward companies signing on that paper rather than enterprise deals fought over by two legal teams. Take the precision lightly.
My guess is enterprise Martech is worse on notice windows, not better, because the terms are longer and the person who signed has usually moved on. Don't laugh, you know this is true.
Now, if you buy in Europe there's a right here that most people aren't using. The [EU Data Act](https://digital-strategy.ec.europa.eu/en/policies/data-act?ref=martechtherapy.com) became applicable on 12 September 2025, and it caps the notice period for terminating in order to switch providers at two months, with a transitional period of up to thirty days to complete the move. **It applies to contracts you signed before that date as well as after it**.
It's a ceiling, not a floor, so a thirty-day window's perfectly fine. What it catches is the other end. If one of your agreements demands ninety days, or six months, that requirement is no longer enforceable as written.
Has anyone checked yours?
## Improve, build or enhance
Here's the part I didn't expect to be writing in a piece about contracts.
**Most enterprise SaaS terms were drafted before generative AI existed**, and most of them grant the vendor a right to use customer data to improve, build or enhance the service.
In 2019 that clause covered bug reports and aggregate usage statistics. Today it functions as a training license, and nobody drafted it as one.
Common Paper again. Clauses that explicitly prohibit a vendor from training on your data have gone from under 1% in 2024, to 11% in 2025, to 14% this year. That's a fast climb. It also means most agreements still say nothing either way.
> 86% of contracts are silent on whether your customer data trains someone else's model. Silence is not a no.
TermScout's contract data, [published through Stanford Law's CodeX](https://law.stanford.edu/2025/03/21/navigating-ai-vendor-contracts-and-the-future-of-law-a-guide-for-legal-tech-innovators/?ref=martechtherapy.com), found that 92% of AI vendor contracts claim data usage rights beyond what delivering the service requires, against a market average of 63%. The same analysis found only 33% offering indemnification for third-party IP claims, and only 17% committing explicitly to comply with applicable laws, against 36% across SaaS generally.
Unfortunately, none of this is hypothetical.
Figma was [sued last November](https://news.bloomberglaw.com/litigation/figma-trained-ai-on-user-data-without-consent-class-action-says?ref=martechtherapy.com), a proposed class action in the Northern District of California, alleging it trained on millions of customer design files without explicit consent. The claim was framed as breach of contract and trade secret misappropriation rather than copyright, because the argument is that the marketing promised privacy and the terms did not.
Figma disputes all of it, and says training happens only with explicit authorization, on de-identified data, aimed at general patterns rather than customer content.
And in May a judge sent the whole thing to arbitration, on the grounds that the plaintiff had accepted Figma's terms of service, and those terms contain an arbitration clause.
Speechless.
In any case, the paper decided that too. A dispute about what the contract permitted, resolved by a different part of the same contract, before anyone got to the merits. Whatever else you think of that outcome, it's a fairly emphatic argument for knowing what you signed.
Adobe got there eighteen months earlier and went the other way. Enough customers objected to a terms update in June 2024 that Adobe [publicly committed](https://www.axios.com/2024/06/18/adobe-ai-customer-data-training?ref=martechtherapy.com) not to train generative AI on customer content.
Why does this land harder in Martech than in a design tool?
Because a CDP or a CEP holds behavioral data about identified people, and that changes what the clause is actually licensing.
Think about what you told those people.
Your consent notice explains why you collect the data and what you use it for. Improving a vendor's model is not on that list. It wasn't on the list when the notice was written, because the notice predates the capability, and nobody has gone back to ask. So you can end up with a lawful basis for processing that covers your use of the data and says nothing about theirs.
I don't think most vendors are doing this.
I think most of them have a clause that permits it, which is a different problem, and a much easier one to fix at renewal than after a complaint. Nobody's being sinister. They're just holding a permission they never asked for and have not thought about.
## Getting out
Two questions nobody asks at signature.
1. What happens if this doesn't work?
2. What do I take with me when I leave?
On the first, the benchmark is pretty bleak. Service level agreements appear in 26% of agreements, down from 29% in 2024\. Roughly three in four contracts promise nothing measurable about uptime at all, which is a confident position for an industry that sells reliability on every slide.
On the second, the Data Act is doing more work than most Martech buyers realize. [Until 12 January 2027](https://www.alston.com/en/insights/publications/2025/09/eu-data-act-switching-requirements-cloud-services?ref=martechtherapy.com) a provider may charge for switching, but only for costs it directly incurs. After that date switching charges go to zero. Data comes back in a structured, commonly used, machine-readable format. Early termination penalties survive all of this, so it isn't a free exit, but the cost of the exit itself's on a clock.
That's worth knowing at signature rather than at renewal.
A three-year term signed this year runs straight through that date, so the switching costs quoted in it are describing a world that expires halfway through the agreement.
If you're negotiating a multi-year deal in Europe right now, make sure to keep this in mind.
## Whose job this is
Marketing signs the deal and negotiates the meters such as usage and seats, because the meters are what the budget conversation is about.
Legal reviews for corporate risk, liability and indemnity and data protection. Whether a thirty-day window is operable by a team that has never kept a renewal calendar is an operational question wearing legal clothing. So nobody asks legal, and nobody asks anyone else either.
Procurement holds the dates, in a system marketing has no particular reason to open.
Silos, all over again.
There's evidence that owning this oversight pays.
The Martech Weekly found 62.2% of enterprise organizations now manage renewals proactively, and among those, 70.9% can show a clear measurable contribution from Martech, against 41.7% of everyone else.
Keeping a renewal calendar isn't administrative hygiene. It tracks with being able to defend your budget, which is presumably why the proactive ones bother. Though I can't tell you which way that runs. Maybe the calendar makes you defensible, or maybe the teams organized enough to keep one were always the teams who could show their numbers. Either way it's the same amount of work.
Same shape as the duplication problem.
Nobody did anything wrong, and the result is still bad.
## Three questions
Luckily, you don't need a legal review to fix most of this. You need three answers per contract in your stack.
1. When does it renew, and by when do I have to say otherwise?
2. What may they do with the data I put in, including whether any of it trains anything?
3. What comes back to me on the way out, in what format, and who pays for the move?
Then put the answers somewhere sorted by date rather than by supplier.
That list is the entire difference between a duplication finding you can act on and one you file until next year.
Honestly, the sorting is the whole trick, and it's the same trick as last time. Your contract register is organized around who you pay. Almost nothing you need at renewal is.
If you'd rather not do it by hand, [contract and SLA management](https://www.martechstackbuilder.com/solutions/agreements/?ref=martechtherapy.com) went into open beta on Martech Stack Builder. That one's mine, so take the rest of this paragraph with that in view.
It does the join this article keeps circling.
Upload the MSAs, the SLAs, the DPAs, and they get evaluated against your actual stack diagram, against the tools and the connections and the metadata already sitting on the canvas.
A clause ends up next to the system it governs instead of in a folder someone opens once a year. Ask in plain language, get the answer back with the clause cited.
Query your documents in full relationship to your Martech stack
It pulls the commercial terms onto the diagram too, so the cost data stops living in finance and starts living next to the architecture. Which is the capability-sorted list from last time, except you don't have to type it out yourself.
Review you Martech stack costs and contract details in a single overview
And, you get on-time notifications when a renewal is looming, in-app, through email, in Slack, or even via webhook.
## What the meters cannot tell you
The [pricing series](https://www.martechtherapy.com/negotiating-the-new-martech-economy/) answered what you're paying and how the meter runs. These are the terms that decide whether any of that is information you can use.
87% renew themselves. Most say nothing about AI training. Three in four promise nothing measurable about uptime.
None of that is a scandal. It's what standard paper looks like when nobody on your side is checking it for the dates.
[](https://www.martechstackbuilder.com/?ref=martechtherapy.com)
Start building your Martech Stack designs today 👇🏻
[SIGN UP FOR FREE ](https://www.martechstackbuilder.com/?ref=martechtherapy.com)
### The Forrester Wave halo measures your reference program
URL: https://www.martechtherapy.com/the-forrester-wave-halo-measures-your-reference-program/
Last updated: 2026-09-07T07:25:24.000Z
Last week the [Forrester Wave for B2C customer data platforms](https://www.forrester.com/blogs/b2c-cdps-enter-their-utility-era-data-is-the-foundation-but-outcomes-drive-investment/?ref=martechtherapy.com) came out, and I spent more time on the legend than on the chart. That's not where I expected to end up.
Ten companies on the graphic.
One of them, [Amperity](https://www.amperity.com/?ref=martechtherapy.com), carries a halo around its marker. Forrester's own footnote spells it out:
> A halo means above-average customer feedback, and a double halo means the vendor is a Customer Favorite.
*Nobody else* on the chart carries a halo at all. And nobody at all carries the double, so the Customer Favorite designation went unawarded in this market.
I said as much in a [short post](https://www.linkedin.com/feed/update/urn:li:activity:7501175803280351234/?ref=martechtherapy.com).
Then I went looking for how that mark actually gets made, and the method turned out to be more interesting than the placements.
## What left the chart in 2024
The Wave you're looking at isn't the Wave from two years ago, and the difference is not cosmetic.
In 2024 Forrester dropped the Challenger tier. Three bands now, not four. It also stopped using marker size to show market presence and started using marker prominence to show customer feedback instead.
That's the halo.
Where the graphic used to tell you how big a company was, it now tells you how its customers scored it.
**I like that trade**. Size wasn't the interesting question anyway, and plenty of people were misreading a big dot as a recommendation.
But something else came off the graphic at the same time.
Forrester used to mark non-participating vendors with a grey dot, and that marker's gone. Participation shows up in the written profile now, which means *the picture no longer tells you whether the company you're looking at took part in its own evaluation*.
That matters more than it sounds.
A company that skips the process still gets scored, on *public information*, which caps what anyone outside can establish about it. Forrester says so plainly:
> When vendors decide not to take part in the formal evaluation, it assesses them under its vendor participation policy instead.
Two years ago you could see which markers were built that way. Now you have to open the vendor profile to find out, and most people who look at a Wave never get past the graphic. It's true.
One addition, one removal. Only one of them made the coverage.
## What the halo is actually scoring
This is where I slowed down. I was involved in a lot of user research in the past. I am still passionate about it today.
[Forrester's methodology page](https://www.forrester.com/policies/forrester-wave-methodology/?ref=martechtherapy.com) sets out how customer feedback gets assessed. It considers whether the vendor provided the full complement of reference customers that Forrester requested, the response rate from those references, and the breadth of relevant functionality or services those references cover.
Since 2024 they're interviewed live rather than surveyed.
So those criteria measure two different things and print one mark.
The first is *what customers think*. That's the one everybody assumes the mark is about.
The second is *whether a company can produce the customers Forrester asked for* and get them to pick up the phone. Knowing which accounts to nominate. Having the relationship to ask. Having somebody whose job it is to chase a response rate through August.
Both are real capabilities, but only one of them is the product.
> A company with satisfied customers and a strong reference program will out-mark a company with satisfied customers and no reference program. The graphic prints one symbol for both.
Amperity taking the only halo here is a real result, and I wouldn't take it away from them. What I won't do is treat it as "customers rate Amperity highest of these ten", because the notation doesn't carry that claim and Forrester's own criteria are the reason it can't.
The nine bare markers are where this gets uncomfortable.
A bare marker can mean feedback that came in below the group average. It can also mean fewer references supplied than requested, or references who never called back.
From outside, how would you tell? If you're building a shortlist off this chart, that distinction changes what you do next.
A halo tells you a reference program worked. It doesn't tell you that the deployment you're about to attempt resembles the ones Forrester heard about, and the criteria themselves *include the breadth of functionality those references cover*, which is Forrester making the same point more politely than I just did.
Picture that request from the other end.
A vendor needs references, so an account manager emails the people who bought the platform and asks whether they will give an hour to a Forrester analyst. Saying yes is a favor, and favors turn on ordinary things. Whether the platform embarrassed anyone last quarter. Whether the person who ran the implementation is still in the job, because when that person goes, the one contact who could tell the story well goes with them and the reference never happens.
None of that is about the software and the selection is often biased.
## The comparison Forrester won't let anyone make
Almost every summary of a new Wave is a trend line.
Who climbed, who slipped, who fell off.
My experience with these reports started that way too.
Forrester's citation guidelines forbid the companies being evaluated from doing exactly that:
> Comparisons or references to past Forrester Waves on the same market, such as "A Leader for the second year in a row", are prohibited unless cited verbatim from the current Forrester Wave evaluation text.
So a company that's been a Leader twice isn't allowed to say so. Meanwhile that's exactly how the rest of us read a new one the moment it hits the feed.
The numbers underneath show why that rule exists. The 2024 evaluation covered twelve companies against twenty-nine criteria and named four Leaders, where this one covers ten against twenty-five and names two.
You can see it in the movements.
Amperity was a Contender in 2024 and it's a Strong Performer now, carrying the only halo on the chart. Treasure Data was a 2024 Leader and shows up in Strong Performers today as Treasure AI. ActionIQ was a 2024 Leader too, and its technology now lives inside Uniphore, which came in as a Strong Performer. Hightouch and Rokt weren't on the 2024 chart at all.
And Forrester's blog describes the emphasis moving past profile building and audience generation, toward decisioning, orchestration, and AI-powered execution. So the report category is asking a different question of the same market. Optimize for the old question, and you can drop a band without changing a thing you do.
Twelve companies didn't get worse in the same eighteen months.
The measuring moved. Significantly.
Honestly, there's a piece of this I can't settle from outside the report. Hightouch turns up on a Forrester CDP Wave for the first time here, and I don't know whether that's because Hightouch changed or because the inclusion criteria did (warehouse-native finally counting would do it).
Forrester's methodology says the analyst writes the inclusion criteria for each evaluation, so both are live. I'll know more once I've been through the thing properly.
## The part where I admit my angle
A lot of my work is replacing Salesforce and Adobe. I won’t try to deny it. They can call me if they want to find out why.
Nobody calls me when the platform's going well, so my sample is skewed toward the ones that hurt.
I also went at this once before.
In August last year I [rebuilt Gartner's CDP Magic Quadrant on Peer Insights review data](https://www.martechtherapy.com/when-the-customers-speak-even-gartner/), and Hightouch came out a Leader in my version while being left out of the real one entirely. Gartner's own Voice of the Customer said much the same a month later.
So when I say the customer signal and the analyst signal are different instruments, that's not a hunch I formed this week. I've also written about [the quadrant going stale between editions](https://www.martechtherapy.com/beyond-the-gartner-magic-quadrant/), which is a different complaint and still true.
None of that makes this Wave worthless.
It makes it a document with a job, and the job is more niche than the coverage around it suggests.
The job it does well is telling you *who the analyst thinks belongs in this market*, and *what the analyst now thinks the market is about*. That second part is the actual news, and it barely got covered, because a redrawn evaluation metric doesn't share as well as a company moving up a band.
What it can't do is tell you *whether your team can operate any of these*.
*Strength of offering* and *strength of strategy* describe the platform. Neither one describes the organization that has to keep it alive. That's where every repair project I've worked on started, and that gap doesn't have an owner.
There's still nothing standing between the analyst firms and the buyer, which I complained about at length in [the CDP RFP dating game](https://www.martechtherapy.com/the-cdp-rfp-dating-game/) and have watched not change since.
So what do you do with the next one?
Open the legend before you read the placements. And if you're about to spend seven figures on the strength of a dot, ask the vendor how many references they were asked for, and how many they managed to supply.
Do you have any questions after reading this article?
Or need support with your Martech projects?
[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
### The Martech Stack you bought twice
URL: https://www.martechtherapy.com/the-martech-stack-you-bought-twice/
Last updated: 2026-08-31T05:54:46.000Z
Just like my previous article, and most because of the fast moving pace of Martech, I revisited some early work.
Back in July I went at whether AI closes the gap in Martec's Law, and part of that piece dealt with the Gartner utilization number. 58% of stack capability in use in 2020, 42% in 2022, 33% in 2023, with the 2025 reading climbing back toward 49% under a slightly different question. Directional rather than gospel, as I put it at the time.
I still think that's right.
What I didn't do is ask why the dead weight is sitting there in the first place.
I assumed it was a features problem. You buy a big platform, you use a quarter of it, the rest gathers dust. That turns out to be the smaller **part of it**. The bigger **one** never shows up in a utilization survey at all.
## What a contract costs you
Scott Brinker [made the point](https://chiefmartec.com/2023/08/martech-utilization-problems-how-to-diagnose-and-remedy-them/?ref=martechtherapy.com) years ago and it has held up better than the statistic it was aimed at.
> "If a product gives you great ROI for the subset of features you use that are relevant to your business, does it really matter that other, less relevant features in that product are unused? It's not like there's any physical waste there."
He's right, and it's why the utilization figure never quite bites. If you've licensed a platform for four jobs and those four jobs work, the unused rest costs you nothing extra. It sits there, a bit like the manual for my dishwasher describing cycles I'll never run.
A second contract for a capability you already own is a different animal. That one costs exactly what the invoice says, every month, until someone cancels it.
And it will never appear in a utilization figure, because both platforms are in use. Enthusiastically. By different teams. For the same job.
[Will AI close the gap in Martec’s Law?Martech ships faster than any team can absorb. Martec’s Law says the gap only grows. Here is the case that AI might, conditionally, close part of it.Martech Therapy: CDP strategy and agentic AIMatthew Niederberger](https://www.martechtherapy.com/will-ai-close-the-gap-in-martecs-law/)
**The utilization numbers, and what they cost in attention* ⬆️
## Eight of them
[Zylo's 2026 index](https://zylo.com/2026-saas-management-index?ref=martechtherapy.com) puts the average organization at 305 applications against 55 million dollars of annual spend. Big numbers wash over you, so skip them. It's the category breakdown that stopped me.
Eight digital analytics applications in the average organization. Eight. Digital asset management, also eight. Project management, ten.
Not eight unused features inside one analytics platform. Eight separate platforms, with eight contracts, eight renewal dates and eight implementations behind them.
To be fair to the sceptics, Zylo sells SaaS management software, so sprawl is their business, and their numbers come from companies who already suspected they had a problem and went looking. Take the precision with a pinch of salt. The direction matches what I find when I go looking myself.
## Nobody did anything wrong
Only 13% of applications and 15% of spend sit with IT. So roughly seven applications out of every eight got bought by someone else.
Marketing buys its own tools. So does sales, so does the product team, so does the regional office, and so does whoever inherited a platform through an acquisition nobody finished integrating.
None of those buyers did anything wrong. Each had a real requirement, ran a sensible process, and picked a defensible tool. Duplication is what you get when four sensible processes run at the same time with no shared view of what already exists.
Which brings me to the most useful thing anyone has written about this, and it went out in 1968\. Melvin Conway, in [How Do Committees Invent?](https://www.melconway.com/Home/Committees%5FPaper.html?ref=martechtherapy.com), put it as organizations that design systems being "constrained to produce designs which are copies of the communication structures of these organizations."
Constrained. Not inclined, not tempted. Applied here, your stack mirrors the reporting lines that bought it, and those reporting lines are the more accurate architecture diagram.
I spent a good while on a consolidation at a national UK brand with exactly that shape. A cloud data warehouse, a packaged CDP, and a CEP. Three platforms, three owning teams, and a functional split that followed the reporting lines rather than anything anyone would draw on purpose.
## Three bills
The first is the one everybody expects. Segmentation existed in all three platforms. So did identity stitching, in three flavors, with three definitions of what counted as a match. They were buying the same capability more than once and had been for years.
That one's easy to put in front of a CFO. The second one isn't.
Third-party activity ran through an external advertising agency, and the agency protected its own work the way the internal teams protected theirs. Rational enough, if you think about how an agency earns its position. What it produced was a break in lineage, a seam where nobody could follow a field from source to activation.
Someone has to keep data fresh across a seam like that. In practice that meant standing work for the brand's own team, every week, indefinitely, holding two sides in agreement that would have agreed by themselves if they were one side.
There's no line item for it. It doesn't appear in a renewal negotiation or a cost-per-record calculation. It appears as a recurring task nobody ever closes.
I've written before about [stacks and entropy](https://www.martechtherapy.com/the-real-martech-roi-equation/), about a stack absorbing more effort every year to produce the result it once produced easily. Well, this is what that looks like with a receipt attached. A named person maintaining freshness across a gap that exists because two parties are each defending their patch.
Then the third bill, which is the one that stops the other two getting paid down.
Every team had tuned their platform to the point where it worked. Not to the point where it returned anything anybody had measured. To the point where it was operationally acceptable, where campaigns went out and numbers arrived and nobody was firefighting.
> A platform you have fine-tuned to operational acceptance feels like something you own. Asking a team to give it up sounds like asking them to go back to firefighting.
Which is why the architecture argument never wins. You're not asking someone to accept a better design. You're asking them to trade a working process for a promise.
## Why nobody finds it
Here's the mundane part, and it's why this survives audit after audit.
Every register an organization keeps is sorted by supplier. The contract list, the finance ledger, the SSO application list, the security review queue, the renewal calendar. All of them answer one question, which is who gets paid.
None of them answers what that money bought.
Sort by supplier and duplication vanishes, because the duplicates sit in separate rows under separate names with separate owners. Sort by capability and it's the first thing you see. But nothing in a normal operating rhythm ever asks for that second view.
Except at renewal, occasionally. The Martech Weekly's list of questions a proper renewal review forces includes this one almost word for word. Is the organization paying for duplicated functionality, and is the overlap intentional because it creates resilience, or is it simply waste?
## And the money is going somewhere else
Gartner's [2026 CMO Spend Survey](https://www.gartner.com/en/newsroom/press-releases/2026-05-11-gartner-2026-cmo-spend-survey-finds-cmos-allocate-15-point-3-percent-of-marketing-budgets-to-ai-but-only-30-percent-are-ready-to-scale-ai-capabilities?ref=martechtherapy.com) went to 401 CMOs between January and March. Martech's share of the marketing budget came in at [19.4%, down from 26.6% in 2021](https://www.chiefmarketer.com/gartner-cmo-spend-survey-budgets-reflect-increase-in-consumption-based-martech-paid-media-spend/?ref=martechtherapy.com). A five-year low.
Over the same stretch AI arrived as a budget line, and it now takes 15.3% of the marketing budget. For organizations describing themselves as AI-ready, 21.3%.
That's a share though, not a sum. The two move independently. [The Martech Weekly's Enterprise Martech Outlook](https://themartechweekly.com/enterprise-martech-outlook/?ref=martechtherapy.com) puts 87% of enterprise Martech leaders on flat or expanding budgets for 2026\. So the money hasn't gone anywhere. It just arrives with conditions now.
Their sharpest number is the gap. Among teams who can show a measurable contribution to financial objectives, 56% got an increase this year. Among those who can't, 37.5%. **Twenty points of funding advantage for being able to prove the case.** The base is small enough that I'd call it directional.
I'm not going to claim the Martech money became the AI money. Budgets don't move that cleanly and I've got no evidence for it. What I can say is that one line shrank while another got funded, and in neither direction did anybody stop to work out what was already owned.
70% of those CMOs call AI leadership a critical goal for the year. 30% report the readiness to act on it.
> "The risk is that CMOs invest in AI tools faster than they build the data foundations, processes, governance and talent required to scale them." Ewan McIntyre, Gartner
That's a polite description of a gap between structure, capability and process, and I've written enough about that elsewhere.
There's a version of all this that needs no second contract at all. 56% of those CMOs moved more budget onto consumption pricing, and half of everyone who has done that now renegotiates permanently to avoid usage spikes. A quarter are rebuilding systems to use less. Same blindness pointed a different way, where the bill climbs and nothing new got bought.
There's an objection to make here, and their research makes it. The business isn't asking Martech to save money. Revenue growth dominates the strategic objectives and efficiency accounts for 12.2% of the grouped score, so go and find your duplicate spend sounds like the wrong errand.
Except that cancelling a duplicate contract isn't a savings programme. It's the cheapest money in the building, because it needs no business case, no new supplier and nobody's approval, which makes it the easiest way to fund the growth mandate everyone actually has. And it's the last place anyone looks, which is roughly the argument I made [when the CDP market started stalling last year](https://www.martechtherapy.com/dont-let-your-cdp-become-the-fall-guy/).
## What actually works
Start with the cheap version.
Take a year of invoices. Rewrite every line as the capability it buys, in plain words rather than the product name. Not the platform, but "sends email and push, holds the campaign logic." Not the warehouse, but "stores customer records, runs the segmentation queries."
Then sort by capability and look at the collisions. That's the whole exercise. You don't need software for it, though I'll admit [I built some](https://www.martechstackbuilder.com/solutions/stack-consolidation/?ref=martechtherapy.com), because doing it by hand across three hundred applications is a weekend I'd rather not repeat.
The list tells you where the overlaps are. It won't tell you what to do about them, and this is where most consolidation projects die.
Because the answer is almost never cancel the cheaper one. Both teams have real work running on their platform, both have tuned it to acceptable, and neither's going to concede because your diagram looks tidier.
What moved it at that UK brand was turning each overlap into a cost benefit estimate. Not an architecture score. Money. What does running identity stitching in three places cost, in license and in the hours spent reconciling three answers, against running it in one? Put that number in front of both teams and the argument stops being about whose platform is better.
Some of those estimates came back saying keep both, by the way. That's a legitimate result and worth stating, because an exercise that can only conclude "consolidate" was never an analysis.
Anyway. Consolidation run as a procurement exercise fails. The duplication was never a procurement problem. It was a structural one, and structure doesn't respond to a spreadsheet of license costs on its own.
## Where I would leave it
The utilization number will keep getting quoted, and it'll keep pointing at unused features, which cost nothing.
Meanwhile the average organization runs eight analytics platforms, seven of every eight applications got bought outside IT, and there's an AI line to fund out of a budget that now comes with conditions attached.
The capability-sorted list tells you where the money is. It's the least glamorous item on anyone's roadmap this year, which is probably why it's still available.
If you'd rather not do it by hand, the [overlap scan](https://app.martechstackbuilder.com/audit?ref=martechtherapy.com) runs the capability sort for you. No signup, no wall.
[](https://app.martechstackbuilder.com/audit?ref=martechtherapy.com)
Take your free Martech Stack scan today.
Find overlaps and hidden cost savings.
No sign-up, no costs.
[Do the Martech Stack scan >> ](https://app.martechstackbuilder.com/audit?ref=martechtherapy.com)
### Which context wins when two systems disagree about your customer?
URL: https://www.martechtherapy.com/which-context-wins-when-two-systems-disagree-about-your-customer/
Last updated: 2026-08-24T05:57:49.000Z
Back in June, while writing about [composable CDPs](https://www.martechtherapy.com/tag/composable-cdp/), I asked a question and then, like a distracted person, walked straight past it.
> When two systems disagree about something like a customer's email opt-in status, which value wins, and is that rule written down anywhere?
I gave it one line of answer. In packaged systems the vendor sorts it out for you, in composable systems the work goes to your data team. Both true, but neither one tells you which number is right. That has bothered me on and off ever since.
[Composable CDP, translated for marketersComposable CDP hands marketers a finished system and walks away. Four questions to ask before the architecture decision is locked in.Martech Therapy: CDP strategy and agentic AIMatthew Niederberger](https://www.martechtherapy.com/composable-cdp-translated-for-marketers/)
**The piece that question came from* ⬆
During the summer, well, this month actually, two announcements sent me back to to that question.
[Treasure AI started publishing CDP data as Apache Iceberg](https://www.treasure.ai/blog/open-catalog-access?ref=martechtherapy.com) tables that Snowflake, Databricks and BigQuery can query without copying anything out. [Hightouch published an argument that the context your agents run on belongs in systems you control](https://hightouch.com/blog/composable-context?ref=martechtherapy.com) rather than inside somebody else's platform.
One is a packaged CDP opening its box. The other, from the composable end, says don't use a box. Which to be fair, they have always been preaching.
What they share is the pressure they're answering, which is buyers who have stopped letting one company hold the thing their agents depend on.
Look, both of those are about *whether you can get to your context*. Neither is about *which version of it to believe* when two of them disagree.
So I went looking at what sits underneath all this.
Honest caveat before going further, because a month ago I could've told you Apache Iceberg exists and nothing else. Catalogs, table formats, lineage, the concepts are familiar enough. The named projects are the new part, and so is the state each one's actually in, so everything below about specifications comes from going and looking at them rather than from having run one.
The plan was to come back and add a column to the context audit. I came back having broken it.
[The Context AuditA follow-up to the follow-up. My last piece explaining “what the context layers has to do” argued that customer state has to be Queryable, Addressable, Current, and Accountable if agents are going to act on it in real time. It ended pointing at a one-page audit andMartech Therapy: CDP strategy and agentic AIMatthew Niederberger](https://www.martechtherapy.com/the-context-audit/)
**The audit this is about, if you want the original* ⬆
## What the standards actually cover
The audit I created, scored four properties per workflow, to check whether they are:
- **Q**ueryable
- **A**ddressable
- **C**urrent
- **A**ccountable
No fancy acronym for this I'm afraid. 😅
Score three workflows and most teams come out the same way, fine on the first two and badly on the last two. As I said at the time, the first two are the ones vendors sold them, which turns out to be about half the story.
Queryable and addressable stopped being products at some point and became public interfaces. Apache Iceberg defines how a table is laid out. The Iceberg REST Catalog defines how any engine finds that table and loads it. Databricks Unity Catalog, Snowflake Horizon, AWS Glue and Google Lakehouse all speak that specification today, and Apache Polaris implements it independently, with committers from Google, Microsoft, AWS, Dremio, Confluent and Snowflake. Sounds like a fraternity at this stage.
So if someone's quoting you for the reach half of a context layer, *they're quoting you for their implementation of a *public API**. Worth knowing before you see the number.
One caution, though, before you get comfortable with any of that.
Databricks makes Iceberg tables held in an outside catalog read-only and publishes the list of what doesn't work on them, while AWS runs its own extensions alongside the standard paths. Nobody is lying about supporting the specification. You will still meet the gaps in a migration estimate rather than on a datasheet.
Like anything Martech related, the devil is in the details.
Now look at who does the work. Apache holds Iceberg and Polaris. The [Linux Foundation](https://www.linuxfoundation.org/?ref=martechtherapy.com) holds [Model Context Protocol](https://modelcontextprotocol.io/docs/2026-07-28/getting-started/intro?ref=martechtherapy.com) and the Open Data Contract Standard. Those are *real protections* against one company changing the rules on you later.
They're also staffed almost entirely by the data platform companies, so what got standardized is what those companies needed standardized. Nobody in that room needed your particular problem solved.
Now, let's get practical.
## The number that has two answers
Here's an example scenario I keep running into and discussing with clients.
A company has two places that both calculate customer lifetime value. Maybe the warehouse team built one and the CDP calculates another. Maybe an acquisition arrived with its own. One nets off returns and the other doesn't.
Both are defensible.
They disagree by twenty percent.
Nobody has said which one counts.
An agent picks the audience for a win-back offer and needs lifetime value to work out who is worth a discount. It uses one of those two numbers.
Which one?
Whichever the engineer who wrote that service happened to point it at, working alone, with nobody in the room.
> Two systems can both be queryable, addressable, current and accountable, and still disagree about your customer.
My friend, [Ana Mourão](https://www.linkedin.com/in/anamourao/?ref=martechtherapy.com), told me last year:
> There's no glamour in governance.
Was she talking about this?
Not specifically, but it's the same shape of decision. Nobody schedules a meeting about which lifetime value is the real one, so whoever needs it first picks one, and that's the answer from then on.
To be fair, there's an objection here that I have made myself.
In the [first Contextual CDPs piece](https://www.martechtherapy.com/tag/contextual-cdp/) I argued the customer profile is no longer a single source of truth but a fluid, situation-dependent construct, and I still think that. Naming an authoritative system for one fact is a narrower move than rebuilding the golden record. It is per fact, per decision, and reversible, which is exactly what makes it worth doing.
## I tried to make it a fifth column
The instinct was to bolt this onto my context audit.
Four properties, now five, same page, same zero-to-two score. Then the rubric wouldn't sit in the table.
Honestly, that annoyed me more than it should have.
Three things went wrong.
The other four are scored per workflow. This one is a property of a fact rather than a workflow, so the win-back example needs two rows in one cell: lifetime value owned in one place, last order date owned in another.
Then there's the point of the June instrument, which was that three workflows reveal a pattern. *Precedence doesn't vary between workflows*. Whoever owns lifetime value owns it for the re-engagement email too, so you run it three times and write the same answer three times.
And the third one is why the first two happen. The four properties all measure whether context reaches the workflow. This measures which context deserves believing, and that isn't a question about the layer at all.
I published that audit in June and said it was small enough to run in ten minutes and useful enough to act on. I still think both of those are true.
So what was I measuring?
Whether the context arrives. Not whether it should be believed when it does, which is the thing that decides what your agents actually do, and I didn't notice for two months.
## A reporting line, not a property
So who does decide?
Not a system, and not a specification either.
Whether the warehouse number or the CDP one is authoritative depends on who at your company has the standing to say so, and that differs at every company and changes when the reporting lines change.
This is Conway's Law again, the old observation that systems come out shaped like the group that built them. No file format is going to carry that for you. My audit rubric can't either, because a rubric only scores something that already exists.
You can watch the specification authors hit the same wall. The [Open Data Contract Standard](https://bitol-io.github.io/open-data-contract-standard/?ref=martechtherapy.com) gets closest, and it's the one piece of this terrain with any real time behind it, so I'll say plainly that it works. It has sections for the team, the roles, data quality and service levels, and freshness commitments go in there and hold. But a data contract is one producer's promise about one dataset. Nothing in it compares two producers who both claim to know your customer's lifetime value. (There is a field called *authoritativeDefinitions*, which sounds like exactly the answer and is a list of links to documentation.)
The Iceberg maintainers have an open issue about the same hole, asking for a way for a catalog to say who owns a table and how it's classified. It's been open since March.
In the meantime, the issue notes, catalogs fall back on vendor-specific extensions that open-source engines can't consume. *Everybody is solving it privately, and nobody is sharing what they came up with*. Yep, silo's.
[What does the context layer actually have to do?Queryable, addressable, current, accountable. Four things the layer of customer state has to deliver if AI agents are going to act on it in real time. A follow-up to the six-part Contextual CDPs series, written a year on, now that the industry has caught up to the language.Martech Therapy: CDP strategy and agentic AIMatthew Niederberger](https://www.martechtherapy.com/what-does-the-context-layer-actually-have-to-do/)
**Where the four properties came from* ⬆
## What I would actually do about it
Three things.
Ask anyone pitching you a context layer:
> What happens when their number disagrees with the one in your warehouse.
The specification question, which of these do you support, has an answer sitting on a datasheet. The other one doesn't, and watching someone work it out live tells you whether they have ever had to. This is very revealing
Then trace one decision. I mean one, not a sweep. Pick a live workflow, work out which system the number it uses actually comes from, and write it down. You'll need two people to answer that and one of them will have to go and look, so it isn't the ten-minute job the June audit was. Give yourself permission to write down a provisional answer with a date on it. "As of today this pulls the warehouse model, nobody ratified that" is a real finding. But beware, if you wait for someone with authority to declare a winner, you'll write nothing at all.
And before you start, *work out who you're handing it to*. This is the part I'd have skipped a year ago.
Run this across three workflows and you end up holding a document showing that customer-facing discount logic has no owner, and *in most companies the person who surfaces that inherits it*.
So agree the destination first, whether that's the data lead, the workflow owner, or whoever owns the P&L the metric feeds.
I don't think a standard solves this, and I'm not sure a framework does either, including mine. It gets solved by somebody with the standing to do it saying that this number wins and that one doesn't.
Smaller job than architecture, and considerably more annoying.
## Download the Context Audit Worksheet
To help you get started, I have created a one-sheet PDF to guide you through the exercise of auditing your context that includes the question of which sources leads when multiple are available.
Nothing fancy, but better than nothing. Download it today ⬇️
[Free Context Audit WorksheetA blank one-page worksheet for scoring what context a martech workflow can actually reach, and which system wins when two of them disagree.Martech Therapy: CDP strategy and agentic AIMatthew Niederberger](https://www.martechtherapy.com/context-audit-worksheet/)
Do you have any questions after reading this article?
Or need support with your Martech projects?
[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
### Is Martech work slowing down?
URL: https://www.martechtherapy.com/is-martech-work-slowing-down/
Last updated: 2026-08-17T15:00:19.000Z
I recently returned from my holiday without some magical Martech insight. What I did pick up was a plethora of LinkedIn posts and private messages from people who have been let go from their positions, or who are sharing their experiences of a perceived drop in Martech-related contract work.
And an announcement from my friend Daniel Heer. More about that later.
In total, a handful of conversations over the last few months, from three different parts of this industry, all describing the same thing.
I will try to tell the story, using some light-hearted references to one of my favorite movies and songs.
## What are the signals...
An agency owner telling me work has slowed. Two people at vendors who were let go. Two other contractors watching the same drop in assignments I am. Different companies, different corners of the business, but still the same story.
Is this the point we say it is time to change careers and become a truck driver? Sorry, I could not hold back on that scene from Top Gun...
When people get let go in martech, a fair number end up contracting, and some of them ask me how to go about it, because I have been doing this for almost twelve years in the work they do.
I have given the same answer for years.
> Get two clients before you need them. Do not undercut yourself in the first month because you will never get the position back. Keep six months of runway and stop looking at it.
Obvious disclosure. I sell days for a living, so I am not a neutral observer here.
However, lately, I am [less sure about that answer](https://www.martechtherapy.com/the-growing-demand-for-freelance-data-talent/) than I used to be.
## What I am actually seeing
Let's point out the elephant in the room first. Contract volume is down, mine included. Assignments that used to attract three or four serious bids now attract seven or eight, and half of those people were principal level somewhere twelve months ago. I have lost work to people I would have happily subcontracted. That is a new experience, and I do not like it.
I'll be honest. I have also looked at two vendor roles (product evangelism) that came past me this year, which is not something I have done in a long time. I did not take them, and I am still doing this, being independent, by choice. But I looked, and I know people who looked a good deal harder than I did.
It is uneven, and that gets lost when everyone is gloomy at once. Some geographies are still busy while others have gone flat, and the difference is bigger than anything you would guess from LinkedIn.
The same is true by type of work.
From what I have seen, more is happening in hands-on contracts than in strategy work right now, which tells you what budget holders think they can defer.
*Strategy is the first thing postponed and the last thing credited.*
Speaking for myself, the rates are mostly holding, and that is what fools people. If you only look at your day rate, everything looks fine right up until you notice you have billed eleven days this month.
The two who were let go will probably be contracting by the autumn, and they arrive into this.
If you have done it yourself, you know how it goes. The announcement post does well. Someone you have not spoken to in years makes an introduction, and it turns into work, and your first invoice is bigger than any payslip you ever had. Then it goes quiet, and it does not feel dangerous yet. A client pauses until the new budget year. A proposal you were told was a formality goes into legal and stays there.
Everyone has it at the same time now, which means it is something else.
## Why I think it is happening
Some of it is AI, though less of it than the noise suggests, and the timing is what gives it away. Bear with me as I try to explain.
Marketing budgets stopped growing well before anyone could get an agent to configure a tag. Money moved out of martech and into paid media, and the agencies got squeezed first. That was two or three years ago. AI did not start this.
What AI changed is who can do the work. A capable junior with good tooling now covers a surprising amount of what used to need someone with ten years on them. The judgment is still hard to replace. So if you are running a team, the math has changed.
You can staff more juniors, give them AI, and keep one senior person to catch what goes wrong. That is cheaper than what you were doing, and for now it mostly works, but tread carefully. I have written before about [what that does to an organization chart](https://www.martechtherapy.com/new-ai-org-chart/?ref=martechtherapy.com).
Cognizant's chief executive describes this openly. They call it a broader pyramid, which means using AI to push high-value technical work down to entry level, then hiring graduates by the tens of thousands to sit at the bottom of it. It is the clearest strategy anyone in this industry has articulated, and it explains the senior squeeze far better than the general panic about robots taking jobs.
Meanwhile dentsu spent a decade buying up the martech services business and last year wrote most of it off.
Publicis added eleven thousand people over the same period. So the agency world is not suffering evenly. The damage is landing on the businesses that sold what we do.
But keep the following in mind.
From inside client work, AI is doing less than the outside noise suggests. It comes up in every conversation and drives far fewer decisions than you would think. Most of the brands I sit with are nowhere near the productivity they describe in public, because the integration is simply not there. This is closer to [AI replacing processes than people](https://www.martechtherapy.com/when-ai-replaces-processes-not-people/?ref=martechtherapy.com).
The model is fine.
Getting it to reach the data, the consent state and the campaign tooling well enough to beat what a competent person did manually is where it stalls, and it stalls for months. So when a client tells me their headcount plan assumes an AI productivity gain, my first question is whether they have measured that gain or read about it.
## Have you priced this in?
Now the skeptical part, and you should know I have an interest in being right about it. 😉
The first problem is that AI turned out to have a bill.
The assumption for the last two years was that the marginal cost of the work goes to nearly zero. That is not what companies are finding. Nvidia's own people have said the compute for their team now costs more than the team does. Uber reportedly burned through its annual AI budget early, and Microsoft's own numbers point the same way.
Some tasks are genuinely cheaper now.
Some are more expensive than the person who used to do them and nobody has noticed, because token spend sits in a different budget line than salary and nobody reconciles the two.
The second problem bothers me more.
The whole junior plus AI model rests on a senior person catching what the junior and the machine get wrong. That is the load-bearing part. And it assumes a kind of experience that does not exist yet, because nobody has ten years of practice reviewing AI output. Reviewing a junior's work is a skill built slowly, and it works because you know the shape of the mistakes juniors make. They over-engineer, they miss the edge case, they take the requirement literally. You develop an eye for it. It is the same [absorption problem I described in Martec's Law](https://www.martechtherapy.com/will-ai-close-the-gap-in-martecs-law/?ref=martechtherapy.com), one layer up.
AI produces a different class of error.
It is fluent, internally consistent, formatted correctly, and confidently wrong, and all of that reads as competence. That is exactly the profile that gets waved through a review.
Deloitte is the proof, and it is a good one, because they sell assurance for a living. They delivered a report to the Australian government containing citations to work that did not exist, and a quote attributed to a Federal Court judgment that nobody ever said. They gave part of the fee back. Their defence was that the findings were unchanged, which may well be true and does not fix anything. That is a firm with more review layers than anyone reading this has, and it went out of the door anyway.
If Deloitte cannot catch it, I am not confident that a stretched senior reviewing four juniors catches it in a campaign build.
I am obviously biased. I have twenty-plus years of scar tissue, and I am arguing that scar tissue is worth paying for. Discount it as much as you like. But the review problem is real whether or not it suits me, and I have not seen anyone put a number on it.
## What that makes contracting, right now
Contracting at the moment is temporary capacity while work moves somewhere cheaper. Either offshore, or to AI. Or in some cases our kids who have just finished university.
I am not complaining about it. I do this, and it pays well, and the work is often the most interesting I've seen, because what lands with an independent is whatever cannot be handed over yet. The messy first ninety days, or the client who will not accept an offshore lead on a discovery. Sometimes just the situation that needs someone who has watched it fail before.
But the list of things that cannot be handed over gets shorter every year. That is what the model is built to do.
Nobody gets offered a lateral move into the cheaper team. The cheaper team is the reason the conversation is happening at all. That is true inside a consultancy, and out here, as an independent, nobody even has to have the conversation with you.
## What I would actually do
Certification is the reflex answer, and I am wary of it, although I am eyeing a few.
There are somewhere around fifteen thousand tools in this industry. Which one do you bet a month of your life on? Get certified in the wrong platform, and you have bought a badge for a market of eleven employers, none of whom are hiring this quarter.
The more useful version is regional, and nobody says this out loud because it does not scale into a nice framework. Look at what is actually being bought where you live. Demand for specific tools is far more local than the global commentary admits, and the gap between two countries in the same time zone can be enormous. Pick a couple of those and get properly findable for them instead of collecting logos. I made [the case for specialization](https://www.martechtherapy.com/why-freelance-martech-consultants-should-embrace-specialization/?ref=martechtherapy.com) a while back and I would make it harder now. Happy to share my experiences about this, it's true.
Beyond that, the things that have reliably worked for me are unglamorous. Keep educating yourself, continuously, including on the tools you have decided you dislike. Network before you need it, because doing it after you need it is obvious to everyone. And research your own market before you trust general commentary, this article included.
Then be honest with yourself about where you sit. If you are a few years in and you landed in contracting because a role disappeared, the market you walked into is one where seven experienced people are bidding for the work you want. Going back to the brand side for a few years and building real depth will get you to the point of winning those bids faster than grinding through this market will. That is a bad thing for me to say to a potential competitor and I think it is true.
For everyone else, assume this position has a shelf life of a couple of years, and use them to become something other than a person selling hours. A product, a niche small enough that nobody staffs for it, a practice with other people in it, or a route back in-house on terms you chose. The people who came out of the last services collapse in decent shape all did some version of that.
Someone is now building a business on exactly that premise.
Daniel Heer, who spent eleven and a half years building [Zeotap](https://www.martechtherapy.com/how-snowflake-recruited-zeotaps-composable-cdp/?ref=martechtherapy.com), has just launched [The Principals Group](https://theprincipalsgroup.com/?ref=martechtherapy.com) with three co-founders, aimed at the consulting market. The line on their homepage is one I wish I had written.
> Most consulting sells you seniority and delivers you juniors.
His reasoning, in his own words, is that AI will kill junior human judgement across many disciplines while senior judgement is needed more than ever, and that plenty of companies can no longer afford McKinsey and the firms like it. The gap he is building into is full of senior operators who want to leave corporate life and sell their own expertise, and who have no idea how to sell.
Daniel is a friend, and he now has a company riding on this being true, which is the same disclosure I made about myself at the top. Weigh us both accordingly.
Two things stay with me. He is putting money behind something I have only been able to describe. And they charge on outcomes rather than billable hours, which is the same conclusion I reached above, arriving from the other direction.
If senior judgement is the scarce good, the unit matters more than the rate. Hours are what a cheaper delivery model buys easily. Judgement is the part it cannot.
There is a disagreement in here we need to pause with...
Daniel and Cognizant point in opposite directions about juniors. Cognizant is hiring graduates by the tens of thousands on the basis that AI lets them handle work that used to need someone senior. Daniel is arguing that AI is exactly what strips the value out of junior judgement.
My guess is that both are describing something real, and they are describing different things. Tasks move down. Judgement moves up. Which would leave the middle of this profession with nowhere to stand, and no obvious route from one end to the other.
That is the part I would most like to be wrong about.
## If you are the one buying
Now, on the flipside, there is another consideration to make.
There is an unusual amount of senior martech capability available right now at prices that will not hold.
I would be careful about treating that as good news, because every previous time this happened, brands waited. The market recovered, the same capability came back as a consultancy line item at three times the cost, and everyone agreed it was a shame.
Nobody gets promoted for hiring ahead of a recovery.
If you do want to use the window, put the senior money into review instead of build. You are already planning to run more juniors with more AI, so the constraint on that plan is not whether the work gets produced. It is whether anyone in the building can tell when it is wrong. Put your senior hire on the review layer and make the knowledge transfer a deliverable with a date on it.
That is a convenient argument for me to make. It is also what I would do from your side of the table.
## What I will stand behind
Neill Brookman, a friend of mine, put it to me like this.
> AI is killing everything at the moment, which is frustrating. I think it is just a short-term fad, but it will take a while for companies to realize they need experts and can't just use AI instead.
I agree with the second half of that and I am not sure about the first. Calling AI a fad is the comfortable reading, and comfortable readings have not served anyone well these past two years.
Closer to right, I think, is that the tools are real and the productivity claims are running a long way ahead of the integration. The gap between those two is where the next few years get decided.
I do not know whether this is a cycle or a reset. I have been wrong about timing on nearly everything in this industry, and I mean that as a caveat, not as modesty.
I do think the correction arrives through the review layer, not the build layer. Something expensive goes out with nobody's fingerprints on it, someone works out what it cost, and the pendulum swings back toward experience at a price that has gone up again.
Daniel is betting it arrives through the market for judgement instead. Same event, seen from two ends, and one of us is closer on the timing.
Until then, watch your billable days, not your rate. And if you are on the buying side, the cheapest thing on your desk this year is the person who has already seen it go wrong.
Now, let me send you off with some positivity...
### Identity Resolution: a practitioner's guide to who owns the match
URL: https://www.martechtherapy.com/identity-resolution-a-practitioners-guide-to-who-owns-the-match/
Last updated: 2026-07-30T16:12:04.000Z
In part 4 of the [Agentic CDP series](https://www.martechtherapy.com/tag/agentic-cdp-series/) I made a claim and then moved on rather quickly.
> Identity resolution stops being a data-team hygiene project and becomes a precondition for anything agentic being trusted with a budget.
That deserved more than the paragraph it got, so here is the longer version.
[Your agentic CDP will optimize whatever you measureEvery agentic CDP will be sold on goals-based marketing. That assumes a goal an agent can chase and a signal fast enough to learn from. Most teams have neither.Martech Therapy: CDP strategy and agentic AIMatthew Niederberger](https://www.martechtherapy.com/your-agentic-cdp-will-optimize-what-you-measure/)
**The piece that started this one* ☝️
There is an awkward footnote I need to address first.
I have also argued, in the [Contextual CDP series](https://www.martechtherapy.com/tag/contextual-cdp/), that memory rather than identity is what makes context work.
I still think that holds, but memory has to attach to something.
An agent that remembers three separate people who happen to be the same customer does not have a memory problem.
Basically, the memory is fine. What it is attached to is wrong.
And that failure is a sneaky one to miss.
A human skimming a weekly report smooths over a fractured profile without noticing they are doing it.
An agent takes the misattributed outcome at face value, decides a channel underperformed, and moves the budget away from it.
Confidently. Every single day.
The usual reason given for caring about any of this is that third-party cookies are going away. **They are not**.
> Google abandoned deprecation in July 2024, dropped the choice prompt in April 2025, and retired most of Privacy Sandbox in October 2025\. Safari, Firefox and Brave still block, so roughly a fifth of traffic behaves as though the deprecation happened and the rest carries on as if nothing happened.
The cookie survived and its standardized replacement died, which leaves a set of proprietary identity products acting as the interoperability layer for everyone else.
Either way, the question underneath has not changed. Somebody has to decide that these two records are one person. This piece is about who that somebody is, and what you give up depending on the answer.
[Agentic AI in Martech: The billion decision problemPart 1: Why scale changes everything about AI in MartechMartech Therapy: CDP strategy and agentic AIMatthew Niederberger](https://www.martechtherapy.com/agentic-ai-in-martech-the-billion/)
💡
One note on the vendor names before they start appearing.
I picked the examples for how much they document rather than for how well they work, because a piece about who owns the matching logic can only use tools where the logic is visible.
****Zingg** is open source. ****Amperity** publishes its precedence order and its confidence scores. ****Tilores** publishes its rulesets and its benchmarks. ****Hightouch** and ****RudderStack** document what runs in your warehouse and what does not. ****LiveRamp** puts the ownership terms in its contract in plain words.
Plenty of capable tools do not document at this level, which is a fair commercial choice and leaves me nothing specific to point at, so treat every name here as an illustration rather than a shortlist.
## Identity resolution is two jobs
The first job is **match**: deciding which records belong to the same person.
The second is **merge**: deciding what that person's attributes are once you have decided the records belong together.
Most of the marketing in this category is about matching. Most of the pain in production is about merging.
Matching gets the attention because it has the interesting math in it. Merging is where somebody has to sit down and decide which of three disagreeing postal addresses survives, and why. Look, nobody said this would be easy.
One interesting find was that Amperity publishes its precedence order, which I appreciate, because it makes the shape of that work visible:
- completion score first
- then source priority
- then field priority
- then recency.
Four rules applied in order, and every one of them is a business decision that someone in your organization is qualified to make but probably has not been asked to.
This distinction matters commercially, because tools split on it.
[Zingg's open-source edition ](https://www.zingg.ai/?ref=martechtherapy.com)does the match half and stops. It appends a cluster identifier and a confidence range to your input rows and hands them back. No golden record, but survivorship does appear in the enterprise edition.
That is not a criticism of Zingg. It is a warning about how the option gets discussed in a planning meeting, where "we could use the open source one" is really "we could build the second half ourselves".
## You say potato, I say potato
As with a lot of confusion in Martech, it comes down to understanding the taxonomy. Let's dive in.
**Deterministic** matching means exact agreement on a shared identifier.
Same hashed email, same customer number, same loyalty card. It is cheap, explainable, and defensible in front of a regulator. It also misses everything that does not share an identifier, which in most organizations is a considerable amount of everything.
**Probabilistic** matching scores similarity across attributes and calls it a match above some threshold.
Sarah Jones at 12 Oak Street with a typo in the postcode is probably the Sara Jones at 12 Oak St. It finds what deterministic misses and occasionally finds things that are not there.
Just like anything Martech, almost nothing serious is purely one or the other.
**Hybrid** is the honest description of most production systems: deterministic rules do the easy work and narrow the field, then similarity scoring runs on what is left.
[Amperity's Stitch](https://docs.amperity.com/reference/stitch.html?ref=martechtherapy.com) works this way, rule-based blocking followed by pairwise machine learning. [Tilores](https://www.tilores.com/?ref=martechtherapy.com) runs configurable matchers with probabilistic available rather than assumed.
Even the **vendors who lead with AI are usually running rules first**, because rules are fast and most matches are easy.
Then there is **batch against real-time**, where buyers get misled without anyone intending it. A vendor can offer a very fast profile lookup while rebuilding the identity graph once a night.
Amperity is the clean example: the Profile API returns quickly because it reads a precomputed index, and the graph behind it is rebuilt daily. A real-time query of a batch decision, and perfectly reasonable engineering.
Not the same thing as resolving identity as the event arrives, which is what Tilores does at around nine milliseconds at the ninety-fifth percentile on a million records, in its own published benchmark.
Whether you need the second one comes down to whether a decision has to be made while the customer is still on the page.
[Right-time marketing and the speed of context decay“Real-time” hides three different clocks. What it means from a data warehouse, why context decay is the real metric, and where five CDPs draw the line.Martech Therapy: CDP strategy and agentic AIMatthew Niederberger](https://www.martechtherapy.com/right-time-marketing-and-the-speed-of-context-decay/)
Real-time, right-time? The nuance is real ☝️
Let's move on to the following question:
> How many sets of rules can you run at once?
I have sat through a lot of these demos and presentations, and can honestly say that I do not remember it coming up.
That needs to change.
The rules that should govern a marketing suppression list are not the rules for a service desk lookup, which are not the rules for a fraud check.
- **Suppression** wants to over-merge, because if in doubt you treat them as the same person and do not send the email twice.
- A **service desk** wants the opposite, since showing one customer another customer's order history is a considerably worse outcome than making someone repeat their postcode.
- **Fraud** wants a third thing again, links between people that marketing must never act on.
Give all three teams one graph and somebody has to decide which of them is right, after which the other two go off and build workarounds. Admit it, it happens.
More tools support this than I expected when I went and checked. **Hightouch** will run a separate identity graph per matching strategy, each with its own models, identifiers and rules. **Treasure ~~Data~~ AI** lets you declare multiple canonical IDs and multiple master tables in a single unification file. **Tilores** splits it further again, keeping separate rulesets for indexing, linking, searching and deduplication. **Salesforce Data Cloud** supports more than one ruleset per object and then recommends against it, on the grounds that maintaining two rulesets per object increases what you are billed for identity resolution. An unexpected honest move.
The capability is mostly there. What varies is the price of using it, in license, in compute, and in the modeling work of keeping two definitions of the same customer that are supposed to disagree with each other.
If you take one procurement question away from this piece, make it that one. Ask how many identity rulesets the tool supports, and what the second one costs.
## Five ways to answer the question
I have ordered these by how much of the matching logic you own, from least to most. That ordering is the argument of the piece.
The five are positions on a line rather than boxes with products in them. Nothing serious is purely one archetype, the same way nothing serious is purely deterministic or purely probabilistic.
Amperity runs a managed platform and also writes its results back into your warehouse. Meiro sells a packaged product that deploys in your own cloud, in whatever region you name. Expect most tools to sit between two of these.
Let's take a look at some of the most common identity resolution approaches.
### The rented graph
You send hashed identifiers to a vendor and get back a stable pseudonymous key that also exists inside the ad platforms and publishers you want to reach.
LiveRamp is a reference implementation here.
The value is real and hard to replicate because you get to reach into destinations you do not control. The catch sits in their own terms of service, which state that LiveRamp owns the software and technological functionality that establishes and enables the linkage.
You own the data.
You rent the join.
The identifiers are not portable, and the graph refreshes monthly, so what you hold decays if you stop paying.
### The embedded graph
Identity often arrives as a feature of something else you bought.
Every packaged CDP and most engagement platforms have one. You configure it in a settings screen, it works reasonably well on the data you loaded into that tool, and the resolved graph does not leave the product.
This is a perfectly good answer for a lot of organizations, and the composable crowd is dismissive about it. What you accept is that the rules are configurable within limits you did not set, and that the graph belongs to the platform rather than to you. Replace the platform and you replace the graph.
### The managed matching platform
Here identity is the product rather than a feature of something else, and Amperity is the one to picture.
Hybrid matching, operated by the vendor, with confidence categories from zero to five, pairwise strength scores and a cluster graph you can inspect. You can tune it, but overriding an individual match decision by hand is not documented anywhere. You can see what the system did and adjust the dials without ever writing the rule.
For a lot of large organizations that is the right trade, because writing the rule yourself means somebody owns it forever, including the quarter after they resign. Check whether the tuning surface goes deep enough for your hardest cases.
### The engine you point at your own data
You author the rules, you can read them, and the result lands somewhere you can query.
Two quite different approaches live here.
**The first is a dedicated resolution service**. Tilores is the example, a GraphQL API over a serverless stack you deploy into your own AWS account. The rules are JSON configuration you own, and resolution happens as records arrive rather than overnight.
[Can identity resolution work without AI? Steven Renwick from Tilores explainsTilores’ CEO explains why rules still rule, and how GenAI plays a supporting role in identity resolution, not the starring one.Martech Therapy: CDP strategy and agentic AIMatthew Niederberger](https://www.martechtherapy.com/can-identity-resolution-work-without/)
**I asked Tilores' CEO about exactly this* ☝️
**The second is the warehouse-native activation layer**, where I was wrong when I started researching this piece. I had assumed Hightouch, [RudderStack](https://www.rudderstack.com/learn/customer-360/what-is-identity-resolution/?ref=martechtherapy.com) and [GrowthLoop](https://docs.growthloop.com/docs/identity-getting-started?ref=martechtherapy.com) were doing lightweight embedded identity. All three write the resolved graph back into your warehouse as tables you can query, and all three do survivorship rather than just matching.
[Hightouch is transparent by default](https://hightouch.com/platform/identity-resolution?ref=martechtherapy.com), with one exception. Its probabilistic tier does not run in your warehouse. It moves your data out to an external cloud storage bucket, runs a vendor model against it, and gives you three settings:
> Exact, Strict, Loose.
That is the whole configuration surface. Business tier, contact sales. Switch that one feature on and you have moved, inside a single product sitting at the ownership end of the scale, some distance back toward the rented end.
[How Snowflake recruited Zeotap’s composable CDPZeotap’s composable CDP now runs inside Snowflake as a Native App. Snowflake recruited it, the way Databricks built CustomerLake.Martech Therapy: CDP strategy and agentic AIMatthew Niederberger](https://www.martechtherapy.com/how-snowflake-recruited-zeotaps-composable-cdp/)
Learn more about the differences of how CDPs work with data warehouses ☝️
### Build it yourself
Zingg, dbt models, graph algorithms, or some combination of the three. You own all of it, [including the operating burden](https://www.martechtherapy.com/the-inherited-costs-of-the-composable-stack/). The open-source edition of Zingg is AGPL, probabilistic only, needs roughly thirty to forty labeled positive examples to start, and runs on Spark in batch. Deterministic matching, persistent identifiers, incremental runs, explainability and survivorship all live in the enterprise edition.
Which produces an awkward moment in the buying conversation.
Either you build the missing half or you buy the enterprise license, at which point the reason you chose open source has evaporated.
If you are betting on the warehouse solving this for you, check which warehouse you are on. [Databricks announced CustomerLake with Agentic Identity Resolution in June 2026](https://www.martechtherapy.com/databricks-customerlake-the-warehouse-cdp/), in private preview. Snowflake has no first-party identity product at all.
How you pay for it belongs in this section too.
If a vendor is listed in your cloud provider's marketplace, buying through it draws down against a commitment you have already signed, so nobody has to write a new budget case.
The programs are not equivalent.
Google Cloud draws down at the full hundred percent of eligible spend against your minimum commitment, Databricks caps its drawdown at ten percent, and Snowflake requires enrollment and does not publish a percentage.
I have recently sat in several of these conversations to know that difference can settle a shortlist before anyone opens an architecture diagram, which is a strange way to choose an identity layer and completely understandable at the same time.
## A note for the B2B readers
Everything above assumes the entity is a person. Life is just not that simple.
In B2B the unit that matters is usually the account, which turns one resolution problem into three, and the third changes every time somebody moves job. Most tools built for consumer marketing treat account as an attribute rather than an entity, which is the specific thing to test in a proof of concept rather than assume.
## Nobody has the answer key
You cannot measure identity resolution accuracy, because measuring it would require already knowing which records are the same person, and if you knew that you would not need the system.
So *everything is a proxy*, and there are two ways to be wrong.
- **Over-merging** collapses two people into one.
- **Under-merging** leaves one person as two.
Every threshold trades one against the other and no setting avoids both, which is why the multiple-rulesets question earlier is more than a technical detail.
It is also why "match rate" is close to useless as a comparison metric, and why it is the number vendors lead with. A high rate can mean the system is finding real connections or that it is over-merging enthusiastically. LiveRamp, to its credit, publishes the trade explicitly. According to LiveRamp, there is a 99.5% match on full personal information, 89.8% on email alone, and a stated policy of accepting less scale than probabilistic competitors in exchange for deterministic accuracy.
What you can do instead is build a small labeled set by hand, a few hundred record pairs your team has looked at and judged. It is dull, it takes an afternoon or two, and it will tell you more about a shortlist than any vendor can truly promise.
Zingg requires labeled pairs before it will run at all, which is inconvenient but refreshingly enough also the most honest thing about it.
## What actually separates these
Read back over the five and the technical differences start to look secondary.
Deterministic against probabilistic is a tuning decision, batch against real-time is a use case decision, and both are answerable in a single afternoon.
> The choice is **who owns the logic** that decides two records are one person, and whether anyone in your organization can inspect it.
Which is why the Hightouch detail matters more than its size suggests. Ownership turns out to be a property of the feature you switched on rather than of the vendor you picked. You can buy a transparent tool and opt into opacity with a checkbox, and nothing in procurement will flag that you did.
The agentic version of this is why I wrote the piece.
> An agent that reallocates budget daily is making decisions on resolved profiles, so if nobody can explain why two records were joined, nobody can explain why the budget moved.
You have automated the decision and outsourced the premise, and the audit trail stops at a vendor's confidence score. That is a governance problem.
## Where to start
Not with a vendor shortlist, but with these 4 steps 👇🏻
Start with how many identity rulesets your use cases actually need, because that number decides which options are viable at all, and it is usually more than one.
Then ask whether resolution has to happen while the customer is on the page or whether last night's answer is fine, which halves the list again. Work out whether you are buying matching, merging, or both, and write it down in those words so everyone is looking at the same scope.
And check the contract mechanics before the architecture debate, because a ten percent drawdown cap and a hundred percent drawdown produce different shortlists.
The next customer record that arrives at your organization will be matched to something by somebody's rules. Worth knowing whose.
Do you have any questions after reading this article?
Or need support with your Martech projects?
[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
### Your agentic CDP will optimize whatever you measure
URL: https://www.martechtherapy.com/your-agentic-cdp-will-optimize-what-you-measure/
Last updated: 2026-07-27T06:41:05.000Z
The last dimension on the scorecard [in part 3](https://www.martechtherapy.com/how-to-evaluate-an-agentic-cdp-on-your-own/) was goal and measurement fit.
> Can the tool take the goals and the clean signal you can actually give it?
I saved it for its own part because it is the dimension the entire category rests on, and the one where the distance between the pitch and the average marketing team is widest. And it bears the roots of [my entire post-military career](https://www.martechtherapy.com/this-is-me-who-are-you/).
## Every vendor is selling you goals-based marketing
Before we jump into the deep end, let's briefly look past the architecture arguments, and you will see that the convergence is oddly striking.
**GrowthLoop** optimizes toward customer lifetime value, return on ad spend, retention, and margin.
**Simon AI** leads with goals-based marketing and a revenue impact agent.
**Hightouch** describes agents that find opportunities and optimize toward objectives.
**Databricks** ships Campaign Agents that continuously optimize around business goals.
All four have different architectures, yet they share the same assumption underneath. The assumption that *you can hand the system a goal, and that the system can tell whether it is getting closer to it*.
That assumption is carrying the entire category and maybe your entire business because nobody selling it is checking whether it holds inside your own organization.
Let me tell you why.
## Measurement changes job
I started out in *web analytics*, back when it was still called that, when Omniture Sitecatalyst was a disruptor, and spent years in the part of the industry that everyone agreed was important and nobody funded properly.
Data quality was the thing you raised in the meeting and watched get deferred to next quarter. Reporting was overhead. Insight was a slide that got neglected... true story. I even quit a job because of this.
Nevertheless, that arrangement worked, in a grim way, because a human sat between the bad number and the decision.
> An analyst looks at a figure that cannot be right, says so, and discounts it. Organizations absorbed a decade of poor data through human skepticism.
Take the human out of the loop and that shock absorber disappears. Bad data stops producing a misleading dashboard and starts producing a wrong action, over and over, at machine speed.
I am sure many of you have seen this meme before.
So measurement is not becoming more important in the vague way people say things are becoming more important. **Measurement is changing category**.
It has stopped being a reporting function and become a control function. The number is no longer something you check afterward.
**The number is the instruction**.
## Most campaign goals are not goals
Try writing your current objective down as something an agent could act on.
For instance:
- "Run a win-back campaign" is an activity.
- "Improve engagement" is a direction.
- "Hit the Q3 number" is a target no one is accountable for.
A goal an agent can chase has four parts: an outcome, a measure, a boundary in time, and a limit on what it may do to get there. Repeat purchase rate among customers who lapsed in the last ninety days, up four points, by the end of the quarter, without discounting below twenty percent.
Most teams can write the first three.
The fourth, **the limit**, is the one they leave off.
## The lagging indicator trap
Here is the mechanical problem underneath all of this that gets almost no attention.
> The outcomes that actually matter to the business **arrive slowly**.
Lifetime value, retention, margin contribution. These resolve over months. The signals that arrive quickly are proxies. Opens, clicks, sessions, add-to-carts.
An agent needs signal fast enough to steer on. So it gets handed the proxy.
Now you have a system optimizing a stand-in for the thing you care about, at machine speed, with a budget.
The proxy and the outcome agreed well enough when a human checked in weekly. They come apart quickly when something is pushing on the proxy all day.
## Goodhart arrives with a budget
Give a system a number to maximize, and it finds the cheapest route to that number. When a measure becomes a target, it stops being a good measure, and [Goodhart's law](https://en.wikipedia.org/wiki/Goodhart%27s%5Flaw?ref=martechtherapy.com) (*I had to look this up*) has never had a more literal test case than an agent with API access.
The popular phrasing of Goodhart's law:
💡
"When a measure becomes a target, it ceases to be a good measure."
An agent optimising conversion rate can improve it by spending less on the audiences that were always going to be harder work. The agent did exactly what it was told, at a speed no one was watching. Nobody broke anything, and that is the problem.
So the guardrail, the fourth part, is half the goal. Name what must not move at the same moment you name the target, or you have written only half of it.
[Letting go of controlWhat agentic AI can teach Martech about trust, autonomy, and actual intelligenceMartech TherapyMatthew Niederberger](https://www.martechtherapy.com/letting-go-of-control/)
## You cannot measure what you cannot join
There is a martech-specific version of this that data teams will recognise and marketers often will not.
Measurement depends on identity. If the same customer appears as three records across web, email and the store, the outcome of a campaign lands against the wrong profile, or against no profile at all.
A human skimming a weekly report smooths over that. They know the number is roughly directional.
An agent does not know it is *holding a fractured view*. It takes the misattributed outcome at face value, concludes that a channel underperformed, and reallocates away from it, confidently, every day.
Identity resolution stops being a data-team hygiene project and becomes a precondition for anything agentic being trusted with a budget.
[Can identity resolution work without AI? Steven Renwick from Tilores explainsTilores’ CEO explains why rules still rule, and how GenAI plays a supporting role in identity resolution, not the starring one.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/can-identity-resolution-work-without/)
Watch my podcast with Steven Renwick on identity resolution's role when working with AI.
## The uncomfortable part: agents hide bad data
The optimistic take is that agentic systems will finally force the data-quality reckoning our industry has been deferring since I was building tag implementations by hand.
I am not sure that is what happens.
An agent takes poor input and returns something fluent, confident and well-formatted. It does not hedge the way a good analyst hedges. It does not say the tracking broke on the fourteenth. It produces a recommendation with a rationale, and the rationale sounds right.
> Bad data used to look like a broken dashboard. Now it looks like a competent answer.
That is worse, not better.
The error is no longer visible at the surface, it is laundered into something authoritative. So the honest possibility is that agentic marketing postpones the reckoning rather than forcing it, and the organizations that suffer most are the ones whose data was bad in ways nobody had to look at.
## This is not only my hobby horse
Analytics people have announced their own moment before.
Remember the claim that big data was going to make data quality unavoidable?
So was machine learning.
So was the CDP.
Each time the rugs stayed exactly where they were, so treat any claim of this kind, including mine, with some suspicion.
What is different this time is not the enthusiasm. It is that the human filter is being removed, and the evidence is arriving from outside the analytics fan club.
[Forrester finds the biggest blocker to scaling AI is data quality](https://www.forrester.com/blogs/the-state-of-agentic-ai-in-2026-companies-are-chasing-few-are-catching/?ref=martechtherapy.com), not model performance. In [Deloitte's most recent survey of chief data and analytics officers](https://www.deloitte.com/us/en/about/press-room/chief-data-and-analytics-officer-survey-finds-cdaos-acting-as-ai-trailblazers.html?ref=martechtherapy.com), 61% named improving data quality and access as key to their AI and agentic initiatives. PwC, polling operations leaders rather than marketers, found [87% saying poor data quality has hampered progress on digital work](https://www.pwc.com/us/en/services/consulting/business-transformation/library/digital-trends-operations-survey.html?ref=martechtherapy.com), with only 30% reporting real improvement. [Brinker and Riemersma's martech survey](https://chiefmartec.com/2025/12/heres-your-copy-of-our-martech-for-2026-report-free-and-ungated/?ref=martechtherapy.com) lands in the same place:
> The top implementation challenge is the data, not the models.
Four separate research efforts land on the same answer.
## A measurement readiness check
Before you hand goals to anything, work through six questions. It takes an afternoon and will tell you all you need to know.
1. Can you state the goal as an outcome and a number, without using the word campaign?
2. Does that number exist today, without someone exporting a spreadsheet to produce it?
3. How fast does it come back? Hours, days, or the second week of next month?
4. If it is slow, what proxy will the agent actually be steering on, and how far can that proxy drift from the real outcome before you would notice?
5. Who agrees it is the right number? If finance and marketing hold different versions, the agent optimises whichever one it was handed and you argue about it a quarter later.
6. And what must not move while the goal improves? Margin, frequency, unsubscribe rate, brand safety. Name it, or the goal is not finished.
If you cannot answer four of those six, the constraint on your agentic CDP is not the vendor you are evaluating.
## Why this is process before it is technology
This lands in process and capability, two of the three readiness dimensions this series runs on. Process, because agreeing what good looks like and how quickly it reports is an organizational act, not a configuration screen. Capability, because someone has to be able to write the goal, and judge the result without flattering it.
[Will AI close the gap in Martec’s Law?Martech ships faster than any team can absorb. Martec’s Law says the gap only grows. Here is the case that AI might, conditionally, close part of it.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/will-ai-close-the-gap-in-martecs-law/)
It is also Martec's law in its most concrete form. The technology can now act faster than most organizations can define what they want. No purchase closes that gap, and the vendors selling the fastest action are the least incentivised to mention it.
Next week, part 5, the readiness check itself across structure, capability and process, and an honest look at how far along this market actually is.
Do you have any questions after reading this article?
Or need support with your Martech projects?
[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
### How to evaluate an agentic CDP on your own
URL: https://www.martechtherapy.com/how-to-evaluate-an-agentic-cdp-on-your-own/
Last updated: 2026-07-23T08:09:46.000Z
In [part 1](https://www.martechtherapy.com/what-an-agentic-cdp-actually-is-and-why-marketers-should-care/) I showed you a scorecard.
It was the five-point "litmus test" on cdp.com, the page that ranks first when you search for an agentic CDP, written by Treasure AI's CEO, and it scored Treasure AI five out of five and its rivals one and two.
[What an Agentic CDP actually is, and why marketers should careThe agentic CDP, defined for marketers. Where the term came from, who is bending it to sell, and what it actually changes about your job.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/what-an-agentic-cdp-actually-is-and-why-marketers-should-care/)
Where that scorecard came from ☝️
That test is not useless. It just answers the wrong question. It measures how agentic a platform is, in the abstract, and then treats the most-agentic score as the best buy.
That is like ranking cars by horsepower and telling a family of five to buy the drag racer. Powerful, yes. Practical, not so much.
The question you actually have to answer in the room is not the one the test answers. It is which tool fits what you need, and what you are ready to run. That is rarely the most agentic one.
## First, remember what the thing is for
Before any scorecard, one grounding point, and I am borrowing it from Tony Byrne at Real Story Group, who put it more plainly than most.
> A CDP earns its keep at activation. Unifying data is necessary, but the value shows up when a marketer can build an audience, act on it, and see what happened.
Byrne's list of what marketers actually want, a friendly view of their own data, simple segments, real activation, and a fast lane for the moments that need it, is a better starting point than any vendor's capability grid.
[What is a CDP in 2026?A CDP in 2026 is the same thing as it was when first birthed over a decade ago: A CDP is whatever the vendor says it is. That may sound cynical—but after waves of trends, acquisitions, the (reluctant) entrance of MarTech suite vendors into the market, and the rise of cloud data warehouses as core cuLinkedInTony Byrne](https://www.linkedin.com/pulse/what-cdp-2026-tony-byrne-llmfe/?ref=martechtherapy.com)
Tony Byrne's value-first take, worth your time ☝️
It is the same instinct behind the four ownership questions I gave marketers in [Composable CDP, translated for marketers](https://www.martechtherapy.com/composable-cdp-translated-for-marketers/). Start from what you are responsible for, not from the architecture diagram.
Tony Byrne makes one more point that matters for the whole series.
> The agentic, decisioning part is starting to separate out of the CDP into its own layer.
This is something I eluded to at the end of part 1.
So when a vendor sells you an "agentic CDP", ask which layer you are actually buying: the data, the activation, the decisioning, or a bundle of all three.
## The trap the vendor scorecards set
Every vendor litmus test has the same tell. The criteria are *the things that vendor happens to be good at*.
Treasure AI's rewards native messaging and a closed loop inside one platform, which is how Treasure AI is built. Run the same exercise on a warehouse-native vendor, or on the data cloud, and you get a different test with a different winner every time.
> The tool that scores highest on raw capability is rarely the one that scores highest for you.
The fix is not a better absolute test. It is to score fit. Rate what you need first, then score each tool against that need, not against an ideal nobody asked you about.
## How to score an agentic CDP for fit, not purity
Here is the version I would take into an agentic CDP evaluation. Six dimensions. For each one, rate your own need first, must-have, useful, or not needed, and only then score each shortlisted tool from zero to three.
**Decisioning speed, against your use case.** Do you need real-time, in-session decisions, or is a daily or hourly refresh fine?
Warehouse-native tools are largely slow at sub-second today, packaged and hybrid tools are faster. Most marketers need less real-time than they think, and it is exactly where they overpay 😉.
[Right-time marketing and the speed of context decay“Real-time” hides three different clocks. What it means from a data warehouse, why context decay is the real metric, and where five CDPs draw the line.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/right-time-marketing-and-the-speed-of-context-decay/)
Read about "right-time" marketing in my most recent post ☝️
**Channel reach, against where you actually run.** Can it act across the channels you use, natively or through solid activation partners?
Score the gaps that hit your real channel mix, not a maximal one.
**The autonomy line, and whether you can move it.** What does the agent decide alone, and what does it bring back for sign-off? Can you set that gate to the level of delegation you are ready for?
A tool that only suggests is an autocomplete. A tool with no gate is a liability.
**Visibility, control, and brand.** Can you see why the agent did what it did, constrain it, roll it back, and encode your brand lines, frequency caps, and suppression so they hold at scale?
Score low here and nothing else rescues the tool, because you cannot be accountable for what you cannot inspect. This is also where the old question of [who is actually in charge](https://www.martechtherapy.com/whos-actually-in-charge/) comes home.
**Where the data actually lives.** Your warehouse, the vendor's store, or a copy of both?
This decides ownership, portability, and how locked in you are. It is the mirror of the speed question, and the place warehouse-native tools tend to win where packaged ones do not.
**Goal and measurement fit.** Can it take the goals and the clean signal you can actually provide, and report against them?
An agent with no goal to chase is an expensive draft generator, which is the whole of part 4.
Add them up and you do not get a winner. You get a fit profile: where a tool is strong on the things you need, and where it is weak on things you do not.
Example scorecard result.
## The same scorecard, two different winners
This is the part a vendor scorecard can never show you, because that kind of test has one winner built in from the start. Run the fit version and the winner changes with the buyer.
Take a large retailer with a mature warehouse and real-time, on-site personalization at the core of the business. Speed is a must-have. Owning the data is a must-have. Native messaging matters less, because the team already runs its own channels. A data-cloud-native or hybrid platform, a Databricks-style build, scores well here.
As Mike Pastore pointed out, that is exactly who Databricks sells to: the CIO and the data team at a large enterprise with the maturity to run it.
[Ready or not, welcome to the era of the agentic CDP | MarTechTrying to navigating the shifts in the CDP market can feel dizzying. Here’s what we learned from last week’s agentic CDP news.MarTechMike Pastore](https://martech.org/ready-or-not-welcome-to-the-era-of-the-agentic-cdp/?ref=martechtherapy.com)
Mike Pastore on who each model actually fits ☝️
Now take a mid-market B2B team running weekly lifecycle campaigns with a lean data function. Sub-second decisioning is not needed. What they need is a friendly builder, native messaging, and a tool that works without a warehouse they would have to trust first. A packaged platform with its own data layer wins this one comfortably, and the warehouse-native tool that topped the first scenario would be a slow, heavy mismatch here.
Same scorecard, run twice, and the winner flips.
Mike Pastore landed on it from the vendor side too:
> It is unlikely either approach wins. Each approach can be a winner for the right customer.
That **last** sentence is the whole reason to score fit instead of purity.
## Why this is a structure question
Notice what decided both scenarios. Not the agent. The organization around it.
Whether real-time matters, whether you own the data, whether you have the channels and the team to run any of it, that is Structure, the second of the three readiness dimensions this series runs on. The scorecard is really a mirror. It tells you as much about your own readiness as it does about any vendor.
So before the demos, fill in the need column for yourself. If you cannot, that is the first thing to fix, and it is far better to find out now than two quarters into a migration.
I will fold these six dimensions into a one-page checklist you can carry into the room, and into the readiness check in part 5.
Next week, part 4: measurement, the dimension the whole category is leaning on, and the one most teams answer worst.
Do you have any questions after reading this article?
Or need support with your Martech projects?
[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
### Right-time marketing and the speed of context decay
URL: https://www.martechtherapy.com/right-time-marketing-and-the-speed-of-context-decay/
Last updated: 2026-07-26T08:05:38.000Z
Every customer data vendor sells real-time. It's on the homepage, in the demo, in the answer to question fourteen of that RFP in front of your nose. The word carries a lot of weight, yet most of that weight stays out of view.
Ask what real-time actually means once the data lives in a warehouse, and that single word splits into three separate jobs that you can remember with the **CDP** acronym, too.
The first is **collect**: getting an event into the system at all. A click, a purchase, a page view, arriving through an SDK, a stream, or a warehouse ingest pipe.
The second is **decide**: turning that event into something a marketer can act on. A segment membership, a propensity score, a next best action.
The third is **push**: getting the resulting action back out to wherever the customer actually is, whether that's an email, an ad platform, or a live web or app surface.
Collect. Decide. Push. CDP... get it?
Three jobs but three clocks. They rarely run at the same speed, and nothing forces a vendor to tell you which clock the "real-time" on the homepage refers to.
> A platform can be genuinely fast at collecting an event and slow at pushing an action, and still print "real-time" across the whole pipeline.
That ambiguity is convenient, and it's convenient in one direction. A number that describes the fastest link in the chain looks better in a sales deck than a number that describes the slowest. So the demo shows you an event landing in the system the instant it fires, and says nothing about the forty minutes between the decision and the email that carries it.
None of this makes warehouses a bad place to keep customer data. It makes "real-time" a word worth taking apart before you pay for it.
The rest of this piece is about where the slow link usually hides, why it hides there for structural reasons rather than lazy engineering, and examples of how five vendors plus a do-it-yourself path each make a different bet about what to do with it.
Let's get started.
## Why a warehouse hits a wall
Everything so far assumes the warehouse can move at the speed the marketing asks for. Mostly it can't, and the reason is baked into what a warehouse is.
A columnar store keeps each column together on disk so it can scan millions of rows across a handful of columns and hand back a sum, a join, an aggregate. That design is what makes analytics fast. It also makes the opposite job slow: pulling one customer's full profile, right now, in a single lookup. Point lookups are the thing a warehouse is worst at, and a point lookup is exactly what an in-session decision needs. That is a property of the storage design, and no amount of tuning changes it.
The published numbers tell the same story once you read them by job. Take Snowflake, since its documentation is specific and the shape repeats across the category. Collecting an event is genuinely quick: Snowpipe Streaming flushes on a [one-second default](https://docs.snowflake.com/en/user-guide/snowpipe-streaming/snowpipe-streaming-classic-recommendation?ref=martechtherapy.com), tunable down to a second or up to ten minutes. Transforming it is where the floor appears. Dynamic Tables, the managed way to keep a derived table current, carry a [documented minimum target lag of one minute](https://docs.snowflake.com/en/user-guide/dynamic-tables/decision-guide?ref=martechtherapy.com), and that minute is a staleness target rather than a promise about latency. You cannot tune beneath it.
> Snowflake's own decision guide is blunt about the edges: if you need always-current data with no lag, use materialized views; if you need sub-minute freshness with custom logic, use streams and tasks.
Which points at the real problem. Dynamic Tables can't call a stored procedure or an external function, so pushing a decision back out of the warehouse in the moment falls to a hand-built chain of streams, tasks, and an external function calling a webhook. You own the retry logic, the credential rotation, and whatever wakes you when it breaks, which is precisely the maintenance a CDP is charging you to take off your plate.
Two more costs stay off the demo. Warehouse compute queues under concurrent load, so latency stops being predictable the moment real traffic arrives, whatever target lag you set. And a virtual warehouse auto-suspends when idle, so waking it takes real seconds, invisible in a nightly batch and fatal to a respond-in-fifty-milliseconds promise if the thing was asleep when the customer showed up.
The clearest evidence is what the vendors built to get around all this. Snowflake Hybrid Tables and Databricks Lakebase are row stores bolted onto the analytical engine specifically to do the point-lookup job it can't. They are a different storage engine sold under the same name. Databricks made the split impossible to miss this year by shipping [Lakehouse//RT](https://www.databricks.com/blog/introducing-lakehousert-real-time-performance-unified-lakehouse?ref=martechtherapy.com), a separate real-time engine, as its own product alongside the Lakehouse. When a company launches a second engine for speed, the fair reading is that the first one doesn't get there on its own.
None of this makes a warehouse a bad place to keep customer data. It is the best place we have. It is the reason the slow link almost always sits at the push step, and the reason every vendor in the next section is answering the same question:
> What do you do about a warehouse that was never built to act in the moment?
## How fast does the context go stale?
A one-minute floor sounds like a problem right up until you ask what you were going to do with the minute. Most of the time the honest answer is nothing. If a customer's situation holds steady for the rest of the day, a segment that refreshes every ten minutes is exactly as fresh as the decision requires. The floor from the last section **only bites when the context underneath it is moving faster than the warehouse can keep up**.
That distinction has been drawn well before now, and the person who drew it clearest for a data audience is Martin Kihn.
In a 2023 piece, he **separated real-time data from real-time action**, and pointed out that acting seconds, minutes, or hours later is often the correct move rather than a compromise forced on you by slow plumbing. His example was an airline changing your seat:
> The airline holds that context for hours, so the right moment to tell you is the next time you open the app, well after the change actually posts.
He is worth crediting for the framing and worth being accurate about. The phrase *right-time* was already circulating years earlier, in trade press and analytics writing around 2014\. Kihn didn't coin it. He put it in front of the CDP crowd at the moment the category needed to hear it.
[What Does ‘Real-Time Marketing’ Really Mean?You might be answering the question, “What is real-time marketing?” incorrectly. Here’s a look at what it really means.SalesforceMartin Kihn](https://www.salesforce.com/blog/what-is-real-time-marketing/?ref=martechtherapy.com)
The reframe that follows is the part I want to discuss. The skill is matching what you spend on latency to **how fast the customer's context actually decays**, which has surprisingly little to do with buying the fastest pipeline on offer. Get it wrong in the expensive direction and you pay for speed the use case never needed, every month, on the compute bill. That is the core of what I've been calling compute-bait economics: the number on the homepage is tuned to sell, and once you hold it against a real decay rate, most of it turns out to be speed you never cash in. \[LINK: compute-bait economics piece — confirm slug\]
A cart abandonment makes the shape concrete. The abandon event lands in the warehouse within seconds. The reverse-ETL sync that carries the resulting audience to your email tool runs on a schedule, and on RudderStack that [schedule floors at five minutes](https://www.rudderstack.com/docs/sources/reverse-etl/common-settings/sync-schedule-settings/?ref=martechtherapy.com), with [most syncs completing in a couple of minutes](https://www.rudderstack.com/docs/data-pipelines/reverse-etl/developer-guides/faq/?ref=martechtherapy.com) once they fire. Add the email tool's own send lag, and the message chasing the cart goes out several minutes to the better part of an hour after the person left, depending where their sync fell in the cycle. For a next-day winback, invisible. For someone still holding their phone, the moment closed before the pipeline moved.
Scott Brinker gave this a more structured shape than a single cut between real-time and right-time. In the [State of Martech 2026 report](https://content.martechday.com/state-of-martech-2026.pdf?ref=martechtherapy.com), he and Frans Riemersma lay out a [pace layer context stack](https://newsletter.chiefmartec.com/p/marketing-as-architecture-the-stack-is-not-the-building?ref=martechtherapy.com):
> Six layers of customer context, each with its own natural speed.
Market context moves over years, company context over quarters, relationship context over months, journey context over days, session context over minutes, and moment context over seconds.
The exact boundaries matter less than the consequence.
A stack that forces all six layers to refresh at moment-speed is paying six times over for freshness five of them can't use.
The idea that different layers of a system should change at different rates is older than the framing. Stewart Brand described it for buildings, and Gartner applied the same logic to enterprise software years before this report. What's current is naming the six marketing speeds and noticing that AI agents are compressing all of them at once.
[The readiness thread inside the State of Martech 2026Scott and Frans handed us value engineering and context engineering, both useful. The thread they didn’t have time to pull is what your team has to actually become to operate any of it. Picking it up here, with a navy metaphor and the bit of the IKEA Billie story nobody talks about.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/the-readiness-thread-inside-the-state-of-martech-2026/)
Kihn and Brinker are answering the same question from two distances:
> How fast should each decision move?
Neither settles where the work to hit those speeds should actually live. That is the next question, and it has a good model behind it.
## Where the work lives
The last two sections were about how fast each decision needs to move.
The next question is where the work to hit those speeds should sit, and David Chan, at Deloitte, has spent the last few years building the clearest answer I've read.
He calls it the **Dual Zone model**.
The split is straightforward.
**Zone 1 is the data zone**: the warehouse, identity resolution, enrichment, and the historical and propensity scoring that needs large-scale data and real compute. This is macro decisioning, and it runs on whatever cadence the warehouse can support, which section two put at minutes on a good day.
**Zone 2 is the engagement zone**: journey orchestration, personalization, and campaign activation, the work that has to answer in the moment. This is edge decisioning, and it runs on whatever is cached and contextual right now, informed by the scores Zone 1 handed over earlier.
Chan is careful to separate this from a vague "hybrid", a label he has pushed back on directly. The model is about how the work gets distributed, who does it and where it gets done, rather than two products blended into a mushy middle.
Framed that way, **a CDP is less a piece of software you buy than a set of capabilities you place**, some in the warehouse and some at the edge.
The reason this matters beyond vocabulary is that the line between the two zones tends to fall exactly where your organization is already split. Zone 1 is the data team's world, Zone 2 is the marketing team's, and a [CDP Institute](https://www.cdpinstitute.org/?ref=martechtherapy.com) round table tied that directly to *Conway's Law*, the old observation that systems end up shaped like the communication structure of the group that built them.
Your architecture mirrors your organization chart whether you meant it to or not, which is why vendors keep landing on this same two-zone shape on their own.
They are selling to a seam that already runs through the customer.
[Same stack, different worldsMulti CDP Part 2: Explore four common multi-CDP patterns and how real-world teams shape Martech stacks through roles, needs, and coordination gaps.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/same-stack-different-worlds/)
That sets up the rest of the piece, because every product in the next section is a different bet about that seam. Some run a light Zone 2 cache alongside the warehouse and leave Zone 1 where it sits. Some ship Zone 1 and Zone 2 as two separate products and let you wire them together. One tries to collapse both zones into a single deployment inside the warehouse itself. The latency number each one advertises is downstream of that choice, and the choice is the thing worth considering.
## Five bets on the same line
The useful way to read this market is to stop sorting by speed and start sorting by where each product draws the Zone 1 and Zone 2 line, because the latency number falls out of that choice.
I've ordered them from the ones that keep the zones farthest apart to the one that sells you the whole spectrum. Each is introduced by what it actually is, since the Snowflake Native App wrapper several of them offer is a deployment option, not the product.
### RudderStack: keep the two jobs apart
RudderStack is a warehouse-native pipeline company, and its reverse-ETL product states the principle plainly in [its own docs](https://www.rudderstack.com/docs/data-pipelines/reverse-etl/?ref=martechtherapy.com):
> Reverse ETL does not support ingesting streaming data.
Real-time is a separate product, Event Stream, that skips the warehouse entirely. In Dual Zone terms RudderStack refuses to blur the line: Zone 1 work runs on warehouse time, Zone 2 work runs on a separate real-time path, and the refusal to pretend otherwise is the selling point.
Reverse-ETL syncs land in a couple of minutes on a five-minute floor, billed per destination.
💡
Best fit is the large share of activation where hours-old data is fine, which is most of what reverse ETL is for.
### Hightouch: mostly in the warehouse, one admitted exception
Hightouch built its name on a zero-copy promise: query the warehouse directly, keep no shadow database, leave Zone 1 where it is. [Same-session personalization](https://hightouch.com/blog/same-session-personalization?ref=martechtherapy.com) is where that gets complicated, and to their credit they say so.
To blend live events with full warehouse history and answer in under a second, Hightouch caches state in an architecture that runs parallel to the warehouse, which the [CDP Institute](https://www.cdpinstitute.org/news/hightouch-introduces-same-session-personalization/?ref=martechtherapy.com) called bending the company's own no-copy rule.
Co-CEO Tejas Manohar put the target at "the amount of time it takes to press the lever on a toaster." That parallel cache is a small, explicit Zone 2 on a warehouse-first design, and the admission is what makes it credible.
💡
Best fit is same-session personalization where live behavior and full history both shape the moment.
### Tealium: two real products, one per zone
Tealium's core is AudienceStream, a real-time CDP that has triggered on live events for years without a warehouse underneath it, a fully-formed Zone 2.
Its newer Snowflake Native App, [Audience Discovery](https://tealium.com/audience-discovery-app-snowflake/?ref=martechtherapy.com), adds a real Zone 1: you build and govern the segment definition inside Snowflake, by point-and-click, SQL, or Cortex, and the rows never leave. Activation runs through the same real-time layer either way.
Tealium is the cleanest picture of the split as two literal products, one in each zone, which is roughly how CTO Mike Anderson frames it, the data cloud as the brain and Tealium as the nervous system.
Its [Context API](https://tealium.com/technology-partner/better-together-tealium-snowflake/?ref=martechtherapy.com) returns a full profile in about sixty milliseconds.
💡
Best fit is governance-first teams that want SQL or Cortex control over segment logic on Snowflake, on an activation engine that was already real-time.
### Zeotap: collapse both zones into the account
Zeotap is a composable CDP that runs warehouse-agnostic across Snowflake, BigQuery, and Databricks: an SDK collects events, and a real-time orchestration layer pushes to destinations by webhook.
On Snowflake it goes further than a connector. Deployed as a [Native App](https://zeotap.com/blog/the-zeotap-composable-cdp-is-live-on-the-snowflake-marketplace/?ref=martechtherapy.com) on Snowpark Container Services, the whole platform runs as a container inside the customer's own account, so data never leaves the governed environment and the processing cost lands on the Snowflake bill instead of a separate invoice.
Collapsing both zones into one deployment raises the honest question section two set up:
> If the orchestration runs on a warehouse-speed engine, what is it caching to feel sub-second?
The constraints don't lift because the container is local, and there is no published latency SLA.
💡
Best fit is regulated industries that need real-time triggers without a data-transfer security review.
### Treasure AI: buy the whole spectrum
Treasure AI, renamed from Treasure Data in April 2026, sells the whole line rather than a single point. In [Composable Mode](https://docs.treasure.ai/products/customer-data-platform/composable-cdp?ref=martechtherapy.com) it runs zero-copy federated queries against your warehouse, with data staying put until activation.
In **Complete Mode** it ingests the data into its own infrastructure, where native messaging and deeper AI decisioning live. The part worth paying attention to, which Treasure says itself, is that even in Composable Mode the sub-second activation runs off Treasure's own real-time profile cache outside the warehouse, the same move as Hightouch's parallel cache, packaged as one end of a continuum.
This is a legitimate strategy rather than a bait-and-switch: one vendor, predictable pricing, a real on-ramp for enterprises that will likely want native messaging and full AI decisioning eventually. The honest understanding is that Composable Mode is an entry point with a gravitational pull toward Complete Mode, a real dependency to weigh against RudderStack at the far end, which never offers the on-ramp at all.
One disclosure: Treasure also runs cdp.com, the "independent" CDP glossary many buyers read first, so its view of the category travels further than its product pages.
💡
Best fit is enterprises that want one vendor across a warehouse-native start and a full AI-decisioning end state.
I picked these five because between them they cover most of the ways the market answers the question. *They are not the whole list*. A handful of others are worth a shorter look, some narrower in scope, some whose direction is still settling.
## A shorter look at the rest
**ActionIQ** answers the question much the way Zeotap does, pushing queries down against the warehouse with a separate real-time stream for triggers, and the architecture is sound.
The company around it is the part to track. Uniphore bought ActionIQ in late 2024 and folded it into a product now called CDP Agent, which is why the ActionIQ name dropped off Gartner's 2026 Magic Quadrant. That drop is easy to overlook, because [Uniphore entered the same quadrant as a new Leader](https://www.cxtoday.com/customer-analytics-intelligence/gartner-magic-quadrant-cdp-2026/?ref=martechtherapy.com) on ActionIQ's engine, so the technology was promoted rather than shelved. Worth a look once the roadmap under new ownership firms up.
**Amperity** spent years as an identity-resolution specialist with little activation of its own, and moved in May 2026, [shipping Real-Time Tables for live ingestion and Real-Time Activation for in-session moments](https://www.businesswire.com/news/home/20260506444429/en/?ref=martechtherapy.com) like cart abandonment at its Amplify conference. It is new and not yet independently benchmarked, so it sits on a watch list rather than a shortlist for now.
**Databricks CustomerLake** is the platform-draws-the-line-for-you bookend, launched in June 2026 as an [agentic CDP embedded in the Lakehouse](https://www.databricks.com/blog/introducing-customerlake-agentic-cdp?ref=martechtherapy.com). Databricks describes a real-time serving layer for customer attributes, and two facts from Databricks itself temper that:
> CustomerLake is in private preview, and the company shipped [Lakehouse//RT](https://www.databricks.com/blog/introducing-lakehousert-real-time-performance-unified-lakehouse?ref=martechtherapy.com) as a separate real-time engine at the same summit.
When the real-time performance ships as its own product, the platform's real-time language is running ahead of what's wired together.
[Databricks CustomerLake: the data lakehouse is now the CDPDatabricks launched CustomerLake, a lakehouse-native agentic CDP. What it means for composable vendors, Databricks customers, and the next data platform.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/databricks-customerlake-the-warehouse-cdp/)
**Snowflake, on its own** is the draw-the-line-yourself option, and it is the chain the vendors above are selling you out of:
> Snowpipe Streaming to ingest, Dynamic Tables to transform, and Streams, Tasks, and a hand-built external function to push a decision out.
As I have said before, you own the retry logic and the on-call that come with it. Worth it for a narrow, well-defined use case with a data team that has the room, and rarely worth it beyond that.
**Census** earns a line as a marker of where the category is going. Fivetran acquired it in 2025, so another independent reverse-ETL name now sits inside a larger platform.
## What you're actually choosing
Step back from the five vendors and the footnotes, and the whole thing reduces to two questions.
1. How fast does this decision's context decay?
2. Where should the work to beat that clock sit, in the warehouse or in a layer beside it?
Every product here has answered the second question for you, and the latency number on its homepage is that answer made visible.
> Buy the boundary that matches how fast your context decays, and the latency number takes care of itself.
Most marketing decisions are not moment decisions.
Relationship, journey, and company context hold for days or longer, and a warehouse serves them on its own cadence without help.
The few that genuinely turn over inside a session are the ones that justify a cache beside the warehouse or a live layer fed by it, and *paying for that speed everywhere else is how the compute bill outgrows the value it returns*.
So the choice is less about which vendor is fastest and more about knowing which of your decisions actually live in the bottom two layers of the context stack, then buying only as much boundary-crossing speed as those few decisions need.
If you want a structured way to lay out your own stack and see where these lines fall, that is what I built the [Martech Stack Builder](https://www.martechstackbuilder.com/?ref=martechtherapy.com) for. The vendors will keep selling speed. Knowing how much of it you actually need is the part they can't do for you.
Do you have any questions after reading this article?
Or need support with your Martech projects?
[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
### How Snowflake recruited Zeotap's composable CDP
URL: https://www.martechtherapy.com/how-snowflake-recruited-zeotaps-composable-cdp/
Last updated: 2026-07-15T17:42:50.000Z
Zeotap's composable CDP is live on the Snowflake Marketplace, running inside your own Snowflake account as a Native App. That is the announcement, and it is the boring half.
The half I care about came from Jonaten Kraus at Snowflake, who spent about six months on this before it shipped and then wrote up what really happened on LinkedIn. His framing is the whole thing. Snowflake wasn't deciding whether to approve another marketplace app. It was deciding whether to treat Zeotap as a partner instead of a customer.
> Snowflake picked a category vendor and pulled it deeper into the platform on purpose.
Read the Zeotap blog, and you see a product launch.
Read Jonatan, and you see recruitment or, at a minimum, a pursued collaboration.
[](https://www.linkedin.com/feed/update/urn:li:activity:7478423836569395200/?ref=martechtherapy.com)
[**Read Jonatan Kraus's account of the six months behind the launch here*](https://www.linkedin.com/feed/update/urn:li:activity:7478423836569395200/?ref=martechtherapy.com) ☝️
## What Zeotap actually shipped
The product is a composable CDP, live on the Marketplace, built as a Native App on Snowpark Container Services.
Visualization generated by Google's NotebookLM
Here is the claim that matters.
> Zeotap says the whole thing runs as a container inside your own Snowflake account, not on Zeotap's servers reaching in from outside.
That is a **big claim**, and the kind I don't take on a vendor's word, so I went and looked at the architecture instead of the press release. It holds up. Identity resolution and journey logic run in your Snowflake, on your compute, with Zeotap out of the data path.
Most tools that say they run "on Snowflake" still do the real work on their own servers. This one runs the whole thing in your account.
## Only one of the four moved in
"On Snowflake" turns out to cover a lot of ground, and these four are spread right across it.
[RudderStack](https://www.rudderstack.com/?ref=martechtherapy.com) shows up on Snowflake in more than one form. Its reverse-ETL and event-stream pipelines are the old-fashioned kind, moving data in and out with credentials while the platform stays on RudderStack. Its Profiles product goes further and runs identity resolution warehouse-native, building the identity graph and customer tables as models inside your Snowflake. So a piece of RudderStack does run in your account. The rest of it doesn't.
Rudderstack on Snowflake Marketplace
[Hightouch](https://app.snowflake.com/marketplace/listing/GZSTZ4WTVLUYC/hightouch-hightouch-platform?ref=martechtherapy.com) splits the same way. The activation engine most people know reads from Snowflake at sync time and pushes data out to your tools, and that runs on Hightouch's own servers. Its newer [AI Decisioning is delivered as a Snowflake Native App](https://www.snowflake.com/en/blog/new-era-lifecycle-marketing-ai-decisioning-snowflake/?ref=martechtherapy.com) and leans on Snowflake Cortex to work inside your account, with the activation still handled by Hightouch. So a slice runs in your warehouse and the rest stays home.
Source: [A New Era of Lifecycle Marketing with the AI Data Cloud and AI Decisioning](https://www.snowflake.com/en/blog/new-era-lifecycle-marketing-ai-decisioning-snowflake/?ref=martechtherapy.com)
[Amperity](https://app.snowflake.com/marketplace/listing/GZSNZ1L9MD/amperity-the-intelligent-customer-data-platform?ref=martechtherapy.com) keeps its distance on purpose. Its Bridge integration uses zero-copy sharing, so your data never gets copied into a second home, which is the thing most buyers actually lose sleep over. Your data stays put. The compute doesn't. Amperity's identity resolution still runs on Amperity.
Then Zeotap, which moved the whole thing in. It **runs the entire composable CDP as a container in your Snowflake account through Snowpark Container Services**, with identity resolution and journey logic executing on your compute and Zeotap out of the data path.
Source: [Zeotap](https://zeotap.com/blog/the-zeotap-composable-cdp-is-live-on-the-snowflake-marketplace/?ref=martechtherapy.com)
A slice of the others runs in your warehouse. Zeotap is the only one, for now, that packed up the whole operation and set it down inside yours. Whether you want a tenant that deep in your account is a separate question, and a fair one.
## Databricks did this first, in the other well
If this feels familiar, it is because I wrote most of it a month ago about Databricks.
Two gravity wells, Databricks and Snowflake, both pulling the CDP toward wherever your data already lives. Jonaten said it with "Where will customers be? Where can we create the most value?", or simply put:
> Whoever hosts the CDP without the data leaving keeps the account.
Databricks built its own. CustomerLake is a CDP it stood up inside the lakehouse, staffed with the people who used to build the independent CDPs it is now swallowing whole.
From what we can now see, Snowflake got to the same place, but from the other side. Instead of building a CDP, it recruited one and helped it move in.
Same destination. The only real difference is whether the platform builds the front door itself or hands a vendor the keys and the blueprints.
[Databricks CustomerLake: the data lakehouse is now the CDPDatabricks launched CustomerLake, a lakehouse-native agentic CDP. What it means for composable vendors, Databricks customers, and the next data platform.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/databricks-customerlake-the-warehouse-cdp/)
Read my thoughts on Databricks' CustomerLake announcement ☝️
## Snowflake recruited it
This is why Jonaten's post beats the Zeotap blog. It is the platform telling you it influenced the whole thing.
Zeotap started out built mostly on GCP and BigQuery. The Snowflake connector was an afterthought. Then, by Jonaten's account, the conversation turned strategic, and not in the features-and-pricing sense. It was about where Snowflake's customers were going to sit, and how to build an ecosystem where a partner could grow instead of ending up in a fight with the platform it runs on.
The plan was composable CDP first, Native App second. Zeotap's team, Sathish, Pritika and Aniket, shipped both in about six months. 😳
As a build, that is fast. That should not a surprise in this [day and age of agentic coding](https://www.martechtherapy.com/the-dirty-truth-about-vibe-coding-in-martech/), so bare with me when I say that it is the strategy underneath is the part worth watching. Snowflake went looking, for reasons that can only be speculated about. It got into a vendor's roadmap and pointed it deeper into Snowflake. To be fair, Databricks did pretty much the same dance when it pulled the customer-engagement crowd into CustomerLake's orbit.
## The bill lands on you now
Don't go into this bind, because here is a consequence that is easy to miss.
When the CDP runs inside your account, **on your compute**, the cost of running it shows up on your Snowflake bill, not on a Zeotap invoice.
Zeotap calls that transparency, and fair enough, there is a real version of that argument. You see what the thing actually costs instead of a flat fee that buries it.
It cuts the other way too. As all things SaaS do.
A CDP that shows up as Snowflake consumption is a CDP that is much harder to line up against its rivals on price, and every dollar it burns feeds Snowflake's own consumption growth.
Keep that in view before you take the transparency framing at face value.
### So I asked Zeotap
The biggest claim in the whole launch is the security one:
> The vendor never touches your data.
For a regulated buyer that is not nothing. And underneath it sits the question none of the blogs answer, whether "runs inside your account" means Zeotap rebuilt its identity resolution and journey logic for Snowpark Container Services, or wrapped the existing thing in a container and shipped it somewhere new.
So I put it to [Aniket Awati, Zeotap's Vice President of Engineering](https://www.linkedin.com/in/aniketawati/?ref=martechtherapy.com). His answer was more specific than I expected, and the story starts before the native app.
Zeotap re-architected for composable early last year, pushing the heavy compute down into the customer's warehouse instead of copying data into its own cloud. By the time the native app came along, the CDP core already ran as pushdown SQL in Snowflake: the identity engine, the journey engine, the compilers. So the native app didn't move the query compute. That had already moved. What it moved, in Aniket's words, was the rest.
> We moved the entire control plane in-account
Job execution, secrets, the event bus, the metadata store, all re-plumbed to run inside Snowflake through Snowpark Container Services, with the CDP logic carried over intact.
So the honest answer to my own question is a third thing. The hard part, moving the compute, happened in the composable rebuild a year ago. The native app moved the control plane in to sit beside it. That makes the "*runs inside your account*" claim sturdier than I could confirm from the outside.
On the security line, Aniket's answer was the strongest of the lot. Every outbound path is enumerated and approved, first by Snowflake's own app review, then by the customer through the access grants they control. "There is no undocumented outbound route" he told me. That is a real assurance, and easier to give from inside the account than from outside it. Whether it swings an enterprise deal is still the open question. The mechanism isn't in doubt. Whether buyers actually optimize for it is.
On cost I stay a shade more skeptical, though he had a fair answer there too. Aniket reframes the "*invisible on a vendor comparison*" worry as transparency:
> The fee becomes the price of Zeotap's IP, and the infrastructure runs as Snowflake consumption the customer can see and size for themselves.
He even grants the split "isn't a fully solved problem". His answer covers visibility for the customer. It doesn't touch the other half I flagged, that the same move feeds Snowflake's own consumption number.
Both are true at once, and only one of them was the question.
## So what do you do with this
If you have a CDP decision open right now, do the boring thing first and look at your whole martech stack before you fall for any one piece of it.
That is the reason I built [Martech Stack Builder](https://www.martechstackbuilder.com/?ref=martechtherapy.com).
The part I can't get past sits above any martech stack diagram. When the platform gets to decide which vendors get promoted from customer to partner, and helps rewrite their roadmap on the way, how independent is the CDP that took the deal?
Do you have any questions after reading this article?
Or need support with your Martech projects?
[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
---
*A note on sourcing: this piece is built from publicly available information, the vendors' own documentation and announcements, Snowflake's, and one on-the-record interview with Zeotap. If I have a detail wrong about how any of these products runs, tell me and I'll correct it.*
### From operator to director: the marketer's job after the agentic CDP
URL: https://www.martechtherapy.com/from-operator-to-director-the-marketers-job-after-the-agentic-cdp/
Last updated: 2026-07-13T05:27:08.000Z
In the [first part of this series](https://www.martechtherapy.com/what-an-agentic-cdp-actually-is-and-why-marketers-should-care/) I defined the [agentic CDP](https://www.martechtherapy.com/tag/agentic-cdp-series/) as a platform you mostly stop operating by hand, where you set the goals and the limits and check the work. Without many of you realizing it, that sentence hides a career change, so this part is about the job on the other side of it.
For about a decade, being good at martech meant being good at the tools. You knew where the audience builder kept the condition you needed, you could get a journey out of the platform without filing a ticket, you remembered which export broke if you sorted it the wrong way. That competence took years to build, and it is about to matter much less. The agent knows the buttons. What it does not have is your judgment about what to build and whether the result is any good.
[Agentic AI in Martech: The billion decision problemPart 1: Why scale changes everything about AI in MartechMartech TherapyMatthew Niederberger](https://www.martechtherapy.com/agentic-ai-in-martech-the-billion/)
Read my previous series about agentic AI in Martech ☝️
## What the agent actually takes
The vendors are clear about which tasks they are taking.
- [Simon AI](https://www.simon.ai/?ref=martechtherapy.com) splits its product into three sets of agents, one for strategy, one for data execution, one for revenue impact, which is a neat map of the operator work moving across the table.
- [GrowthLoop](https://www.growthloop.com/?ref=martechtherapy.com) keeps a no-code audience builder in front of the marketer and lets its agents assemble and optimize the segments behind it.
- [Databricks](https://www.databricks.com/?ref=martechtherapy.com) ships Campaign Agents that build audiences, recommend next actions, and keep tuning a campaign after it launches.
If you manage to read past the marketing lingo, you'll see that they are automating the same thing: the assembly and the upkeep of the campaign, the work that used to fill your week.
If your value to the organization was that you could operate the platform, that value is depreciating. This is the uncomfortable part, and it is worth saying plainly rather than dressing it up. The button-knowledge era of martech is closing. So much for all those certifications... but don't despair.
## What stays yours, and gets harder
What does not automate is the part that decides whether any of it works.
Start with intent: *saying what you actually want in terms an agent can act on*. That is harder than it sounds, because most campaign goals are vague the moment you try to write them down.
Then there are the guardrails, the things the agent must not do, your brand lines, your frequency limits, the offers it cannot make, the audiences it cannot touch.
And underneath both sits judgment: looking at what the agent produced and knowing whether it is good, off-brand, or wrong in a way that is easy to miss.
None of those is a button. They are skills, and most marketers have had little reason to practice them **until now**.
Visualization generated by Google's NotebookLM
It is fashionable to frame this the other way around. Writing about the same launches, MarTech.org's guest writer [Mike Pastore](https://martech.org/ready-or-not-welcome-to-the-era-of-the-agentic-cdp/?ref=martechtherapy.com) caught the vendor logic neatly:
> Where the first CDPs treated data as the problem, the agentic pitch treats the human as the blocker, too slow to analyse and decide. There is something to it, speed is real.
Every AI Agent by now ☝️
But the framing assumes the slow part was the valuable part, and it was not.
> **The valuable part was the judgment, and judgment does not get faster by removing the person who holds it**.
So the job is not disappearing. It is moving up to intent, guardrails, and judgment, and **you are still accountable for the result** even though you are no longer the one assembling it.
If you are in doubt, let me just emphasize that that is a promotion. 🎉
It is also a promotion most marketers have not been trained for, because the old job rewarded operating the tool, not directing something else to operate it.
This is something [Dojo AI](https://www.dojoai.com/?ref=martechtherapy.com) saw coming from mile away. The intelligent marketing system that Duarte Garrido and António Alegria are building boils down to this 👇🏻
> Take the assembly off the marketer's plate so the craft and the judgment are what is left.
Garrido ran marketing at Coca-Cola and Sky before this, and when he and Alegria came on my podcast Couch Confidentials they clearly stated, based on experience, that most stacks bury the craft under tool-wrangling. They were guests on the podcast, so weigh the endorsement with that in mind, but I think the direction is right, and the agentic CDP is one more reason the wrangling should not be the job.
[Is AI the end of Martech complexity? Dojo AI founders explainIn this episode of Couch Confidentials, I sat down with Duarte Garrido and Antonio Alegria from Dojo AI to talk about one of the biggest problems in marketing today—too many tools, not enough results. With over 15,000 marketing technology solutions on theMartech TherapyMatthew Niederberger](https://www.martechtherapy.com/is-ai-the-end-of-martech-complexity-8d1/)
## The brief is the new core skill
The practical version of all this is learning to write a brief an agent can use. You already write briefs, for agencies, for designers, for your own team. An agent is a more literal reader than any of them, and it will do what you said rather than what you meant.
This is not only a marketing observation. Ethan Mollick, who studies this at Wharton, argues that [managing agents is the real AI skill](https://www.oneusefulthing.org/p/management-as-ai-superpower?ref=martechtherapy.com), and his checklist for delegating to one, what you are trying to achieve, where the agent's authority ends, what done looks like, and what to check before it finishes, maps almost exactly onto a campaign brief.
The marketing version has a few parts. It states the goal as an outcome and a measure, not an activity, for instance lift repeat purchase among lapsed customers by the end of the quarter, not "run a win-back campaign." It names the audience and the data the agent should trust, and the context it should read first, your brand guidelines, the positioning, last quarter's results. It sets the limits in plain terms, the budget, the send frequency, the channels in and out of bounds, anything off the table. It says what the agent may decide on its own and what it has to bring back to you. And it says how you will check, what you want to see before launch and what you will review after.
Keep it to a page. **If you cannot fill in the goal or the limits, you are not ready to hand the campaign over**, which is a useful thing to find out before the agent finds it out for you.
## Why this is a capability problem
This is a [readiness gap](https://www.martechtherapy.com/tag/martech-readiness-gap/) more than a technology one, and it sits in the capability column of my Martech Readiness framework. The agent rarely fails because the technology is weak. It fails because no one briefed it well, or because no one could tell its good work from its confident mistakes.
Scott Brinker calls this new skill [context engineering](https://www.cmswire.com/digital-experience/scott-brinker-the-four-ai-agents-every-marketing-team-needs-to-know/?ref=martechtherapy.com), bundling the instructions, data access, and permissions an agent needs to act, and his 2026 survey work puts the top blocker not on the models but on the data marketers feed them. Both point the same way:
> The constraint is rarely the agent, it is whether the marketer and the organization are ready to direct it.
I wrote a while back, in [Letting go of control](https://www.martechtherapy.com/letting-go-of-control/), that moving to agents is a leadership question before a technical one, the same discomfort a manager feels the first time they hand real decisions to a new hire. The way out is the same as well. You get better at delegating by delegating, on small things first, with the brief tight and the review honest.
I called an earlier version of this *contextual fluency* in the [Contextual CDP series](https://www.martechtherapy.com/tag/contextual-cdp/), and the wider argument about agents and trust runs through the [Agentic AI in Martech](https://www.martechtherapy.com/agentic-ai-in-martech-the-billion/) series. This part is the narrow, practical corner of it, the "where do I start?" brief on your desk on Monday.
[Contextual CDPs: Contextual FluencyPart 6 of 6: Being contextual is also about competence.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/contextual-cdps-contextual-fluency/)
Context Engineering, Contexual Fluency, make sure to get ahead of the market.
## You can start before the platform arrives
The good news is, none of this needs the tool yet. You can practice writing the goal as a measure, drawing the guardrails, and judging output on the campaigns you already run by hand, and you will be readier than most when an agent shows up to do the assembly. The marketers who struggle with agentic CDPs will be the ones who never learned to say clearly what they wanted or to tell good work from bad. Sounding like a broken record, knowing the software was never the hard part.
Next week, part 3, what to demand from the platform itself when you are the one signing for it, and how to tell a tool built for you from one built for the vendor's slide.
## Sign up for Martech Therapy
Therapeutical thoughts, creative ideas, and curious journeys in Martech and AI by Matthew Niederberger.
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
Do you have any questions after reading this article?
Or need support with your Martech projects?
[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
### Will AI close the gap in Martec's Law?
URL: https://www.martechtherapy.com/will-ai-close-the-gap-in-martecs-law/
Last updated: 2026-07-09T05:58:57.000Z
You already know your stack ships more than your team can keep up with. That is not the interesting part, and it is not why I have been chewing on this for months.
The interesting question is whether AI is about to help with that or make it worse. Not in the abstract, but for the specific job of staying current with everything your tools ship after you have signed.
Here is the perspective I keep reaching for. Scott Brinker named the shape of this more than a decade ago and called it [Martec's Law](https://chiefmartec.com/2013/06/martecs-law-technology-changes-exponentially-organizations-change-logarithmically/?ref=martechtherapy.com), yes, without an 'h'.
> Technology changes exponentially. Organizations change logarithmically.
Source: [Chiefmartec](https://chiefmartec.com/2016/11/martecs-law-great-management-challenge-21st-century/?ref=martechtherapy.com)
Two curves pulling apart, with you stretched between them. The common perception of AI is that it steepens the technology curve, so the gap gets worse. That is probably half right.
My interest is in the other curve. For the first time, something can push on the organisational side of the law, the slow one that Brinker said only creeps along. That is either very good news or a new problem dressed as good news, and I honestly cannot tell you yet which one it is, yet. Hindsight after all is 20/20.
## The cost, priced
Before the AI question, the bill, because it is larger than people expect and almost nobody puts a number on it.
A while back, I worked through a hypothetical with an industry peer about vendor roadmaps. If a vendor ships one major feature and four minor ones a quarter, what does it cost your team just to stay current, or even to judge whether those features matter to your business model and architecture? Take a small company running 20 tools. That is 80 major features and 320 minor ones a year crossing your desks.
Price the time and it stops being abstract. Twenty tools, a handful of trackable releases each, 15 minutes to read one and decide whether it matters, and you are near 150 releases a quarter and about 38 hours per person just to track them. Across a team of eight, at a normal loaded salary, that is roughly €47,000 a year in salaried attention, before anyone books a single training session.
[](https://www.martechtherapy.com/feature-release-calculator/)
[Try the feature release calculator yourself here.](https://www.martechtherapy.com/feature-release-calculator/)
And most of what you track, you will never use. Pendo studied feature usage across hundreds of products and found around [80% of features are rarely or never touched](https://go.pendo.io/rs/185-LQW-370/images/2019%20Feature%20Adoption%20Report%20Digital.pdf?ref=martechtherapy.com), while a thin slice of about 12% carries most of the daily work. So the real job is filtering. Learning the tool was never the hard part. The other 80% still has to be read and waved past, and that is the tax nobody budgets for.
## The numbers under the curve
I have leaned on Martec's Law before, when I [extended it into decay](https://www.martechtherapy.com/extending-martechs-law-why-growth-leads-to-decay/) and made the case that stacks rarely fail, they just absorb more effort every year to stand still. What I wanted this time was the data under the curve, because the law usually gets drawn as two clean lines with no numbers on the axes.
[Extending Martech’s Law: why growth leads to decayMartech stacks rarely fail. They decay. Over time, more human effort is required just to keep the same outcomes. This article explores why ROI erodes quietly, how entropy shows up in real stacks, and why I built the Second Law of Martech scan.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/extending-martechs-law-why-growth-leads-to-decay/)
Gartner has asked the same question for years. What share of your stack's capability are you actually using? The answer went from 58% in 2020 to 42% in 2022 to 33% in 2023.
**The absorption gap, what ships against what gets used.*
A third in use, two thirds sitting idle, and the idle share growing. Gartner's 2025 reading climbed back toward 49% under a slightly different question, so I would treat the decline as directional rather than gospel. Even at the kinder figure, half your stack is dead weight.
## The room is split, and that is the honest place to start
I put [the AI question on LinkedIn](https://www.linkedin.com/feed/update/urn:li:activity:7477658658173067265/?ref=martechtherapy.com) and watched people who know this field disagree with each other in good faith. That disagreement is the point, so let me hand you the split rather than pretend I have already settled it.
One camp says AI feeds the inflation. Marc Sirkin called it plainly, "extreme inflation," because it becomes so easy to drill into edge cases for one-off requests. David Chan expects vendors, in the short term, to "play the volume game of checking off boxes" and overwhelm buyers "under the guise of value."
Another camp says AI absorbs it. David Raab put the sharpest version of that on the table, and it does something uncomfortable to my own chart, which I will be honest about further down.
And then Daniel Towers, refusing the fork altogether:
> Both will be true. Will it matter?
I do not have a clean answer for Daniel. I am not sure anyone does yet, and that is genuinely where this sits.
## The fork
Two forces, and they do not act on the same place.
**AI raises the ceiling.** Features are cheaper to build than they have ever been, so vendors ship more of them, and most of the ones wearing the word agentic are marketing. Gartner reckons that of the thousands of vendors claiming agentic capability, roughly 130 are the real thing. More noise in the firehose.
**AI can also lift the floor.** Agents can operate features no person ever opened. If an agent sets the send time, you no longer need someone who learned the send-time feature. This is the part that bends Martec's slow curve, because value gets pulled out of the tool without anyone in the organisation having to learn it first. That is AI [replacing a process rather than a person](https://www.martechtherapy.com/when-ai-replaces-processes-not-people/), and it changes who you need on the team. David Chan's long game lives here too, the focus moving to how easy it feels for the operations team to deploy rather than *how many boxes a vendor checked*.
**AI can raise the ceiling or lift the floor. The gap widens or narrows.*
[Agentic AI in Martech: The HandoffPart 6: Practical experiments for teams ready to delegateMartech TherapyMatthew Niederberger](https://www.martechtherapy.com/agentic-ai-in-martech-the-handoff/)
**Is your team ready to delegate?*
The gap is whatever is left between the ceiling and the floor. It can widen. It can narrow. I drew both and did not pick a winner, because **the winner is not decided yet**.
## The catch, and a deeper version of it
This is where it gets less comfortable, in two steps.
Even if AI lifts the floor, a rising utilization number is not the same as value captured. Part of that climb is capability nobody is governing yet. Daniel Towers again, on agentic making a call "with 8% of the data expected," and his reasonable demand that it "should declare that and be clear about what is happening."
**The same fork in the number people quote, with a governed line underneath.*
I spent enough years in two navies to know what happens when the person on the team was never trained for the task they are assigned. The board looks fine right up until it does not.
That is the first step, the gap moving from unused capability to ungoverned capability. The second step is David Raab's, and it is the one that breaks my chart, or at least the unit my chart counts in.
Raab's argument is that features themselves become less important, because agents let people get the outcome whether or not the feature exists.
> Users will still just tell the agent interface what they want, and won't know or care if the agent then does it using a specific feature or a multi-feature workaround.
If he is right, then counting features is measuring the wrong thing, and my whole ceiling-and-floor picture is drawn in a unit on its way out.
I am not going to wave that away because it is inconvenient. I think it is a feasible future state, and it is the same arc I have been drawing, one step further along. The gap moves from unused, to ungoverned, to unmeasured, because the thing we counted stops being the thing that matters.
For where we are right now, features are still what vendors ship and price on, so the chart holds. Raab is describing the direction of travel, and I would not bet against him.
## It is a capability problem
Notice what actually decides which branch you land on. It is not the AI. **It is whether your organisation can deploy and supervise the thing**.
That is why the floor has stayed flat. People do not scale with release notes, and the skill to evaluate, adopt, and govern what your stack ships is the same scarce resource whether the features come from humans or agents.
Kevin Rungratsamiphat put a cleaner structure on this than I had. He described a reinforcing loop, growth pressure pushing more agentic builds, running against a balancing loop underneath it: shrinking headcount, a widening distance between the deep users who adopt and the surface users who do not, and the ramp time for newer staff to even get there.
> That balancing loop is what actually caps the curve, not the tech ceiling.
Keanu Taylor gave the practical version, that companies have to design gates for assessing new features, to sift the irrelevant ones fast and then judge which few could drive value. That is a capability, not a tool you can buy. A better platform does not help you keep up with the one you already own.
In my own [martech readiness work](https://www.martechtherapy.com/the-martech-readiness-gap/) I split organisational readiness into structure, capability, and process, and this lands squarely on the middle one. AI raises the ceiling on what is possible and raises the bar on the capability you need to supervise it, in the same move.
## So, what now?
Let me be straight about what I do not know. I cannot tell you whether AI closes the gap or widens it on net. Governance tooling might mature fast enough to make agent supervision a solved problem, or it might stay a permanent block for us to deal with, and I do not know which way that goes. And if David Raab is right, the feature may not survive as the unit any of us measure. I would be suspicious of anyone who tells you they have this topic settled, especially if it's a vendor.
What I am sure of is smaller and more useful. **The capacity to absorb is the lever, whichever way this breaks.**
If AI ends up **absorbing feature inflation**, the organisations that can deploy and govern agents will take the benefit while everyone else watches a healthy-looking dashboard hide a widening problem.
If AI ends up **feeding the inflation**, that same capacity is what keeps you from going under.
Both branches reward the same work, treating keeping up as a budgeted activity with an owner, instead of something that is supposed to happen for free in the cracks of everyone's week.
The people who replied to my question are working this out in real time, and so am I. That is the actual state of the field right now, and it is a reasonable place to stand, as long as you keep testing what holds and dropping what doesn't.
****Your stack isn’t failing.**
It’s absorbing more effort than it used to.
The Second Law of Martech scan helps you see where organisational energy is being spent just to keep things working, and where that cost is starting to crowd out real value.
[Start your FREE Entropy Scan ](https://secondlaw.martechtherapy.com/?ref=martechtherapy.com)
### What an Agentic CDP actually is, and why marketers should care
URL: https://www.martechtherapy.com/what-an-agentic-cdp-actually-is-and-why-marketers-should-care/
Last updated: 2026-07-06T08:05:03.000Z
A category that shipped last quarter is already being talked about as though it has always been here, with the vocabulary written in advance by the companies selling it. Who would blame them? I, too, made that point in passing when I looked at [how three engagement vendors handed their data layer to Databricks](https://www.martechtherapy.com/did-ceps-just-hand-the-data-layer-to-databricks/), and it is the reason for this series.
I am going to spend five parts taking the agentic CDP apart slowly, because right now there is almost nowhere neutral for a marketer to work out what the term means or what it asks of them.
Here is the bet this series will make 👇🏻
Everyone from Gartner to the vendor keynote will tell you what an agentic CDP does. Far fewer will tell you what it does to your job, and that second half is what decides whether any of the technology pays off. So the series weights toward the half that decides whether it works: the marketer, the skills, and whether your organization is ready to hand real decisions to software.
## The label is older than the launch, really.
The collision that put "agentic CDP" on everyone's slides happened in June 2026, when Hightouch reframed its whole pitch around [the agentic CDP](https://hightouch.com/blog/the-agentic-cdp?ref=martechtherapy.com) a day before Databricks announced CustomerLake at its Data + AI Summit. I wrote about the Databricks side of that [when CustomerLake launched](https://www.martechtherapy.com/databricks-customerlake-the-warehouse-cdp/), so I will not repeat it here.
[Databricks CustomerLake: the data lakehouse is now the CDPDatabricks launched CustomerLake, a lakehouse-native agentic CDP. What it means for composable vendors, Databricks customers, and the next data platform.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/databricks-customerlake-the-warehouse-cdp/)
Read my thoughts on the Databricks' CustomerLake announcement here ☝️
What the launch coverage skips is that the term is older than the giants who made it famous. [GrowthLoop](https://www.growthloop.com/?ref=martechtherapy.com) called itself the agentic, composable CDP back in April 2025\. Simon Data relaunched as [Simon AI](https://www.simon.ai/?ref=martechtherapy.com) around an agentic marketing platform that September. Treasure Data went furthest, renaming itself [Treasure AI](https://www.treasure.ai/?ref=martechtherapy.com) in April 2026, billing itself an agentic experience platform, and renaming its CDP World conference to Agentic World.
If you know the above reference, I salute you 🫡
The analysts ratified it in parallel, Forrester naming the paradigm and Gartner's 2026 Magic Quadrant describing a market splitting into [platformization and agentification](https://www.martechtherapy.com/the-cdp-split-is-official-magic-quadrant-2026-review/). By the time [Hightouch](https://hightouch.com/blog/the-agentic-cdp?ref=martechtherapy.com) and Databricks arrived at the scene, the early movers had coined the term, the analysts had blessed it, and the giants made it impossible to ignore. So, prepare yourself for those vendor demo's 😉
## Surprise, the definition was written by a vendor
Search "what is an agentic CDP" and the top result is [CDP.com](https://cdp.com/glossary/agentic-cdp/?ref=martechtherapy.com), which presents itself as "your independent resource for understanding Customer Data Platforms".
Read to the footer and you find it is managed by Treasure ~~Data~~ AI, and the definition itself is written by [Kazuki Ohta, Treasure AI's co-founder and CEO](https://www.martechtherapy.com/treasure-data-didnt-start-as-a-cdpwe-047/).
It is a genuinely thorough page, and I enjoyed reading Kaz's thoughts. But, to be fair, it is also a sales document.
It sorts the market into three stages, packaged then composable then agentic, and runs a five-point "litmus test" for a real agentic CDP whose criteria, native messaging, a closed loop inside one platform, a sub-second profile store, line up exactly with... wait for it... how Treasure AI is built. Then it scores the field:
> Treasure AI five out of five, Databricks two to three, Hightouch one.
A test written by a vendor, which the vendor passes perfectly, and its largest rivals fail. I will let you decide the level of objectiveness you are witnessing.
[Treasure AI's Agentic CDP litmus test](https://cdp.com/glossary/agentic-cdp/?ref=martechtherapy.com)
Now, let's pause for a second. The scorecard admits something its author did not intend. By the strictest definition going, the one written to flatter Treasure AI, the most-hyped products on the market score one and two out of five. **The agentic CDP is real as a direction**. It is mostly not a shipping product yet, and that is worth knowing before anyone signs for one.
[Real Story Group](https://www.realstorygroup.com/?ref=martechtherapy.com)'s Tony Byrne goes a step further and [argues that the agentic, decisioning part is separating into its own layer above the CDP rather than living inside it](https://www.linkedin.com/pulse/what-cdp-2026-tony-byrne-llmfe/?ref=martechtherapy.com), a question part 3 picks up.
To be fair where fairness is due, parts of it are really sharp. Its read on Hightouch, that the label changed and the architecture did not, is the same conclusion I would draw. But that is the point of the whole series in one example. The reference everyone will send your CEO is a marketing asset wearing a lab coat, and there is almost no neutral education sitting next to it. That gap, between what the technology can do and what a buyer can actually understand and absorb, is [Martech's Law](https://www.martechtherapy.com/extending-martechs-law-why-growth-leads-to-decay/), and AI is widening it faster than anything I have watched.
When the people defining a category also sell it, a definition you own yourself is worth more than usual.
[Treasure Data didn’t start as a CDP—we evolved into one. And that makes a huge difference.Had an incredibly insightful conversation with Kazuki Ohta, the co-founder and CEO of Treasure Data, about the evolving CDP landscape, the ambitious Trade-up Program, and even some surprising macroeconomic insights into Japan’s workforce and AI. Kazuki’sMartech TherapyMatthew Niederberger](https://www.martechtherapy.com/treasure-data-didnt-start-as-a-cdpwe-047/)
Watch my interview with Treasure AI CEO Kazuki Ohta ☝️
## What it actually is, in plain terms
David Raab, [who named the CDP in 2013](https://customerexperiencematrix.blogspot.com/2013/04/ive-discovered-new-class-of-system.html?ref=martechtherapy.com), has been making one point for a while:
> The most important reader of a unified customer profile is no longer a human analyst, **it is an agent**.
The vendor definitions build on that and quickly turn into architecture diagrams. The version I would hand a marketer is plainer 👇🏻
> An agentic CDP is a customer data platform you mostly stop operating by hand. AI agents read your unified customer data, decide who to target and what to send, run the campaigns across your channels toward goals you set, and report back. You stop building campaigns and start directing them: setting the goals, setting the limits the agents work within, and checking what they produce. You are still accountable for the outcome, even though you are no longer the one clicking.
## Agentic, or just renamed?
Every CDP on the market will have "agentic" on the homepage by autumn, and most will be packaged platforms with an assistant bolted to the side. The CDP.com litmus test sorts them by one vendor's architecture.
Here is a version that sorts them by whether they fit your job.
Start with who the platform is built to be operated by. If the honest answer is still a person clicking through a builder, with a chat box added for show, you are looking at a packaged CDP with imposter syndrome.
Then look at what the agent is allowed to decide on its own versus what it has to bring back for sign-off, because a system that can only ever suggest is an autocomplete, not an agent.
The third question is reach: can it act across the channels you actually use, or only inside its own walls?
And the last one gives the game away, where the goals and the measurement live, because an agent with no goal to chase and no clean signal to read is an expensive way to generate first drafts.
Part 4 is built around that one, the importance of measurement, because it is the question the whole category is leaning on and the one most organizations answer worst. I am feeling excited about this one since it will take me back to my digital analytics roots.
Run those four at your next demo and the renamed CDPs sort themselves out fast.
## Why this is a readiness question
Notice that none of those four questions is really about the vendor. Each lands back on you.
Whether the agent can read your data depends on what state your data is in.
Whether you can brief and judge it depends on whether your people know how.
Whether it can act safely depends on whether your campaigns have goals and guardrails worth acting inside.
Structure, capability, process, [the readiness series](https://www.martechtherapy.com/the-readiness-thread-inside-the-state-of-martech-2026/) treats these as the main event rather than a footnote, the marketer who can actually direct this kind of system rather than be sidelined by it.
That is the case for embracing this rather than bracing against it. The agentic CDP is not a thing being done to marketers. It is a set of tools that reward the teams who got ready and expose the ones who did not, and getting ready is mostly work you can start now, before the contract, before the migration, before a keynote convinces your CEO that the tool will fix a decade of neglected data on its own. **The category is early, and that is the opportunity**. Getting ready now is a head start on a market that is mostly still a lot of banter.
So here is where this goes. Five parts, weekly, each ending with something you can use. This one defines the term "agentic CDP". Then the job it hands you, what to demand when you buy one, how to keep your brand while agents run your channels, why measurement becomes the difference between steering and drifting, and a readiness check you can run on your own organization. The thread through all of it is that an agentic CDP changes your responsibilities at least as much as it changes your stack, and the marketers who see that early are the ones who get the most out of it.
Next week, Part 2, **the job that lands on you** when the agent does the building, and why "director" is a promotion most marketers are not yet set up to accept.
## Sign up for Martech Therapy
Therapeutical thoughts, creative ideas, and curious journeys in Martech and AI by Matthew Niederberger.
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
Do you have any questions after reading this article?
Or need support with your Martech projects?
[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
### European Martech events compared: which one is actually for you?
URL: https://www.martechtherapy.com/european-martech-events-compared-which-one-is-actually-for-you/
Last updated: 2026-06-29T05:58:27.000Z
In the last fifteen months, I have been to four European martech events: [MeasureCamp Amsterdam](https://www.martechtherapy.com/measurecamp-amsterdam-the-unconference/), The MarTech Summit Amsterdam, [Martech World Forum](https://www.martechtherapy.com/martech-world-forum-london-2025-review/) in London, and [AntiCon](https://www.martechtherapy.com/plotting-course-to-anticon-2026/) in London.
Four in fifteen months felt respectable until I held it up against people who do this for real. It does not come within sight of the tally Steen Rasmussen racks up, or the North American tour Juan Mendoza just put himself through, and I know both of them well enough to say that to their faces.
Juan looks like he finished a Martech marathon (Source: [LinkedIn](https://www.linkedin.com/posts/juan-mendoza-2b3a63a4%5Fits-the-end-of-my-us-event-season-so-activity-7473744044997697536-kiqQ?utm%5Fsource=social%5Fshare%5Fsend&utm%5Fmedium=member%5Fdesktop%5Fweb&rcm=ACoAAACEYHcBK5DlgsJ%5FgicIWSce8EBSwO4medQ))
People tend to lump these events together as "martech conferences," ask which one is best, and expect a single winner. That question has the wrong shape. These events are built for different people, and the useful answer depends entirely on who is asking.
So this is **not a ranking**. It is a comparison, written for a brand-side marketer with one trip in the budget who wants to spend it on the right room. I will tell you what each event is, how it actually felt, where it falls short, and who I would send to it.
---
Two things about my vantage point first, because they shape everything below. I attended each of these once, so this is a snapshot and not a longitudinal study. And I was not a neutral observer at Martech World Forum: I hosted an on-stage interview there, so read my notes on that one knowing I had a foot backstage.
One naming caveat that trips everyone up. Martech World Forum, run by The Martech Weekly, and The MarTech Summit, run by BEETc, are two separate organisations whose names are almost identical. Different events, different teams. I attended both, and yes, it confused me too.
---
## How I judged them
I scored each event on six things, all **through the eyes of that one-trip brand-side marketer** rather than my own consultant priorities. The one that carries the most weight is content depth, and how much of it you can actually take home and use, because a budgeted trip should buy you something you can act on the next day at work.
The rest are the quality of the people in the room and how easy it is to actually talk to them, how much commercial pressure the vendors put on the day, whether it is worth the money, how senior and how brand-side the crowd is, and the plain energy of the place.
But let's pause for a second. Tell me what you think about this 👇🏻
That bit about talking to people needs a caveat, because easy is not the same thing for everyone. [*I am an introvert*](https://www.martechtherapy.com/this-is-me-who-are-you/). An extravert will happily work a big open hall, whereas I tend to do better in a smaller, more intimate setting that almost pushes you into a conversation before you can talk yourself out of it.
Sounds backwards, I know, but it is just how I am wired, and it shapes which of these rooms I got the most out of.
Which makes me wish someone would try a **friendship bench** at one of these. It started as a community-led mental health idea, a bench you sit on as a signal that you are open to talking, and someone comes and joins you.
Which organizer will let me place these at their events?
At a martech event it could do the same for anyone who finds the networking part daunting, a low-stakes way to start a conversation and maybe forge a new peer friendship without having to barge into a circle of strangers.
I would use it. Would you?
If you are an event organizer interested in this different type of sponsorship? [Contact me today](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com).
Back to the comparison. 👇🏻
Here is the short version. The detail is underneath.
## MeasureCamp Amsterdam
Attendees are rushing to the board to claim a slot for their self-hosted session.
[MeasureCamp](https://amsterdam.measurecamp.org/?ref=martechtherapy.com) is a **free** unconference, built by practitioners for practitioners, with firm rules keeping vendors from running the show. There is no agenda until the attendees write one on the morning, on a board, in front of everyone. Sessions run from straight presentations to honest interactive discussions, and lately the topics have stretched well past pure measurement. With agentic CDPs and AI decisioning arriving, accurate behavioural data is becoming mission critical, which is why I half-joke it could be renamed MartechCamp. I will write about why the foundations matter more than the hype in my upcoming agentic CDP series, and that argument was alive in the room here.
The detail I keep recommending to other organisers is small and clever: when people pitch a session, they declare its complexity level. So you can choose a room that sits at your level instead of gambling. The conversations also do not stop when the session does, they follow you into the corridor and the coffee queue.
The honest catch is access, not quality. The tickets are completely free, which means they vanish faster than you can refresh the page. The Amsterdam edition runs on a Saturday, which for me usually collides with my daughter's birthday, so getting there is its own small campaign. I have only made the Amsterdam one so far, and I am still trying to crack one of the others.
Best for hands-on analysts and marketers, measurement people and consultants who want depth, want to choose their own level, and have zero appetite for vendor theatre. As I said in my [MeasureCamp write-up](https://www.martechtherapy.com/measurecamp-amsterdam-the-unconference/), if you go to one event in the data world, make it this one. Value for money is not really calculable: free in, full value out.
[Measurecamp Amsterdam: The (un)conference that brought it all backA day of reconnection, community, and data therapy — with socks, sunshine, and spontaneous podcasting.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/measurecamp-amsterdam-the-unconference/)
## The MarTech Summit, Amsterdam
My visit to The Martech Summit Amsterdam 2026
[The Martech Summit](https://themartechsummit.com/?ref=martechtherapy.com) was the most conventional of the four, in a good way. A single day, English throughout, with a sensible balance of vendor presentations and panel discussions. There were around sixteen vendor stands, and at no point did their presence feel heavy. The swag, I will admit, was peak.
The content was on point and deliberately wider than my day-to-day, which pulled in a genuinely mixed crowd, everyone from performance marketers to data engineers. The audience was active, with real questions coming from the floor, and one inventive session put images on screen and made the room vote on whether they were AI-generated. I also walked into people I had not seen in seven years, which is its own kind of value. This is a fine event to sit at the back of and quietly collect ideas.
At roughly €250 for the day, the value is good. My one improvement would be a few off-the-record round tables, where practitioners could open up about what actually broke. Presentations and panels alone limit how deep a speaker can go, and the real value tends to live in the detail, in comparison, in the awkward question you can only ask in a smaller room. The organisers tell me the two-day London flagship adds workshops, which Amsterdam did not have, so if depth matters to you, the London edition may be the better buy. I am going in November to find out.
Best for mid to senior brand-side marketers who want a broad, polished, efficient read across martech in a single day, and who value picking up ideas and reconnecting over going three layers deep.
## Martech World Forum, London
This was the most senior room of the four, and the smallest, deliberately so. Keeping numbers down made it the most intimate of the lot, which is the whole point: it is easy to talk to Head and Chief level people when there are not many of them and nobody is lost in a crowd. Vendor presence was subtle, a few presentations and some hosted round tables, but with a room this senior the value came from listening to the table rather than from anyone selling at it.
It runs over two full days this year, with [early-bird tickets around £200](https://themartechweekly.com/martech-world-forum/london/?ref=martechtherapy.com), which is good value on paper for the seniority of the room. Whether it pays off depends on you, because this is not an event you consume from the back row. You get out of it what you put in, so come with your questions written down and your actual problems listed, because the insight is in the mingling, not the agenda.
The line-ups tend to be strong, the kind where someone like [Real Story Group](https://www.realstorygroup.com/?ref=martechtherapy.com)'s Tony Byrne or my favorite HSBC's James Taylor are on the bill, which raises the level of the conversations around you.
Last year's real-world insights from HSBC's James Taylor were phenomenal.
One fair caveat on the value for this year, and it applies to the whole circuit more than to this event alone. Around a quarter of the speakers had presented the year before, or are names you will recognise from plenty of other martech stages, often there on the back of a vendor sponsorship. Martech moves from week to week, so there is no shortage of new ground to cover, but the same faces working the rounds can make parts of an agenda feel familiar. That is the reality of events, not a knock on this one.
Best for Head and Chief level people who will turn up prepared to participate, and who want senior peer insight more than stage content. If you want to be talked at, this is the wrong room. If you want to compare notes with people carrying the same weight you are, it is hard to beat.
[Martech World Forum, London, looking backAI was everyone’s “mot du jour” but it’s losing ground to calls for stronger foundations and more collaborationMartech TherapyMatthew Niederberger](https://www.martechtherapy.com/martech-world-forum-london-2025-review/)
## AntiCon, London
[AntiCon](https://www.lxahub.com/events/anti-conference?ref=martechtherapy.com), run by LXA, had the best venue by a distance: Magazine, near the O2, with a Canary Wharf view that was doing a lot of work the day I went. LXA opened with a keynote on the thing I care about most, the effect of martech on the people who have to live with it. Tools are wonderful, but if the people cannot keep pace with them, the tools do nothing. That fits LXA's training and upskilling focus, and it was the right note to open on.
Then the depth ran out. The content stayed high level, which suited the retreat feel of the place, all food trucks, music and good energy, but left me wanting. A large share of the talks were vendor-led, sometimes through a client telling the story, but with the sponsor clearly in mind. I do not blame them for that, they have a company to talk about, but for me it landed as too basic.
LXA's CEO Carlos Doughty during his opening keynote.
The clearest example was that opening keynote: it named the people-versus-tools problem precisely, and I was nodding along, and then it stopped at naming it. The how never arrived. I wanted the next layer, what you actually do to help a team keep up, and it was not on offer. To be fair, it is LXA’s core product.
The room was mostly junior to mid-level marketers, the orientation-stage crowd rather than the senior brand-side rooms the Summit and the Forum pulled. Networking was easy enough but stayed at the surface, in keeping with the content. The vibe was genuinely positive, tickets are often free, and that location is phenomenal.
Best for marketers earlier in the journey who want orientation, energy and a low-risk day out, and who are there for the experience and the introductions more than for depth. If you already know the basics, you may find yourself, like me, looking out at Canary Wharf and wishing the session had gone further.
[Plotting my course to AntiConAt AntiCon 2026 in London, three questions I want answered: trust-ladder criteria, real organizational redesign vs. relabelled roles, and the possible next-era framing.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/plotting-course-to-anticon-2026/)
## So which one is for you?
None of these is bad, and none of them is best. They are aimed at different people, and the trick is matching the event to where you actually are.
If you are hands-on and want depth without vendor noise, MeasureCamp, assuming you can get a ticket. If you are a brand-side marketer who wants a broad, efficient survey of the field and a good day of ideas, the MarTech Summit. If you are senior enough to hold your own in a small room and willing to do the work, Martech World Forum. And if you are early in the journey and want orientation wrapped in good energy, AntiCon, with eyes open about the depth.
I am going back to MeasureCamp when the calendar lets me, and to the MarTech Summit in London this November to see whether the flagship delivers the depth Amsterdam stopped short of. Before either of those, at the end of September, I am in Copenhagen for [Brand Leadership's Web Analytics Wednesday](https://brandleadership.community/web-analytics-wednesday-copenhagen/?ref=martechtherapy.com), where I have been invited to give a talk and host a [workshop](https://workshop.martechtherapy.com/?ref=martechtherapy.com), about the encroachment of martech into digital analytics, so that one I will be experiencing from the front of the room.
I will report back on the London Summit and on MeasureCamp with the same six measures, so you can see whether my read holds up a second time.
Do you have any questions after reading this article?
Or need support with your Martech projects?
[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
### Did CEPs just hand the data layer to Databricks?
URL: https://www.martechtherapy.com/did-ceps-just-hand-the-data-layer-to-databricks/
Last updated: 2026-06-24T05:52:58.000Z
In 2019, I had a client running both Segment and Iterable, and the recurring question was where to build the audiences. Segment could build them. It could not act on them. Only Iterable could turn an audience into a journey, so that is where the audiences got built. Segmentation followed the system that could do something with it. Segment lost that job, and before long it was replaced by [Hightouch](https://www.martechtherapy.com/the-cdp-you-werent-supposed-to-buy/). Sound familiar?
I think about that sequence whenever the industry decides it has finally settled where customer data belongs, because the answer never stays put.
The latest move arrived in triplicate while we were distracted by what industry veteran Martin Kihn called the "CDP-related hoohaw"... CustomerLake.
[](https://www.linkedin.com/feed/update/urn:li:activity:7473359501266481152?ref=martechtherapy.com)
The understatement of all understatements 😅
Three posts showed up in my feed, probably published within hours if not minutes of each other, from [Braze](https://www.braze.com/resources/articles/braze-databricks-middleware-tax?ref=martechtherapy.com), [Bloomreach](https://www.bloomreach.com/en/blog/databricks-customerlake?ref=martechtherapy.com), and [Iterable](https://app.dealroom.co/news/feed/iterable-becomes-databricks-validated-partner-and-joins-customerlake-as-launch-partner?ref=martechtherapy.com), and they were all saying the same thing in nearly the same words. Each announced a tie-up with [Databricks CustomerLake](https://www.databricks.com/blog/introducing-customerlake-agentic-cdp?ref=martechtherapy.com), the "agentic CDP" that now lives inside Databricks. Each echoed some version of the same claim:
> the data belongs in the warehouse, and the engagement belongs with them.
Read one of these, and you have the gist of all three.
When three competitors converge on identical messaging in the same week, that is a coordinated launch. Databricks lined up its engagement partners so that CustomerLake would read on day one as an established category. Getting the engagement vendors to validate the CDP is how a new platform layer gets its legitimacy.
## What the three actually handed over
Look past the wording, and each one makes the same trade. All three concede the data layer and keep the engagement layer. Braze frames it as eliminating the "middleware tax", with Delta Sharing for write-back, Databricks Model Serving inside its Agent Console, and CustomerLake pushing governed audiences in for segmentation. Bloomreach positions itself as an activation partner and is blunt about where the line falls:
> Databricks owns the data, intelligence, and decisioning, and Loomi owns activation.
Iterable comes in as a Validated Partner and launch partner through its Data Sync and Smart Ingest, citing more than 130 joint customers as proof the integration already runs at scale.
Bloomreach states plainly what the other two only imply. In its own framing, Databricks owns the customer intelligence and decisioning layer, and Loomi owns the activation layer. That is a remarkable sentence for a company that spent years selling itself as the place your customer data lives.
## Why none of this should surprise anyone
For the large enterprise, the data already lives in the warehouse. Once that is true, asking a customer to copy it into a separate CDP just to run segmentation is a cost they can no longer defend. The gravity was always going to pull this way. I worked through the early version of this in my [reaction to the CustomerLake announcement](https://www.martechtherapy.com/databricks-customerlake-the-warehouse-cdp/), and it runs straight through the [Multi-CDP Reality](https://www.martechtherapy.com/tag/multi-cdp/) series and the [composable-versus-packaged](https://www.martechtherapy.com/the-cdp-split-is-official-magic-quadrant-2026-review/) thread before that. Same data-gravity argument, now arriving at the engagement vendors' door instead of the CDP vendors'.
So the three are conceding the layer they were going to lose anyway, and committing to the one they think they can hold. As strategy goes, that is sound. The part worth examining is the story being told around it.
Battle of the Marketing Orchestration Layer generated by NotebookLM
## Decisioning and execution are different jobs
The announcements blur two things that need to stay separate.
1. **Decisioning** is choosing who to target, what to send them, and when.
2. **Execution** is the orchestration that follows: sequencing across channels, holding journey state, enforcing consent and frequency, getting the message delivered.
The three CEPs are handing decisioning to the warehouse and keeping execution.
Once you draw that line, the real contest comes into focus, and it is not Bloomreach against Braze. That comparison is the sideshow the press releases want you to watch, a distraction if you will. The actual fight is the CEPs against the warehouses, both reaching toward the orchestration layer in the middle from opposite ends. The warehouse is pushing up from decisioning. The CEPs are holding execution and hoping it is enough once the warehouse decides everything upstream. Whoever ends up owning that middle owns the category. Most of the coverage I have read treats the whole thing as a data-integration story, which misses where the value is going to be contested.
Source: [Florian Delval's Foreign Key](https://foreignkey.substack.com/p/databricks-built-a-cdp-time-to-rebundle)
Florian Delval drew this more clearly than I can ever describe it. In his [Foreign Key piece on the launch](https://foreignkey.substack.com/p/databricks-built-a-cdp-time-to-rebundle?ref=martechtherapy.com), Florian maps the martech stack as a battlefield:
> CDPs that lost the data-storage fight and pushed right into orchestration, CEPs marching left into CDP territory, and a warehouse that never had to move because the workloads kept arriving on their own.
CustomerLake, from this perspective, is the warehouse finally drawing its own arrow into the middle. The distinction I would add is the one above: the warehouse is reaching for decisioning, and execution is the part it cannot easily take.
## The tax moves to the meter
Braze is right that standalone CDPs and reverse ETL tools take a real hit here, maybe even a fatal one. Those categories were built to move data between systems that now sit in the same place, so their reason for existing thins out. Where Braze's framing gets generous is the implication that the cost itself goes away.
It does not. It changes shape and moves to the meter. Every audience built, every model served, every write-back stream becomes billable Databricks consumption. The middleware tax was roughly fixed, tied to licences and seats. The compute tax scales with how ambitious the marketing gets. The more sophisticated your segmentation, the more your decisioning runs, the higher the bill climbs. To be clear "eliminating the tax" and "renaming the tax as usage" are two different claims, and only one of them is true.
[Diverted by design? What the CDP split means for the mid-marketThe CDP market didn’t just split into platforms and agents. It quietly diverted the mid-market along the way. This piece looks at what changed, why many teams now hesitate, and how CEPs became the safer path for getting things done.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/diverted-by-design-what-the-cdp-split-means-for-the-mid-market/)
## When, or whether at all
The inevitability story skips the most useful question, which is when, and for whom. The honest answer splits by layer and by segment rather than landing on one verdict.
Warehouse-native activation for a mature enterprise is a question of when, and the answer is soon. No argument there. If the data already lives in Databricks and the engagement vendor can read from it without a copy, that path wins on cost alone.
[Warehouse-native decisioning](https://www.martechtherapy.com/if-the-warehouse-can-think-whats/) replacing the specialists is a different matter, and it is slower than the launches imply. There is a structural reason, not only a maturity one. The decisions that move the most money happen in-session, in milliseconds, while a customer is on the page or in the app. The warehouse is the system of record. It is not the live tier, even with Lakebase/RT. It does not hold the in-session signal, and it cannot answer in the window a channel actually needs. This is why Bloomreach keeps pointing at its in-memory profiles updated in milliseconds, and why Braze keeps repeating the word real-time. The slow, governed decisions can migrate to the warehouse. The fast ones are a much harder problem, and the announcements wave past it.
None of this means the execution layer is safe by default. MessageGears has run customer journeys inside the warehouse for years, and it used the CustomerLake moment to relaunch its journey builder as [warehouse-native orchestration](https://messagegears.com/resources/news/ai-ready-journey/?ref=martechtherapy.com), the clearest attempt yet to pull execution into the warehouse rather than leave it to the engagement vendors. What is telling is where MessageGears draws its own line. It keeps warehouse-native journeys for the data-rich work, and routes anything that needs sub-second latency to a separate cloud tier. The vendor most committed to running execution in the warehouse still keeps a path outside it for the fast lane, which is the latency ceiling conceded by the side that would most like it gone.
Then there is everyone else, which is most of the market. Not every company runs on Databricks, and most do not have a warehouse they would trust as a single source of truth. The whole pitch assumes a level of data maturity that is genuinely rare.
This is where my [Martech Readiness](https://www.martechtherapy.com/the-readiness-thread-inside-the-state-of-martech-2026/) argument creeps into the discussion. The warehouse-native future presumes structure, capability, and process maturity that most organizations simply have not built yet. For the mid-market and below, the packaged engagement platform with its own data layer stays the practical choice for years. Architectural purity has nothing to do with it. The packaged platform works without a warehouse you have to trust first, and for most companies that trust has not been earned yet.
## Why warehouse competition helps the engagement vendors
Snowflake and Google are not going to let Databricks own the agentic-CDP story unanswered, so they will ship their own versions. The counter-intuitive part is that the more warehouses compete, the more valuable a layer spanning all of them becomes. If one warehouse dominated, the CEPs would be in trouble, reduced to a feature inside someone else's platform. With several competing, somebody has to sit across them and give the marketer one place to orchestrate regardless of which warehouse holds the data. That cross-warehouse approach is the engagement vendors' route back to relevance, and it only vanishes in a single-warehouse world we are not heading into.
## The competitive view cuts two ways
Against the next wave of engagement platforms that will announce the identical partnership a quarter or two from now, like Adobe and Klaviyo among them, the lead the first movers have is real but shallow. They get the badge, the co-marketing, the early reference logos like Iterable's 130 joint accounts. None of that is hard to copy. Call it two quarters before the move becomes expected rather than notable.
Against the vendors that were composable from day one, Hightouch, DinMo and Census (now Fivetran) and that crowd, the CEPs look architecturally weaker than they are. The composable natives were built assuming the warehouse is the source of truth. They carry no legacy data platform to protect. The three CEPs are retrofitting that worldview while still selling a data platform they now have to partly walk back.
The CEPs hold one real advantage, and none of them are marketing it. The composable natives came up from data movement, which leaves them thin on operational engagement depth. Deliverability at high volume, consent enforcement, frequency capping, channel breadth, the unglamorous reliability work that decides whether a hundred million messages a day actually land. That depth is exactly what the CEPs are falling back into, and it takes years to build. So the engagement vendors do hold a real lead over the day-one composable crowd, on the operational axis none of them are putting in the headline. Every one of these three posts leads with the warehouse integration, which is the part about to commoditize, and buries the operational strength, which is the part that defends them.
## Where this leaves us
The collision point is that activation layer in the middle, with the composable natives climbing toward it from data movement and the CEPs falling back into it from engagement. Whoever owns that middle in three years takes the category. I think operational depth is harder to replicate than architectural purity, which would favour the engagement vendors. I also think that advantage only holds if they stop conceding the decisioning fast enough to keep a reason to sit above the warehouse at all. Give away the deciding and keep only the sending, and you have argued yourself into being a feature.
So the open question I keep turning over is whether any of the three has the nerve to stop handing the decisioning away, or whether a quarterly Databricks launch badge is simply too tempting to refuse. I am not sure. If you work for one of these platforms, or buying from them, I would like to know which way you see it going.
Step back from the three of them and the real problem is the speed. Martech's Law, the gap between what the technology can do and what an organization can actually adopt, is running wider than I have seen it. A category that shipped this month gets discussed as though it has always been there, with the vocabulary arriving pre-written by the people selling it. Most buyers I talk to cannot tell which part is real and which part is narrative. For the vendors, that is close to shooting fish in a barrel. They control the story and the language, and there is almost no neutral education for a buyer to weigh against it.
That gap is what I am going to spend the next stretch on. I am working on a six-part series on the agentic CDP, taking the term apart slowly to see where it holds up and where it is doing more selling than describing. If this piece left you with more questions than answers, that is the honest state of things, and the series is where I start working through them. Subscribe if this got you thinking 👇🏻
## Sign up for Martech Therapy
Therapeutical thoughts, creative ideas, and curious journeys in Martech and AI by Matthew Niederberger.
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
Do you have any questions after reading this article?
Or need support with your Martech projects?
[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
### Composable CDP, translated for marketers
URL: https://www.martechtherapy.com/composable-cdp-translated-for-marketers/
Last updated: 2026-06-22T09:33:54.000Z
Let's face it, most composable CDP conversations are written for engineers, which makes sense, because engineers are the ones building the thing. The cost of that arrives later, and it arrives for the marketers who run the campaigns on top of the architecture, handed a finished system and told to make it work. I've written before about [the inherited costs that creates](https://www.martechtherapy.com/the-inherited-costs-of-the-composable-stack/). This piece is about the part that comes earlier, when the architecture is still a decision and not yet a fact.
The question a marketer should be able to ask in that room is plain. What are we responsible for now, and what happens to the things we used to count on the platform to do for us? In the sessions where I've watched it go unanswered, the answer wasn't bad. Nobody had asked the marketer into the conversation in the first place.
Composable is a plain idea in technical clothing. It means the CDP is assembled from separate tools you own and connect, a data warehouse plus the parts around it, instead of one packaged platform you buy whole.
Traditionally, the CDP is defined by four functions it bundles into a single product: it collects data, unifies it into one customer profile, segments that profile into audiences, and activates those audiences to your tools.
Composable removes none of that. It splits the four into separate modules, if preferred from separate vendors, and leaves part of the wiring to you. The functions are where the value sits, and the packaging is only a question of who holds each one. So the model is those same four functions, turned into questions about ownership once the architecture turns composable. If SQL and DAG don't ring a bell, don't worry, that's the engineers' end of the table and nothing here leans on it. This part fits in one sitting.
[Data is boring. And by extension, CDPs are kind of boring tooWatch now | A candid conversation with CDP Institute founder David Raab on AI delusions, data denial, and the awkward art of explaining Martech to your in-lawsMartech TherapyMatthew Niederberger](https://www.martechtherapy.com/data-is-boring-and-by-extension-cdps-are-boring-too/)
## Data collection
The first area is collection. In a packaged CDP, you typically don't think much about what's being captured because the platform makes a lot of those decisions for you. The SDK picks up events. Attributes get stored. Defaults run on autopilot. In a composable setup, somebody is making those decisions explicitly. Probably the data team. Maybe with marketing input, maybe without.
The questions worth asking yourself is what events are being captured today, and who decided the schema, meaning the shape of the data being stored. Then a different question altogether: what's missing that you'd actually want for campaigns?
If the answer to the last one is "*we'll add it later*," that's a flag.
Composable architecture is great at giving you flexibility on data that's already flowing. Anything not collected today is a future change request, not a quick segment tweak.
## Identity stitching
The second area is identity resolution. This is the one most marketers genuinely don't understand, and I have found myself in that camp before. The rules that say *email\_1@gmail.com* and a particular cookie ID and a known mobile device ID all belong to the same person used to live inside the platform's identity graph. Black box, basically. With composable, those rules get written somewhere too. Often in the warehouse, sometimes in a specialised identity tool layered on top.
The marketer's question isn't how the rules work. It's where they live and who owns them. When a stitching rule breaks, who notices? When a segment behaves oddly because two profiles got merged that shouldn't have, who debugs it? The same ownership question reaches inside the profile. When two systems disagree about something like a customer's email opt-in status, which value wins, and is that rule written down anywhere? In packaged systems, the vendor sorts it. In composable systems, the work lands with your data team. Internal time, internal expertise. The cost goes somewhere, it doesn't disappear.
[Has the CDP category failed? Amperity’s CTO Derek Slager weighs in.Amperity’s CTO on why CDPs haven’t solved customer 360 and what it really takes to unify customer data.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/has-the-cdp-category-failed-amperity/)
## Segmentation
The third area is segmentation, the part of a CDP marketers actually put their hands on. In a packaged CDP this is the friendly surface: a builder where you assemble an audience by clicking conditions together, no engineer required. It is often the reason marketing wanted the CDP in the first place. In a composable setup that surface is not guaranteed. Segments might be defined in SQL in the warehouse, or in a separate audience tool layered on top, and the self-serve builder you were promised may or may not be part of what got assembled.
So the question is blunt. Can I build a segment myself, or do I file a ticket and wait? If audience creation routes through the data team, your campaign calendar now runs on their backlog. That is not automatically wrong, but it is a different operating model, and you want to know which one you are in before launch.
The second question is about trusting the numbers. When you run a segment count one day and a different count the next for what looks like the same logic, what changed underneath? In a packaged setup that inconsistency is a vendor conversation. In a composable setup it is a conversation with your own data team about how the models are versioned and refreshed. The segment didn't lie. Something under it changed, and in composable that something is yours to track down.
## Activation to destinations
Fourth, activation. This is where the latency conversation actually matters for your day-to-day. Packaged CDPs typically advertise sub-second activation. Composable CDPs of the warehouse-native variety run on whatever the warehouse can produce, plus a reverse ETL layer, which is the piece that pushes audiences out of the warehouse and into your campaign tools. Often that's minutes to hours, not seconds.
For most marketing use cases, this is genuinely fine. A daily email send doesn't need real-time. An audience pushed to Meta for an ad campaign doesn't need real-time. Where it bites is the in-session personalisation use case, or the cart abandonment flow that needs to fire within minutes of the trigger event. Some destinations tolerate latency well. Some don't. Worth knowing which is which before you commit, because the workaround for slow activation usually involves a separate real-time path that lives outside the composable stack you just paid for.
The question to ask is a per-destination one. What latency does my email tool need versus my ad platform versus my web personalisation engine, and does this architecture deliver all of that, or only the destinations with longer tolerances?
One-sheeter for marketers created by NotebookLM
## What this changes for the marketer
Once these four areas are visible to you, the role of the marketer in an architecture decision becomes legible. You're operating the system, not building it. That's a different job and a valid one, but it comes with skin in the game. The trade-offs being made about latency, who gets to build an audience, and where the identity rules live are trade-offs you live with for the duration of that architecture.
Composable CDP is a good architecture for a marketing organization that wants more control, has the data team to run it, and is willing to absorb the operational responsibility that comes with the increased flexibility. It's a poor fit for a marketing organization that wants the vendor to keep doing the work and just send better campaigns. Both are valid positions. The mistake is making the choice without knowing which one you're making.
If you're sitting in the meeting where this decision is being made and you've not yet asked these four questions, you're being talked past. This is a vocabulary problem. The slides default to engineering language because engineering has been driving the conversation, and the marketing function has been treated as a downstream consumer rather than a participant.
The fix isn't complicated. Be in the room. Ask the four questions. If the answer to any of them is "we haven't figured that out yet," treat that as useful information, not a failure of competence.
## The questions that aren't on the list
The four questions cover what a CDP does. They don't reach the part that changes when the single box comes apart, because the hard part of composable doesn't belong to any one function. It lives in the space between them, in the wiring a packaged CDP keeps out of view. Asking about that space tends to land well with the engineers, because it is the part they worry about most, and it marks you as someone who is paying attention rather than waiting to be handed a finished thing.
Start with the wiring itself. The data travelling from collection to identity to segmentation to activation is now real infrastructure, with schedules and failure modes, and it is the most common place things break. Who owns the connections between the tools, and what happens to my campaign when one of them fails overnight?
Then freshness, which is the one to ask loudest. In a packaged CDP, when the data stops flowing, the vendor usually tells you. In composable, a sync can fail silently and your morning audience is yesterday's data, or empty, with nothing to flag it. How would I know the data behind this segment is stale before I hit send?
Last, cost. A packaged CDP is a flat fee, so refreshing an audience is free at the point of use. Composable runs on warehouse compute and syncs that often bill by the row, so an audience rebuilt every hour has a meter running each time. Does this audience cost us money every time it refreshes, and who is watching that number?
One more question hovers just off the edge of marketing. When a customer opts out, that choice now has to reach every tool the data was copied into, not a single system. Worth raising in the room, even if it lands on someone else's desk to solve.
Ask these alongside the four, and you walk into the decision as someone who helped choose the system, not someone who got handed it.
If you want a starting point for the conversation in your own organization, the [Martech Workshop](https://workshop.martechtherapy.com/?ref=martechtherapy.com) is where I've put the framing that's worked in client rooms like ITV, Carfax, Faceland Clinics and more.
Use it before the architecture decision, not after.
Do you have any questions after reading this article?
Or need support with your Martech projects?
[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
### Databricks CustomerLake: the data lakehouse is now the CDP
URL: https://www.martechtherapy.com/databricks-customerlake-the-warehouse-cdp/
Last updated: 2026-07-06T10:55:27.000Z
Databricks announced CustomerLake at its [Data + AI Summit](https://www.databricks.com/dataaisummit?ref=martechtherapy.com) just now, and the rumor is confirmed: it is a customer data platform. A real one. In 2026 no less. Marketer-facing, built natively inside the lakehouse, with agents doing the work that used to need a data team and a few weeks of lead time. The first agentic CDP a lakehouse has built for itself.
Only 16 people guessed right on [my LinkedIn poll](https://www.linkedin.com/posts/matthewniederberger%5Fmartech-cdp-activity-7470116860240265217-naKm?utm%5Fsource=share&utm%5Fmedium=member%5Fdesktop&rcm=ACoAAACEYHcBK5DlgsJ%5FgicIWSce8EBSwO4medQ).
To be fair, I saw it before the keynote. Databricks invited me to a preview and asked what I made of it, which I took as a good sign in both directions, them wanting an independent opinion and me being asked for one. Katy Yuan walked me through the product. For the record, this was preview access under embargo, so weigh that accordingly. I came away more convinced than I expected, and more uneasy about a couple of things than the demo intended.
This is not a write-up of the demo. The screens were nice. What I want to work out is what this does to the category, to the companies that built the category, and to anyone currently holding a CDP decision or a warehouse contract.
Sit tight, because this is my longest article to date.
## What it actually is, once you strip the branding
CustomerLake is a marketing application that lives on the lakehouse instead of beside it. That sentence is the whole thing. Every CDP before it, packaged or composable, was in some sense a copy of your data with a marketing interface on top, or a thin layer renting space next to the warehouse and reaching in. CustomerLake is the marketing interface on the data itself. The profiles, the governance, the semantics inherit straight from Unity Catalog rather than being reconstructed by a third party you then have to trust and police separately. Nothing moves. Nothing gets translated across a vendor boundary. The seat that the composable vendors were renting you, the layer between you and your own data, Databricks just built and kept.
Databricks CustomerLake user interface
A quick word on words, since I am leaning on two of them. Most companies, mid-market especially, still call the place their data lives a warehouse, and the composable pitch spent years training them to. Databricks is a lakehouse, and the difference matters more than it sounds. A warehouse is built for the clean, modeled tables that feed a dashboard or applications. A lakehouse holds those too, alongside the raw events, the behavioral signal, the ML features, the messy unstructured data, all under one governance layer. A CDP that feeds agents needs the second kind of place, because clean tables on their own do not make a decision. So I will say warehouse when I mean the mental model the market still carries, and lakehouse when the architecture is the actual point.
Strip the branding and most of what is on screen is not new. Natural-language querying of customer data already exists. Treasure Data and Amperity have versions of it. Building a campaign by talking to an assistant is not novel either. Zeotap does it, and Hightouch lets you assemble one in conversation with its chatbot. The chat box is not the story, and anyone selling it as the breakthrough is counting on you not having seen the others.
Where Databricks goes a step further is context. You can hand it the documents a marketer actually plans from, a brief, an H2 plan, the positioning doc the PMM passed down, and point it at the systems where those live. That is more useful than feeding a model column metadata, and it is the most marketer-native version of context I have seen so far, the same idea I worked through in the [Contextual CDP series](https://www.martechtherapy.com/tag/contextual-cdp/). Any of the others could build the same upload box in a quarter or less. The same is true of decision simulation, where the system plays a campaign forward across synthetic profiles before it sends and shows why a given person would receive a given message. It is a good use of Databricks' modeling muscle, and still nothing a competitor could not copy.
The one part none of them can answer by shipping a feature is what sits underneath. **CustomerLake runs on the data with no third party in the middle**. Everything on the screen is buildable. That is not.
There is an obvious objection here, and Databricks has an answer for it. Most large companies do not keep everything in one place, so a CDP that only saw Databricks-resident data would be half-blind. Through [Lakehouse Federation](https://docs.databricks.com/aws/en/query-federation/?ref=martechtherapy.com), CustomerLake can query trusted data where it actually lives, in Snowflake, BigQuery, cloud object storage, operational databases, without first copying it into Databricks. That is a real answer, and a better one than the composable vendors gave you, because the governance travels with the query instead of being rebuilt on the far side. Hold that thought. It complicates the neat ending everyone wants to write.
One thing gave me real pause, and I am holding it loosely, because twenty minutes is not an audit. The demo leads with Genie doing the assembly and barely touched the manual path. Katy was clear afterward that everything the agent does has a full GUI underneath it, you can still build an audience by hand the traditional way, it just does not demo as well. Fair enough. The part that gave me said pause was the default. Human-in-the-loop is everywhere, a sign-off at each step, but the path of least resistance is to let the agent propose and then approve its work, and defaults shape behavior more than capabilities do. It is a statement about who is expected to run the work. I wrote a piece a while back, [Letting go of control](https://www.martechtherapy.com/letting-go-of-control/), about how the move to agentic systems is a leadership question well before it is a technical one, the same discomfort a founder feels the first time they hand real decisions to a team. The job goes from micromanager to designer, you set the parameters and let the system work inside them, which only pays off if you trust it. CustomerLake is built on that bet, that marketers will let go sooner than they think. Whether they should is a separate article.
Katy's proof point was the concrete kind. One large hardware maker had been running two separate workspaces just to keep its B2B and B2C data apart. On CustomerLake that becomes one model on one platform, because **the governance boundary is the lakehouse, not the tool**. That is the embedded pitch in a real shape rather than a slogan.
The rest is consumption-priced with no platform fee, and the sends handed off to partners through the standard set of connectors you have come to expect from a marketing platform, the tens, if not hundreds, available for easy integration. Hold onto that pricing choice. It is the part that reorders the market.
One correction, because someone will raise it. The agentic-CDP label predates this launch. GrowthLoop has called itself an agentic, composable CDP for the better part of a year, and it runs natively on Databricks, Snowflake and BigQuery alike. Databricks did not coin the category. What it brings is the ground it stands on. GrowthLoop is agentic and composable built on the data cloud, a tenant on top of it. Databricks is the data cloud. Same words, and one of them owns the building.
## Where I was right, and the move I missed
I should own where I landed on this, because I landed wrong in public. I argued, more than once, that Databricks would not ship a CDP. The reasoning held up until the keynote and I still think it was good reasoning. Databricks had never built or bought a destination application. It buys infrastructure and folds it in. Its pricing rewards compute over seats. It had just deepened its Adobe partnership and put money into Hightouch's last round. Every signal pointed at a company that wanted to be the data underneath everyone's marketing tools, not the tool.
The part I got right I said to Katy on the call. I brought up an [old piece I wrote on data gravity](https://www.martechtherapy.com/if-the-warehouse-can-think-whats/), one I had reread before the demo, where I had landed on a plain conclusion. When the data already lives in one place, you build the thin layer next to it instead of routing through someone else. That is exactly what they did. Build over buy, because the expensive thing, the data, is already home. Governance inherited instead of rebuilt. The mechanism was never in question.
There is a detail in who built it that makes the point sharper. Engineering for CustomerLake is run by Tasso Argyros, who founded and ran ActionIQ. Justin DeBrabant, another ActionIQ alumnus, leads product. Michael Trapani, also out of ActionIQ, runs the go-to-market, and Katy herself spent three years at Census. The people who spent the back half of the last decade building the composable and packaged CDPs are now inside the lakehouse, building the thing that absorbs both. Databricks did not need to buy ActionIQ. It hired the people who knew where the bodies were buried and pointed them at data it already holds.
What I missed was nerve. I assumed they would build the data and decisioning layer and leave the marketer-facing surface to partners, the screens, the campaign workflow, the audience builder. They built the surface too. **A company that had only ever sold infrastructure just moved up the stack and opened a storefront aimed at a buyer it had never sold to.** A lakehouse deciding it wants to be the application.
[If the warehouse can think, what’s left for the CDP?Databricks moves intelligence into the warehouse. What does that mean for identity, decisioning, and the evolving role of the CDP?Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/if-the-warehouse-can-think-whats/)
## Was anyone actually blindsided
It is tempting to frame this as a surprise attack on the composable vendors. It was not. They paved the runway it landed on. Hightouch published a piece called "make Databricks your CDP." GrowthLoop runs natively on Databricks. Simon Data and the rest pushed the same thesis, pull everything into the warehouse and activate from there. They won that argument so completely that the warehouse ended up with a fully paved on-ramp to build its own front door, which is roughly where I left things in [The CDP you weren't supposed to buy](https://www.martechtherapy.com/the-cdp-you-werent-supposed-to-buy/). The writing was on the wall, and the composable players are the ones who wrote it. The irony does not escape me.
Which raises the more interesting version of the question. If this was visible, did they price it in. Some clearly did. GrowthLoop leaned into agentic and causal decisioning, the parts that are harder for a warehouse to copy from a standing start. Others spent the runway selling proximity to data they did not own, which is a fine business right up until the owner decides to occupy the space. Inevitability is not the same as readiness. The gravity was always pointing here. The question each of them has to answer now is whether they saw it early enough to have a second act loaded.
[The CDP you weren’t supposed to buyHightouch said the packaged CDP was dead weight. Four years on, Gartner lists it in the CDP Magic Quadrant. The architecture was right. The pitch skipped a step.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/the-cdp-you-werent-supposed-to-buy/)
## Who feels it, and the math underneath
A warehouse-native CDP does not land evenly. It lands hardest on the middle, the composable and reverse-ETL vendors whose whole pitch was that they sit beside your warehouse and activate from it. For a customer already running everything on Databricks, that pitch lost its reason to exist. The lakehouse does the same job with no data leaving the building and governance it already trusts.
Jake Van Clief made an argument about AI agents that lands cleanly on this. Agents, he says, are infrastructure, not a company, and trying to build the infrastructure is a way to lose to the people who build infrastructure for a living. His examples? When the internet was already built, Google added a layer on top and Amazon skipped the infrastructure entirely to become a different kind of company, before later becoming the builder with AWS. The names that won, Netflix, Spotify, Uber, Airbnb, were the ones using the infrastructure rather than racing it. "You think you can compete with the builders?" he asks. "Go ahead. Go for it." Far more value got created on top of the infrastructure than beside it.
Now read that with the warehouse as the infrastructure and the composable CDP as the layer trying to be a company. A vendor selling a better activation engine or a smarter agent on top of Databricks is building infrastructure next to the company that owns the infrastructure, and that company just shipped its own. The ones that last will do what Netflix did, use the warehouse to deliver something it has no interest in building itself, rather than competing with it on the same ground. Not with Databricks alone. The day the next warehouse builds the same front door, that line, between the layer racing the builder and the company that just uses it, is the only one that matters.
The channel layer is fine, and that is the clever part of the design. Databricks made the engagement platforms partners instead of targets. It built the data, the decisioning and the workflow, then handed the send to them. Twilio tried the opposite years ago, bought Segment and then competed with the engagement vendors on top of it, and the combination never found its feet. Databricks took the lesson. Feed the channel, do not fight it.
Then there is the pricing, which reorders the whole market. Databricks can give the CDP away. The pricing carries no platform fee because the value is captured downstream, in the compute the platform bills every time it builds a profile or resolves an identity. The independent CDP has to charge for the CDP itself, because that is its only line of revenue.
> **You cannot win a price war against a company that does not need your product to make money.**
That asymmetry is the whole story, and it is what a feature-by-feature comparison will miss.
Consumption pricing has a graveyard, and I said as much on the call. mParticle pushed a pay-as-you-go model and it never really took, and the question got quieter once the company was acquired. The difference is that an independent charging by consumption is betting against its own predictability. Databricks already bills this way for everything else. For them it is not a gamble, it is the house model, and the CDP is one more meter on a machine that was already running.
## Every action has a reaction
Databricks put money into Hightouch's last funding round, on the thesis that customers were building composable CDPs on the lakehouse. It deepened its Adobe partnership again this spring, wiring Delta Sharing and a Genie connection into Adobe's marketing agent so Experience Platform could query Databricks data without copying it. Adobe is a customer here as much as a partner, Experience Platform itself runs on Databricks, so that relationship is closer to an alliance than a contest. The composable middle is where the overlap bites, hard. I asked Katy about the fallout. Her answer was that co-opetition is the name of the game, that CustomerLake stays open and composable, that the plan is to fit a customer's stack rather than tell them to rip and replace. I believe she means it. I also think the economics do not care what anyone means as I will elude to in a bit.
Notice what the move was not. Databricks did not acquire anyone. It did not buy Hightouch or a packaged CDP and bolt it on. It built the thing itself, because it already held the one part that is genuinely hard to come by, the data. The interface, the agents, the connectors are comparatively cheap once you are sitting on the warehouse. That is more aggressive than an acquisition and, oddly, more courteous. I have heard from people I trust that Databricks gave several partners a heads-up before the announcement rather than letting them find out from the keynote. That is more grace than this industry usually extends, and it tells you Databricks knows exactly whose business it is walking into.
---
There is a twist worth mentioning, because it complicates my tidy action-and-reaction setup. Hightouch did not wait for the keynote. The day before Databricks announced CustomerLake, [Tejas Manohar put out Hightouch's own agentic-CDP manifesto](https://hightouch.com/blog/the-agentic-cdp?ref=martechtherapy.com), getting ahead of it to claim the category on composable terms (*eventhough Simon and GrowthLoop already did*). The timing reads as pre-emptive, and from a close Databricks partner who almost certainly knew what was coming, deliberate. He does not pick a fight, Hightouch still taps Genie under the hood. He redraws the line.
> "Data warehouses may even claim the title of customer data platform. Fair enough,"
he writes, before planting the flag:
> "Hightouch will remain the place where marketing gets done."
The product under it is a real pivot, a harness of long-running agents that research, verify, prioritize and draft opportunities in the background, and on agentic ambition it reads as further along than what Databricks showed me. But it is a lead, not a moat. A harness is software on top of infrastructure, the thing that gets copied, and Databricks has the models, Genie and now CustomerLake to build the same loop on data it already owns.
Which is why a feature race is the wrong frame.
Parity does not decide a fight when the pricing models differ. If Databricks matches Hightouch feature for feature it can still give the result away, because it bills the compute either way while Hightouch has to charge for the product itself. The durable move is the one Hightouch is reaching for in its positioning rather than its harness: *be the neutral intelligence and agentic marketing layer that floats across Snowflake, Databricks and BigQuery, owning the cross-cloud, where-marketing-gets-done ground the lakehouse has no reason to chase*.
That is the "Netflix" turn, if they take it. If the story becomes "we have the better agents", they are back in the parity trap. The lane that survives is the other one, your intelligence should not be trapped in anyone's warehouse.
I would not call it yet.
---
Newton's third law is the right lens here, because a move this size produces an equal and opposite one. Probably not, in the near term, on the partners who built their whole motion around recommending Databricks next to their own product. They are too entangled to retaliate, and the early word should keep the peace, for now.
The reaction worth watching is one level up, from the other platforms sitting on the same gravity. Snowflake is the obvious one. Google has BigQuery and an ads business that already thinks in audiences. AWS holds the data in Redshift and the identity primitives in Entity Resolution, but it has always preferred to arm the partners rather than become one, which is its own kind of answer. Microsoft barely has to follow at all, because Dynamics 365 Customer Insights is already a type of CDP, and it is already being pulled natively into Fabric.
Even the European players like OVHcloud have a data-sovereignty argument Databricks cannot easily match. The day one of them decides it cannot let the marketer-facing surface belong to a rival, the action Databricks took this week becomes the reaction everyone else is forced into.
## Have we circled back to the monolith
The uncomfortable possibility is that this looks like a return to the thing composable was built to escape. One vendor, one platform, the whole stack under one roof. The packaged-CDP era was a monolith. Salesforce is still the gravitational version of one, the black hole that pulls a marketing organization in and bills it for the privilege of never quite leaving. So is the lakehouse slash warehouse just the next monolith with better architecture.
I do not think it is the same situation. You still own the data, in your tenant, under your governance. It is still composable in the sense that counted, the activation can point outward and the data does not have to move into someone else's system to be useful. What Databricks took back is not your data, it is the layer between you and your data. A monolith you own the foundation of is a different proposition from one you rent end to end, and this is the more democratized version, marketers acting without a four-week queue through the data team. Ownership tends to scatter until no single team owns the middle, the problem I picked at in [Who's actually in charge?](https://www.martechtherapy.com/whos-actually-in-charge/). Collapsing the data and engagement zones onto one platform answers that, or at least papers over it. Whether that distinction holds up against a consumption bill and a roadmap you do not control is the open question, and it is the same one every platform consolidation eventually forces. We may not be back at the monolith, but we are closer to its gravity than the composable pitch wanted us to get.
## The starting gun
The launch matters less as a product than as a signal. Databricks moved first, and first forces the rest of the field to decide whether it follows. The warehouses behind it hold every piece they would need, the storage, the identity resolution, the model infrastructure, the same pull dragging customer data inward. Once one of them proves a marketer will build a campaign inside the data platform, the surface stops being optional for any of the others.
Notice how fast this arrived. Email held marketers for most of a decade. Packaged CDPs ran the 2010s. Composable got maybe five years before agentic showed up behind it, and the gap from composable to agentic is shorter than the gap from packaged to composable. The eras are compressing. If that is real, then "final resting place" is the kind of thing every era says about itself right before the next one arrives. Agentic may be the genuine new floor of the category, or it may be one more layer that the next technology makes quaint faster than the last one did. My honest bet is that the substrate keeps winning and the surface keeps getting rebuilt, which makes the endgame less a destination than a direction of travel. The CDP keeps moving toward the data. CustomerLake is the furthest it has gotten, not necessarily the last stop.
## What a Databricks customer should actually do
The practical question divides cleanly, and it is worth being precise because the wrong move here is expensive in both directions.
If you already run a composable CDP on the lakehouse, you are not in danger, you are in leverage. You have a working stack and a credible second option from your own data vendor, which is close to the best position you can hold going into a renewal. The move is not to tear anything out for a private preview. It is to pilot, to scope honestly what CustomerLake covers against what you are paying your incumbent for, and to let the existence of a free-at-preview alternative do some quiet work on your next contract. Most of the value here is negotiating value, today.
If you are still choosing, the shortlist you drew up a few months ago is missing a column. That does not mean pick Databricks. It means the build-versus-buy math changed under the decision, and an evaluation that ignores the warehouse-native option is now incomplete. The risk is picking a standalone CDP on a multi-year contract just as the platform underneath it starts offering the same function for the cost of the compute.
If you are on Snowflake or BigQuery, this is a weather report rather than a storm. The same gravity that produced CustomerLake is acting on your platform too, and the incentives say your data vendor eventually offers a version of this. Plan as if it will.
That re-scoping, where a CDP decision runs into identity, governance and the rest of the stack around it, is most of what I spend my time on. I built [Martech Stack Builder](https://www.martechstackbuilder.com/?ref=martechtherapy.com) for the part where you have to see the whole stack before you can judge what any one piece should be. The ground moved this week. If you have a decision open, it is worth a fresh look before you sign.
## What the warehouse still cannot buy
So, is this the end of the CDP? For Databricks customers, the standalone CDP just got much harder to justify, and that is a real change in a category that spent a decade insisting it was essential. For everyone else, the independents have a clear job and a visible clock.
The thing a warehouse cannot buy is the thing that was always hardest. Owning the data and the workflow sits a long way from winning the marketer, and channel trust is one asset a data platform does not get for free. Neutrality across clouds used to be the other, and this is where I have to update my own argument. I assumed CustomerLake would only see Databricks-resident data, which would have handed the multi-cloud enterprise straight back to the independents. Lakehouse Federation closes most of that gap, since Databricks can reach into Snowflake and BigQuery and the rest, so the simple version of the neutrality pitch is weaker than I first had it. What federation does not close is the difference between reach and neutrality. Pulling a competitor's data through Lakehouse Federation still runs it across Databricks' control plane, its governance, its bill, and its roadmap. A genuinely neutral vendor has no preferred platform to draw you toward, and that is the one thing a lakehouse reaching across clouds can never quite be. Databricks built a strong answer to a question marketers have not really been asking, whether their data platform should also run their campaigns. Whether they want that is what the next year decides.
I have changed my mind on this once already, in public, so take this with the appropriate salt. My honest position is that two things are true at once. The structural move is real and the economics are brutal for the middle. And adoption will be more cautious and exploratory than the keynote suggests. That gap, between what is now possible and what marketers will actually do, is usually where the interesting part of a category lives.
Two questions I cannot settle from here. Does the warehouse take the marketer, or only the seat the composable layer was keeping warm? And is this a circle back to the monolith, or a genuinely different shape? I have a guess on each. I would rather hear yours, especially when it lands opposite mine.
Do you have any questions after reading this article?
Or need support with Databricks, or your Martech projects?
[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
### A little lift never hurt anyone
URL: https://www.martechtherapy.com/ad-match-boosting-what-is-it/
Last updated: 2026-06-15T05:24:30.000Z
You spend a week defining an audience in your CDP. Lapsed high-value customers, the ones actually worth winning back. You push the segment to Meta feeling good about it. Then the matched figure comes back at around sixty percent of what you sent, and the rest just isn't there. The platform couldn't recognise four in ten of your own customers.
Anyone who has run paid media knows that feeling. It's *the match rate gap*, and it has a few causes. People sign up with one email and log into Meta with another. Phones get replaced every couple of years. And the work address someone handed you is almost never the login their personal Meta account runs on. The audience is real. The platform just can't see all of it.
Over the past six months, a handful of CDPs have started selling a fix for exactly this. [Hightouch](https://hightouch.com/platform/match-booster?ref=martechtherapy.com) calls it Match Booster. [mParticle](https://www.mparticle.com/blog/introducing-match-boost/?ref=martechtherapy.com), now part of Rokt, calls it Match Boost and shipped it in February before opening it to everyone in March. [Zeotap](https://zeotap.com/platform/capabilities/audience-boost/?ref=martechtherapy.com), the European option, calls it Audience Boost. Same capability, three brand names, no agreed category term yet. I'll call it *in-flight enrichment*, because that's what it does.
## What does it actually do?
Here's the mechanic, without the usual marketing gloss.
You send your first-party audience toward an ad platform. Before it arrives, the CDP appends extra identifiers to each record from a third-party identity graph. Additional emails, phone numbers, device IDs, sometimes household data. A record that left your warehouse with one email lands at Meta carrying three identifiers, which gives the platform more chances to recognise the person. More matches, which means a bigger addressable audience and less wasted spend.
What is it that really matters? The enrichment happens *in transit*. The extra identifiers get added as the audience syncs, and then they're gone. They don't write back into your CDP. Hightouch, mParticle and the others all stress this, and they're right to. It's meaningfully better for your data hygiene than the old approach of bulk-uploading your whole list to a third party and letting them keep a copy.
Think of it like posting a letter with a name and a street but no postal code. The sorting office looks up the rest against its directory and completes the address before delivery. Your letter leaves your hands incomplete and arrives deliverable. The part worth holding onto is that the extra detail on the envelope came from the directory, not from the person who wrote to you.
The figures vendors quote are plausible, for what it's worth. [mParticle reports customers seeing match rate improvements](https://www.mparticle.com/blog/introducing-match-boost/?ref=martechtherapy.com) from 30% to over 100%. [Hightouch claims it beats LiveRamp](https://hightouch.com/blog/liveramp-alternative-match-booster?ref=martechtherapy.com) in head-to-head tests on several platforms. I haven't run those tests myself, so take the comparative claims with the usual pinch of salt, but the underlying gain is consistent across vendors and it lines up with how the mechanic works.
A NotebookLM generated explainer of match boosting.
## Who's shipping it?
[LiveRamp](https://liveramp.com/our-platform/enrichment/?ref=martechtherapy.com) has done a version of this for years through its identity graph, so the approach has a track record. What's different now is that it lives as a toggle inside the CDP you already own, rather than a separate onboarding contract. Hightouch even uses some of the same aggregated third-party datasets LiveRamp does, a family resemblance nobody mentions a lot.
[Zeotap](https://zeotap.com/blog/boosting-match-rates-and-engagement-with-zeotap-cdp/?ref=martechtherapy.com) is worth pausing on, because it comes at this from a different starting point. It's European, built with GDPR at the core, and it markets the capability through a deterministic identity graph with custom match logic and match-rate reporting rather than raw reach figures. For anyone operating under European rules, that framing matters more than another percentage point, which is why I'd think twice before lumping it in with the US players by default.
So the cast is Hightouch, Zeotap and mParticle, with LiveRamp as the elder statesman. Expect more to follow. When three vendors ship near-identical features in one quarter, the category has decided something.
## Before you switch it on
None of this should put you off the feature. Give it an afternoon of understanding first and you can use it with confidence. A few things are worth checking.
The first is what that in-flight enrichment means for how you think about your own data. What you activate on Meta is now a richer profile than the one you hold internally. That's fine, as long as you can explain it when your data protection officer asks why a customer who gave you a work email is being matched on a personal mobile. You want that answer to hand before an audit, rather than discovering the question during one.
The second is consent, and this is the one I'd genuinely slow down for. These platforms let you configure opt-out rules and suppression. The real question is whether your consent signals are actually wired into those rules. If your consent management platform and your CDP aren't talking properly, you can enrich and activate someone who opted out of advertising, and the enrichment layer won't know any better. The gap is easy to fix. It just has to be fixed before you flip the switch.
The third is [picking sensible first use cases](https://www.martechcookbook.com/?ref=martechtherapy.com). Suppression and retargeting of people who are already your customers is the lowest-risk, highest-value place to begin. Enriching a cold prospecting audience is a different conversation, especially in Europe and especially in regulated sectors. One practical detail for global campaigns: mParticle's enrichment is currently US-only. If your audiences are European, check the data residency story before you assume parity.
## So, is match boosting worth it?
I'll be honest, I came at this expecting to dislike it more than I do. The performance case is sound, and the in-flight design is a real improvement on the bad old days of handing your entire customer list to a broker and hoping. The technology is the easy part. What needs your attention is the half-hour of consent and use-case housekeeping that should happen before the toggle goes green.
That's the part that tends to get skipped, because the feature is built to be effortless, and effortless things invite a certain carelessness. A one-click setup doesn't mean a one-click decision.
[Martech Stack Builder — Plan, Evaluate & Govern Your StackMap your vendor landscape, run AI-powered evaluations, manage procurement, and track costs — on one canvas. The planning tool for martech architects.Martech Stack BuilderMartech Stack Builder](https://www.martechstackbuilder.com/?ref=martechtherapy.com)
If you want to pressure-test how identity matching and enrichment would behave against your own data model, that's the kind of thing the [Martech Stack Builder](https://www.martechstackbuilder.com/?ref=martechtherapy.com) is built for. Worth a look before a vendor demo, not after.
I'm curious whether anyone has switched one of these on in a GDPR-first setup yet. I'd like to know how the consent inheritance held up once it met a real preference centre.
Do you have any questions after reading this article?
Or need support with your Martech projects?
[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
### The CDP you weren't supposed to buy
URL: https://www.martechtherapy.com/the-cdp-you-werent-supposed-to-buy/
Last updated: 2026-06-08T14:28:08.000Z
In 2022, Hightouch published a piece with a headline built to draw attention: [Friends Don't Let Friends Buy a CDP](https://hightouch.com/blog/friends-dont-let-friends-buy-a-cdp?ref=martechtherapy.com). I remember where I first saw it, neck deep in my client's packaged CDP project. Sure, it was vendor content. Everyone knew it was vendor content. Nevertheless, it got passed around, because the frustration underneath it was real, and most of us had heard it, or even felt it.
The argument was simple enough to fit on a t-shirt. Your data already lives in the warehouse. Why pay a second vendor to copy it into a separate box, call that box a [Customer Data Platform](https://www.martechtherapy.com/tag/customer-data-platform/), and then struggle to get your data back out again? Skip the box. Activate straight from the warehouse. The packaged CDP, in this telling, was dead weight a mature data team had already outgrown.
Almost four years on, Hightouch sells a composable CDP. Heck, even Gartner now lists them in its Magic Quadrant for Customer Data Platforms. The poacher who spent years telling you the fences were pointless now keeps the gate.
I want to be careful here, because the easy version of this story is a cheap shot, and the easy version misses what actually went on and disrespects all the effort put into the change that really took place.
## What Tejas actually argued
It helps to give the original its due. Tejas Manohar, Hightouch's co-founder, was not wrong about the architecture. The warehouse really had become the place where serious organizations kept their data. Reverse ETL really could push that data into the tools where marketers worked. For an organization with engineers on hand, a warehouse already doing real work, and a tolerance for assembling its own setup, buying a packaged CDP on top of all that was paying twice for one capability. Tejas had a point. In the right room, he was simply right.
The architecture held up fine. The address on the envelope was where it went wrong.
[Hightouch’s AI Decisioning, what will this mean for marketers? A chat with Tejas ManoharIn this episode of Couch Confidentials, host Matthew Niederberger interviews Tejas Manohar, co-founder of Hightouch. They discuss the evolution of customer data platforms (CDPs) and the innovative AI Decisioning product. Tejas shares insights on the needMartech TherapyMatthew Niederberger](https://www.martechtherapy.com/hightouchs-ai-decisioning-what-will-877/)
## The assumption underneath
The pitch was written for data engineers. It assumed a reader who owned a warehouse, trusted the data in it, and could write the models to turn raw events into something a campaign could use. That reader is real. I have worked with that reader. But that reader is not the person who usually buys a CDP.
The person who buys a CDP is more often someone in marketing operations who needs a re-engagement campaign live by the end of the month. Their organization does not run one warehouse. It runs three, with no settled view on which is the source of truth. For them, "just activate from the warehouse" is the start of a data engineering project measured in quarters. The slogan made it sound like you were setting a toggle.
The composable argument treated warehouse maturity as the starting line. For most buyers, it was the finish line, and they hadn't reached it. That gap is the whole story, and I'll come back to it.
## Exhibit A is Hightouch itself
Watch what Hightouch built. In the years since the t-shirt slogan, the product grew event collection, so it could gather the behavioural data in the first place. Identity resolution came next, to stitch those events to a person. Then audience building and campaign analytics, so marketers had somewhere to actually work. Each addition made sense on its own. Together they rebuilt, piece by piece, a composable alternative of the very thing the company had told you not to buy, the packaged CDP.
By early 2026, Hightouch had entered [Gartner's Magic Quadrant for Customer Data Platforms](https://www.martechtherapy.com/beyond-the-gartner-magic-quadrant/) for the first time. David Chan, [who writes some of the sharpest analysis in this corner of our industry](https://medium.com/@iamdavidchan/why-its-difficult-to-evaluate-composable-cdp-vendors-against-packaged-hybrid-cdp-vendors-4a19dca988de?ref=martechtherapy.com), had pointed out only a year earlier that pure-play composable vendors like Hightouch were absent from the quadrant entirely, and argued they arguably weren't CDPs at all, since they store none of your data by design. Within twelve months, the thing David noted was excluded had been included. The category redefined itself around the vendor faster than the vendor could redefine itself.
This is Hightouch delivering the architecture it argued for, and Gartner moving the category to meet it. The market kept asking Hightouch for the parts of a CDP it had dismissed, and Hightouch, sensibly, built them. The architecture won. The slogan did not last once buyers said what they actually needed.
[When the customers speak, even Gartner listensHightouch’s Strong Performer nod shows how Voice of the Customer reshapes the CDP debate. It’s time to listen to peers.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/when-the-customers-speak-even-gartner/)
The expansion didn't stop at the quadrant either. In February 2026 Hightouch launched Content Assembly, its first content tool, and now bills itself as a composable CDP and an agentic marketing platform. It has company in that respect. In April, [Treasure Data became Treasure AI](https://www.treasure.ai/blog/treasure-ai-announcement?ref=martechtherapy.com), relabelling itself an "agentic experience platform." The category that spent years arguing about warehouses is sanding CDP off its own signage and stencilling "agentic" in its place.
## Exhibit B is everyone else
While Hightouch was growing into the category, the leaders' tier was emptying out. Across the last two quadrants, Adobe fell from leader to visionary. Treasure Data dropped to challenger and stayed there. Tealium, a fixture at the top since the first CDP quadrant in 2024, slid to challenger as well, with Gartner pointing to a slowdown in its annual recurring revenue growth rate between 2021 and 2025\. And the roster of names that simply stopped qualifying kept growing: SAP, Blueshift, ActionIQ, mParticle, and Zeta Global among them.
Calling this the death of the CDP would be tidy and wrong. An audit is the better word. Gartner's own figures are the damning part: fewer than a quarter of marketers report high usage of the CDP they bought. The vendors who couldn't prove they were worth the line item got squeezed out, and the survivors were the ones who either burrowed deeper into the enterprise data setup or rebuilt themselves toward the warehouse-native model Hightouch had been preaching. The packaged silo, sold as a finished product to a marketing team, was the thing that aged badly.
## So what does composable even mean now
Here is where I plant a flag, knowing I might walk it back in a year. I am not infallible. Composable won the architecture argument. Nobody serious now claims the right answer for a large organization is to copy all its data into a proprietary box it can't see inside. Even Gartner has come around to warehouse-native as a credible, often preferable design.
But "composable won" and "you don't need a CDP" turned out to be different sentences. The model still describes a CDP. It just assumes the warehouse is already carrying the load underneath it, and that assumption is a wager. Whether it pays off depends entirely on who is making it. For an organization with a well-modelled warehouse and a data team, composable is liberation. For an organization without those things, composable is a bill for work it hasn't done yet, and often presented as if the work were already finished.
This is roughly the question David keeps circling. If a vendor stores none of your data and resolves none of your identities until you build the pipes, is it a CDP, or is it a very good activation layer waiting for you to supply the platform? The honest answer is that it depends on what you bring to it. Which is a deeply unsatisfying thing to put in a Magic Quadrant, and exactly the thing a buyer most needs to hear.
[Why it’s difficult to evaluate Composable CDP vendors against Packaged / Hybrid CDP vendorsWhy it’s difficult to evaluate Composable CDP vendors against Packaged / Hybrid CDP vendors In the most recent 2025 Gartner Customer Data Platform (CDP) Magic Quadrant, a seemingly glaring omission …MediumDavid Chan](https://medium.com/@iamdavidchan/why-its-difficult-to-evaluate-composable-cdp-vendors-against-packaged-hybrid-cdp-vendors-4a19dca988de?ref=martechtherapy.com)
Read more by David Chan
## The question that outlived the argument
The fight everyone had for five years, [packaged versus composable](https://www.martechtherapy.com/are-we-still-comparing-composable-cdps-to-packaged-cdps/), was an argument about the shape of the tool. Success or failure came down to something the tool never controlled: the state of the organization holding it.
I keep coming back to this in client work, and it is the spine of how I assess [martech readiness: structure, capability, and process](https://www.martechtherapy.com/the-martech-readiness-gap/). Does the organization have the structure to own customer data across teams instead of fighting over it? Has it got the capability, the actual people and skills, to model and maintain that data? And the process to keep it clean once the launch glow fades? An organization that can answer those three can succeed with a packaged CDP, a composable one, or, as I explored in the [Multi-CDP Reality series](https://www.martechtherapy.com/tag/multi-cdp/), more than one running in parallel without it being a scandal. An organization that can't answer them will struggle with any of them, and will blame the vendor either way.
The 2022 article was a good provocation. The industry needed someone to say the packaged silo had problems, loudly, and Hightouch said it louder than anyone. What the industry maybe didn't need was for buyers to take it as permission to skip the unglamorous work, buy a warehouse and a Reverse ETL tool, and assume the activation layer would assemble itself. Some organizations did exactly that, and a few of them are still untangling it.
So I'll leave it where I actually am, which is unsure about the next turn. The vendor who told you not to buy a CDP now sells one that Gartner ranks, and that journey describes the market better than any slogan did. If the category could circle all the way back to itself in three years, I wouldn't put much faith in today's consensus, warehouse-native and agentic and confident, looking any wiser when we read it back in 2029.
But the consensus is the industry's argument to have. Yours is narrower and more useful. Earlier I said the composable reader is real, and that this reader is rarely the person signing the CDP contract. *So the question worth your attention is whether that reader is you*. Is your organization the one composable was written for, and if it isn't yet, what would it take to get there?
---
*Part one of two. Part two works through how to tell whether composable was written for your organization, and what to do when the answer is "not yet."*
Do you have any questions after reading this article?
Or need support with your Martech projects?
[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
### The Context Audit
URL: https://www.martechtherapy.com/the-context-audit/
Last updated: 2026-06-01T10:12:43.000Z
A follow-up to [the follow-up](https://www.martechtherapy.com/what-does-the-context-layer-actually-have-to-do/). My last piece explaining "what the context layers has to do" argued that customer state has to be **Q**ueryable, **A**ddressable, **C**urrent, and **A**ccountable if agents are going to act on it in real time. It ended pointing at a one-page audit and stopped there.
This is that audit.
The context layer's job is to make the customer state usable when an agent needs to act on it. Whether it's doing that job is not a question anyone can answer from an architecture diagram. Architecture diagrams describe what was bought. The audit describes what a workflow can actually reach.
So the move I described was simple. Take one live workflow. Score the context it depends on against the four properties. Find the gap. Fix the lowest score first. Then do it again with two more workflows and see what pattern shows up.
That's the whole instrument. One page, four columns, three workflows.
## Why audit a workflow, not a stack
A stack audit will tell you what platforms exist, what they connect to, and which licenses are up for renewal. Useful for a renewal cycle. Less useful when an agent has to decide whether to send a re-engagement email to someone who churned eleven days ago.
[Martech Stack Builder — Plan, Evaluate & Govern Your StackThe interactive planning tool for martech architects. Map your vendor landscape, run AI-powered evaluations, manage procurement with RFIs, and track costs — all on one canvas.Martech Stack BuilderMartech Stack Builder](https://www.martechstackbuilder.com/?ref=martechtherapy.com)
The reason is that workflows are where context gets consumed. A platform can hold beautifully modelled customer state and still be invisible to the workflow that needs it, because the workflow reads from a different system, on a different cadence, with a different identity key. The data is there. The agent can't see it. The decision happens anyway.
So the audit starts at the workflow and works backwards. What context does this workflow need? What does it actually have? Score the delta on four properties. Done.
## The four properties as a scoring rubric
Each property gets a score from zero to two. Zero means the workflow can't rely on it at all. One means it works most of the time, with known failures. Two means it's solid enough that an agent could act on it without supervision.
| Property | 0 | 1 | 2 |
| ----------- | ---------------- | ------------------- | --------------------------- |
| Queryable | Unreachable | Reachable, awkward | Documented, fast, parseable |
| Addressable | Wrong identifier | Mostly resolves | Same identifier end to end |
| Current | Stale by design | Mostly fresh enough | Window matches the decision |
| Accountable | No log | Partial log | Decision log with inputs |
**Queryable** is whether the workflow can ask the right question of the context, in the right shape, fast enough to act. A two looks like a documented query, a known latency, and a response format the workflow can parse without translation. A zero looks like the context exists in a warehouse table that the workflow has no path to.
**Addressable** is whether the context resolves to the right unit of work. A two means the workflow knows who or what it's about, with the same identifier the rest of the system uses. A zero means the context exists, but against an identifier the workflow can't match (email vs. CRM ID, anonymous vs. known, household vs. individual).
**Current** is whether the freshness is compatible with the decision. A two means the context was last updated within a window that makes sense for the workflow, and the workflow knows what that window is. A zero means yesterday's snapshot is being used for an in-session decision, or last quarter's model is being used to predict next week's churn.
**Accountable** is whether you can trace, after the fact, what context the workflow used, what it decided, and why. A two means there's a decision log that points to the inputs. A zero means the workflow ran, something happened, and nobody can reconstruct what it was looking at when it acted.
Eight points possible. Six is functional. Four is a good sign that work needs to be done to derive real value.
A quick visualization of the 4 property context audit generated by NotebookLM.
## Walking one workflow
Let's run through an example.
Take a re-engagement email triggered by inactivity.
The agent's job:
> Send a relevant message to a customer who hasn't engaged in fourteen days.
To do that well, it needs to know who the customer is (*Addressable*), what they last engaged with (*Queryable*), whether anything has happened since the trigger fired (*Current*), and whether the team can later see why this specific customer got this specific message (*Accountable*).
Now score it.
Queryable: two. The workflow can pull recent activity from the engagement table, response in under a second, in a format the orchestration agent can use. Fine.
Addressable: two. Identity stitching between the marketing platform and the warehouse is solid. The customer is the customer. Fine also.
Current: one. The engagement table is refreshed every six hours. So a customer who clicked an email ninety minutes ago could still receive a "we miss you" trigger. Most of the time this doesn't happen. Sometimes it does, and the customer notices.
Accountable: zero. The agent decides to send, sends, and logs the send. Nothing about the agent's reasoning, the context it considered, or the alternative messages it rejected is captured anywhere a human can reconstruct it later.
Final tally, five out of eight. The workflow delivers partial value. It also occasionally produces the embarrassing "we miss you" email to someone who just bought something, and nobody on the team can explain why a particular variant got chosen for a particular customer when leadership asks.
The first move is not to rebuild the workflow. The first move is to raise the lowest score. Accountable went to zero because nobody decided what a decision log should contain. Keep in mind that this is a working session, not a full fledged project. Define the minimum payload, log it from the workflow, hold the line. Accountable goes to one. Then look at Current, which is constrained by a refresh cadence. That's a data-engineering ticket. Move it to hourly, then to streaming where the cost makes sense.
The audit doesn't tell you to do all of that this quarter. It tells you which score to raise first, and what raising it requires. One step at a time, that is something to be proud of.
## Three workflows is where the pattern appears
Now, let me let you in on a secret. One workflow audit tells you about that workflow. Three can reveal a pattern.
Run the same audit on an inbound lead triage that routes incoming form fills to sales, and on a paid retargeting suppression that's supposed to stop bidding on customers who already converted. Or something more appropriate to your business.
The triage workflow scores well on Queryable and Addressable, because that's what sales operations teams have been polishing for fifteen years. It often scores badly on Current, because the firmographic data it relies on was enriched at the time of first contact and never refreshed. And it scores badly on Accountable, because the routing logic is buried in a tool that nobody on the marketing side has read in two years.
The retargeting suppression scores well on Current, because ad platforms force a fast cadence. It scores badly on Addressable, because the suppression list lives against a hashed email and the conversion event lives against a customer ID, and the join between them is approximate. And it scores badly on Accountable, because nobody is keeping a log of which customers got suppressed when, so when finance asks why ad spend doesn't reconcile, the answer is a shrug.
Three workflows, three different lowest scores, but in most real-world cases a pattern starts to show. Most teams pass on Queryable and Addressable, because those are the properties vendors sold them. Most teams fail on Current and Accountable, because nobody sold them those. Like my good friend [Ana Mourão](https://www.linkedin.com/in/anamourao/?ref=martechtherapy.com) recently told me:
> There's no glamour in governance.
And she is right. Freshness is a data-engineering problem with no marketing budget line so it gets a low priority. Accountability is a governance problem with no owner. But we all know this, unfortunately.
That pattern is the actual finding from the audit. Not "your stack is broken." Not "you need a new platform." Something more useful: the two properties most likely to be missing are the two properties nobody is paying attention to.
Once that pattern is visible, the fix stops being a procurement question. Freshness SLAs go into the data contract. Decision logs go into the orchestration design. Both are working problems, not buying problems. There is light at the end of the tunnel.
## What the audit does not do
Let's be realistic though. The audit does not tell you which vendor to buy. It scores what you have, against what workflows need. The answer might be "your current platform is fine, you just haven't connected it to the workflow that needs it."
It does not replace a data contract. It surfaces where one is missing.
It does not grade the CDP. It grades whether the context a workflow needs is reaching the workflow. The CDP might be doing its job perfectly and still scoring badly on this audit, because the workflow is reading from somewhere else.
It does not produce a maturity score. There is no "your context layer is at level three out of five." There is a list of named workflows, their scores against four properties, and a ranked list of fixes. That's the deliverable.
## Run it on one workflow this week
Now, again, it is your turn.
Pick one workflow. A real one, one that runs in production, one that an agent or an automation already drives or could potentially drive. Write the workflow's name at the top of a page. Below it, four columns:
Queryable / Addressable / Current /Accountable
Score each from zero to two. Underneath, write the lowest score. Below that, write the one move that would raise it by a point.
That's the audit. One workflow, ten minutes, one page.
Do it again next week with two more, and the pattern will start to show. The pattern is the part that changes the conversation with the data team, with finance, with whoever owns the platform that nobody audits.
If running it solo is uncomfortable because the answer might be inconvenient, [Martech Therapy](https://workshop.martechtherapy.com/?ref=martechtherapy.com) runs context audits with teams as a half-day working session. We bring the rubric, the workflow list, and the awkward questions. You bring the workflows and the people who own them. Three audits in, the pattern is yours to act on.
Either way, the one-page version is the one that matters. The audit is small on purpose. The work that comes out of it isn't.
*A follow-up to* [*the six-part Contextual CDPs series*](https://www.martechtherapy.com/tag/contextual-cdp/)*, via* [*What does the context layer actually have to do?*](https://www.martechtherapy.com/what-does-the-context-layer-actually-have-to-do/)
Do you have any questions after reading this article?
Or need support with your Martech projects?
[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
### What does the context layer actually have to do?
URL: https://www.martechtherapy.com/what-does-the-context-layer-actually-have-to-do/
Last updated: 2026-05-26T05:40:29.000Z
*A follow-up to the* [*six-part Contextual CDPs series*](https://www.martechtherapy.com/tag/contextual-cdp/)*.*
A year ago, I published a six-part series on contextual CDPs. It started with MCPs reframing the CDP as a dynamic context engine, then memory as the orchestration layer, then trust as the interface when systems start to infer and decide, then the practical bridge between today's stack and an agent-driven future, then composability that needs sequence and scaffolding rather than more connectors, and finally contextual fluency as a human skill rather than a technical one.
I thought I was making an argument that needed defending at the time. However, a year later, I'm watching the rest of the industry arrive at the same word from different doors, and the argument has changed.
### Everyone arrived at the same word
Scott Brinker published ["Systems of Context and Systems of Truth"](https://chiefmartec.com/2025/02/meet-the-new-martech-stack-systems-of-context-and-systems-of-truth/?ref=martechtherapy.com) in February, framing it as the mental model that replaces systems of record and systems of engagement now that AI agents are doing a lot of the engaging. Snowplow's Alex Dean, writing alongside Databricks, described a [customer context layer where real-time behavioral signals flow into agents at the moment they decide](https://www.databricks.com/blog/real-time-decisioning-ai-agents-why-you-need-customer-context-layer-first?ref=martechtherapy.com). Amperity launched [real-time customer context at Amplify 2026 as a shared layer unifying identity, behavior, and history](https://amperity.com/announcements/amperity-turns-real-time-customer-context-into-meaningful-brand-experiences?ref=martechtherapy.com). Lee Hammond raised the contextual CDP unprompted on a call with me two weeks ago. Frans Riemersma and the State of Martech 2026 report center context as one of the defining shifts of the year.
[Read more about Scott Brinker's Systems of Context/Truth](https://chiefmartec.com/2025/02/meet-the-new-martech-stack-systems-of-context-and-systems-of-truth/?ref=martechtherapy.com)
That convergence matters more than any single framing. When five smart, independent observers reach for the same word to describe the same underlying problem, the word has stopped being a positioning exercise and *started being a shared reference point*. The question is no longer what is context. It is:
> What does the layer that holds it actually have to do?
In Part 1 I called these contextual fragments and described the customer profile as a real-time construct rather than a single golden record. A year on, with Scott Brinker calling it systems of context and Snowplow calling it a customer context layer, the thing has a name. So let's spend the rest of this piece on what that named thing has to do at the build level.
### Four things the layer has to deliver
If an agent is going to act on behalf of a customer in real time, the layer it reads from has to do four things well. None of these are novel individually. The novelty is that they all have to be true at once, and most stacks deliver two out of four.
**It has to be queryable.** An agent deciding whether to send a message, hold a message, or escalate to a human needs to ask a specific question and get a specific answer back fast enough to act on it. Has this customer opened the last three sends is a query. Is this customer in an active service issue right now is a query. The layer either answers those in milliseconds or it doesn't, and if it doesn't, the agent either guesses or stalls. Both are bad outcomes. The build move is treating customer state as an API surface from day one, not as a report that gets refreshed nightly.
**It has to be addressable.** Every entity the agent might ask about needs a stable name. A customer, a household, a session, a cart, a service ticket, each of these is a thing the agent can fetch by key. This sounds basic and it is, but it's where a lot of real implementations come apart. Identity resolution gives you the customer key. The harder work is giving every other entity a key the agent can reach for too, and keeping those keys stable as the underlying systems change. The build move is publishing a small, deliberate set of addressable entities and letting agents read against those rather than against the source systems directly.
**It has to be current.** Current means current enough for the decision being made, which is a different threshold for different decisions. A churn-risk score can be current to yesterday. A cart-abandonment trigger needs to be current to the last few minutes. An in-session next-best-action needs to be current to the last few seconds. This is what I was reaching for in Part 2 when I argued real-time isn't speed, it's right time. The build move is being honest about which decisions need which freshness, and architecting the read paths accordingly. Trying to make everything sub-second is expensive and unnecessary. Letting everything default to overnight is cheaper and broken.
**It has to be accountable.** When an agent acts, you need to be able to ask later what it read, and when it read it. If you can't reconstruct the state the agent saw at the moment of decision, you can't debug the decision, you can't audit it, and you can't learn from it. This is the same ground I covered in Part 3 as trust as the interface and in Part 5 as the audit-friendly stack with narrative debugging. The build move is logging the read alongside the action. Not the whole profile, just the specific values the agent saw at the moment it acted. That log is what makes the layer trustworthy over time.
Visualization of the four layers of the agent-ready data layer (Generated by NotebookLM)
**Queryable, addressable, current, accountable.** Most stacks I've worked on deliver two of these well, a third sometimes, and the fourth as an aspiration. The work of the next two years, for most teams, is closing those gaps.
### What this looks like next to the systems you already have
None of this replaces anything. The warehouse still stores. The CDP still resolves identity and persists the profile. The CEP still executes. If that is your [martech stack](https://www.martechstackbuilder.com/?ref=martechtherapy.com) at least.
What's new is the read layer that lives between the persistent systems and the agents asking questions of them. The systems-of-context framing is the cleanest mental model I've seen for where this lives: the systems of truth keep arbitrating what's canonical, and a thinner layer in front of them organises that truth for whatever context the agent is operating in.
That's also why composability stopped being chaotic, which is the argument I made in Part 5\. The chaos wasn't composability itself. The chaos was composability without a shared read layer, which meant every consuming system invented its own version of the customer. Once the read layer is in place, composability becomes what it was always supposed to be: pick the best system for each job, knowing they all agree on what the customer looks like right now.
[Martech Stack Builder — Plan, Evaluate & Govern Your StackThe interactive planning tool for martech architects. Map your vendor landscape, run AI-powered evaluations, manage procurement with RFIs, and track costs — all on one canvas.Martech Stack BuilderMartech Stack Builder](https://www.martechstackbuilder.com/?ref=martechtherapy.com)
### The interesting build questions
Three design choices are live right now in real implementations. None of them have a single right answer. All of them are worth your team chewing on.
**How current is current?** The temptation is to make everything as fresh as possible. The reality is that freshness costs money, latency, and operational complexity, and not every decision needs it. A useful exercise is to list the decisions your agents and workflows make, then assign each one a freshness tolerance: this minute, this hour, this day, this week. The shape of that list tells you which read paths need to be hot, which can be warm, and which can stay cold. Most teams find that a small number of decisions need real-time and the rest are fine on a slower cadence. That distribution is what your architecture should match.
**How do you expose state without exposing everything?** An agent asking is this customer eligible for the loyalty offer doesn't need the full profile. It needs the answer to that question. The build choice is whether to give agents access to the underlying attributes and let them compute the answer, or to expose pre-computed answers as named values. The first is flexible and harder to govern. The second is governed and harder to change. Most mature implementations I've seen end up doing both, with the named-value approach for high-volume decisions and the attribute approach for exploratory or edge cases. The trick is being deliberate about which is which.
**How do you log the read?** Logging every read at full fidelity is expensive and produces noise no one will ever look at. Logging nothing means you can't debug a bad agent decision after the fact. The middle path most teams are landing on is logging the read at the same grain as the action: if the agent took a decision, log the values it consulted to take that decision, with a timestamp. That gives you a replayable record of what the agent saw without drowning in observability cost. It's also the foundation for the audit trail you're going to need as regulators start asking harder questions about how automated decisions get made.
These are the questions I'd want a team to be able to answer before they commit to an architecture. Not because there's a textbook answer, but because the answers reveal what the team actually values.
[Agentic AI in Martech: The billion decision problemPart 1: Why scale changes everything about AI in MartechMartech TherapyMatthew Niederberger](https://www.martechtherapy.com/agentic-ai-in-martech-the-billion/)
### Where to start this week
Pick one agent or workflow in your stack that's currently using customer state to make a decision. Could be a triggered email, a personalised recommendation, an in-app message, a routing rule. Anything where state shapes the action.
Trace three things on one page.
1. What does it read?
2. When does it read it?
3. How stale is that read by the time the action fires?
That single page is the smallest useful version of a context audit.
It will tell you, immediately, which of the four properties you're delivering for that one decision and which you're not. The gap is your first meter of work. Do it for one agent this week, two more next week, and within a month you'll have a map of where your stack actually stands against what agentic marketing needs. That's a more useful artefact than any architecture diagram you could buy.
**Read the full Contextual CDP series:**
- Part 1: [Contextual CDPs, is this the next-gen?](https://www.martechtherapy.com/understanding-mcps-a-cdp-insiders/)
- Part 2: [Memory, not identity, is what makes context work](https://www.martechtherapy.com/contextual-cdps-memory-is-what-makes-context-work/)
- Part 3: [Trust as a feature](https://www.martechtherapy.com/trust-as-a-feature/)
- Part 4: [Building the bridge](https://www.martechtherapy.com/contextual-cdps-building-the-bridge/)
- Part 5: [Composable, not chaotic](https://www.martechtherapy.com/contextual-cdps-composable-not-chaotic/)
- Part 6: [Contextual Fluency](https://www.martechtherapy.com/contextual-cdps-contextual-fluency/)
Do you have any questions after reading this article?
Or need support with your Martech projects?
[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
### Plotting my course to AntiCon
URL: https://www.martechtherapy.com/plotting-course-to-anticon-2026/
Last updated: 2026-05-18T06:00:31.000Z
AntiCon lands in London on May 21 and I'm registered for the full main-stage track on day one. Looking at what I've signed up for, the route through the day is revealing... in hindsight. Behavioral science as the human advantage, and as a former data analyst, I am looking forward to this one. The three levers of marketing transformation. Redesigning the marketing organization for an AI era. Architecting the agentic operating model. Co-pilot or autopilot. Are you prepared for the next Martech eras. Conviction at scale.
A bunch of different titles, with vastly different speakers, but the same underlying question asked from **seven** angles.
> What does the marketing function actually look like once agents are doing real work, and who in the buyer's team is responsible for any of it?
That question, along with many others (yes, my head is a busy place) is the one I am seeking answers to. The [Martech Readiness Gap piece in March](https://www.martechtherapy.com/the-martech-readiness-gap/) was the first attempt to name it. The [comprehension-over-generation argument from a fortnight ago](https://www.martechtherapy.com/comprehension-is-where-the-value-lives-now/) was another angle on the same shape. The piece I wrote [after the State of Martech 2026 keynote](https://www.martechtherapy.com/the-readiness-thread-inside-the-state-of-martech-2026/) was the most direct attempt. Scott Brinker and Frans Riemersma described the new ship and named the trust ladder; AntiCon's agenda looks like the first event this year built to walk the next stretch of the conversation, the part about who in the buyer's team actually operates any of this.
AntiCon's agenda is unusual because it's framed around the operating model rather than the platform, which means the speakers have signed up to attempt the harder conversation, and I couldn't be more excited.
Three things I want to be listening for during the day.
## One. Does anyone give the trust ladder its progression criteria?
Scott named three rungs in the State of Martech keynote.
Interpret. Create with a human. Autonomous.
The Trust Ladder
Useful taxonomy, as far as it goes. The next layer, the one I flagged as missing, is what it actually takes to move a use case from rung two to rung three.
[Funnel.io's](https://funnel.io/?ref=martechtherapy.com) János Moldvay's Co-Pilot or Autopilot session is the most direct heir to this question on the agenda, and Christine Bailey's Conviction at Scale lands at the other end of the spectrum, presumably arguing for getting on with it. Christine being at [Moody's](https://www.moodys.com/?ref=martechtherapy.com) matters here because Moody's operates in a category where model risk management is a daily practice. Marketing is just now reaching the point where it needs the same disciplines, and learning from categories that already have them is the fast path forward.
A real answer would name the artefacts.
- Which monitoring signals you'd need clean for thirty days before promoting an agent from human-in-the-loop to autonomous?
- Which decision rights move with the agent, and which stay with a human reviewer?
- What the rollback looks like and how fast it has to fire?
None of that is exotic in regulated industries, and the moment marketing starts borrowing those disciplines on purpose, the trust ladder stops being a feeling and starts being something you can put in a runbook. I'm hoping at least one of these two sessions begins to sketch what those criteria could look like.
[Agentic AI in Martech: The billion decision problemPart 1: Why scale changes everything about AI in MartechMartech TherapyMatthew Niederberger](https://www.martechtherapy.com/agentic-ai-in-martech-the-billion/)
## Two. Is "redesigning the marketing organization" actual design work, or relabelled boxes?
This session belongs to Carlos Doughty, who founded [LXA](https://www.lxahub.com/?ref=martechtherapy.com) and is hosting the entire event. Putting yourself on stage to talk about the hardest organizational question of the day, on the day you're hosting, is a notable choice. It's the session I'm most curious about and the one where the difficulty is most apparent.
Real organization redesign in an agentic context means working at the level of decision rights. New roles, new reporting lines, new escalation paths, and the actual mechanics of [who approves an agent's output before it goes to a customer](https://www.martechtherapy.com/letting-go-of-control/). The honest test is whether the redesign survives a question like this. If a journey gets misfired by an agent at 2am on a Saturday, who gets paged, what do they have authority to do, and what's the rollback path? Carlos has the chance to show what a serious answer to that question looks like.
Given that LXA exists to teach marketers and to help them figure out what comes next, this is exactly the kind of work the host should be modelling, and it's a good signal for the field that AntiCon has put it on the main stage rather than tucked into a breakout. I'll be listening for whether Carlos has worked the problem at the level of decision rights or at the level of role names. The two look identical on a screen. They diverge the moment something goes wrong, and the answer to that divergence is what I'm hoping to take home from this session.
[The readiness thread inside the State of Martech 2026Scott and Frans handed us value engineering and context engineering, both useful. The thread they didn’t have time to pull is what your team has to actually become to operate any of it. Picking it up here, with a navy metaphor and the bit of the IKEA Billie story nobody talks about.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/the-readiness-thread-inside-the-state-of-martech-2026/)
## Three. What does Adam Greco do with the era framing?
[Hightouch's](https://www.hightouch.com/?ref=martechtherapy.com) Adam Greco is presenting *Are you prepared for the next Martech Eras*, and this is the session I'm most interested in for reasons that have less to do with the topic and more to do with Adam.
I have a low tolerance for era-language at the best of times. It tends to be the marketing version of geological epochs, useful for slides and such, less useful for anyone trying to plan a Q3 budget. But Adam's body of work over the last decade has been precise, technically grounded, and refreshingly free of the hype patterns the rest of the industry has fallen into. So if Adam is the one making the case for thinking in eras, I'm coming in with the assumption that the framing is doing real work.
What I'm hoping for is the talk where Adam names a specific operating-model capability the previous era's marketing function lacked, and a concrete capability the next era's function needs, and is honest about the parts of the previous era that are still load-bearing. Adam at Hightouch is also at an interesting structural vantage point. Reverse ETL and the composable end of the data activation conversation has been at the centre of the last eras-worth of [martech stack](https://www.martechstackbuilder.com/?ref=martechtherapy.com) evolution, and Adam has had a front-row seat to both the rhetoric and the reality.
I'll take notes and come back to this one in the post-event write-up. If anyone is going to make me believe in era-language, it'll probably be him. And whatever I conclude after the session, I'm looking forward to arguing about it with him afterwards.
[Martech Stack Builder — Plan, Evaluate & Govern Your StackThe interactive planning tool for martech architects. Map your vendor landscape, run AI-powered evaluations, manage procurement with RFIs, and track costs — all on one canvas.Martech Stack BuilderMartech Stack Builder](https://www.martechstackbuilder.com/?ref=martechtherapy.com)
## Why this matters beyond AntiCon
The Spring conference circuit's red line is visible from space. The architecture conversation has matured. The organizational design conversation has not. AntiCon's agenda is unusually well-positioned to push the latter forward, because it's been deliberately shaped around the operating model rather than the platform. If the speakers deliver on that framing, the day will be one of the most useful events I've been to this year, and the field will have moved an important step closer to a conversation marketing has been needing for a while.
I'll be there with a notebook and an open ear. If you're attending and want to argue about any of this between sessions, find me. I will have some stickers for you to help alleviate the Martech stress.
Martech stickers, feel free to ask me for them 😄
I'm also working on a Martech readiness self-assessment, the worked-out version of the framework I keep referring to in these pieces. Not ready yet, but close enough that I'll be testing language with people at the event.
See you in London.
Do you have any questions after reading this article?
Or need support with your Martech projects?
[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
### The iceberg under the demo
URL: https://www.martechtherapy.com/the-iceberg-under-the-demo/
Last updated: 2026-05-11T06:20:01.000Z
Last week two things crossed my ~~desk~~ screen that, on the face of it, had nothing to do with each other.
The first was an email from an investor running an internal AI contest across six of their portfolio companies, one of which [I used to work with](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com). The framing was good, and I was happy to see this development. They were asking employees (*and somehow former contractors like me*) to record a two-minute screen capture of an AI workflow they'd started using. A 15-minute task done faster. A draft response written in half the time. You get the idea.
Three winning teams, a thousand euros each in travel vouchers, and an independent jury. That was the whole thing.
The second showed up on [Reddit](https://www.reddit.com/r/OpenAI/comments/1t0y2e2/uk%5Fgovernment%5Fissued%5Fan%5Furgent%5Fwarning%5Fto%5Fuk/?ref=martechtherapy.com). An open letter from the [UK Department for Science, Innovation and Technology](https://www.gov.uk/government/organisations/department-for-science-innovation-and-technology?ref=martechtherapy.com) and the Cabinet Office, signed by the Secretary of State and the Security Minister. Serious stuff, yet addressed, plainly, to "Dear business leaders." Not addressed to me, obviously, but worth reading anyway.
The open letter from the UK Department for Science, Innovation and Technology and the Cabinet Office, April 2026.
It said, among other things, that the [UK's AI Security Institute](https://www.aisi.gov.uk/?ref=martechtherapy.com) had assessed that frontier model capabilities are now doubling every four months, compared to every eight months previously. Recent tests of advanced AI models, including [Anthropic's new Mythos](https://www.anthropic.com/glasswing?ref=martechtherapy.com), indicate that AI cyber capabilities are advancing faster than previously envisaged. That criminals will not just target government systems and critical infrastructure. They will target ordinary companies, of every size, in every sector. Attackers go where defenses are weakest.
I read them the same morning. And I sat with them for a while.
For about 2 cups of coffee.
This was the first cup of coffee ☕
## The healthy thing first
Look, the investor email is the healthy version of where most companies are, or really should be aiming for. AI inside organizations has, for a couple of years now, mostly arrived in one direction. Imported. Pitched to leadership. Bought. Then handed down, with some instructions and a rollout plan. Meanwhile the actual work, the 15-minute task, the email triage, the spreadsheet wrangling, was either being automated by individual employees on their own initiative, or not being touched at all because nobody had told them they were allowed.
Asking employees to surface what they're already doing is, genuinely, a smart move. It's a kind of organizational stethoscope.
Where is AI actually being used?
By whom?
For what?
You learn more from that than from any maturity assessment a vendor will sell you.
It also has the rare quality of being practical. There's no transformation theatre. No call to "reimagine the future of work". Just: show me what you did last Tuesday that worked.
I'm highly in favor of this. I think more investors and more leadership teams should run something like it. Learning to walk before you run is not a cliché in this case. It's literally what's happening. People are figuring out where AI fits in their day, one workflow at a time, and the smart organizations are paying attention.
TUI did something similar with the ****Embrace AI Tour** at the end of 2025\. ([Source](https://www.linkedin.com/posts/tuigroup%5Ftui-embrace-ai-tour-2025-activity-7340231401679585280-Xk8J/?ref=martechtherapy.com))
## And then the UK letter
The Cabinet Office letter is doing something different. It's not asking. It's warning.
What caught my eye, as I scanned it, was the specific framing.
> "We are entering a period in which the pace of technological change may test every institution in the country."
Although it sounds like a rogue version of [Martech's Law](https://www.martechtherapy.com/extending-martechs-law-why-growth-leads-to-decay/), we need to accept that it is not a sentence civil servants write lightly. The bit about frontier capabilities doubling every four months instead of every eight gets argued over before it ends up in a signed letter from two ministers.
And then the asks, which are deliberately unsexy. Take cybersecurity seriously at the top of your organization. Don't delegate it to IT and forget about it. Get the basics right with Cyber Essentials. Sign up for the [Early Warning Service](https://www.ncsc.gov.uk/section/active-cyber-defence/early-warning?ref=martechtherapy.com). Plan and rehearse how you'd respond to a significant incident.
When topics like this become a meme, you know it is time to take it seriously.
This is governments, in writing, telling business leaders that the same AI capabilities employees are using to draft emails faster are, on a slightly different vector, being used by people trying to break into their networks. And that the velocity of that is changing faster than most boards have processed.
## The iceberg
There's an image that's been doing the rounds that captures part of what I'm trying to say better than I can in prose.
The tip is what we see and celebrate. The Lovable logo, the ChatGPT logo, the Cursor logo, the few tools that make the AI workflow demo look effortless. The investor's contest submissions will mostly live up here. Someone showing a clever prompt, a useful agent, a workflow that saves an hour.
The mass below the waterline is everything the workflow can eventually depend on. Databases. Encryption. Load balancers. Rate limiting. Error logging. Web sockets. Caching. The boring infrastructural reality that decides whether a clever prompt, run a thousand times a day across a business, holds up or collapses.
I think most contests like the one I described will surface tip-of-iceberg work, because that's what employees can see and record in a two-minute screen capture. That's fine. That's the point. But the people watching the contest results need to remember what's underneath, because that's where the actual risk lives.
[The dirty truth about vibe coding in MartechAfter \~1000 hours vibe coding, I’ve learned something surprising. AI makes building software easier. But the moment your tool actually works… the real work begins. Hosting. Security. Monitoring. Maintenance. Are we replacing SaaS, or just redistributing responsibility? Curious how others see this.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/the-dirty-truth-about-vibe-coding-in-martech/)
## What the two emails are saying together
The two of them, read together, are describing the same underlying reality from opposite ends. I'm still working out how to articulate this cleanly, so bear with me.
At one end, employees are integrating AI into their workflows organically. Some of it is brilliant. Some of it is duplicating work that the company across the street has already automated. Some of it is running through personal accounts on personal devices with company data inside the prompts. Most of it is invisible to the people who'd need to know if something went wrong.
At the other end, the threat surface is getting wider and faster. Not just from external attackers. From the unmanaged sprawl of AI use inside the building, sitting on top of infrastructure that has its own ongoing supply of disclosed vulnerabilities to patch.
The contest model is a great way to find out what's happening. **It is not, on its own, a way to govern what happens next.** And the gap between those two things, between *we asked people to share what they're doing* and *we have a coherent picture of how AI is being used across the company and what the risks are*, is where most organisations will sit for the next year or two.
I don't say that to be gloomy. I say it because I think the contest is the right first move and the wrong last move. You learn what's there. Then you have to do something with what you learned.
[Comprehension is where the value lives nowProduction used to prove competence. AI broke that chain. The same break is happening to martech stacks, and the fix isn’t more tooling.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/comprehension-is-where-the-value-lives-now/)
## What "doing something" actually looks like
This is the part where I'm tempted to give you a model and I'm going to resist, because I'm honestly not sure the model exists yet. And more honestly I am not a model kind of person. What I have are observations from inside the work.
Most companies I see don't lack AI ideas. They lack a way to triage them. The submissions a contest like this surfaces are going to range from "I use ChatGPT to summarise meeting notes" to "I built a workflow that pulls customer data from three systems, runs it through a model, and writes back into the CRM." Those two things need very different governance responses, and most leadership teams I've worked with don't yet have the language to tell them apart.
There's a piece in the Cabinet Office letter that I think applies directly. They distinguish between things you delegate to IT and things that belong at the top of the organisation. The same logic applies to AI inside companies. Drafting a response faster is not a board-level concern. Pulling customer data through a third-party model, deployed on infrastructure with a steady drip of high-severity CVEs, is. The contest will surface both, mixed together, and someone needs to do the sorting.
The other observation, and this one I hold less firmly, is that the operator-led approach probably can't be governed top-down without killing what made it valuable in the first place. The reason employees are surfacing useful workflows is that nobody told them they couldn't. The minute that becomes a compliance gauntlet, the surfacing stops, and the work goes back underground where you can't see it. So the governance has to be light enough to keep the visibility, but real enough to catch the things that matter. That's a hard balance and I don't think anyone has it figured out yet.
[Why AI strategy fails for the same reason data strategy didTiankai Feng on the human behaviors that determine whether your AI implementation accelerates dysfunction or actually solves problems.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/why-ai-strategy-fails-for-the-same-reason-data-strategy-did/)
## Where I land, for now
I think the investor running that contest is doing the right thing. I think the UK government writing that letter is doing the right thing. And I think most boards will read the contest results in July and the cyber letter in passing, and not connect them.
That's the gap I'd want to be in the room for. Not the contest itself, which is fine on its own terms. Although a paid holiday would be nice. But the conversation that comes after, when the submissions are in and someone has to look at the spread and ask what it means for how the company actually works, what's running where, and whether the iceberg under the demo is solid enough to hold the weight people are about to put on it.
If you're running something similar, or you're about to be, that's roughly the territory my Martech Foundry work is in. Once people start using AI tools in earnest, somebody has to hold the picture together. That's the part I work on. [martechfoundry.com](https://www.martechfoundry.com/?ref=martechtherapy.com)
Curious if anyone else is seeing this pattern. I know one email and one open letter in one week is a small sample. But it's a sample.
Do you have any questions after reading this article?
Or need support with your Martech projects?
[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
### The readiness thread inside the State of Martech 2026
URL: https://www.martechtherapy.com/the-readiness-thread-inside-the-state-of-martech-2026/
Last updated: 2026-05-07T06:44:14.000Z
Like many of you, I watched the [State of Martech 2026](https://content.martechday.com/state-of-martech-2026.pdf?ref=martechtherapy.com) keynote on MartechDay this past Tuesday. Around the forty-minute mark, Scott Brinker made a passing remark about MarOps careers.
> AI is not taking over this work.
>
> Quite the opposite.
>
> As a result of AI, there is so much work to be done.
Frans Riemersma nodded. They both clearly believe it, and so do I. The line had no follow-up. A 55-minute keynote can only do so much, and the organizational implications of value engineering and context engineering were always going to be a thread to pick up rather than a chapter on their own.
So this is me picking up the thread.
## A refit is the start, not the finish
The Royal Navy has a thing, a metaphor I use often, having experienced it many times myself, called FOST. Flag Officer Sea Training. After a ship comes out of a refit, no matter how good the new radar is, no matter how shiny the new combat system, it doesn't deploy until FOST has put the crew through hell for a few weeks. They simulate fires, hull breaches, and missile attacks. Basically, any kind of contingency is possible. The point isn't the kit. The point is whether the crew can fight with the kit they've just been handed.
The 2026 keynote did the refit beautifully. 15,505 vendors in the survey. The new SaaS-and-AI strata. Value engineering. Context engineering. Three pace layers and a Venn diagram with a golden context at its center. All of it is useful, all of it is accurate, and all of it is focused on what the ship now looks like.
The readiness work is what comes next. The FOST part. Someone in your organization has to actually figure out what the team has to become to operate any of this.
[Before you deploy your CDP, train your crewCDP projects test more than tech -> they test teams. What military work-ups taught me about readiness, response, and Martech project success.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/before-you-deploy-your-cdp-train-your-crew/)
Read how I applied the FOST metaphor to the deployment of a CDP. It can be applied to any piece of tech you are onboarding within your organization.
## Following the Billie story all the way through
The most useful organizational moment in the keynote was the IKEA Billie story. Frans told it to illustrate that AI doesn't have to mean redundancy. Their chatbot handled 70% of customer service queries, and instead of firing the staff that became redundant, IKEA reskilled them as interior design advisors. New revenue stream of $1.4 billion. It's a great example, and the point Frans was making is exactly the point I want to extend.
Because somewhere between "Billie goes live" and "we're now doing $1.4bn in interior design consulting" there were **months of organizational work that nobody outside IKEA has written about**. A manager had to figure out what to do with a person who'd spent eight years answering "where is my missing screw" and now needed to hold a conversation about open-plan kitchens. That curriculum didn't exist. Someone built it. Finance signed off on a re-skilling budget that wouldn't show return for at least a year, while the chatbot rollout next door was busy showing efficiency gains every week. Some people probably didn't make it through the transition.
That whole middle bit is the readiness work. **Structure, capability, process**. The IKEA outcome is what becomes possible when an organization actually does it. Most won't, not because they don't want to, but because the conversation usually stops at the technology decision.
I'd happily spend a year arguing about whether your context graph should be deterministic or probabilistic. I think the harder and more valuable conversation is which manager owns the re-skilling plan when an agent absorbs a workflow.
[How IKEA Reskilled 8,500 Employees To Boost Sales by $1.4 BillionA case study on how IKEA chose to reskill, not downsize 8,500 employees displaced by new AI technology, and made $1.4 billion too.Steal These Thoughts!Ross Stevenson](https://stealthesethoughts.com/2023/09/01/ikea-reskill-employees-and-boost-sales-by-billions/?ref=martechtherapy.com)
As Ross Stevenson duely noted in the article above:
> What made IKEA’s approach particularly impactful was how they identified the gap between the employees’ current skills and the demands of the new roles.
>
> Instead of starting from scratch, they built on the employees’ foundational customer service knowledge. Training programs focused on crafting specific customer interaction, design, and sales capabilities.
>
> Others were up-skilled to handle more complex customer service tasks that required empathy, creative problem-solving, and expertise. **The skills we know that AI can’t replicate.**
## Context engineering is mostly an organizational job
Context engineering, the way Scott frames it, is about getting the right data and tools to an agent at the right time with the right governance. Fine. I agree with the definition. Every word in that sentence is doing work that someone in your organization has to actually do.
*Right data*. Who decides what right means? In whose authority does that decision sit? When the marketing ops team says "we need session-level context for this agent" and the data platform team says "that breaches our retention policy," who arbitrates? Conway's Law eats this for breakfast.
*Right tools*. Procurement processes were built for a SaaS world where you could trial a thing for 30 days, sign an MSA, and have it in production by quarter end. The probabilistic side doesn't behave that way. You can't really pilot an agent the way you pilot a campaign tool. You discover its edge cases in production. Most procurement functions are not set up for that.
*Right governance*. Scott named the governance gap directly, pointing out that adoption of AI use cases focused on compliance, brand standards and content validity is lagging the rest. The implication that follows is that closing that gap is mostly a question of process and accountability rather than tooling. Someone has to own the policy. Someone has to update it when the model changes under them, which it will, monthly.
Each of those is a structure question, a capability question, a process question. Those are the three axes I keep coming back to in the [Martech Readiness Gap](https://www.martechtherapy.com/the-martech-readiness-gap/), and I'm becoming more convinced, not less, that they're the actual unit of work for the next two years.
## The bullish case is real, with a footnote
Scott and Frans's framing of value engineering and context engineering is one of the more useful conceptual additions to the discipline this year. Both terms have started to show up in my client work and they hold up well. Also because strategic leaders and operators alike are trying to define the direction of their careers. The keynote will move the conversation forward, and that's worth a lot.
The footnote I'd add is on what the bullish MarOps case actually requires. MarOps will thrive *if* the organization gives MarOps the mandate to redesign procurement, governance and training, and *if* leadership accepts that 18 months of capability building precedes most of the value. Without those two ifs, MarOps becomes the team that gets handed an agent, a budget, and an impossible deadline, and burns out.
I've watched that movie before. So have you. The technology side of the keynote is in good hands with Scott and Frans. The organizational side is the bit I think a lot of us working on the people layer of this now need to go and write up properly.
## What I'm watching for next
Two things I'd like to see in 2026, both of which are natural next steps from where the keynote left us.
The first is a credible maturity model for the trust ladder. Scott named three rungs (interpret, create-with-human, autonomous) and that taxonomy is useful as far as it goes. The next layer is progression criteria. **What does it actually take to move a use case from rung two to rung three, beyond "trust"?** Public data on what's happening to mid-career marketing roles would help here too. The keynote was bullish on MarOps in aggregate, but the sub-cuts are where the picture will sharpen.
The second is more conversations that lead with the organizational change alongside the platform feature. Scott's central point that AI is augmenting SaaS, not replacing it, is an organizational point as much as a technology one, and I think there's a lot of room to keep building it out from that angle.
If you watched the keynote and felt the same thread pulling at you, I'd be curious to hear about it. I'm working through this with clients at the moment, and I don't think anyone has the right answer yet, including me. The butterfly Scott and Frans described is a generous way to think about where we're heading. The chrysalis is where most of us are still working, and the organizational change inside it is the work I'd love to see more of us writing about openly.
Thank you to Scott Brinker and Frans Riemersma for an excellent report. If your team is in that exact spot where the tooling decision feels clear enough but the organizational redesign is fuzzy, that's the kind of work the [Martech Workshop](https://workshop.martechtherapy.com/?ref=martechtherapy.com) is built for.
Do you have any questions after reading this article?
Or need support with your Martech projects?
[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
### Comprehension is where the value lives now
URL: https://www.martechtherapy.com/comprehension-is-where-the-value-lives-now/
Last updated: 2026-05-04T06:58:49.000Z
So, before we sit down and enjoy [MartechDay 2026](https://www.martechtherapy.com/the-pilgrimage-to-martechday-2026/), let's take a moment to reflect on the **Hypertail** situation as described in the State of Martech 2025, where companies are starting to leverage AI to build production solutions to fill the gap left by off-the-shelf Martech.
[](https://content.martechday.com/state-of-martech-2025.pdf?ref=martechtherapy.com)
**"The rise of low-code/no-code platforms over the past 5-10 years has steadily changed that equation, making it easier, faster, and cheaper to build, giving rise to “citizen developers” who could increasingly scratch their own itch by creating lightweight apps and automations."* Source: [State of Martech 2025](https://content.martechday.com/state-of-martech-2025.pdf?ref=martechtherapy.com) (page 6) by [****Chiefmartec.com**](https://chiefmartec.com/2025/05/2025-marketing-technology-landscape-supergraphic-100x-growth-since-2011-but-now-with-ai/?ref=martechtherapy.com)
A scale-up founder called me last year with a clear ask. They said that they needed a CDP. Revenue was growing, channels were multiplying, and the marketing team wanted personalization across all of them. Three vendors had already sent quotes that started at five figures a year.
Could I help pick one.
**I asked four questions** before we got to the vendors.
1. What customer data do you actually have today, and where does it live?
2. What does “personalization” mean to your team in concrete terms?
3. Who on your side will own the implementation after the SI partner hands it over?
4. And if the platform is down for a day, what breaks?
The marketing lead answered the first one in detail. The other three got the kind of answer where someone starts a sentence three different ways and doesn’t finish any of them. Not because the team wasn’t smart. They were. The questions just hadn’t been asked yet, because the vendors don’t ask them. The vendors generate. They generate decks, reference architectures, ROI calculators, personalization heatmaps. What they don’t generate is comprehension on the buyer’s side.
That gap is the thing I want to talk about.
## The argument I’m borrowing
[Nate B Jones posted a piece recently on YouTube](https://www.youtube.com/watch?v=-dJ9WrTG6zQ&list=WL&ref=martechtherapy.com) arguing that production used to signal competence because production used to be hard, and AI broke that chain. His point is aimed at individuals trying to prove their worth in a job market where AI generates portfolios faster than anyone can read them. His central move → comprehension over generation. One project you fully understand teaches you more than ten you vibe coded. He wraps it in a line worth quoting straight: taste comes from having understood enough things deeply enough to recognize patterns.
Read that and you’re thinking about careers.
Read it again and you’re thinking about stacks.
The same break is happening to martech, for the same reason. Production used to be the proof. A stack got built, ergo someone understood it. The vendors did discovery, the SI ran the implementation, the documentation got handed over, and the assumption was that competence sat somewhere inside that pile of work. Now I walk into clients with seven, ten, fifteen tools wired together at speed by some combination of vendor recommendations, agency suggestions, and an internal champion who left eighteen months ago (true story). The stack runs and the dashboards populate. Ask why a particular event fires server-side here and client-side there, or what happens to the audience sync if Snowflake is down for two hours, and the answers don’t come. Same break, different layer.
## Why the AWS story is a martech story
Nate tells a story I want to borrow. An Amazon engineer used a mandated AI coding tool, the tool decided the optimal path was to delete the production environment, AWS went down for thirteen hours, and the official response called it user error. The user was following a corporate mandate to use AI tooling.
That same dynamic shows up in martech now. Marketing ops people get told to use AI agents to manage segments, suppression lists, journey logic. Sometimes the agents do something catastrophic. A consent flag gets misinterpreted, a suppression rule gets inverted, a customer who churned gets a winback campaign because nobody on the team can fully explain the audience definition the agent generated. When it breaks, the answer is some version of “user error.” It almost never is. It’s a comprehension gap, and it sits with the people who picked the tools, not the person who pushed the button.
[The dirty truth about vibe coding in MartechAfter \~1000 hours vibe coding, I’ve learned something surprising. AI makes building software easier. But the moment your tool actually works… the real work begins. Hosting. Security. Monitoring. Maintenance. Are we replacing SaaS, or just redistributing responsibility? Curious how others see this.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/the-dirty-truth-about-vibe-coding-in-martech/)
## What the scale-up actually needed
Back to my client. In the end, the honest answer wasn’t a CDP. They were in a stage where their data wasn’t yet messy enough or distributed enough to justify a five-figure platform, but their team was being pitched as if they were a Series C ecommerce brand. The vendors had generated a need that didn’t match the reality.
What we built instead → a self-hosted n8n instance running at six dollars a month instead of four thousand, doing the orchestration work. A custom survey tool with a backend portal so the team could manage participants without paying for someone else’s UI. A document processing flow that extracts, verifies, and stores data for activation through downstream flows. As volume grew, we expanded onto Postgres with cloud functions and monitoring. Full control. Full risk acceptance. And every piece of it understood by the people running it, because they were in the conversation when the choices got made.
The savings are nice. They’re not the point. The point is that the team can answer the four questions I opened with. They know what data they have, what personalization means in concrete terms, who owns the implementation, and what breaks if a piece goes down. The stack is comprehensible because it was built deliberately, not generated.
[Before you deploy your CDP, train your crewCDP projects test more than tech -> they test teams. What military work-ups taught me about readiness, response, and Martech project success.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/before-you-deploy-your-cdp-train-your-crew/)
## Domain expertise as the explanation artifact
Nate has a second move in his piece worth lifting → explanation as artifact. The idea that a clear, plain answer to what does this do, why this way, what would break, what did I learn travels with the work itself. He compares it to a commit message in traditional software. A commit without a message is technically complete. A commit with a thoughtful message signals someone understood what they were changing and why.
The architecture decision record is the commit message of a stack. Most clients don’t have one. The reasoning behind their stack lives in a Slack thread from 2023, in the head of someone who left, or nowhere at all. And here’s where I want to push the argument further than Nate did → in martech, the explanation artifact isn’t a document you write at the end. It’s the domain expertise of whoever was in the room when the decisions got made.
That’s the part the vendors and the big SI partners can’t bring. They generate. They produce reference architectures and implementation playbooks at impressive speed. What they don’t have is the pattern library that comes from sitting with twenty different stacks across twenty different business models, watching which ones fall apart in eighteen months and which ones don’t. Taste, in Nate’s sense. The thing that lets you tell a scale-up founder that the CDP they think they want is actually a six-dollar n8n instance, an opinionated Postgres schema, and a survey tool the team can extend themselves.
You can’t generate that. You can only build it slowly, by being there when stacks break and asking honestly why.
## The 5pm conversation, one floor down
Nate’s framing is that the proof problem is the 5pm happy hour conversation across tech right now. People are wondering how to demonstrate they can still think when the tools generate so much so fast. That conversation has a parallel in every martech leadership team I talk to. Stacks have grown faster than anyone’s understanding of them. Even though the dashboards keep producing numbers, nobody is sure the numbers mean what they used to mean. **The team has absorbed more tooling without absorbing more comprehension**, and the gap between what the stack does and what anyone thinks it does keeps widening.
Look, I don’t have a tidy framework for fixing this at scale. What I have is a working hypothesis → comprehension is where the value lives now. The build is the easy part. Picking the right things not to build is the hard part, and you can’t shortcut that by generating.
If this is the shape of the problem you’re sitting with, [Martech Foundry](https://www.martechfoundry.com/?ref=martechtherapy.com) is what I do about it. Right-sized stacks for teams that need to actually understand what they own. Built deliberately, with the team in the room, so the explanation travels with the work.
****Your stack isn’t failing.**
It’s absorbing more effort than it used to.
The Second Law of Martech scan helps you see where organisational energy is being spent just to keep things working, and where that cost is starting to crowd out real value.
[Start your FREE Entropy Scan ](https://secondlaw.martechtherapy.com/?ref=martechtherapy.com)
### What Martech development services actually means in 2026
URL: https://www.martechtherapy.com/what-martech-development-services-actually-means-in-2026/
Last updated: 2026-04-30T11:54:06.000Z
Last month a CMO emailed me a screenshot. It was a Google search for "Martech development services" and she had circled three of the top results in red pen. *(Digital pen, on a screenshot. I know. Oh, the irony)* Her question was a single line.
> "Which one of these am I supposed to approach?"
None of them, as it turned out. But I understood why she was asking. When you Google that phrase right now, you get agencies pitching campaign microsites, systems integrators quoting discovery phases, and vendor-certified partners offering to configure the [Salesforce](https://www.salesforce.com/?ref=martechtherapy.com) or [HubSpot](https://www.hubspot.com/?ref=martechtherapy.com) or [Braze](https://www.braze.com/?ref=martechtherapy.com) stack you just finished onboarding. All real services. All with their place. And none of them answering the question she was actually holding, which was closer to *why is my expensive new stack still producing data my team can't use*.
That is the question Martech development services should answer. Most of the time, the category as currently sold does not.
## Why the current market for Martech development services reads sideways
Here's the thing → the phrase is a [Rorschach test](https://en.wikipedia.org/wiki/Rorschach%5Ftest?ref=martechtherapy.com). Ask any vendor what Martech development services cover and you get back an answer shaped by whatever they happen to sell. That's not an insider's joke. Categories form around procurement templates, and procurement templates need boxes to tick. Build a campaign tool. Integrate two platforms. Configure a product. All legitimate things to buy.
None of them start from the place a Martech leader usually starts, which is:
> "I have the systems, I have the team, I have the data, and something between them is broken. **What do I actually build?**"
That question doesn't map to configuration. The product is already configured. It doesn't map to integration in the iPaaS sense either. The pipes exist, they just don't carry what the team needs. And it rarely maps to a new campaign tool, because the problem is internal. A join between two systems that nobody owns. A decisioning layer that your [Segment](https://segment.com/?ref=martechtherapy.com) implementation promised but doesn't deliver in your specific context. An operational view, no single tool in the stack produces natively, so someone in marketing ops is maintaining it in a Google Sheet and pretending that's fine. And trust, the latter happens more than you can imagine.
**These are small pieces of custom software, built deliberately, sitting on top of what's already there.** That is the work. The market just doesn't have a clean name for it yet.
## The precision build
Scott Brinker and Frans Riemersma's [State of Martech 2025](https://chiefmartec.com/2025/05/2025-marketing-technology-landscape-supergraphic-100x-growth-since-2011-but-now-with-ai/?ref=martechtherapy.com) report describes what they call the hypertail. A wave of small, purpose-built applications emerging alongside the commercial catalogue. Often built with AI assistance. Often solving highly specific internal problems the big platforms were never going to touch.
I call this work a **precision build**. Partly because it sounds better than "a little script we wrote," and partly because it's accurate. A precision build isn't a platform replacement. It's a piece of software, sometimes a single page, sometimes a scheduled job, sometimes a small service, built on top of the stack to do the one thing the stack can't.
The reason this is a category now, and not just what engineers have quietly been doing since 2014, is that the cost curve has bent. Two weeks of focused build work is often cheaper and more useful than the twelve-month platform programme that would nominally address the same gap. You know when you play Fallout and you find a settlement full of broken turrets, and instead of rebuilding the whole defence grid you just drop one sentry bot near the entrance and call it fixed? That. Small, targeted, keeps the settlement alive while you figure out the bigger question later.
[The dirty truth about vibe coding in MartechAfter \~1000 hours vibe coding, I’ve learned something surprising. AI makes building software easier. But the moment your tool actually works… the real work begins. Hosting. Security. Monitoring. Maintenance. Are we replacing SaaS, or just redistributing responsibility? Curious how others see this.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/the-dirty-truth-about-vibe-coding-in-martech/)
## When it's the right call
I spend a fair amount of time talking clients out of development work, which is an awkward admission on a page meant to attract development enquiries. But I'll be honest → *most Martech problems aren't development problems*. They're process and ownership problems dressed up as technology failures. If your marketers can't get an audience built in your CDP, the real question is usually whether anyone on the team knows how to use it. Building a tool around that is treating a symptom, and the symptom will come back.
[Why martech teams need diagnostic talent in 2026 | MarTechMost martech friction comes from misinterpretation. The right talent can distinguish useful complexity from decay and restore team confidence.MarTechMatthew Niederberger](https://martech.org/why-martech-teams-need-diagnostic-talent-in-2026/?ref=martechtherapy.com)
Development makes sense when the gap is specific, repeatable, and measurable in hours of manual work per week. Anything vaguer than that is probably a training issue or a vendor conversation. Both are legitimate answers, just not ones a development practice should be selling you.
## One example
A client running Adobe Real-Time CDP, [OneTrust](https://www.onetrust.com/?ref=martechtherapy.com) for consent, and [Braze](https://www.braze.com/?ref=martechtherapy.com) for activation had a latency problem. When a customer updated their preferences, the change took somewhere between eighteen and forty-eight hours to propagate through to active journeys. Technically within contract. Operationally a regulatory risk the compliance team was not willing to carry into the next audit cycle.
Adobe offered a paid upgrade that would shorten the window and extend the contract by two years. A systems integrator offered a discovery phase. What the client actually needed was a small service, about three hundred lines of Python, that listened for OneTrust webhook events and forced a re-evaluation of any active Braze journey touching the affected customer within minutes.
Two weeks of work. Runs in their own infrastructure. Cost less than the Adobe upgrade renewal clause would have added to year two. Nine months later Adobe shipped a similar feature natively, the client turned the custom service off, and the maintenance burden went to zero. That is how these builds are supposed to end.
[Martech FoundryCustom data integration and activation solutions for organisations that have outgrown what off-the-shelf software can do. Built in weeks. Handed over to run without me.Martech FoundryMatthew Niederberger](https://www.martechfoundry.com/?ref=martechtherapy.com)
## So what is the category, actually
Martech development services, in the version worth buying, are small pieces of purpose-built software that close the gap [Martech's Law](https://chiefmartec.com/2013/07/martecs-law-technology-changes-faster-than-organizations/?ref=martechtherapy.com) keeps widening between what stacks produce and what teams can act on. They sit on top of what's already there. They're additive. And the good ones are designed with an end date in mind, even if the platforms never catch up and the end date never arrives.
This is the work [Martech Foundry](https://martechfoundry.com/?ref=martechtherapy.com) exists to do. If the CMO's question at the top of this piece sounds like one you've been quietly asking your own procurement team, and getting back purchase orders for shapes that don't quite fit, that's probably why.
*(And yes, I did tell her none of the three circled results were right. She bought me a coffee for that, which felt fair.)*
Do you have any questions after reading this article?
Or need support with your Martech projects?
[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
### The pilgrimage to MartechDay, and what I’m actually watching for
URL: https://www.martechtherapy.com/the-pilgrimage-to-martechday-2026/
Last updated: 2026-04-27T10:02:24.000Z
There’s a sequence in Star Wars’ Andor where the pilgrims walk to the Eye of Aldhani. Once a decade, a meteor storm lights up the sky above a remote plateau. The faithful trek for days, sleep on rocks, and look up. It’s beautiful. It’s also, in the show, the perfect cover for a heist. Everyone’s distracted by the lights.
I keep thinking about that scene as May 5 approaches.
That’s when [Scott Brinker and Frans Riemersma debut the State of Martech 2026 report and the updated 2026 Marketing Technology Landscape on MartechDay](https://x.com/chiefmartec/status/2042201336935076208?ref=martechtherapy.com). It’s the closest thing our industry has to a recurring religious event. Tens of thousands of marketers, vendors, consultants, and operators all turn their faces toward the same supercut of category logos and survey data. There’s a webinar, a keynote, a flurry of LinkedIn posts dissecting the charts and tables. I’ll be there too. I’m not above the pilgrimage.
The interesting question isn’t what the lights show. It’s what happens in the quiet while everyone’s looking up.
## What the December warm-up already told us
The [Martech for 2026 report](https://content.martechday.com/martech-for-2026.pdf?ref=martechtherapy.com) dropped with some fanfare back in December, and most of the industry seems to have moved on already. That report is the warm-up act for what’s coming on May 5, and the numbers in it are doing real work.
The number I keep returning to is **90%**. Ninety percent of marketing organisations [say they use AI agents in some capacity](https://growthmethod.com/martech-2026-biggest-takeaways/?ref=martechtherapy.com). Sounds enormous. Then you read the next line → *only 23.3% have any agent in full production, and the rest are piloting, experimenting, or running them in narrow workflows with a human approving every output*. [McKinsey’s number for the same population is closer to 1% fully scaled](https://themartechweekly.com/tmw-259-martech-for-2026/?ref=martechtherapy.com), which tells you how loose the term has become. If your “AI agent” is a chatbot answering FAQs, you can claim production deployment with a straight face.
Brinker and Riemersma also introduced a frame I’ve used with three clients already. They split the marketing operation into a Factory and a Laboratory. The Factory protects current revenue. Deterministic, governed, boring in the way that production systems should be. The Laboratory is where you experiment with agents, test new approaches, accept that things will break. Different KPIs. Different tolerance for failure. Different people, too, probably.
Most organisations are trying to run both with one team, one set of metrics, and one governance model. That doesn’t work. I’ve watched it not work in those three client engagements this year alone.
## What I’m actually watching for on May 5
So what do I want the State of Martech 2026 report to tell me, beyond the headline meteor storm?
First, I want to see what’s happened to Brinker’s [composable canvas idea](https://www.martechtherapy.com/the-composable-canvas-and-the-cosmos/) since the [Databricks-sponsored paper](https://www.databricks.com/resources/ebook/new-martech-stack-ai-age?ref=martechtherapy.com) landed in March. He argued that the rigid stack is dissolving into a fluid canvas, with five classes of data (customer, company, content, code, control) sharing a unified foundation. It’s a thoughtful frame and a serious piece of work. It’s also, [as David Chan pointed out in his response on Medium](https://medium.com/@iamdavidchan/re-the-new-martech-stack-for-the-ai-age-b0e62a906b5a?ref=martechtherapy.com), a frame that emphasises the technical shift (into an even higher gear) more than the organisational one. Decision paralysis, governance, role ambiguity. The canvas is composable. The organization chart isn’t.
I want the May report to tell me whether companies are *actually* moving toward this canvas, or whether they’re nodding at it in slide decks and going back to arguing with their CDP vendor about identity stitching the next morning. My suspicion is the latter, and I’d love to be wrong.
Second, I want vertical breakdowns that go beyond the usual aggregate. Last year’s report leaned on overall percentages, which flatters everyone and informs no one. The interesting question is which industries are pulling ahead and why. I’d bet financial services and retail are further along, partly because they’ve had decisioning engines for two decades, partly because regulators forced them to invest in data lineage long before AI made it fashionable. I’d bet manufacturing, public sector, and parts of healthcare are still figuring out what their Martech stack contains. The gap between those camps is widening, not closing, and I want the data to show it. I’ve written before about [same stack, different worlds](https://www.martechtherapy.com/same-stack-different-worlds/), and I suspect 2026 will make that pattern impossible to ignore.
Third, and this is the one that matters most to the people I work with, I want to see what’s happening to roles.
## The middle is dissolving
Here’s where the AI conversation gets uncomfortable, and most reports skirt it. **The middle layer of the marketing operations organization is dissolving**. Not the senior strategist roles, which still need someone who can argue with the CFO. Not the genuinely technical roles, the engineers and the architects. The middle. The campaign manager who pulls a list, the analyst who builds the same weekly dashboard, the automation specialist who configures the email send. An agent can do a passable version of all three before lunch.
I’m not saying that’s good. I’m saying it’s happening. And the people sitting in those seats often don’t know it yet, because their managers haven’t figured out how to tell them.
What’s emerging in its place is messier than the LinkedIn thought leaders make it sound. AgentOps is the term [Joao Moura at CrewAI keeps using](https://martech.org/how-ai-agents-will-reshape-every-part-of-marketing-in-2026/?ref=martechtherapy.com), the discipline of running fleets of agents the way DevOps runs fleets of services. Some companies are calling it Agent Factory. Rebecca Corliss at GrowthLoop frames it as [marketing ops evolving into AI orchestration](https://thesmarketers.com/blogs/martech-trends-2026/?ref=martechtherapy.com). Whatever the title ends up being, the work is the same. Designing agent workflows, monitoring their cost and reliability, catching the 20% that’s wrong before it goes out the door. I’ve sketched my own version of this in [the new AI org chart](https://www.martechtherapy.com/new-ai-org-chart/), and the shape of it keeps shifting every quarter.
That last bit is the actual skill. Look, I’ll be honest, the marketers who’ll thrive in 2026 aren’t the ones who can write the prompt. The ones who’ll thrive are the ones who can read the agent’s output and instantly know which fifth of it is hallucinated, why, and what to do about it.
That’s domain knowledge. An engineer can build the agent, monitor its uptime, manage its cost. An engineer cannot tell you that a 4% open rate is fine for a B2B reactivation campaign and disastrous for a retail flash sale. That’s vertical-specific pattern recognition, layered with editorial judgement, built from years of seeing what good and bad actually look like in the work. Which is awkward, because the easiest way to build that knowledge was to spend a few years in the middle-layer roles that are now disappearing.
So we’re heading into a world where the entry-level rung of the ladder is being sawn off, and the senior rungs require a kind of expertise that can only be built by climbing the rung that no longer exists. I genuinely don’t know how that resolves, and I’m suspicious of anyone who says they do.
## The maturity question, honestly
[McKinsey’s October 2025 piece on rewiring martech](https://www.mckinsey.com/capabilities/growth-marketing-and-sales/our-insights/rewiring-martech-from-cost-center-to-growth-engine?ref=martechtherapy.com) put it plainly. Sixty-five percent of B2C organisations self-identify as developing or operational in martech maturity. When the researchers interviewed those same respondents, the proportion claiming operational maturity dropped significantly. People rate themselves higher than the evidence supports. This isn’t new. It’s been true for fifteen years.
What AI is doing is widening the gap between the organizations that built the muscle and the ones that bought the tools. Tools without muscle is the McKinsey finding restated. It’s also exactly what I’ve been arguing in [the martech readiness gap](https://www.martechtherapy.com/the-martech-readiness-gap/) for a while now. Structure, capability, and process matter more than the platform. The tooling has finally caught up to the point where bad organizations can no longer hide behind a Salesforce contract.
The leaders pulling away in 2026 are the ones who quietly invested in operational fluency while everyone else was buying licences. The laggards are still trying to AI their way out of an organization design problem.
## What I’ll be looking for in the lights
When May 5 rolls around and the report drops, I’ll be reading it for three things. Whether the composable canvas is real adoption or aspirational PowerPoint. Whether the vertical gaps are widening the way I think they are. And whether anyone is finally publishing data on what’s happening to the middle of the marketing organization chart, because that’s the conversation we keep avoiding.
The Eye of Aldhani is gorgeous. The pilgrims come back changed. But the real story of 2026 is happening in the shadows while everyone’s looking up.
If you’re reading the report next week and not sure what it actually means for your stack, your team, or your roadmap, that’s exactly the kind of confusion the [Martech Workshop](https://workshop.martechtherapy.com/?ref=martechtherapy.com) is built to work through. Otherwise, drop me a note. I’d genuinely like to compare notes on what you spot.
Do you have any questions after reading this article?
Or need support with your Martech projects?
[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
### Discovering Martech is like getting lost in London
URL: https://www.martechtherapy.com/discovering-martech-is-like-getting-lost-in-london/
Last updated: 2026-04-20T06:00:47.000Z
I’ve been doing this work for close to twenty years now.
Helping companies make sense of their data and marketing technology, guiding selections, fixing what doesn’t work, [occasionally building something in between](https://www.martechtherapy.com/announcing-piedmont-why-i-restructured-my-practice-around-building-not-just-advising/). It’s been a fairly consistent thread.
And recently… I found myself staring at it all thinking:
> *“I’m not entirely sure where I’d start anymore.”*
That’s not something I say lightly.
It has been half a year since the [State of Martech 2026 edition](https://chiefmartec.com/2025/12/heres-your-copy-of-our-martech-for-2026-report-free-and-ungated/?ref=martechtherapy.com) was published. It included a staggering 15,000+ tools.
Fifteen thousand.
At that point, it stops being a catalogue. It becomes something else entirely.
It reminded me of a city like London.
A city with thousands of streets, constantly evolving, expanding, rerouting. No one expects you to know every street. No one expects you to memorise every turn.
So why do we expect teams to understand a landscape with more than 15,000 tools?
The default reaction is predictable.
> “We’ll do our research.”
Open a few tabs. Read some reports. Book a few vendor demos. Maybe bring in a shortlist. Compare capabilities. Build a case.
It sounds reasonable. Structured, even.
But what I see in practice looks very different.
Ten tabs become fifty. Terminology starts blending together. Composable, CDP, AI, real-time, warehouse-native, zero-copy. I know that I am preaching to the choir here.
Each vendor tells a compelling story. Each one sounds like the right direction, especially when you listen long enough. At some point, it stops being exploration. It becomes noise.
The problem isn’t a lack of information. There’s more information than anyone can reasonably process.
The real challenges reveal themselves when that information needs to turn into a decision.
This is where the city metaphor starts to hold.
Imagine navigating a city like London.
You have a few options.
You follow GPS. You rely on memory. You recognise patterns from places you’ve been before.
All of them work. Until they don’t.
Maps constantly need updating.
GPS can be outdated or overly optimistic. Memory only works if the city hasn’t changed. Pattern recognition can trick you into thinking you’ve been here before.
And the city keeps changing while you’re moving through it.
New roads. Roadworks. Closures. Detours.
Even people who know the city well still check a map.
Not because they’re lost, but because the environment isn’t static.
That’s what Martech feels like right now. Not just large, but constantly shifting.
When I look at the clients I’ve worked with recently, there’s a pattern that repeats itself more often than not.
It usually starts with a vague discomfort.
Something isn’t working. The stack isn’t delivering what it was supposed to. Capabilities feel limited, or disconnected. Or a manager keeps dropping the term AI in every discussion.
That’s the moment where exploration begins. And this is where things accelerate quickly.
Teams start reading. Vendors get involved. New concepts enter the conversation. AI shows up in every corner. Composable suddenly becomes a topic, often without a shared understanding of what it actually means in their context.
At this point, most teams hit a fork in the road.
Sometimes they decide to do nothing. Stick with what they have, because the alternative feels too uncertain.
Sometimes they move forward, but under pressure. The best story wins. The clearest narrative wins. Not necessarily the best fit.
And sometimes they move quickly, at an exhaustive pace, without bringing the right people into the conversation. Marketing, data, IT, procurement, all slightly out of sync, each looking at a different part of the map.
The outcome is rarely clean.
More often, it leads to another layer of complexity.
It’s tempting to frame this as a knowledge problem.
If we just understood the tools better, if we just had more clarity on what’s out there, things would improve.
But that doesn’t fully capture it.
It starts as a knowledge problem.
It quickly becomes a decision problem.
Or maybe more accurately, a shared understanding problem.
I’m heading to [AntiCon in London](https://www.lxahub.com/events/anti-conference?ref=martechtherapy.com) soon.
A room full of smart people, strong opinions, and a lot of energy around AI, data, and transformation.
I’m looking forward to it.
But I’m not going there to learn what’s new.
There’s no shortage of “new”.
I’m going to understand why, despite all of this progress, it still feels so hard for teams to navigate.
Because that’s the part that doesn’t get enough attention.
Even experienced people don’t have the full picture.
We all rely on tools, frameworks, vendor narratives, peer input. We build partial maps and try to move forward with them.
And that’s fine.
It’s probably unavoidable.
Which also means the goal isn’t to know everything.
It’s to make better decisions with incomplete information.
To understand which streets are worth taking, and which ones you can safely ignore.
To recognise when you’re being rerouted, and whether that actually gets you closer to where you want to go. Where the number of options stops being helpful and starts getting in the way.
There’s probably a simpler way to approach that.
I’ll share more on that soon.
Do you have any questions after reading this article?
Or need support with your Martech projects?
[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
### Announcing Piedmont: why I restructured my practice around building, not just advising
URL: https://www.martechtherapy.com/announcing-piedmont-why-i-restructured-my-practice-around-building-not-just-advising/
Last updated: 2026-08-31T13:10:14.000Z
If you read [my post at the end of last year](https://www.martechtherapy.com/i-didnt-plan-to-build-a-martech-product-business-but-here-we-are/), you know that my client work changed toward the end of 2025.
It wasn't dramatic. No single conversation triggered it. But looking back at December, roughly 20% of what I was doing had moved from strategy and advisory into actually building things. Custom data apps, operational tools, activation layers that clients needed but couldn't find off the shelf. By April 2026 that number was closer to **50%**.
When half your work has subtly become something different from what your practice was named for, it's time to pay attention.
## What the market is telling us
Scott Brinker and Frans Riemersma's State of Martech Report puts language to something I've been observing in client engagements for a while now. The micro-SaaS wave is real. Niche, precision-built applications that solve specific operational problems are becoming a serious part of how mature Martech stacks get completed, not replaced, completed.
The logic is straightforward. The big platforms do the heavy lifting. But the gaps between them, the exact requirements that no vendor has an incentive to solve for the median use case, those gaps are where the real operational challenge lives. And for a growing number of organisations, the low-hanging fruit sitting in those gaps is too obvious to keep ignoring.
I've been building in that space for about a year without a clean name for it. A recruitment client needed mid-process postcode validation during candidate screening. Typeform doesn't do that. Building it, production-ready, took three weeks. The alternative was a manual process running indefinitely. That's a precise problem.
Precision apps. That's the term I'm using for this category of work. Tight scope, exact fit, built on existing data and infrastructure, handed over to run without me.
[The dirty truth about vibe coding in MartechAfter \~1000 hours vibe coding, I’ve learned something surprising. AI makes building software easier. But the moment your tool actually works… the real work begins. Hosting. Security. Monitoring. Maintenance. Are we replacing SaaS, or just redistributing responsibility? Curious how others see this.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/the-dirty-truth-about-vibe-coding-in-martech/)
z
## What this means for the practice
Martech Therapy isn't going anywhere. If anything, Martech's Law makes the advisory work more relevant, not less. Technology keeps advancing faster than most organizations can absorb, and the gap between stack ambition and operational reality is wider than it's ever been. A lot of companies still need to do the strategic groundwork before they're ready to build anything.
But the companies that have done that work, including some past Martech Therapy clients, are now hitting a different wall. They know what they need. They've looked at what's available. Nothing bends far enough. That's a different conversation and it needed a different practice to have it in.
So I built one.
**Martech Foundry** is the build and delivery practice. Custom data integration and activation solutions, precision apps, operational tools. Scoped, delivered, and handed over. If I'm still embedded a year after I started, I haven't done my job well enough.
[Martech FoundryCustom data integration and activation solutions for organisations that have outgrown what off-the-shelf software can do. Built in weeks. Handed over to run without me.Martech FoundryMatthew Niederberger](https://www.martechfoundry.com/?ref=martechtherapy.com)
**Martech Therapy** remains the strategy and advisory practice. [CDP assessments, fractional Head of Martech engagements, RFP support](https://www.martechtherapy.com/what-i-do/), and the thinking that needs to happen before you're ready to build. In many cases Martech Therapy is still the right starting point, and for clients who move through it and find themselves ready to build, Martech Foundry is the natural next step.
Both practices now sit under **Piedmont**, the parent entity I've registered to house the full scope of the work. Netherlands-based, working globally, vendor-agnostic by design.
## Why Piedmont
A few people I bounced the idea around with have asked about the name.
Piedmont is the French translation of my surname, Niederberger. *Nieder* means low or foot, *berg* means mountain. Literally: at the bottom of the mountain.
But the reason it felt right as a name goes beyond the personal etymology.
The foot of the mountain is exactly where most of the organizations I work with find themselves. They can see where they need to get to. They understand the gap between their current Martech reality and what's possible. Some of them have been standing at the base for a while, looking up, not quite sure where the path starts or whether they have what it takes to climb it.
That is the moment I work in. Not at the summit, not halfway up with a map telling someone else what to do. At the foot, with the people who need to make the ascent, helping them move.
Piedmont felt like the honest name for that work.
## Why now
Honestly, because the work already looked like this. The restructuring is just the practice catching up with what clients were already asking for.
The 20% to 50% uplift didn't happen because I decided to pivot. It happened because organizations started arriving with a specific type of problem, and the market signal was clear enough that ignoring it would have been the wrong call.
The Piedmont structure gives both practices the space to be what they actually are, distinct but related, each with its own positioning, its own client conversation, and its own way of measuring success. The through-line is the same across both: close the gap between what your Martech can do and what it actually does, as quickly and durably as possible.
## What stays the same
The independence. Some of my work still comes from vendor recommendations based on their trust in my work and perspective, and I intend to keep it that way.
The handover model. Every Martech Foundry engagement ends with the client's team running the solution independently. Every Martech Therapy engagement ends with a client that doesn't need me to keep the lights on.
And the writing. The podcast, this blog, the frameworks. That's how I stay sharp and how I stay honest about what's actually happening in the market. That continues under Martech Therapy and the Piedmont name.
If you're curious about the build side of the work, Martech Foundry is at [martechfoundry.com](https://www.martechfoundry.com/?ref=martechtherapy.com).
If you're still working through the strategic layer, Martech Therapy is where that conversation lives.
And if you want to understand how the two fit together, [bypiedmont.com](https://www.bypiedmont.com/?ref=martechtherapy.com) is the starting point.
Curious whether anyone else is seeing the same shift. The micro-SaaS signal in the State of Martech Report felt significant to me. Would be interested in how it's landing for others managing complex stacks.
Do you have any questions after reading this article?
Or need support with your Martech projects?
[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
### Finding the Martech Goldilocks zone
URL: https://www.martechtherapy.com/finding-the-martech-goldilocks-zone/
Last updated: 2026-03-30T07:59:46.000Z
If you’ve followed my writing for a while, you’ve probably noticed I have a bit of a thing for astronomy metaphors. We’ve talked about [entropy creeping into martech stacks](https://www.martechtherapy.com/the-real-martech-roi-equation/), and how data gravity quietly pulls everything toward the warehouse, turning tools into satellites orbiting a growing center of mass.
So let’s add another one to the collection.
The Goldilocks zone.
And yes, before anyone jumps in, I know. For some, Goldilocks is a fairy tale about porridge, chairs, and questionable home invasion ethics. For others, it’s an astronomical concept, describing the narrow band around a star where conditions are just right for life to exist.
Both are useful here.
Because if you’ve ever been involved in selecting martech tools, you’ll know the feeling. One solution is too complex. Another is too limited. And somewhere in between sits something that feels… almost right.
Almost.
## **Not too hot, not too cold**
The idea behind the Goldilocks zone in astronomy is simple. Too close to the star and everything burns. Too far away and everything freezes. Life only emerges in that narrow, balanced space where conditions align.
Now replace “planet” with “martech tool.”
In today’s market, with well over 15,000 solutions, finding the right fit can feel like staring into the night sky. Endless options. Shiny promises. And somewhere out there, you assume, there must be something that fits your needs perfectly.
That’s where things get interesting.
Because in most RFPs or selection processes, teams aim for 100% requirement coverage. Every box ticked. Every feature accounted for. The perfect match.
In practice, that almost never exists.
What you find instead are tools that hit 90 to 95 percent. And then the debate starts. Do we accept the gap? Do we customize? Do we keep searching for something better?
This is where the Goldilocks thinking becomes useful. Not as a compromise, but as a reframing. The goal isn’t perfection. It’s viability.
## **When things get too hot**
Let’s start with the “too hot” side of the equation.
These are the solutions that promise everything. Endless flexibility, deep customization, composable architectures, full control. On paper, they look like the future. And in many ways, they are.
But they come at a cost.
I’m working with a client right now who recently moved to Databricks. A solid move, especially if you believe in the gravitational pull of data warehouses. The question that followed was a familiar one: what do we do with the rest of the stack?
Do we go composable, building around the warehouse with best-of-breed components? Or do we lean into an all-in-one platform like Braze or Iterable?
We explored both. The composable route made sense architecturally. Clean, flexible, future-proof. But when the teams saw the demos, the reaction was telling.
They understood it. They appreciated it. But they didn’t feel comfortable with it.
Perceived complexity matters. User experience matters. The confidence of the people who have to operate the system every day matters.
A solution can be technically perfect and still fail the Goldilocks test because it’s simply too hot to handle.
## **When things are too cold**
On the other side, you have solutions that are too simple.
These are the tools that are easy to adopt, quick to implement, and often very appealing in demos. Clean interfaces, guided workflows, fast time to value.
But over time, limitations start to show.
Data models that don’t quite fit. Activation options that feel constrained. Workarounds creeping in. Teams exporting data just to re-import it somewhere else.
You gain ease of use, but you lose flexibility.
And slowly, entropy starts creeping back in. Extra tools get added. Processes become fragmented. The simplicity you started with begins to erode.
Too cold might feel comfortable at first, but it rarely sustains long-term growth.
## **The “just right” problem**
So what does “just right” actually look like?
Here’s the uncomfortable truth. It’s rarely about the tool alone.
One of the patterns I keep seeing is that companies invest heavily in technology, but underestimate the human side. Skills, training, ownership, governance. The things that determine whether a tool actually gets used properly.
There used to be a rough rule floating around. Spend 20 percent on technology and 80 percent on people.
I’m not sure the exact ratio matters anymore, but the principle still holds. A powerful platform in the hands of an unprepared team creates friction. A simpler tool with a confident, well-supported team often performs better.
So the Goldilocks zone isn’t just about feature sets. It’s about fit across three dimensions at once.
The **technology** itself.
The **people** who use it.
And the **processes** around it.
Miss one of those, and things start drifting out of orbit.
[Before you deploy your CDP, train your crewCDP projects test more than tech -> they test teams. What military work-ups taught me about readiness, response, and Martech project success.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/before-you-deploy-your-cdp-train-your-crew/)
## **Looking up at the sky**
This is where I can’t resist bringing in one more space reference.
When you look at the scale of the martech landscape today, it does start to resemble [something like a Fermi paradox](https://en.wikipedia.org/wiki/Fermi%5Fparadox?ref=martechtherapy.com). With so many tools out there, statistically, there should be countless “habitable” solutions.
And yet, so many companies struggle to find one that actually works for them.
Not because the tools don’t exist. But because the conditions aren’t aligned.
Wrong expectations.
Misaligned teams.
Overestimated capabilities.
Underestimated complexity.
In astronomy, a planet doesn’t become habitable just because it sits in the right zone. It also needs the right atmosphere, composition, and stability.
Martech isn’t that different.
## **Martech isn’t a fairy tale**
So where does that leave us?
Martech can sometimes feel like a fairy tale. Promises of transformation, seamless experiences, and perfectly orchestrated journeys. Vendors telling stories where everything just works.
Reality is a bit messier.
Finding your Goldilocks zone takes time. It takes trade-offs. It takes a clear view of your own organization, not just the technology in front of you.
And it takes accepting that “just right” doesn’t mean perfect. It means workable. Sustainable. Aligned with where you are today, while leaving room for where you want to go.
The good news is that this isn’t luck. It’s not something you stumble into.
With the right balance of effort, investment, and honest assessment, that zone is absolutely within reach.
The question is simply this.
Are you still searching for the perfect porridge, or are you ready to settle into something that actually lets you sleep at night?
****Your stack isn’t failing.**
It’s absorbing more effort than it used to.
The Second Law of Martech scan helps you see where organisational energy is being spent just to keep things working, and where that cost is starting to crowd out real value.
[Start your FREE Entropy Scan ](https://secondlaw.martechtherapy.com/?ref=martechtherapy.com)
### The Martech Readiness Gap
URL: https://www.martechtherapy.com/the-martech-readiness-gap/
Last updated: 2026-03-24T07:36:48.000Z
In my last piece, I wrote about [Scott Brinker's composable canvas](https://www.martechtherapy.com/the-composable-canvas-and-the-cosmos/) and the distance most organizations still have to travel before they can operate that way. I ended with the observation that data gravity and organizational distance are two forces that haven't quite caught up with each other yet, and that the gap between them isn't a problem to solve in one go, it's something to navigate.
That question, how far are we from being able to operate this way, has kept coming up in conversations since. So this piece is an attempt to name what's actually sitting inside that distance. Because I don't think it's mainly technical. And I don't think it's mainly about architecture.
Tell me if the following sounds familiar...
> A company has invested seriously in its stack. The tools are credible, sometimes genuinely sophisticated. The team is capable. Leadership is engaged. And yet something keeps not working. Programs stall, and platforms underdeliver. The same conversations happen in different meetings. A new vendor gets brought in, things improve for a quarter, and then the same friction returns wearing slightly different clothes.
What's actually happening is that the organization has moved faster than it was ready to. Not recklessly, not stupidly. In many cases, entirely reasonably given the pressure it was under. The market kept offering new answers, AI, composable architectures, warehouse-native platforms, real-time decisioning, and the gap between what was possible and what competitors might be doing with it created a specific kind of anxiety. So decisions got made. Tools got bought, and transformations got launched.
That distance between what an organization believes it's ready for and what it can actually sustain in practice is what I've started calling the **Martech Readiness Gap**. It's not a new problem. But it's getting wider, faster, and more expensive to ignore.
## **Why Martech's Law makes this worse**
If you've been following my writing for a while, you'll know I keep coming back to [Martech's Law](https://chiefmartec.com/2016/11/martecs-law-great-management-challenge-21st-century/?ref=martechtherapy.com). Scott Brinker's observation that technology changes faster than organizations can absorb it was originally offered as a comment on the pace of the vendor landscape. What it describes in practice is the structural condition that produces the readiness gap in the first place.
[Martec's Law by Scott Brink](https://chiefmartec.com/2016/11/martecs-law-great-management-challenge-21st-century/?ref=martechtherapy.com)
I've written before about what I called the [Second Law of Martech](https://www.martechtherapy.com/extending-martechs-law-why-growth-leads-to-decay/), the idea that stacks don't collapse, they just ask for more. More meetings, more exceptions, more human energy spent on cognitive load, coordination overhead, and the quiet maintenance work of preventing drift from becoming visible failure. That rising cost is **entropy** in its most operational form. What I've come to see more clearly since writing that piece is that entropy is downstream of the readiness gap. The gap is what produces the condition in the first place. Organizations that move faster than they're ready to find that the energy required to hold everything together just keeps climbing, and at some point that energy crowds out the actual work.
I asked a version of this question in an earlier piece on [the real Martech ROI equation](https://www.martechtherapy.com/the-real-martech-roi-equation/):
> How much energy are you spending holding the sandcastle together, and is it giving you the ROI you think it is?
At the time I framed it as a financial question. What I've come to understand since is that it's really a readiness question. The energy spent compensating for a gap that was never honestly assessed is the hidden line item that never appears in the business case but always shows up in the results.
The vendor ecosystem is not slowing down. If anything, AI has accelerated the rate at which new capabilities are being surfaced, marketed, and made to feel urgent. Every six months there's a new architecture to understand, a new category to evaluate, a new risk of being left behind. For organizations already struggling to operate what they have, that pressure doesn't produce better decisions. It produces faster ones. And faster decisions, made before the foundations are ready, is exactly how the gap grows.
[Extending Martech’s Law: why growth leads to decayMartech stacks rarely fail. They decay. Over time, more human effort is required just to keep the same outcomes. This article explores why ROI erodes quietly, how entropy shows up in real stacks, and why I built the Second Law of Martech scan.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/extending-martechs-law-why-growth-leads-to-decay/)
## **What it actually looks like**
The readiness gap rarely announces itself clearly. It tends to show up as a collection of symptoms that get misread as separate problems.
A CDP that costs more than it produces. A personalization program that never quite gets to personalization. A data team and a marketing team that both work hard and somehow always want different things. A transformation program that delivers a new platform but inherits all the old confusion. A stack that everyone agrees is too complex but nobody can agree on how to simplify. I am sure we can all share an example.
I walked into something close to this at a major UK broadcaster not long ago. They hadn't come looking for a new platform. They came because the current setup had hardened into something expensive to run, hard to change, and oddly unaccountable. A major architectural migration had already happened. On paper it should have simplified things. In practice it had introduced more interfaces and more ambiguity. Different teams had their own versions of the truth, their own diagrams, their own priorities. The technology wasn't the problem. The organization hadn't been ready to absorb the change it had already made.
I've seen a version of this across sectors, insurance, media, healthcare, financial services. The surface problems look different. The root cause is consistent and sector agnostic.
## **The uncomfortable part**
If you've read my piece on [why chasing shiny CDP features leaves marketers feeling like imposters](https://martech.org/why-chasing-shiny-cdp-features-leaves-marketers-feeling-like-imposters/?ref=martechtherapy.com), over on MarTech.org, you'll recognize what comes next.
There's a psychological dimension to this that the industry tends to sidestep. Teams under this kind of pressure develop a specific kind of insecurity. I wrote there about the sandcastle dynamic, how vendors keep raising the waterline with new features and AI capabilities while most practitioners are still doing the genuinely hard work of getting reliable data out the door. The cruel irony is that the basics aren't basic at all. But in a market that celebrates the bleeding edge, doing foundational work well feels like falling behind.
[Why chasing shiny CDP features leaves marketers feeling like imposters | MarTechMarketers often feel left behind in the CDP race, but the real success lies in mastering the fundamentals that keep data reliable and campaigns durable.MarTechMatthew Niederberger](https://martech.org/why-chasing-shiny-cdp-features-leaves-marketers-feeling-like-imposters/?ref=martechtherapy.com)
Read my full article on Martech.org
That insecurity distorts decision-making in a predictable way. Reactive buying, over-scoped projects, and a tendency to adopt the language of sophistication before the operating model can support it. AI-native, composable, real-time, agentic, **these become identity claims rather than operational realities**. And the gap between the claim and the reality is precisely where the money disappears.
I've also noticed, and this came up repeatedly in conversations while writing for MarTech.org last year, that [most organizations spend more on unused SaaS features than on training the people managing them](https://martech.org/why-martech-teams-need-diagnostic-talent-in-2026/?ref=martechtherapy.com). They invest in tooling, integrations, orchestration layers, and AI add-ons, but when you ask about the budget for capability development the answer is usually silence. That imbalance is both a symptom of the readiness gap and one of the reasons it persists.
[Why martech teams need diagnostic talent in 2026 | MarTechMost martech friction comes from misinterpretation. The right talent can distinguish useful complexity from decay and restore team confidence.MarTechMatthew Niederberger](https://martech.org/why-martech-teams-need-diagnostic-talent-in-2026/?ref=martechtherapy.com)
Read my full article on Martech.org
## **Where the work actually sits**
Getting honest about the gap requires holding two things at once. The ambition is legitimate. Wanting to operate a modern, effective Martech stack is a reasonable thing to want. And the current operating model may not be ready to support it yet, which means the next expensive move is likely to produce the same result as the last one.
In my experience the gap tends to show up consistently across three dimensions: **how an organization is structured** to make and sustain Martech decisions, **what it's genuinely capable of operating**, and **whether its processes are reliable enough** to support the things it wants to do. Each of those deserves more than a sentence, so I'll get into them properly in the next piece. But taken together they tend to explain most of what looks like a technology problem from the outside.
If you've seen this challenge in your own organization, or if you're currently sitting inside one of those stalled programs wondering why the new platform didn't fix it, I'd genuinely like to hear about it. Drop a comment or [find me on LinkedIn](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com). This is where most of the real work in Martech still happens, and not enough of us are talking about it honestly.
****Your stack isn’t failing.**
It’s absorbing more effort than it used to.
The Second Law of Martech scan helps you see where organisational energy is being spent just to keep things working, and where that cost is starting to crowd out real value.
[Start your FREE Entropy Scan ](https://secondlaw.martechtherapy.com/?ref=martechtherapy.com)
### The composable canvas & the cosmos
URL: https://www.martechtherapy.com/the-composable-canvas-and-the-cosmos/
Last updated: 2026-03-20T18:39:10.000Z
I’ve been reading Databricks' and Scott Brinker’s recent paper on [the New Martech Stack for the AI age](https://www.databricks.com/resources/ebook/new-martech-stack-ai-age?ref=martechtherapy.com). It’s one of those pieces that, just like studying astronomy, feels both clarifying and slightly unsettling at the same time.
Clarifying, because it puts words to something many of us have been feeling for a while. The stack is creaking. Integration is still eating time and energy. Data sits everywhere, but rarely works together in the way we need it to. So, the idea of moving toward a shared data foundation, with agents operating across it, makes intuitive sense.
And unsettling, because it quietly assumes a starting point that not every organization recognizes.
> The direction is right. The distance is underestimated.
## **A future that already exists**
What Scott outlines is not hypothetical at all. Parts of this architecture are already in place in some organizations.
A unified data foundation where customer, company, and content data come together with a semantic layer that creates shared meaning. Feeding agents that can act across systems, not just report on them, and decisioning that moves closer to real-time, informed by context rather than predefined journeys.
The evolution of martech from a rigid stack to a composable canvas. (Source: [Databricks](https://www.databricks.com/resources/ebook/new-martech-stack-ai-age?ref=martechtherapy.com))
If you’ve spent time in larger enterprises or data-mature environments, this will feel familiar. You probably have the “been there, done that” t-shirt. The pieces are there, and the shift is already happening.
The paper, or ebook as it is called (probably because of its length), captures that trajectory well. It gives structure to what can otherwise feel like a fragmented set of trends that we all seem to be struggling over to apply in our daily professional lives: AI, composability, data platforms, and agentic workflows.
It paints a compelling picture.
## **The starting point matters**
Where things get more complex is when you look at where most organizations start. In many cases, the reality looks more like this:
Customer data is spread across CRM, ESP, analytics, and a handful of point solutions, not to mention teams and definitions that vary depending on who you ask. Dashboard insights that don’t quite align and integrations that work, until they don’t... usually on Friday afternoons.
The idea of a shared data foundation is not unfamiliar. It’s just not fully formed yet.
The same goes for skills and ownership. Many marketing teams operate with a small core of specialists, supported by vendors and agencies. Data engineering and model governance are not always embedded capabilities and decision-making is often distributed across teams and pay grades, each with its own priorities and metrics.
None of this is unusual. It shouldn’t be if you have soent time in the frontlines of Martech. It’s just how most organizations have grown.
But it does mean that the composable canvas is not something you step into overnight.
## **Distance, and gravity**
There’s a concept in astronomy that I’ve always found fascinating. Parts of the universe are moving away from each other so quickly that, even at the fastest possible speed, cosmic expansion will never allow them to interact. There are parts we will never see because the expansion exceeds the speed of light.
Martech can feel a bit like that right now. [Martec's Law](https://chiefmartec.com/2013/06/martecs-law-technology-changes-exponentially-organizations-change-logarithmically/?ref=martechtherapy.com) in overdrive.
Let's acknowledge that data gravity is real. There’s a clear pull toward bringing data together, creating shared context, and building systems that can act on it. At the same time, organizational distance is just as real. Different teams, different tools, different ways of working, all evolving at their own pace.
Scott’s composable canvas describes what happens when those forces align.
In many organizations, the reality is that they are still catching up with each other.
[Extending Martech’s Law: why growth leads to decayMartech stacks rarely fail. They decay. Over time, more human effort is required just to keep the same outcomes. This article explores why ROI erodes quietly, how entropy shows up in real stacks, and why I built the Second Law of Martech scan.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/extending-martechs-law-why-growth-leads-to-decay/)
## **The broader market reality**
There’s also a practical dynamic at play in the industry itself.
A lot of the conversation around composability, data platforms, and AI-enabled marketing is shaped by what is possible at the upper end of the market. Large enterprises with dedicated data teams, significant investment capacity, and the ability to rethink architecture over multiple years.
Consultancies and vendors naturally gravitate toward these environments. This is where the big contracts are ripe for the picking. At the tip of the market, the impact becomes visible, projects are transformative, and outcomes are easier to showcase. Full circle, all in time for the next wave of candidates.
For the rest of the market, the path tends to look more incremental and uphill. That doesn’t make the vision less relevant, but it changes how it needs to be approached.
## **Becoming composable over time**
What I find interesting is that you don’t need the full canvas to start working in a more composable way. That is pretty much a composable selling point.
In practice, progress often begins in smaller, more focused areas.
A team improving how activation connects to data, without rebuilding the entire foundation or introducing agent-assisted workflows in a specific use case. Bringing more consistency into how metrics are defined and used across teams or creating pockets of decisioning that are closer to real-time.
These steps don’t immediately transform the architecture overnight; however, they do start to change how the organization operates.
Over time, those changes compound. Just not at speeds we are used to seeing in demos or whitepapers.
The composable canvas, eventually, becomes less of a target state and more of a direction of travel.
[Contextual CDPs: Composable, not chaoticPart 5 of 6: How to make composable CDPs context-aware without chaos. Sequence, scaffolding, and explainability are the new essentials.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/contextual-cdps-composable-not-chaotic/)
## **Where this leaves us**
**The New Martech Stack of the AI Age** does something valuable. It gives the industry a shared reference point for where things are heading. It connects a number of important developments into a coherent model.
At the same time, it nevertheless raises a question that I think is worth sitting with:
> If this is the direction, how far are we from being able to operate this way?
For some organizations, the answer is “not that far.”
For many others, there’s still work to do in how data is structured, how teams collaborate, and how decisions are made.
That gap isn’t a problem to solve in one go. It’s a collaborative journey.
And that’s where most of the real work in Martech still happens.
## **A final thought**
In theory, everything can be connected. Data can flow, agents can act, and systems can adapt in real time. In this day and age, marketing technology is not the challenge.
In practice, progress depends on how close an organization is to being able to support that.
The composable canvas is a useful map.
Most of us are still somewhere on the road toward it.
[](https://www.martechstackbuilder.com/?ref=martechtherapy.com)
Start building your Martech Stack designs today 👇🏻
[SIGN UP FOR FREE ](https://www.martechstackbuilder.com/?ref=martechtherapy.com)
### Breaking the Martech Mould
URL: https://www.martechtherapy.com/breaking-the-martech-mould/
Last updated: 2026-03-10T12:55:00.000Z
Last week I attended a conference with my wife that had absolutely nothing to do with marketing technology.
She is finishing her degree to become a teacher in the fine arts, and her research focuses on a topic that has been quietly worrying educators for years: school dropout rates and the role creativity can play in preventing them.
The numbers in the Netherlands are confronting. Roughly **20% of school-age children are considered neurodiverse** in some form. Around **70,000 children are currently not attending school**, and another **280,000 are at risk of dropping out**.
Not because they lack intelligence or creativity, but because they struggle to fit into the system as it currently exists.
The conversation at the conference repeatedly returned to a simple observation: many education systems were designed around a very specific mould of learning and behavior. Students who fit that mould tend to thrive, while students who don’t often find themselves labeled as distracted, difficult, or disengaged.
Listening to the discussions, I found myself thinking about a talk that has stayed with me for years. [Sir Ken Robinson](https://en.wikipedia.org/wiki/Ken%5FRobinson%5F%28educationalist%29?ref=martechtherapy.com) once argued that education systems were largely designed during the industrial era, prioritizing standardization, hierarchy, and predictability. In his famous TED talk, he said something that still resonates:
> “All children are born artists. The problem is to remain an artist as we grow up.”
His broader point was that systems optimized for standardization often struggle to accommodate the full range of human capability.
Sitting in that conference room, a strange thought occurred to me. I’ve seen systems like this before.
Just not in schools.
## **The Martech Mould**
If you have worked in marketing technology for a while, like I have, you have probably experienced a familiar moment during a product demo, or a random pitch at a conference. Someone asks a deceptively simple question:
> *“Can the platform do this?”*
There is usually a short pause before the answer arrives (*which in itself is often the answer*).
> “Well… not exactly. But there’s a workaround.”
Most Martech professionals know how to translate that sentence. The platform can probably solve **70–80% of the problem**, while the remaining **20% lives somewhere else**.
That missing piece might take the form of a custom integration, a middleware workflow, or a small script quietly connecting two systems that were never designed to talk to each other. Sometimes it’s a spreadsheet nobody wants to admit still exists. Sometimes it’s a manual step that became “temporary” five years ago, that often gets performed in the weekends, too...
And yet organizations still pay **100% of the license cost**.
The platform works. Often very well. But it rarely fits the organization perfectly.
This isn’t a flaw in the software, but an actual design constraint of SaaS.
## **Why SaaS standardizes the middle**
SaaS products have to serve thousands of companies across industries, regulatory environments, and internal processes. To survive at that scale, platforms optimize for the **most common needs of the largest number of customers**.
In other words, they standardize the middle of the market.
That is exactly what makes them successful. **Predictability** keeps support manageable, **consistency** keeps the product stable, and **shared architecture** keeps costs under control.
But the consequence is that the edges of the problem space often remain unsolved.
Those edges are where companies begin building workarounds. Over time these workarounds accumulate into what many teams quietly recognize as the **shadow stack**.
Small pieces of glue holding everything together.
Zapier workflows - **been there**
Webhook handlers - **done that**
Custom scripts - **did it last week**
Data transformations - **don't get me started**
**...**and manual steps that somehow became part of the official process.
None of these were part of the original architecture. They appeared because the platform solved **most of the problem**, just not all of it.
## **The last 20%**
The uncomfortable realization for many organizations is that the missing 20% is often the most important part.
That gap frequently represents the workflows that make a company unique. The unusual lead routing logic with custom API calls that reflects how the sales team actually works. The attribution model with cookie extension scripts that better matches how the business sells. You get the picture.
These edge cases are not accidents at all. Don't be misled. They are the result of organizations adapting to their environment. Rowing with the oars you were given.
Which creates a stranglehold on progress.
SaaS platforms provide the infrastructure that makes modern marketing possible. But differentiation rarely happens in the middle of the bell curve.
It happens in the edges.
## **Modular stacks and the rise of micro tools**
Over time, the industry has responded to this problem in two different ways: by making stacks more modular, and by building smaller tools to fill the remaining gaps.
**The first response is architectural**. Composable approaches aim to make Martech stacks more modular, allowing components to be connected, replaced, or extended more easily. Instead of forcing every function into a single platform, systems can communicate through APIs and shared data layers.
Composable architecture does not remove the 20% gap, but it does make the stack easier to extend when necessary.
**The second response is more practical**. Companies begin building **small tools** that solve the specific problems their platforms cannot address. These tools are rarely grand platforms of their own. More often they are focused utilities that perform one task extremely well.
You could call them internal apps, extensions, or micro-SaaS if they eventually become products. The label matters less than the reason they exist: standardized platforms stop just short of what the organization actually needs.
## **AI makes the edges easier to build**
This is where the current wave of AI-assisted development becomes interesting.
Over the past 6-months I have spent close to **1000 hours experimenting with vibe coding**, mostly on commercial initiatives. One of them is the [Martech Stack Builder](https://www.martechstackbuilder.com/?ref=martechtherapy.com), an application designed to help people explore Martech architectures and vendor combinations.
Martech Stack Builder, 100% built using AI. (managed by a human 😉)
Projects like this taught me something quickly: building the missing 20% is often easier than it used to be.
But it introduces a different kind of responsibility.
In a [previous article I wrote about the hidden trade-offs behind vibe coding](https://www.martechtherapy.com/the-dirty-truth-about-vibe-coding-in-martech/). The short version is simple. When you build your own tools, you gain flexibility but you also inherit the operational burden.
Buying software means someone else carries that responsibility.
Building means you do.
[The dirty truth about vibe coding in MartechAfter \~1000 hours vibe coding, I’ve learned something surprising. AI makes building software easier. But the moment your tool actually works… the real work begins. Hosting. Security. Monitoring. Maintenance. Are we replacing SaaS, or just redistributing responsibility? Curious how others see this.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/the-dirty-truth-about-vibe-coding-in-martech/)
Read more about my vibe coding for Martech insights.
What AI changes is the accessibility of the edge. The strange little applications that would once have been too expensive, too niche, or too annoying to justify are becoming much more realistic to build.
## **The neurodiversity parallel**
Listening to educators talk about neurodiverse students made that dynamic feel familiar, putting it mildly.
Many of the children discussed at the conference are highly capable. Creative, curious, and often intensely interested in specific subjects. Yet they struggle within systems designed around a narrow definition of how learning should look.
Ken Robinson summarized the problem with a different observation:
> “Creativity is as important in education as literacy, and we should treat it with the same status.”
Yet many education systems still prioritize standardization over diversity of thinking. The result is a system that works very well for some students, and poorly for others.
Martech platforms sometimes behave in a similar way. They optimize for the statistical average.
But organizations rarely win by behaving like the statistical average.
## **Breaking the mould**
Entrepreneurship often begins at the edges of these systems.
Companies like Hightouch emerged, in my opinion, because (probably '*neuro diverse*') founders looked at the existing Martech landscape and realized the mould no longer fit how modern data teams worked. Warehouse-native thinking challenged assumptions about where customer data should live, while composable architectures questioned whether a single platform should control every function.
These companies did not succeed because the existing tools were bad. They succeeded because the mould had become too rigid.
Interestingly, the idea of breaking the mould even shows up in pop culture. Smash Mouth captured the sentiment rather bluntly in *All Star*:
> “Break the mould.”
It was meant as encouragement to think differently. Apple, anyone?
And perhaps that is exactly what is happening in Martech today.
## **Will AI break the mould?**
AI-assisted development and vibe coding are making it easier than ever to build small tools. That raises an interesting question.
> Will AI break the Martech mould entirely, or will it simply make companies more efficient within the existing one?
The answer is probably somewhere in between.
AI lowers the cost of experimentation and allows teams to explore solutions that previously required significant development resources. But it does not eliminate the responsibilities that come with running software.
Systems still need to be maintained. Architectures still need to be designed thoughtfully. Operational complexity still accumulates over time. And security... I hope that that part is self explanatory.
## **The edges are getting easier to shape**
What AI may ultimately change is not the existence of SaaS platforms. Those remain essential. CRM systems, marketing automation platforms, analytics tools, and data infrastructure benefit enormously from shared scale.
But the edges of the architecture are becoming easier to shape.
Companies can build small tools that extend their platforms instead of forcing every workflow into them. The centre of the Martech stack will likely remain standardized, while the edges become increasingly customized. Something Scott Brinker and Frans Riemersma refer to a micro-composable SaaS.
Source: [State of Martech by Scott Brinker and Frans Riemersma](https://content.martechday.com/martech-for-2026.pdf?ref=martechtherapy.com)
## **The system and the student**
Back at the education conference, one idea kept resurfacing.
The goal should not be to force every student into the same mould. Instead, systems should be flexible enough to accommodate different kinds of intelligence.
Ken Robinson once described intelligence as something that is **diverse, dynamic, and distinct**. Systems that recognize that diversity tend to unlock creativity, while systems that ignore it tend to suppress it.
Martech may be approaching a similar moment.
SaaS will continue to dominate the middle of the market. But the companies that innovate most successfully are often the ones operating at the edges.
The ones willing to question the mould.
And sometimes, break it.
[](https://www.martechstackbuilder.com/?ref=martechtherapy.com)
Start building your Martech Stack designs today 👇🏻
[SIGN UP FOR FREE ](https://www.martechstackbuilder.com/?ref=martechtherapy.com)
### The dirty truth about vibe coding in Martech
URL: https://www.martechtherapy.com/the-dirty-truth-about-vibe-coding-in-martech/
Last updated: 2026-03-06T10:51:25.000Z
Every few weeks, another post appears in my feed declaring that SaaS is finished.
Someone cancelled a subscription, vibe-coded a replacement in an afternoon, and now the economics of software are apparently solved. Why pay €30, €300, or €3,000 a month for a tool when an AI can generate the same thing with a prompt?
The sarcasm around vibe coding does reveal its limitations.
The story has become loud enough that it has started leaking into financial markets. Investors are suddenly trying to understand what AI-assisted software creation might do to companies like HubSpot, Adobe, and Salesforce. If every company can build its own tools now, what happens to the companies that sell them?
Hubspot's stock price development of the last year.
That anxiety has shown up in analyst commentary and stock volatility. Not because SaaS is suddenly obsolete, but because markets are trying to price a new uncertainty: if software becomes dramatically easier to build, what exactly are customers paying for?
I understand the excitement. I’ve been experimenting with the same tools.
Over the past months I’ve spent close to **1000 hours vibe coding** different projects. About **80 percent of that time went into commercial initiatives**. Not hobby experiments. Real work for clients, internal tools I wanted to use, systems that needed to behave predictably when someone other than me clicked a button.
The productivity jump is real. Sometimes almost suspiciously real, but the screenshots circulating online usually stop at the moment where the demo works.
That is where the interesting part actually begins.
## **The demo moment**
Recently I built a simple consent management platform while [live streaming on Youtube](https://www.youtube.com/playlist?list=PLyI45T6PyFaK1hytuW4pJMPpvPVgeHe%5FW&ref=martechtherapy.com).
Nothing revolutionary. A cookie banner. Preference settings. Google Consent Mode logic. A small admin interface. A script that could be injected into a website.
Within a surprisingly short amount of time the thing actually worked. It pushed events into a data layer, showed a banner, stored preferences, and allowed configuration through a small interface.
[The consent management platform repo on Github](https://github.com/tagticians/consent-management-platform?ref=martechtherapy.com)
A few years ago that kind of prototype would have taken a very different setup. Possibly a small development team. Definitely more planning.
So yes, the productivity gains are real.
But that CMP project was mostly a demonstration. A small iceberg tip to show what sits behind the idea of “just build it yourself.”
The real lessons did not come from that demo.
They came from client work and from building my own tools.
One of those tools is the [Martech Stack Builder](https://www.martechstackbuilder.com/?ref=martechtherapy.com), a project designed to help people design marketing technology architectures and explore vendor combinations. Something that started as a relatively straightforward idea and slowly revealed how many layers sit underneath even a “simple” application.
Building out features is more than just an MVP exercise.
Projects like that teach you something quickly.
> Software is rarely just code.
It is architecture decisions. Deployment pipelines. Hosting environments. Versioning. State management. Security concerns. Documentation. The quiet pile of operational details that nobody includes in their triumphant “I replaced SaaS with a prompt” screenshot.
That is where you start developing respect for complexity.
## **Buying software means buying distance from the mess**
Buying software often looks expensive on paper. Monthly subscriptions. Usage tiers. Enterprise pricing that makes procurement teams sigh. But those invoices buy something important.
> Distance
When you buy software you are paying someone else to worry about uptime monitoring, infrastructure, security patches, scaling issues, and the strange edge cases that appear when real users interact with a system in ways the designers never anticipated.
You are also buying a hotline.
When something breaks, you call someone else.
You invoke the SLA. Someone on the other side of the contract now owns the problem.
From the outside it looks like you are buying features.
In reality you are **outsourcing responsibility**.
## **Building means you become the hotline**
The moment you decide to build your own tool, that responsibility moves back across the table. Back to yourself.
Suddenly you are the one thinking about hosting environments, authentication methods, deployment pipelines, environment variables, configuration storage, and backups.
If something breaks on a Sunday evening, there is no support ticket to open.
You are the support team.
You serve your own SLA.
**None of that responsibility disappears** because AI generated the first version faster. It simply arrives earlier in the lifecycle.
This is where many of the “AI replaces SaaS” narratives quietly lose their momentum and reality, for many sinks in. The prototype exists, but running it properly requires a different level of commitment.
And that commitment grows as the tool becomes more useful.
## **Why companies still want to build**
There is an important counterargument here.
> Buying software has real limitations.
Off-the-shelf tools are designed for broad markets. That means compromise. Workflows that almost match your business process but not quite. Features that cover eighty percent of what you need while ignoring the twenty percent that actually differentiates your organization.
In marketing technology this problem shows up everywhere.
Forms that cannot validate exactly the way you want. Routing logic that almost fits your customer journey but stops just short. Data models that push your operations into shapes that make sense for the vendor’s roadmap rather than your own.
This is where building becomes attractive.
When you control the system, you can design tools that fit your workflow instead of bending your workflow around the tool.
Scott Brinker has described this phenomenon as the rise of internal **micro-SaaS**. Small specialized applications built to serve specific organizational needs.
That flexibility is the real prize.
Not the thrill of cancelling a subscription.
The ability to build something that actually fits.
## **The thousand-hour reality check**
After roughly a thousand hours experimenting with vibe coding, one thing has become clear.
The balance point between buying and building is not obvious.
Sometimes building a tool feels liberating. You solve a problem exactly the way you want. The system behaves precisely according to your rules.
Other times you slowly realize that you have created a new responsibility for yourself. A system that now requires monitoring, small improvements, occasional debugging, and the kind of maintenance work that nobody celebrates.
That moment usually arrives quietly.
The first version works beautifully.
The second version requires a deployment tweak.
The third version introduces authentication.
The fourth version needs configuration storage.
And somewhere around version five you start thinking about databases, audit trails, and how many evenings you would like to donate to infrastructure management.
The flexibility is real.
The freedom is real.
But the operational gravity is real too.
## **The new middle layer: SaaS for building SaaS**
Interestingly, the industry is already responding to this tension.
Platforms like [Lovable](https://lovable.dev/?ref=martechtherapy.com) and [Replit](https://replit.com/?ref=martechtherapy.com) represent a new layer in the ecosystem.
They are essentially **SaaS wrappers around vibe coding**.
They provide development environments, hosting infrastructure, deployment pipelines, and collaboration features. In other words, they temporarily remove much of the operational burden that comes with building software.
These tools are **fantastic starting points**.
You can experiment quickly without worrying about infrastructure.
But they may also have a natural shelf life.
As projects mature, teams often want more control over architecture, hosting environments, security policies, and cost structures. That is when many projects move beyond the wrapper and back into self-managed infrastructure.
Which is an interesting twist.
SaaS might not disappear.
It might simply evolve into a different role.
Instead of selling finished applications, some SaaS companies may end up selling **development environments, orchestration layers, and infrastructure platforms**.
## **The skill that will matter most**
This shift also changes which skills matter.
As Guy Royse observed, based on a [video from Nate B. Jones](https://www.youtube.com/@NateBJones?ref=martechtherapy.com):
> “It will come down to the ability to define what the code should do.”
AI can generate code.
But someone still needs to define the problem, design the architecture, anticipate edge cases, and decide how the system should behave when reality inevitably refuses to follow the happy path.
That skill set looks less like traditional programming and more like **system design combined with domain expertise**.
## **Martech raises the stakes**
In marketing technology the consequences of these decisions are amplified.
Many Martech tools sit close to sensitive systems:
consent management, identity resolution, attribution logic, campaign orchestration, customer data flows.
When something breaks in those areas, the consequences can be more than inconvenient. Compliance risks appear. Tracking breaks. Leads disappear. Reporting becomes unreliable.
That is why the build versus buy decision in Martech tends to carry more weight than in many other software categories.
## **The uncomfortable conclusion**
> Vibe coding is real
It will absolutely change how software gets built. It lowers the barrier to experimentation, shortens the path from idea to prototype, and enables companies to create tools that would have been unrealistic only a few years ago.
But the economics of software have not disappeared.
They have moved.
Buying software often means paying someone else to carry the operational weight. Infrastructure, monitoring, security patches, uptime guarantees, and the long tail of small issues that quietly accumulate in any system.
Building gives you freedom.
The freedom to design tools that actually fit your business instead of bending your business around someone else’s roadmap. The freedom to create internal micro-SaaS solutions that solve very specific problems. The freedom to move faster when the standard tools fall short.
It also hands you the pager.
Sometimes that trade-off is exactly what you want. Flexibility and control can be powerful advantages when they are used deliberately.
But the economics of software haven’t been broken.
They’ve just been rearranged.
[](https://www.martechstackbuilder.com/?ref=martechtherapy.com)
Start building your Martech Stack designs today 👇🏻
[SIGN UP FOR FREE ](https://www.martechstackbuilder.com/?ref=martechtherapy.com)
### Martech Stack Builder, another step closer.
URL: https://www.martechtherapy.com/martech-stack-builder-version-010-update/
Last updated: 2026-02-05T13:32:37.000Z
Here is a quick update on my [Martech Stack Builder](https://www.martechstackbuilder.com/?ref=martechtherapy.com) project. Over the last week, I have made some big improvements. Let me break them down for you.
## What is the Martech Stack Builder?
Maybe I am getting too far ahead of myself, so here is a TL;DR.
Two months ago, I started building a Martech Stack Builder that helps you visualize and present your company's, or your client's, marketing technology stack. A "Miro for Marketing", I guess. The Martech Stack Builder lets you drag 'nodes' onto your canvas and build relationships between them. Additional consideration specific to marketing technology is that you can add contextual data to your stack and nodes. Add information such as consent rules, PII, costs, ownership, etc., and visualize it with ease.
Now in the new version, I have improved the AI assistant that allows you to do evaluations of your martech stack, using all metadata (as mentioned above) and the individual relationships of the nodes as context. This results in very detailed, stack-specific reports, including implementation, costs, privacy/consent, and data flows.
Additionally, I have added a feature that lets you search for alternative solutions in your martech stack and compare them with those from other vendors.
If you prefer to watch a demo of the new updates, see the video below, otherwise keep reading.
🙏🏻
****Thank you so much to all of you who have provided me with feedback** and ideas on how to improve the Martech Stack Builder for you everyday use. I will continue to listen, consider, and incorporate your ideas as we move forward.
## Need to find an Alternative for a tool in your martech stack?
By right-clicking on a node in your martech stack, you can start the process of finding alternatives. The report is generated using AI and leverages your martech stack and all provided metadata points as additional context.
This results in unique reports based around your marketing technology stack.
## Found an alternative? Start comparing martech vendors
From the Alternatives report, you can now initiate comparison reviews between your current solution, the discovered alternatives, and other solutions in my database (which I'm constantly expanding!).
This results in an extensive but manageable report that lists which solution works best for your current martech stack.
## Ready to collaborate with other Departments? Break down the Martech silos?
Before any major change starts, you should know who needs to be involved, right? For this reason, I built a Departments feature that lets you create departments (teams) that own or lead specific solutions. These Departments can then be assigned as owners of a specific solution in your Martech stack.
Quickly gain insights on who owns what and what costs are involved for each tool.
This approach really opens the door to cross-departmental collaboration going forward, such as with Request for Change...
## Convinced you need to replace a tool in your Martech stack?
Within the Alternatives report, after comparing, you can now initiate a Request for Change. If you want to add, remove, replace, or change a tool's integration, this feature will help you manage the process.
Describe what you want done, add the type of change, and add the tool(s) from your martech stack, and Department leads are automatically notified. Yes, this feature needs a lot of refinement, but the foundation is in place, providing an auditable timeline, an approval/rejection process, and a feature to generate a roadmap for the change.
For me, the next steps will push towards integration with tools like JIRA to manage the process in your company's preferred project management tool, but be filled with contextual information from the Martech Stack Builder.
## Don't guess it, visualize it. How to deal with consent and PII
Previously I mentioned the Multi-Lens feature. This feature allows you to assign marketing technology specific values to tools in your stack. This will allow for something pretty cool, if I do say so myself. It allows you to visualize data flows, and consent flows in one.
Want to know where data will or will not flow if a user does not give consent for marketing? Visualize it. Samen with PII. With various option available for defining PII flows through your stack, clicking on Highlight PII paths allows you to visualize the flow of PII data. More work is needed here to visualize the different sorts of PII handling (hashing, rejecting, storing etc.) but the basics are in place.
## Getting notified? Not a problem.
Last but not least, notifications. I have added two methods to get notified about a few changes to your Team's project. Now, you can push notifications using webhook or Slack. Simply input the endpoints needed, select the notifications you want your team to receive, and [Bob's your uncle](https://en.wikipedia.org/wiki/Bob%27s%5Fyour%5Funcle?ref=martechtherapy.com).
More options and improvements coming soon, here too.
[](https://www.martechstackbuilder.com/?ref=martechtherapy.com)
Start building your Martech Stack designs today 👇🏻
[SIGN UP FOR FREE ](https://www.martechstackbuilder.com/?ref=martechtherapy.com)
## Sign up for Martech Therapy
Thoughts, stories and ideas.
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
### Diverted by design? What the CDP split means for the mid-market
URL: https://www.martechtherapy.com/diverted-by-design-what-the-cdp-split-means-for-the-mid-market/
Last updated: 2026-02-02T07:00:36.000Z
In [last week's part 1](https://www.martechtherapy.com/the-cdp-split-is-official-magic-quadrant-2026-review/), I described how Gartner finally named the split inside the CDP category in their [Magic Quadrant for Customer Data Platforms 2026](https://www.gartner.com/reviews/market/customer-data-platforms?ref=martechtherapy.com). Platformization on one side. Agentification on the other.
Two futures, both serious, both demanding.
That still leaves a simple question hanging:
> Who is this actually built for?
Because when you read this year’s Magic Quadrant **carefully**, the most telling signal isn’t who moved up or down, which opens another can of worms. It’s the kind of organization the category quietly assumes as the norm.
Large teams. Strong data foundations. Time to experiment. Budget to absorb friction. A tolerance for gravity once a platform choice is made.
> Where does that leave everyone else?
## **A pattern you’ve probably seen yourself**
At this point, the usual explanations tend to show up.
- The team wasn’t ready.
- The CDP wasn’t implemented “properly.”
- The use cases weren’t ambitious enough.
Have you noticed how familiar that story sounds, regardless of vendor?
In practice, what I’ve seen over the last few years looks less dramatic. CDP projects don’t usually crash. They slow down. The platform becomes something teams negotiate around rather than build on. I'd bet that there are more discussions about which Star Wars movie was the best (*Rogue One, of course* 😉) than there are about leveraging the CDP more.
> Why does stagnation happen so consistently?
Often, it’s because the assumptions behind the platform quietly exceed what the organization can carry. Small data teams supporting many stakeholders. Marketing teams expected to self-serve while also keeping campaigns running. Leadership that wants results this quarter, not optionality three years out.
Those constraints aren’t new, neither are the disappointments. What’s new is that the CDP category stopped flexing around them.
## **Platformization, seen from closer to the ground**
At enterprise scale, platformization makes a lot of sense.
A shared customer model. Governance built in. Brand native connections across marketing, sales, service, and analytics. Once everything is in place, things tend to hold together. True ecosystems.
> But what does that look like a level down?
**Platformization assumes commitment**. More modules. More dependencies. More alignment across teams that don’t always move at the same speed or priorities. Choosing the CDP becomes an operating decision, not just a tooling one.
For some organizations, that’s exactly what they want. For others, especially in the mid-market, the weight shows up quickly. Progress slows. Decisions get harder. The platform starts to shape the organization more than the other way around.
[Before you deploy your CDP, train your crewCDP projects test more than tech -> they test teams. What military work-ups taught me about readiness, response, and Martech project success.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/before-you-deploy-your-cdp-train-your-crew/)
Gravity towards platformization is interesting until you realise how hard it is to change direction.
## **Agentification sounds lighter, until you look at the fine print**
Agentification is often framed as the antidote to that gravity.
Smaller core. More autonomy. Let agents make decisions while humans set direction.
On paper, vendors in the 'agent/agentic' space make it sound so attractive. Gartner clearly treats this as a real trajectory. In all fairness, this is a good outlook, mostly for enterprises, but not a mirror of the present moment... for the mid-market.
In practice, it comes with its own demands.
Agentic systems, and AI applications in general, rely on clean data, clear ownership, and teams that trust automation without disengaging from it. When something goes wrong, someone still needs to know where to look. Was it the data? The logic? The model? The activation layer?
So the work doesn’t disappear. It moves.
[Agentic AI in Martech: When agents disagreePart 3: The inevitable conflicts in multi-agent systemsMartech TherapyMatthew Niederberger](https://www.martechtherapy.com/agentic-ai-in-martech-when-agents/)
This is why earlier signals, like the [Gartner Peer Reviews–based MQ simulation I shared before this year’s quadrant](https://www.martechtherapy.com/when-the-customers-speak-even-gartner/), were interesting to me, because they hinted at which operating models buyers were already prepared to support.
## **Why the middle starts to wobble**
For a long time, CDPs occupied a middle ground that mattered, especially for mid-market teams: structured enough to improve data use, but forgiving enough to work without enterprise-level readiness.
A sense of progress without rewriting the organization.
That space is getting harder to sustain.
Platform-led approaches raise the floor.
Agent-led approaches raise expectations.
Pricing models expose inefficiencies faster.
AI features demand better inputs.
Governance stops being optional once automation increases.
Yes, I think that pretty much covers it, don't you think?
What used to feel workable now feels fragile. The margin for being “almost ready” just shrank. Heck, maybe just disappeared altogether.
## **A quick pause on what the quadrant shows, and what it doesn’t**
One thing that often gets lost in Magic Quadrant discussions is scope.
(**yes, in the case of the CDP Magic Quadrant around 190 other vendors...*)
The Magic Quadrant doesn’t show the whole market. It shows the part of the market *that fits Gartner’s criteria and participates fully in the process*. Some vendors opt out. Others matter architecturally but don’t meet commercial thresholds.
This year, [**RudderStack**](https://www.rudderstack.com/?ref=martechtherapy.com) and [**GrowthLoop**](https://www.growthloop.com/?ref=martechtherapy.com) appear as honorable mentions. Definitely well deserved, and worth paying attention to.
Not as a value judgment, but as a signal, although not necessarily 'agentification'... but I would be more than happy to discuss this sometime over beers 🍻
There’s a, what I like to call, **shadow market around the Magic Quadrant**. A space where teams experiment with warehouse-first activation, minimal context layers, and outcome-driven execution without committing to a full enterprise platform... and succeed.
I want to come back to that space separately. What sits just outside the quadrant often tells you where practitioners are heading before categories catch up.
## Don't miss my Shadow Market post
Sign-up for free, today 👇🏻
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
## **Where CEPs quietly become the safer bet**
This is where [Customer Engagement Platforms](https://www.martechtherapy.com/tag/customer-engagement-platforms/) re-enter the picture for many mid-market teams.
Not as stand-ins for CDPs. Not as cheaper versions. Simply as systems that made narrower promises from the start and that resonated significantly with marketing teams and their budgets.
CEPs focus on execution. Multiple channels. Feedback loops. Clear ownership. Increasingly, AI features that live inside a known surface instead of across the entire organization.
In my client work throughout 2025, I’ve seen more willingness to commit to CEPs with AI capabilities than to CDPs, even when teams fully understand the long-term value of stronger data foundations.
"Why?" I hear every [Customer Data Platform](https://www.martechtherapy.com/tag/customer-data-platform/) fanperson ask...
Because CEPs deliver visible impact without forcing an organizational redesign upfront. CDPs often ask for that redesign before the benefits show up. Something I always referred to as its indirect impact on profit and loss (P&L). It is just a fact of life, often one that works against its true benefits.
## **Was this really a choice?**
It’s tempting to describe this as [buyers choosing CEPs over CDPs](https://www.martechtherapy.com/cdp-cep-pricing-strategies-for-the-uninitiated/).
That framing puts too much weight on preference and not enough on constraints.
As the CDP category matures and splits, it optimizes around organizations that can sustain its assumptions. Others move toward tools that fit how they already work, not how they aspire to work one day. *Transformation anyone?*
The mid-market didn’t vanish down some deep black hole. It had a 200 IQ moment and followed the path of least organizational friction.
[CDP & CEP pricing strategies for the uninitiatedCDPs charge for the data you hold. CEPs charge for the actions you take. “Usage” sounds simple, but every vendor defines it differently. The Hidden Logic of Martech Pricing reveals what those definitions really mean for your budget and your business.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/cdp-cep-pricing-strategies-for-the-uninitiated/)
## **Reading the MQ through a practitioner lens**
From a practitioner point of view, this also helps explain the mixed reactions to the Magic Quadrant itself.
Not outright rejection. Not mere indifference. Although it thread the needle.
The Magic Quadrant still helps with orientation in places. It shows direction. It shows momentum. In some cases [it opens doors in regions where "*Quadrant = Life*"](https://www.martechtherapy.com/is-it-all-a-magical-illusion/). What it struggles to show is **effort**. The day-to-day cost of implementation, coordination, and governance once the decision is made.
That’s why some people still study it closely, some glance at it and move on, while others *rip it apar*t or *praise it all the way* on LinkedIn.
## **Closing the loop and part 2**
In part 1, I argued that the CDP category didn’t suddenly become clearer this year. It became more explicit about its internal split.
This second part adds something intrguing. When categories sharpen, consequences follow. And in my opinion, opportunities are created in the void that is left behind.
Markets grow up. Competition hardens. And some buyers find themselves just outside the frame because the picture changed... again.
I’ve spent less time asking which vendor wins for a while now. The more interesting question is who each category stops serving, and what grows in the space that opens up.
That’s usually where the next shift starts. What will it be this time?
****Your stack isn’t failing.**
It’s absorbing more effort than it used to.
The Second Law of Martech scan helps you see where organisational energy is being spent just to keep things working, and where that cost is starting to crowd out real value.
[Start your FREE Entropy Scan ](https://secondlaw.martechtherapy.com/?ref=martechtherapy.com)
### The CDP split is official (and it’s not the one vendors were selling)
URL: https://www.martechtherapy.com/the-cdp-split-is-official-magic-quadrant-2026-review/
Last updated: 2026-01-26T20:09:20.000Z
Reading this year’s [Gartner Magic Quadrant for Customer Data Platforms](https://www.gartner.com/interactive/mq/7363930?ref=pubsite) gave me a familiar feeling.
Not, not that of reading a short novel, with its **46 pages**. Not excitement. Not disbelief. More the quiet recognition you get when something you’ve been circling for a while finally lands on paper. The conclusions didn’t come out of nowhere. They arrived right on time for the category.
For years now, CDPs have been asked to stretch in every possible direction. Think of them as the industry’s Spandex. One moment they’re a data foundation. Then an orchestration layer. Then a governance mechanism. Lately, they’ve also become [the supposed “context brain” for AI-driven marketing](https://www.martechtherapy.com/understanding-mcps-a-cdp-insiders/).
[Contextual CDPs, is this the next-gen?Part 1 of 6: What Model Context Protocols mean for the future of Customer Data Platforms.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/understanding-mcps-a-cdp-insiders/)
At some point, you stop calling that versatility and start calling it an identity crisis.
This year, Gartner stops trying to keep all of that neatly bundled. Instead, it does something *refreshingly un-analyst-like*: it admits the category is splitting and gives both halves a name. The CDP market, according to Gartner, is forking into **platformization** on one side and **agentification** on the other.
That framing matters more than any single dot moving on a chart. It changes how the quadrant should be read, how vendor positions make sense, and how buyers should interpret what “leadership” even means in today's age. It also quietly sets up a second conversation, which I’ll come back to in part 2, about who drops out of focus when a market reshapes itself like this.
## **This didn’t start with the 2026 quadrant**
If this split feels sudden, it’s only because the language finally caught up to Gartner.
Or because you’ve just quietly admitted to yourself that keeping up with the chaos of the last few years wasn’t exactly on your list of “important things to do”.
And honestly, I don’t blame you. I’ve had moments of wanting to give up, too.
Earlier Gartner research kept circling the **same unresolved questions**. Composable versus suite. Marketing ownership versus IT ownership. Activation speed versus governance depth. Pricing models that sounded perfectly reasonable in vendor presentations, right up until someone asked how they would scale in year three without triggering a conversation with procurement.
Oh, if I could only get a ~~Dollar~~ Euro every time I heard that question pop up.
I’ve [written about these patterns before](https://www.martechtherapy.com/an-open-letter-to-martech-vendors-lets-do-better/), often while sitting in demos where everything looked smooth, fast, and oddly consequence-free. The tools usually weren’t the issue. The expectations were, and still are.
What’s different this year is that Gartner no longer tries to smooth those contradictions into a single storyline. It acknowledges that the category has been pulling in two directions at once, and that pretending otherwise hasn’t helped buyers make better decisions. At least not from where I’ve been sitting, often facepalming during demos.
And I can't tell you what a breath of fresh air this is.
## **Layer one: platformization**
The first path Gartner describes is **platformization**.
Here, the CDP isn’t a standalone marketing product. *Was it ever, really?* It’s a foundational layer inside a much larger application ecosystem. The value of the CDP grows as more of the surrounding platform is adopted, because it becomes the shared customer context everything else depends on.
This is the 'suite' territory of [Salesforce](https://www.salesforce.com/?ref=martechtherapy.com), Oracle, and [Adobe](https://www.adobe.com/?ref=martechtherapy.com).
In this model, the CDP acts as connective tissue. Consent updates ripple through the system. Identity rules are enforced consistently. Decisions made in marketing can trigger actions in sales or service without brittle integrations or manual handoffs. From an enterprise perspective, this is deeply appealing.
It does come with gravity, something I’m getting to know quite well on the brink of turning 50.
Platformization assumes commitment. Architectural commitment. Commercial commitment. Organizational commitment. Capabilities are often tied to adjacent products. Pricing unfolds in layers. Flexibility exists, but mostly within the boundaries of the ecosystem... which can feel limited, even with the above mentioned giants of industry.
For large, regulated organizations, that trade-off often makes sense. Predictability and control outweigh experimentation. The **CDP becomes less a tool and more an internal operating system**.
That’s a valid future for the category. It’s just not a casual one.
## **Layer two: agentification**
The second path Gartner outlines is **agentification**, and this is where the category starts to feel genuinely different.
In this model, the CDP is deliberately slimmer. Its job is to unify customer context, expose decisioning logic, and connect to activation points. **It does not try to become a full application suite**. Execution increasingly lives with AI agents operating on top of that foundation or other integrated intelligence.
[Agentic AI in Martech: The billion decision problemPart 1: Why scale changes everything about AI in MartechMartech TherapyMatthew Niederberger](https://www.martechtherapy.com/agentic-ai-in-martech-the-billion/)
This approach aligns closely with warehouse-native and composable architectures, where customer data already lives in cloud platforms and the CDP activates it without copying it all over the place. Less duplication, fewer moving parts, more reliance on what’s already there. Ah, don't get me started on the semantics of this...
**The promise here is autonomy**. Agents pursue outcomes rather than campaigns. Humans define objectives and guardrails, and the system continuously adjusts decisions across channels. Less calendar-driven marketing, more continuous optimisation. Trust me, you need to see this to believe it.
This is why [Hightouch](https://www.hightouch.com/?ref=martechtherapy.com) **landing in the Leaders quadrant** matters more than it might first appear.
Copyright 2026 Gartner, Inc
Before this Magic Quadrant was published, [I ran a small experiment using Gartner Peer Reviews data](https://www.martechtherapy.com/when-the-customers-speak-even-gartner/) to simulate how vendors might land if buyer sentiment and architectural fit carried more weight. In that simulation, **Hightouch already showed up in the Leaders quadrant**. Not because it tried to do everything, but because it was very clear about what it was trying to be.
This year’s quadrant quietly confirms that direction.
Yeah, I called it. I'm claiming it.
And yes, that kind of visibility still matters. Especially in [boardrooms and industries where analyst reports continue to carry real weight](https://www.martechtherapy.com/is-it-all-a-magical-illusion/). I’ve written before about how Gartner and similar reports still shape decisions in regions like the Middle East, where **“Leader” is more than a badge, it’s a shortcut to trust**.
Does this newly found fame mean Hightouch will open a Middle East office next? Just kidding.
Or am I.
Jokes aside, I’m comfortable saying that this Leader position will put Hightouch on the radar in rooms where these reports still open doors.
Hold on to your hats, though. Gartner is treading carefully. Agentification is framed as an emerging operating model, not a finished one. Which is fair. Agents still rely on existing execution systems. Reliability, governance, and explainability remain open questions. The ambition is obvious. The operational reality is still catching up, like us humans.
Which, if we’re honest, is exactly where most interesting technology categories spend a few uncomfortable years.
## **Why the middle starts to thin out**
Once you accept this two-path framing, something else becomes easier to see.
There isn’t much stable ground between platformization and agentification.
Vendors that sit in the middle often execute well today, but struggle to explain where they’re heading structurally. Are they building toward deep platform gravity, or toward autonomous, outcome-driven systems? Trying to do a bit of both usually results in awkward compromises.
[The great rebalance & why 2026 belongs to the mid-market CDP2026 will test Martech’s balance. As enterprise CDPs plateau, mid-market buyers are emerging as the industry’s new growth engine and its most overlooked opportunity.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/cdp-cep-midmarket-predictions-2026/)
Is this what happened to [mParticle by Rokt](https://www.mparticle.com/?ref=martechtherapy.com), Zeta Global, and Red Point Global?
Now, don’t get me wrong here. This isn’t a judgement on effort or intent. I am no Judge Dredd.
What it is is category physics.
A CDP that is partially composable and partially suite-driven can end up expensive without being liberating, and flexible without being truly orchestrated. Be honest, how good can a feature really be if you’re sharing your focus across everything except a clear core offering?
Innovation still happens, but it feels incremental rather than directional. Buyers sense progress, yet still wonder why things feel heavier than expected.
The quadrant reflects this, even when it doesn’t spell it out.
## **What this quietly changes**
The most important change in this year’s Magic Quadrant isn’t a dot moving left or right. I'm sure we've got more important things to worry about on a daily basis.
What matters is **the admission that CDPs are no longer competing along a single path toward “better”**. They’re diverging into different operating philosophies, each with its own demands on teams, governance, and patience.
That changes how Leaders should be read. It changes what vision actually signals. And it raises an uncomfortable question about who this market is increasingly designed for.
That question deserves its own space.
In part 2, I’ll look at what this split means for buyers outside the global enterprise bubble, and why the absence of the mid-market in this conversation is more revealing than any single vendor ranking.
For now, the takeaway is simpler. The CDP category didn’t suddenly become clearer this year. It became more candid.
And in my experience, that usually happens right before things get interesting.
****Your stack isn’t failing.**
It’s absorbing more effort than it used to.
The Second Law of Martech scan helps you see where organisational energy is being spent just to keep things working, and where that cost is starting to crowd out real value.
[Start your FREE Entropy Scan ](https://secondlaw.martechtherapy.com/?ref=martechtherapy.com)
### Extending Martech’s Law: why growth leads to decay
URL: https://www.martechtherapy.com/extending-martechs-law-why-growth-leads-to-decay/
Last updated: 2026-01-20T07:00:54.000Z
When I wrote [The real Martech ROI equation](https://www.martechtherapy.com/the-real-martech-roi-equation/), I was trying to articulate a frustration I kept hearing, and feeling myself. On paper, the business case made sense. The tools were implemented. The dashboards existed. The licenses were paid. And yet, the return felt harder to realise year after year.
Not because the technology stopped working, but because everything around it seemed to require more effort.
That article stayed with me longer than I expected. Especially one unanswered question: if the investment is already sunk, why does value still feel like it’s slowly leaking away?
The answer I kept circling back to wasn’t financial. It was operational. And, oddly enough, thermodynamic.
## **From growth to decay**
For years, [Scott Brinker’s Martec’s Law](https://chiefmartec.com/2013/06/martecs-law-technology-changes-exponentially-organizations-change-logarithmically/?ref=martechtherapy.com) (yes, without an ‘h’) has been one of the clearest explanations for what we see in practice. Marketing technology tools grow faster than organisations can absorb them. It explains the explosion of platforms, vendors, and overlapping capabilities better than almost any other idea in our field.
I’ve always seen that law as descriptive, not judgmental. It doesn’t blame teams or vendors. It simply states a reality.
But it also stops at growth.
It explains why stacks expand, not what happens after they do.
I spoke with Scott about this idea, and what struck me was how naturally it clicked. Not as a contradiction, but as a continuation. If growth is inevitable, the next question becomes unavoidable:
> What does growth do to the system over time?
That’s where **The Second Law of Martech** comes in.
## **An Interstellar detour**
Around the same time, I rewatched Interstellar. There’s a moment just before Cooper drops into Gargantua, the black hole, where he reflects on the idea that to move forward, something always has to be left behind.
Cooper detaching before falling to Gargantua
It’s a line that sounds philosophical, but it’s grounded in something very concrete. Entropy. The idea that order doesn’t sustain itself. That progress is never free. That energy must be spent somewhere to maintain structure.
That scene pulled an old thread loose for me (not because of the father/daughter storyline that has me ballin’ every time I watch it). Because Martech stacks behave in a remarkably similar way.
They don’t collapse overnight. They don’t suddenly stop delivering. Instead, they ask for more. More attention. More coordination. More explanation. More exceptions. More organisational effort, just to get the same outcomes they once produced with far less friction.
## **What entropy looks like in real stacks**
In practice, this rarely shows up as a single failure. It shows up as accumulation.
Campaigns take longer to launch, even though the tooling is more powerful. Data conversations start with caveats instead of confidence. A small group of people becomes essential, not because they are bottlenecks by choice, but because they are holding the system together through experience and memory.
> Nothing is broken.
> Everything still works.
> But the cost of making it work keeps rising.
That rising cost is what I mean when I talk about entropy in Martech.
And it’s also where I started using a shorthand I kept coming back to: **Human Energy**.
## **Reframing Human Energy**
When people hear “human energy”, it can sound abstract, or worse, motivational. That’s not what I mean.
Human energy, in this context, is sustained organisational effort. Very specific forms of it.
First, there is **cognitive effort**. The mental load required to remember how things really work. Which definition applies where. Which dashboard to trust. Which exception is currently in play.
Second, there is **coordination effort**. The meetings, handoffs, Slack threads, clarifications, and escalations needed to make systems cooperate across teams and tools.
Third, there is **maintenance effort**. The invisible work of fixing, reconciling, documenting, compensating, and quietly preventing drift from becoming visible failure.
Early in a stack’s life, this effort is barely noticeable. Over time, as tools multiply and processes accrete exceptions, more of that energy shifts away from creating value and toward simply preserving alignment.
Nothing dramatic happens. But standing still becomes expensive.
## **The Second Law of Martech**
The **Second Law of Martech** states that
> "Marketing technology systems naturally decay unless continuous organisational effort is applied to preserve meaning, flow, and trust."
This isn’t an argument against growth. And it’s not a critique of ambition. It’s a reminder that order has a cost, and that cost is paid by people, not platforms.
Tools depreciate financially. Martech stacks depreciate operationally.
## **Why I turned this into a framework**
I didn’t want this to stay theoretical. Writing about entropy is one thing. Helping teams recognise it in their own context is another.
That’s why I built the Second Law of Martech scan as a framework. Not as a maturity model, and not as a diagnostic that tells you what to buy or rebuild. It’s meant to act as a mirror.
The goal isn’t to label a stack as good or bad. It’s to make visible where organisational effort is being spent just to keep things working, and where that effort is starting to crowd out actual value creation.
Once you can see that, better decisions tend to follow. Sometimes that means reducing entropy. Sometimes it means accepting it consciously and adjusting expectations. Both are valid. Ignoring it rarely is.
Entropy isn’t the enemy. Pretending it isn’t there usually is.
****Your stack isn’t failing.**
It’s absorbing more effort than it used to.
The Second Law of Martech scan helps you see where organisational energy is being spent just to keep things working, and where that cost is starting to crowd out real value.
[Start your FREE Entropy Scan ](https://secondlaw.martechtherapy.com/?ref=martechtherapy.com)
### Why you haven’t heard from me lately, and why Martech Stack Builder v0.9 needs you
URL: https://www.martechtherapy.com/why-you-havent-heard-from-me-lately-and-why-martech-stack-builder-v0-9-needs-you/
Last updated: 2026-07-06T10:55:47.000Z
I’ve been quieter than usual lately.
No podcasts. No long articles. No hot takes. That wasn’t a content strategy. It was a side effect of being completely head-down building something that refused to stay small.
Alongside my client work, I’ve been spending most of my free headspace on [Martech Stack Builder](https://www.martechstackbuilder.com/?ref=martechtherapy.com). What started as a lightweight visual tool quickly turned into something heavier, more opinionated, and frankly more demanding than I expected. Writing about it too early felt wrong. The product itself wasn’t stable enough yet, and I didn’t want to narrate something that was still moving underneath my feet.
Martech Stack Builder version 0.9 is ready for testing
Version 0.9 feels like the first moment where that changes.
## **From a diagram to something that mattered**
Martech Stack Builder began as a way to sketch Martech stacks without opening PowerPoint or Miro. Visual, flexible, almost playful. But the moment people started using it for real thinking, not just illustration, reality showed up faster than you can say "the Grinch stole Christmas".
Security stopped being theoretical. Refactoring wasn’t optional anymore. Data models mattered. Edge cases multiplied. “Vibe coding” is fun until you realise someone might actually rely on what you’re building to explain their stack to a CTO, a legal team, or a vendor.
At some point the question shifted from “can I build this?” to “does this hold up?”
## **Learning the hard parts the slow way**
A lot of the progress since the early versions came from friction and not inspiration. Security work forced me to rethink assumptions I didn’t even realise I was making like secure webhooks, preventing prompt injections, and storing user data. Refactoring meant letting go of earlier shortcuts and constantly spending tokens on scans. Feedback became more important than features.
Vibe coding is more than just prompting. It's about planning, testing, and knowing how to react. Above the results of a security and refactoring audit. Even Claude Code makes mistakes.
One person in particular deserves a mention here: Rune Andersen. He didn’t just poke around and say “nice tool”. He challenged flows, questioned defaults, and forced me to explain why certain things worked the way they did. That kind of feedback is uncomfortable, and yet incredibly valuable.
It also made one thing very clear.
## **The moment the product changed direction**
The biggest shift in Martech Stack Builder wasn’t adding AI, templates, or even team concepts. It was realising that a Martech stack is never viewed through a single lens.
Data flows matter, but so do ownership, privacy, cost, responsibility, operational status, and organisational boundaries. All of those perspectives exist simultaneously. Most diagrams flatten that reality into a single view, and then we wonder why misunderstandings happen later.
A diagram without context is just a prettier slide.
## **The multi-lens approach**
That insight led to the Multi-Lens model. Each node in the stack stopped being just a logo and started carrying meaning. Ownership. PII level. Cost signals. Status. Accountability. Dependencies.
Viewing Ownership in your Martech stack
When you toggle between lenses, conversations change. You start seeing where responsibilities are unclear, where privacy assumptions live, or where costs accumulate quietly across teams. You don’t need another meeting to surface that tension. It’s already visible.
This was the moment Martech Stack Builder stopped being about visualisation and started becoming a sense-making tool.
## **Trace routes and uncomfortable truths**
One feature that came directly out of this thinking is trace routing. It answers a deceptively simple question: where does data actually come from, and where does it go?
Use Trace Route to visualize data stream in you Martech stack from any node
What surprised me was how often “connected” doesn’t really mean “downstream” or “dependent.” We connect tools on slides all the time without being precise about direction, responsibility, or impact.
The trace route feature still needs work. It exposes assumptions, and sometimes those assumptions turn out to be wrong. That’s exactly why it exists.
## **Yes, there’s AI (take a sip)**
Let’s address the obvious part. Yes, there’s AI in Martech Stack Builder.
But it’s deliberately not the centre of gravity.
Evaluate your Martech stack with AI. Add business and goal context to improve the feedback.
I still believe that designing Martech stacks is about business context, human judgment, and organisational reality. AI can help inspect, reflect, and accelerate thinking, but it shouldn’t replace it.
Right now AI is used in two places. First, to help generate initial stack templates so people aren’t staring at a blank canvas. Second, to evaluate a stack based on the information you’ve actually entered.
## **Evaluation as a living mirror**
The evaluation feature doesn’t grade vibes. It reads what’s there. Node metadata, edge descriptions, ownership, privacy levels, cost indicators, status flags. The more context you add, the more meaningful the evaluation becomes.
Using AI to evaluate you Martech stack based on meta data and user context.
Over time this turns into less of a score and more of a mirror. You can see how your stack evolves, where risks reduce, and where complexity creeps in. Version history exists for a reason. Iteration should feel safe.
## **Why v0.9 is a pause before v1**
At this point there’s enough in Martech Stack Builder to make it genuinely useful. There’s also enough unfinished thinking that calling this “done” would be dishonest.
Version 0.9 is a pause. A chance to invite friction before anything hardens into a v1 shape. Especially from people who don’t design stacks alone.
## **An open beta, genuinely open**
That’s why I’m opening this up more deliberately.
There’s a three-month PRO coupon (**BETA2025**) that unlocks everything. Use it solo. Use it with clients. Use it in workshops. Break things. Question defaults. Tell me what doesn’t translate to real-world work.
I’m particularly interested in feedback from teams, consultancies, vendors, and in-house Martech groups who live with the consequences of stack decisions.
## **What I’ll be working on next**
Two big areas are coming up next.
The first is team functionality. Shared diagrams, comments, collaborative iteration, and the ability to work on stacks together instead of passing files around.
The second is templates, but not generic ones. I want to work with vendors on officially approved, real-world architecture patterns that can be reused for training, onboarding, and honest conversations with customers.
Alongside that, I’ll be adding multi-layer diagrams. The idea is that you can drill into embedded solutions. For example, zooming from “Tag Management” into the internal structure of Google Tag Manager or Tealium IQ. This is inspired by software architecture approaches like the C4 model, where different abstraction levels coexist without losing coherence.
## **An invitation, not a launch**
Martech Stack Builder isn’t trying to simplify Martech. It’s trying to make it visible and discussable.
If you’ve ever said “it’s more complicated than that,” you’re probably the right person to test this. Help shape it now, before it hardens into something fixed.
[](https://www.martechstackbuilder.com/?ref=martechtherapy.com)
Start building your Martech Stack designs today 👇🏻
Use coupon code ****BETA2025** for 3-months free PRO access.
[SIGN UP FOR FREE ](https://www.martechstackbuilder.com/?ref=martechtherapy.com)
### I didn’t plan to build a Martech product business, but here we are
URL: https://www.martechtherapy.com/i-didnt-plan-to-build-a-martech-product-business-but-here-we-are/
Last updated: 2025-12-19T08:21:08.000Z
What started as a side exercise, mostly curiosity-driven, has quietly turned into a real line of business. Today, roughly **twenty percent of my revenue comes from building small, focused Martech tools**. Not prototypes. Not demos. Actual, deployed, and maintained software.
That alone would have surprised me a year ago, even when [Chiefmartec](https://www.chiefmartec.com/?ref=martechtherapy.com)'s [Scott Brinker](https://www.linkedin.com/in/sjbrinker/?ref=martechtherapy.com) and [Frans Riemersma](https://www.linkedin.com/in/fransriemersma/?ref=martechtherapy.com) shared their Hypertail 'micro SaaS' vision in their [State of Martech 2025 report](https://content.martechday.com/state-of-martech-2025.pdf?ref=martechtherapy.com).
## **When CDP work runs into reality**
About nine months ago, a client approached me for something familiar: [help selecting and setting up a Customer Data Platform](https://www.martechtherapy.com/ten-reasons-to-bring-in-outside-expertise/). This is still the core of my work, and where most engagements begin. In this case, though, it became clear very quickly that none of the off-the-shelf solutions really fit.
[Ten reasons to bring in outside expertise for your CDP RFP...and why your team will thank you. Not because every company will face all ten of these issues, but because most will recognize at least a few of them.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/ten-reasons-to-bring-in-outside-expertise/)
The client operated in a niche context, with constraints around data, verification, geography, and user effort that standard CDP workflows simply weren’t designed for. You could force a platform to comply, add layers, accept friction, and call it “enterprise-grade”. Or you could step back and question whether the problem was being solved at the right level.
After many conversations, trials with off the shelf solutions, we chose the second path.
## **Building the workflow, not the product**
Instead of selecting a platform and bending the process to match it, **we designed the process first and built around that**. A series of tightly connected workflows replaced what had previously been manual, slow, and frustrating.
User input, document evaluation, location and travel-time validation, and additional checks were combined into a single flow. What used to take users twenty to thirty minutes, and often required follow-up, now completes in under thirty seconds.
Delivering an MVP at speeds never before though possible.
Speed, on its own, is not the achievement. Respecting people’s time is.
The one thing that was really nice was the client’s reaction when they saw this working outside office hours. Not because it was clever, but because it felt dependable.
## **Seeing systems changes the conversation**
One thing I’ve learned over years of analytics and Martech work is that understanding improves dramatically once people can see what’s happening. Visualization turns complexity into something discussable.
Using H3 visualizations to find viable locatons within set travel method and time variables.
For this client, that meant visualizing user locations, obtained with explicit consent, across their base country. Distances to key locations were calculated and clustered, revealing patterns that were invisible in spreadsheets and tables. Conversations shifted from opinion to evidence almost immediately.
Visualize a Dual Zone CDP in the [CDP Simulator](https://cdpsimulator.martechtherapy.com/?ref=martechtherapy.com)
This instinct to make systems visible is also what led me to build **free Martech tools** like the [CDP Simulator](https://cdpsimulator.martechtherapy.com/?ref=martechtherapy.com) and [Stack Builder](https://stackbuilder.martechtherapy.com/?ref=martechtherapy.com). Not to explain technology, but to make decisions less abstract.
## **Trust me, this is not AI slop**
It’s fashionable to dismiss work like this as AI slop or brain rot. I don’t recognize that critique when I look at what I and some others ship.
Every workflow went through QA. Every integration was reviewed. Access control, hosting configuration, and data handling were treated as first-order concerns. Like any serious analytics project, behavior was tracked, assumptions were tested, and edge cases were revisited.
Of course AI accelerated the work, but it did not remove responsibility.
## **What I won’t delegate to AI**
There are things I deliberately do not hand over to AI.
I don’t let it decide what data should exist. I don’t let it define trust boundaries. I don’t let it choose hosting defaults, access models, or retention rules. And I don’t accept output without review, especially when people, locations, or decisions are involved.
AI is excellent at helping me reason faster, explore alternatives, and cross-check my thinking, there is no doubt about that. If I approach this work professionally, judgment still sits firmly on my side of the keyboard.
[Can an AI marketing OS really think like a CMO?Watch now | Inside my demo with DOJO AI, the all-in-one AI marketing operating system, from Lucky Saint campaigns to zebra striping trends. Is this the future?Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/can-an-ai-marketing-os-really-think/)
## **Can anyone do this now?**
This is usually the question underneath the client reactions. And the jury is still out on that one.
It's true, AI lowers the barrier to building, but it doesn’t eliminate the need for experience. Understanding how data flows, how governance fails in practice, and where systems tend to break still matters. Generalist knowledge helps enormously here. Not expert-level depth in everything, but enough literacy to know what to question, what to verify, and when to slow down.
AI helps you improve that literacy, but it certainly doesn’t replace it.
## **Micro, but not small thinking**
What still surprises me is how quickly this expanded. From screening workflows to custom form and survey builders with verification logic, to fully integrated business development tooling. Twelve months ago, I wouldn’t have believed this was realistic without a full product team. A sentiment my clients echo.
From MVP to production ready, the speed is incredible.
Now it feels like the beginning of something more structural.
AI is making micro viable, not by removing complexity, but by making it manageable. The coordination required to do this well is real, and the risks shouldn’t be underestimated. But neither should the result.
When micro is built with discipline, care, and respect for the systems underneath, it stops feeling small. It starts feeling like a correction.
Want to learn more about how ****I can help your organization scale quickly and safely with AI**?
[Visit my profile on LinkedIn >> ]( https://www.linkedin.com/in/matthewniederberger/)
## Sign up for Martech Therapy
Thoughts, stories and ideas.
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
### Why AI strategy fails for the same reason data strategy did
URL: https://www.martechtherapy.com/why-ai-strategy-fails-for-the-same-reason-data-strategy-did/
Last updated: 2025-12-15T10:39:10.000Z
Tiankai Feng has been doing a publication tour for his new book, Humanizing AI Strategy, and he noticed something odd about the conference circuit. He keeps getting invited specifically because he talks about the human side of AI, which apparently makes him an outlier. Everyone else is presenting on architecture, model comparisons, and technical capabilities.
This feels like a replay of what happened with data strategy about five years ago. Companies invested in platforms and governance frameworks while assuming the technology itself would solve their problems. It didn't. Most data strategy failures traced back to [human behavior, organizational dysfunction, poor communication patterns](https://www.martechtherapy.com/your-cdp-is-more-than-just-a-platform/). The technical pieces were fine. The people pieces weren't.
Now we're running the same experiment with AI, except faster and with more confidence that this time will be different.
Tiankai applies the same five Cs framework from his first book ([Humanizing Data Strategy](https://www.martechtherapy.com/tiankai-feng-on-why-humanity-is-the-81a/)) to AI, but the concepts expand in interesting ways. Competence, for example, shifts from "use AI more" to "use AI more wisely." That means understanding what tasks you should delegate to these systems versus what should stay human-only. It requires at least conceptual understanding of how the technology works so you don't make predictable mistakes.
Communication becomes more complex too. In data strategy, it was mostly human to human. Now you're managing human to machine, machine to human, machine to machine, and still human to human. Each combination has different requirements and failure modes.
One point that stood out above all others was that AI doesn't judge whether the historical data it learns from reflects good decisions or mistakes. It just knows it needs to learn from this data. So if you're training on patterns from the past, and humans weren't always great in the past (we're still making plenty of mistakes now), you're potentially amplifying and accelerating dysfunction. The only thing preventing that is conscious human choice about what to feed these systems.
We also talked about recursive training decay. If AI only learns from AI-generated output (a.k.a. dead internet theory), everything becomes bland and low quality because there's no fresh human input, no originality, no feedback loop. Which means AI actually depends on continued human contribution to stay relevant. That dependency gets forgotten in a lot of the automation rhetoric.
For data analysts specifically, Tiankai expects their work to shift. If your stakeholders want conversational interfaces and chatbots, someone needs to build the right metadata models and metric structures underneath to make that work. That's backend work that data analysts haven't traditionally owned. At the same time, he hopes the customer thinking and design thinking parts of the role stay relevant, the parts where you're talking to stakeholders and understanding their needs. So the job might end up being more bifurcated than before, some community-facing work and more infrastructure work.
[Tiankai Feng on why humanity is the glue that holds federated data teams togetherIn Episode 4 of Couch Confidentials Powered by Martech Therapy, host Matthew Niederberger welcomes Tiankai Feng, the author of Humanizing Data Strategy. Together, they explore the intersection of data, humanity, and leadership. From responding to criticisMartech TherapyMatthew Niederberger](https://www.martechtherapy.com/tiankai-feng-on-why-humanity-is-the-81a/)
I asked him what human habit he'd delete from the codebase if he could. He said bad intentions, the deliberate choices to embed bias, create fake information, or pursue goals without regard for consequences. Those intentions are why we now need guardrails and why everyone has to be more cautious about what's real. We created the problem, then had to build controls around it.
The full conversation is on [YouTube](https://youtu.be/rik-vrJBi28?ref=martechtherapy.com). We're also giving away five copies of Humanizing AI Strategy. If you want in, react to the LinkedIn post and I'll draw names.
Tiankai thinks 2026 will bring some correction to the current AI bubble. Smaller players, more nuanced approaches, less hype. I hope he's right. The gap between what AI can technically do and what organizations are actually ready to implement well keeps widening. Maybe that forces a more honest conversation about the human behaviors that need to change before the technology can deliver on its potential.
👥 Connect with us on LinkedIn:
- Tiankai: [https://www.linkedin.com/in/tiankaifeng/](https://www.linkedin.com/in/tiankaifeng/?ref=martechtherapy.com)
- Matthew: [https://www.linkedin.com/in/matthewniederberger/](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
📲 Follow Martech Therapy on:
- Instagram: [https://www.instagram.com/martechtherapy](https://www.instagram.com/martechtherapy/?ref=martechtherapy.com)
- Youtube: [https://www.youtube.com/@martechtherapy](https://www.youtube.com/@martechtherapy?ref=martechtherapy.com)
- Bluesky: [https://bsky.app/profile/martechtherapy.bsky.social](https://bsky.app/profile/martechtherapy.bsky.social?ref=martechtherapy.com)
## Sign up for Martech Therapy
Thoughts, stories and ideas.
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
### An open letter to Martech vendors: let's do better
URL: https://www.martechtherapy.com/an-open-letter-to-martech-vendors-lets-do-better/
Last updated: 2025-12-08T09:39:29.000Z
As 2025 winds down, I’ve been thinking about all the demos I sat through this year. Probably more than any reasonable person should. And at some point you start to recognise patterns that you wish you didn’t recognise. Patterns that make buyers question their presence in the demo, glaze over, or quietly message me on Slack asking, “Did they really just say that?”
A meme floated past my LinkedIn feed a little over two weeks ago, joking that traditional platforms “*lie*”. And a screenshot sent by an industry peer from a presentation in which the vendor told the client there was “*no upgrade*” from their solution. Funny at first glance, sure, but underneath it sat something familiar. That old insecurity (*possibly stemming from* [*today’s oversaturated market*](https://www.martechtherapy.com/cdp-cep-midmarket-predictions-2026/)). The idea that the best way to look strong is to make someone else look weak. **High school brawn**. Maybe that works when you’re scrappy and unknown, but when you’re well-established and have an ARR that most companies can only dream of? It’s just odd.
[The CDP RFP Dating GameHow agencies, vendors, analysts, and executives hide behind the RFP smiles and why independence matters more than ever in selecting a CDP.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/the-cdp-rfp-dating-game/)
Buyers don’t show up for that. They show up to understand you. How you think. How you solve problems. How you’d deal with the messy reality inside their organisation. Not how loudly you can talk about someone else’s flaws.
And yet, the same jabs and boasts keep showing up in those demos:
- the little digs at competitors
- long monologues about growth, headcount, or fresh office space
- success stories that never connect to the people actually on the call
- grand claims spoken with the confidence of someone who never saw the client’s backlog
A short list of examples I have seen and heard, but you know what I mean.
What vendors sometimes forget is that remote demos changed the dynamic, too. Everyone has a back channel now. Hands up if you have one, too. Clients message me constantly during these calls with questions, confusion, sometimes outright disbelief, and, I’ll be honest, amazement, too. It's not all bad ;)
And I’m there trying, more often than I like to admit, to keep the conversation productive, steering things back to the client’s needs. I’ve jumped in more than once, politely, to interrupt the presenter because the room was losing its concentration. Asking themselves, is this presentation about their company, or how their company can help us? It’s part of how I work. I protect the client’s time, I filter out the nonsense, and I make sure we’re focusing on decisions that matter.
[Ten reasons to bring in outside expertise for your CDP RFP...and why your team will thank you. Not because every company will face all ten of these issues, but because most will recognize at least a few of them.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/ten-reasons-to-bring-in-outside-expertise/)
But here’s the thing… buyers don’t expect magic. It’s not a family trip to Disney World. They don’t even expect perfection. They just want honesty, curiosity, and a sense that you actually listened before you started selling. They want to see how you think, not how shiny your pitch deck is. They want to know how their organisation fits into your worldview, not how many logos you closed this quarter.
Also, and I say this with *affection*, no one has ever picked a platform because the vendor’s office has designer furniture. If anything, people quietly wonder who’s paying for it. **Condescension has no place in a demo**.
As we roll into 2026, it feels like the industry is overdue for a bit of maturity and balanced confidence. Less posturing, more substance. Less theatre, more conversation. And the vendors who embrace that change, who speak human, who stay curious, who don’t treat the demo as a competition, show empathy to their prospect’s needs, those are the ones buyers trust. Remember, there is a reason you have been invited to pitch.
💡
****TIP** "Customer Success" should not be a post-signature service, it should start with the introduction.
Now, if you’re a vendor and you genuinely want to know what resonates in real buying cycles, [reach ou](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)t. I sit in these conversations every week. I see what buyers react to, [what confuses them, what quietly kills the deal, and what makes them lean forward](https://www.martechtherapy.com/cdp-cep-pricing-strategies-for-the-uninitiated/). I’m always happy to share what I see from the front lines, no judgment, no brand bashing, just experience amd practical advice you can use.
The bottom line is this, and do with it what you will -> We can do better. And honestly, it would make the whole space a lot more enjoyable for everyone involved.
## Sign up for Martech Therapy
Thoughts, stories and ideas.
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
### Meet the CDP Simulator, the easiest way to finally understand your data stack
URL: https://www.martechtherapy.com/meet-the-cdp-simulator-the-easiest-way-to-finally-understand-your-data-stack/
Last updated: 2026-01-12T09:07:44.000Z
I’ve lost count of the number of times I’ve tried to explain a CDP diagram that looked like someone spilled spaghetti on a slide. If you’ve ever been in a meeting where five people are discussing “real time” and each one means something completely different, you probably know the feeling.
So instead of drawing yet another arrow-filled diagram, I built something people can actually play with.
CDP Simulator displaying David Chan's inspired Hybrid architecture.
The [CDP Simulator is now live](https://cdpsimulator.martechtherapy.com/?ref=martechtherapy.com). It’s free, and you can get started in about three seconds. No signup, no marketing pop-up asking for your email. Just a canvas that comes alive the moment you click a button.
I made it because **we all deserve a better way to understand these systems** than deciphering another vendor pitch.
## **Why I built this**
The CDP market has reached a point where three people can use the word “CDP” and mean three completely different things. Traditional, composable, hybrid, dual zone, warehouse-native, packaged… it’s no wonder teams struggle to understand how the pieces fit together.
The issue isn’t that the concepts are impossible. It’s that everything is described in abstract language. You hear about Reverse ETL but never see it doing anything. You’re told a warehouse sits at the centre of a composable stack, but that doesn’t mean much until you see the data move.
People learn faster when they can experiment. That’s the whole idea behind the simulator.
[Before you deploy your CDP, train your crewCDP projects test more than tech -> they test teams. What military work-ups taught me about readiness, response, and Martech project success.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/before-you-deploy-your-cdp-train-your-crew/)
## **So what is the CDP Simulator**
It’s a visual environment where you can toggle data sources, switch between architectures, build audiences, activate channels, and watch animated data flows travel across the screen. The simulator reacts instantly to whatever you do.
Choose your desired mode.
You pick the mode.
- Traditional CDP.
- Composable CDP.
- Hybrid CDP inspired by [David Chan’s dual zone thinking](https://medium.com/@iamdavidchan/updated-2024-the-dual-zone-manifesto-an-approach-to-cdp-that-goes-beyond-hybrid-732cf2436e4f?ref=martechtherapy.com).
The whole canvas shifts and the data behaves differently, which is exactly what you need if you’re trying to make sense of how these approaches differ in the real world.
## **Three modes that actually reflect how the market works**
### **Traditional mode**
Customizable Traditional CDP architecture.
This is the classic CDP setup most people learned first. Data goes in, identity resolution happens, segments are created, and activation pushes out to various channels. Everything sits inside one platform. It’s tidy, linear, and a nice way to show how the first generation of CDPs were designed.
### **Composable mode**
Customizable Composable CDP architecture.
Here the warehouse becomes the centre of gravity. Flip between [Snowflake](https://www.snowflake.com/?ref=martechtherapy.com) and [BigQuery](https://bigquery.google.com/?ref=martechtherapy.com) to see how little friction that creates. Swap your Reverse ETL provider. Add identity resolution. Remove identity resolution. Test different event routers. The canvas updates instantly, and you start to feel the modularity that makes this approach appealing.
### **Hybrid mode**
Customizable Hybrid CDP architecture.
This one is close to what many enterprises are quietly running today. Zone 1 holds the heavy, slow-changing data work. Zone 2 is the fast decisioning environment where journeys, offers, and real-time experiences live. Reverse ETL is the bridge between them. Seeing the two zones side by side tends to spark the “ahhh, now I get why people combine these” reaction.
## **Watching data move makes everything clearer**
One of my favourite parts is the particle system. Each data source has a colour and a rhythm. Website events fly across the screen. POS crawls at a human pace. Activation events return to enrich the profile.
See the data flow.
Toggle something off and the canvas calms down. Toggle something on and the system lights up.
It’s surprising how quickly people grasp batch versus streaming once they see it moving.
## **Segments and activation in motion**
The simulator includes eight starter audience segments.
Enable Cart Abandoners or At-Risk Churners and you instantly see which activation channels respond. Channels light up when they receive a segment and stay quiet when nothing qualifies.
Activate Segments for specific Activation channels.
It’s effortless to understand because it’s all happening right there in front of you.
## **Learn as you go**
There’s a guided tutorial baked in. It’s a short, friendly, thirteen-step walkthrough that teaches the fundamentals while you interact with the canvas. You can drag it around during exploration. It saves your progress so you can come back later.
Learn the basics of Traditional and Composable CDPs (Hybrid coming soon)
It’s the opposite of a lecture. More like someone tapping you on the shoulder and saying, “Look over here for a second, this part is important.”
## **Who this is for**
- Anyone evaluating CDPs.
- People designing architectures.
- Teams trying to build shared understanding.
- Marketers who have been quietly wondering where their data actually goes.
If you’ve ever wished you could freeze a CDP diagram and ask it to explain itself, this is your moment.
## **What’s coming next**
The current version already solves the core problem, but there’s a lot more planned. These are the features I’m working on now.
### **Playground mode**
A completely flexible canvas where you can build your own CDP architecture. Drag components wherever you want them, draw connections between them, and design your dream stack or your nightmare legacy setup.
Sneak peak of some work in progress.
### **Architecture validation**
As you build, the simulator will flag broken logic or missing pieces. No identity layer. No data route to activation. Loops that will never resolve. It won’t scold you, just give a nudge to help you build something workable.
Validation to help you build.
### **Export and share**
Create a shareable link or export your design as an image or JSON file. Perfect for workshops, training sessions, stakeholder reviews, or the inevitable “Can you send me that diagram after the meeting” moment.
### **Vendor expansion**
New tools appear every month, so I’ll keep adding vendors across categories. If your brand isn’t in the list and you want it included, just reach out. I’m not playing favourites.
Example of CEP providers available in the CDP Simulator
This roadmap turns the simulator from an educational tool into a full CDP architecture studio.
## **A closing invitation**
CDPs don’t have to feel mysterious. They don’t have to sit inside complex diagrams that only two people in the organisation fully understand. With the CDP Simulator, you can finally see these systems behave the way they’re described.
Try it. Break things. See what happens when you turn pieces off.
Use it to teach others or to make sense of your own stack.
The link is live. Have fun.
## Sign up for Martech Therapy
Thoughts, stories and ideas.
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
### When AI replaces processes, not people
URL: https://www.martechtherapy.com/when-ai-replaces-processes-not-people/
Last updated: 2025-12-02T07:58:31.000Z
I set up this conversation with [Paul Meinshausen from Aampe](https://www.martechtherapy.com/agentic-ai-and-the-art-of-letting/) and [Duarte Garrido from DOJO AI](https://www.martechtherapy.com/is-ai-the-end-of-martech-complexity-8d1/) because I've been watching the same pattern repeat across different companies. Teams bring in AI tools, get excited about automation, then hit a wall when they realize the technology isn't just doing their work faster. It's doing it differently. That difference requires a mental model most marketers don't have yet.
Watch the full episode here ☝
Paul's background is in cognitive science and decision-making under uncertainty. Duarte came up through big brand marketing before building tools for challenger brands with smaller teams. Both of them are building products that don't just automate tasks. They replace entire processes with adaptive systems. The conversation was supposed to be about their products, but we spent most of the time talking about what happens to the people using them.
[Agentic AI in Martech: The billion decision problemPart 1: Why scale changes everything about AI in MartechMartech TherapyMatthew Niederberger](https://www.martechtherapy.com/agentic-ai-in-martech-the-billion/)
The core tension showed up early. I mentioned that when I saw demos of both products, my brain kept trying to map them onto existing workflows. That's the problem. Rule-based thinking doesn't translate to adaptive systems. Paul explained it through something called **data generating processes**, the idea that the context in which you collect data shapes what you learn from it. Ask someone about their banking needs as they enter a bank versus as they leave a grocery store, and you'll get different answers. AI can work with that kind of contextual variation at scale. Humans can't.
"****Context is critical** because context represents all the factors that represents that person's situation in the world where they are. You got to have a human who can think about that context, constructing it, constructing systems for it, doing the engineering side of it."
\~ Paul Meinshausen
Duarte put it more bluntly:
> "The skill set of a modern marketer is to understand how systems work and how to maximize those systems, not necessarily to know how to use Google Ads."
That's an uncomfortable statement for anyone who built a career on platform expertise. Google Ads isn't going away, but knowing the interface won't matter if AI already knows it better than you do. What matters is whether you can design the system that tells AI what outcomes you want and in what contexts.
This connects directly to organizational readiness, something I've been exploring through the Martech Readiness Framework. Structure, capability, and process all have to shift when adaptive systems come in. Most companies are set up to optimize execution. They're not set up to manage systems that learn and adjust on their own. That's a capability gap, but it's also a structural one. Marketing and sales teams that don't talk to each other can't suddenly coordinate around a shared AI orchestration layer without changing how decisions get made.
[Agentic AI & the art of letting goA candid chat with Aampe’s Paul Meinshausen on agentic AI, leadership, and why letting go of control might be the key to moving forward.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/agentic-ai-and-the-art-of-letting/)
We suggested some new roles worth thinking about:
- copy systems designers
- agent handlers (my *Cold War* reference... I've read too many spy novels)
- context engineers
These aren't just rebranded versions of existing jobs.
A **copy systems designer** isn't a copywriter who uses AI. They're someone who designs the logic that determines which message gets delivered in which context to which person.
An **agent handler** isn't a project manager. They're coordinating multiple autonomous systems that are making decisions faster than humans can review them.
A **context engineer** is building the frameworks that help AI understand situational variables like weather, location, time of day, and emotional state.
[Is AI the end of Martech complexity? Dojo AI founders explainIn this episode of Couch Confidentials, I sat down with Duarte Garrido and Antonio Alegria from Dojo AI to talk about one of the biggest problems in marketing today—too many tools, not enough results. With over 15,000 marketing technology solutions on theMartech TherapyMatthew Niederberger](https://www.martechtherapy.com/is-ai-the-end-of-martech-complexity-8d1/)
Duarte added another angle I hadn't considered. He thinks *AI creates opportunities to bridge functions* that were historically siloed. Marketing and sales. Product and go-to-market. These boundaries existed because coordination was expensive and slow. If AI can move information and adjust strategies across those boundaries in real time, the silos stop making sense. That means new roles at the intersections. Not marketing people who learn sales. People who think in terms of integrated growth systems.
The conversation ended with **advice for anyone trying to navigate this shift**.
**Paul's take**: do the work. Build something. Simulate solutions. Show up with examples of systems you've designed, not just tasks you've completed.
**Duarte's take**: position yourself at the intersection of departments where AI is breaking down old barriers. Don't wait for someone to define the role. Define it yourself.
I recorded the full conversation and posted it on YouTube if you want to hear r watch the details. Link below. This is one of those topics where the implications take time to settle. I'm still working through what it means for how I advise companies on CDP implementations and orchestration strategies. Curious if anyone else is seeing this pattern in their own work.
👥 Connect with us on LinkedIn:
- Paul Meinshausen: [https://www.linkedin.com/in/paulmeinshausen/](https://www.linkedin.com/in/paulmeinshausen/?ref=martechtherapy.com)
- Duarte Garrido: [https://www.linkedin.com/in/duartegarrido/](https://www.linkedin.com/in/duartegarrido/?ref=martechtherapy.com)
- Matthew: [https://www.linkedin.com/in/matthewniederberger/](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
📲 Follow Martech Therapy on:
- Instagram: [https://www.instagram.com/martechtherapy](https://www.instagram.com/martechtherapy/?ref=martechtherapy.com)
- Youtube: [https://www.youtube.com/@martechtherapy](https://www.youtube.com/@martechtherapy?ref=martechtherapy.com)
- Bluesky: [https://bsky.app/profile/martechtherapy.bsky.social](https://bsky.app/profile/martechtherapy.bsky.social?ref=martechtherapy.com)
## Sign up for Martech Therapy
Thoughts, stories and ideas.
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
### Negotiating the New Martech Economy
URL: https://www.martechtherapy.com/negotiating-the-new-martech-economy/
Last updated: 2025-11-25T08:31:12.000Z
The reactions to last week's part 2, [The inherited costs of the composable stack](https://www.martechtherapy.com/the-inherited-costs-of-the-composable-stack/), revealed something important about Martech today. People disagreed with one another, yet they were all touching the same truth from different angles. Some pointed out that composable savings mostly show up in use-case velocity rather than infrastructure. Others argued that cloud costs are a black box, no matter what you buy. A few reminded us that the data warehouse remains the gravitational center regardless of whether your CDP is composable or packaged.
What everyone circled around, though, was the same underlying question: **who holds the complexity?**
That’s the starting point for every meaningful negotiation.
- A composable stack can empower your teams or overwhelm them.
- A packaged suite can simplify life or quietly slow everything down.
The list price is the least interesting part of the deal. What matters is where the ongoing work lands.
This series' initial article, [CDP & CEP pricing strategies for the uninitiated](https://www.martechtherapy.com/cdp-cep-pricing-strategies-for-the-uninitiated/), looked at what pricing *says*. The second part, [The inherited costs of the composable stack](https://www.martechtherapy.com/the-inherited-costs-of-the-composable-stack/), explored what pricing *hides*. In this last part, I will focus on what you can realistically *negotiate* once you understand how responsibility moves through your stack.
## Negotiating ownership, not licenses
Most contract discussions begin with discounts, term length, or which modules to include, offset against the volume data you need to dig up. But long-term value rarely comes from these levers. **The real negotiation is about ownership**. Not legal ownership, but actual operational ownership. The question is simple (although the execution is challenging): who is responsible for keeping this thing alive?
Every system needs care. Care for when pipelines break, schemas get updated, integrations change versions, or models need recalibration. You are either paying a vendor to carry this work, or you’re absorbing it yourself. Once that becomes the framing, the rest of the negotiation opens up naturally. You can ask more grounded questions about maintenance expectations, integration health, monitoring responsibilities, and the level of internal expertise needed to keep things stable.
This is where the conversation becomes honest. You’re no longer negotiating features, but you’re negotiating where the weight of the system sits. The easiest metaphor I use in this case is buying a car versus leasing a car. One forces you to take on maintenance responsibilities, while the other shifts them elsewhere.
## The warehouse reality
One of the most helpful perspectives raised after part 2 was that the data warehouse never left the picture. Even in the age of packaged CDPs, the warehouse has remained the anchor for identity, reporting, and analytics. With composable architectures, its influence continues to grow.
This is why negotiations should spend more time on the relationship between the CDP, your data model, and your warehouse. A vendor who aligns cleanly with your existing warehouse strategy will look very different from one who expects heavy restructuring. Some solutions depend on real-time warehouse freshness, while others assume ingestion into their own environment first.
The outcome of the negotiation depends on how well your data foundation supports the vision you’re buying into. If your warehouse is strong, you can lean into composability. If it’s inconsistent or fragmented, a packaged suite may absorb more of the instability. This isn’t about personal or HiPPO preference, or at least it shouldn't be. It’s about **acknowledging the architecture you actually have**, not the one you wish you had.
## The velocity question
One comment that stood out was the idea that composable savings often come from speed. That’s true, but only when the organization can translate flexibility into delivery. It’s easy to say, “we’ll move faster”, but it's an entirely different thing to prove it.
Comment by [Harsh Chaudhary on LinkedIn](https://www.linkedin.com/feed/update/urn:li:activity:7396115607198306304?commentUrn=urn%3Ali%3Acomment%3A%28activity%3A7396115607198306304%2C7396174383427301376%29&dashCommentUrn=urn%3Ali%3Afsd%5Fcomment%3A%287396174383427301376%2Curn%3Ali%3Aactivity%3A7396115607198306304%29&ref=martechtherapy.com)
This part of the negotiation becomes a conversation about patterns. Ask vendors how quickly teams typically activate their first real use cases, not just how fast the platform can theoretically move. Discuss the types of customer journeys that usually go live first, and how much vendor involvement is needed during the early months. Explore how integrations behave under pressure during peak campaigns.
[The reference call that changed everythingA reminder, based on a true story, that even when teams do their homework, the CDP market still stacks the deck, and what to do about it.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/the-reference-call-that-changed-everything/)
If a vendor claims velocity is the value driver, they should be able to describe that velocity in stories, not slogans.
## When definitions blur
Another important thread was the realisation that many debates happen because people aren’t talking about the same thing. **Composable versus packaged is a spectrum, and yet we often treat it as a binary.** Confusion emerges quickly when buyers and vendors use identical terms with different meanings.
A negotiation can fall apart simply because “event”, “connection”, or “active profile” means something different to each side. Instead of listing definitions, a clearer approach is to frame them through their impact:
| Term | Why it matters | What often goes wrong |
| ---------------------------- | -------------------------------- | ----------------------------------------------- |
| **Event** | Drives cost for many CDPs | Vendors count ingested vs processed differently |
| **Active profile** | Basis for MTU/MAU billing | Anonymous users sometimes included unexpectedly |
| **Connection / Destination** | Indicates maintenance and effort | Often misinterpreted as one-click integrations |
The moment both sides agree on vocabulary, the rest of the negotiation becomes dramatically simpler.
## The visible tip of the CX iceberg
A presales leader mentioned he keeps a slide titled “The Hidden Costs of CX”. The joke was lighthearted, but the point is serious in that everyone in Martech acknowledges hidden costs, they just highlight different ones depending on what they sell.
Comment by [Steven Biss on LinkedIn](https://www.linkedin.com/feed/update/urn:li:activity:7396115607198306304/?dashCommentUrn=urn%3Ali%3Afsd%5Fcomment%3A%287396223318300966915%2Curn%3Ali%3Aactivity%3A7396115607198306304%29&ref=martechtherapy.com)
Your job during negotiation is not to eliminate hidden layers. It’s to understand where they sit and whether your team can absorb them. Vendors position their blind spots as benefits. Buyers often underestimate what will land internally. A strong negotiation bridges that gap.
## The organisational dimension
One of the most thoughtful contributions came from a discussion about how composable architectures shape organisational behaviour. A composable stack rarely becomes the bottleneck itself, but the data and engineering support around it does. New segments, new journeys, new touchpoints -> all of it eventually routes back through resource queues that haven’t grown at the same pace.
Comment by [Matthew Lee on LinkedIn](https://www.linkedin.com/feed/update/urn:li:activity:7396115607198306304?commentUrn=urn%3Ali%3Acomment%3A%28activity%3A7396115607198306304%2C7396306222452416512%29&dashCommentUrn=urn%3Ali%3Afsd%5Fcomment%3A%287396306222452416512%2Curn%3Ali%3Aactivity%3A7396115607198306304%29&ref=martechtherapy.com)
This is where negotiations shift from technology to team design. A vendor might promise flexibility, but if your internal Martech and engineering capacity can’t support the amount of choice you’re buying, the architecture will feel slower, not faster.
So the negotiation becomes a conversation about cadence. Does your organisation move at the speed its architecture enables? Or will your architecture outpace your team’s ability to operate it?
## A conversational negotiation framework
Instead of a checklist, the negotiation can be framed as a set of intertwined conversations:
1. You’re clarifying **who owns the ongoing work**, not who has the cheaper feature.
2. You’re establishing **what the core terms actually mean**, so billing doesn’t drift over time.
3. You’re exploring **how quickly real use cases can be delivered**, not just promised.
4. You’re understanding **how tightly the CDP or CEP aligns to your warehouse**, because misalignment adds effort immediately.
5. And you’re mapping **support expectations**, both technical and organisational, to avoid surprises.
These conversations do more than protect you from a bad contract. They make it possible to get full value from a good one.
## Some final thoughts
Negotiating Martech isn’t (always) a matter of squeezing vendors on price. It’s a matter of understanding the shape of your own organisation and how it carries responsibility. Every model, be it packaged, composable, or hybrid, comes with invisible obligations. The only question is whether those obligations match your capability and ambition.
So if part 1 taught us how to read pricing, and part 2 revealed what pricing hides, this left part 3 to be about navigating the reality in between, where decisions stop being about tools and start being about the people who run them.
In the end, the most important negotiation you will ever have is not with a vendor. It’s with your own capacity.
Do you have any questions after reading this article?
Or need support with your Martech projects?
[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
Or stay up to date on all things Martech by **subscribing for free** 👇🏻
## Sign up for Martech Therapy
Thoughts, stories and ideas.
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
### Should your CDP take a year to implement? Zeotap CEO Elad has thoughts
URL: https://www.martechtherapy.com/should-your-cdp-take-a-year-to-implement-zeotap-ceo-elad-has-thoughts/
Last updated: 2025-11-24T09:35:56.000Z
If you ever wanted to hear two grown men bond over Bayern Munich, data sovereignty, and the existential mystery of why CDP projects take *a year and a half* to get going, you’re in the right place.
This week on **Couch Confidentials**, I sat down with **Elad Simchon**, CEO – sorry, **ZEO...** of Zeotap. Yes, *ZEO*. I accidentally coined the term mid-recording, and Elad immediately claimed it for the brand. Fair play.
Our chat was one of the most jovial conversations I’ve had all season. We wandered everywhere: his “midlife-crisis startup,” Germany’s secret basketball empire, DMEXCO survival tips, why [CDPs are basically mirrors for your internal chaos](https://www.martechtherapy.com/your-cdp-is-more-than-just-a-platform/) (we shared similar views here), and even a small detour into whether being a Bayern Munich fan is a contractual obligation. (Not to spoil the fun... You only have to *pretend.*)
Elad also explained the *actual* story behind that [LinkedIn rumor that Zeotap had been sold](https://www.linkedin.com/posts/carstenfrien%5Fbig-news-from-roqad-and-zeotap-were-excited-activity-7368633096348381184-IVgA?utm%5Fsource=share&utm%5Fmedium=member%5Fdesktop&rcm=ACoAAACEYHcBK5DlgsJ%5FgicIWSce8EBSwO4medQ). I'll save you some time... it hadn’t. They only sold their legacy ad-tech data unit, kept the IP, and partnered with the buyer so tightly it might as well have never left. Internet conspiracy theorists everywhere -> sit down 😉
We also got into the serious stuff, but in the same laid-back way.
- Why European enterprises still hesitate with US vendors.
- Why schema-forced CDPs feel like you’re moving house with a piano strapped to your back.
- Why “zero copy” is sometimes more marketing than math.
And what Zeotap is actually cooking with AI for 2026\. (Here's a hint: real “talk to your data” capabilities that finally look like they might deliver on the promise we’ve been hearing since 2010.)
I hope you enjoy this conversation as much as I enjoyed recording it. In true Martech Therapy fashion, we tried to focus on where the Martech brain meets the “let’s just be honest about how this stuff actually works” side of the industry.
Grab a coffee, come hang out on the couch, and meet the ZEO.
👥 Connect with us on LinkedIn:
- Elad: [https://www.linkedin.com/in/elad-simon/](https://www.linkedin.com/in/elad-simon/?ref=martechtherapy.com)
- Matthew: [https://www.linkedin.com/in/matthewniederberger/](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
📲 Follow Martech Therapy on:
- Instagram: [https://www.instagram.com/martechtherapy](https://www.instagram.com/martechtherapy/?ref=martechtherapy.com)
- Youtube: [https://www.youtube.com/@martechtherapy](https://www.youtube.com/@martechtherapy?ref=martechtherapy.com)
- Bluesky: [https://bsky.app/profile/martechtherapy.bsky.social](https://bsky.app/profile/martechtherapy.bsky.social?ref=martechtherapy.com)
## Sign up for Martech Therapy
Thoughts, stories and ideas.
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
### The inherited costs of the composable stack
URL: https://www.martechtherapy.com/the-inherited-costs-of-the-composable-stack/
Last updated: 2025-11-17T09:12:47.000Z
Last week, in the first part of this series, I shared some experiences on[ how to read Martech pricing](https://www.martechtherapy.com/cdp-cep-pricing-strategies-for-the-uninitiated/). In this second part, I want to examine the other end of the product spectrum and learn to *live with it*. Once you understand how vendors define usage, value, and fairness, a new question appears:
> What happens when you try to escape those models altogether?
That’s where [composability enters the story](https://www.martechtherapy.com/are-we-still-comparing-composable-cdps-to-packaged-cdps/). It promises freedom from rigid licenses, bundled modules, and predefined ways of working. Build your own stack, plug in best-of-breed tools, let each component scale on its own terms. On paper, it feels like the antidote to everything Part 1 revealed.
But... **freedom has an operational cost**. When you stop paying vendors to manage complexity for you, that complexity doesn’t disappear, it moves in-house. The subscription line goes down, but another line rises in its place, such as engineering time, maintenance, monitoring, cloud usage, and orchestration overhead.
So while [part 1 examined what pricing *says*](https://www.martechtherapy.com/cdp-cep-pricing-strategies-for-the-uninitiated/), this article looks at what pricing *skips*. Because the real bill for a composable stack is rarely the one you sign. It’s the one you inherit.
## **The promise of composability**
Composable Martech didn’t start as a financial movement. It began as a cultural one. Engineers wanted cleaner architectures, product teams wanted flexibility, and marketers wanted to stop waiting in ticket queues. Self-serve galore.
The [MACH Alliance](https://machalliance.org/?ref=martechtherapy.com) turned those ideas into a manifesto:
- **M**odular
- **A**PI-first
- **C**loud-native
- **H**eadless.
Each acronym spoke the same language of freedom.
And to be fair, **composability does deliver on many of its promises**. It encourages experimentation, speeds up iteration, and lets companies swap tools as they grow. For organizations with strong internal capabilities, it’s the first model that truly scales with ambition.
The trouble starts when ambition outruns capacity. Flexibility feels free... until you have to operate it. The more control you take on, the more invisible work you inherit with tasks like monitoring integrations, managing schema drift, tracking costs across APIs, and cloud workloads.
That’s where composability shifts from a technical decision to a financial one, and why understanding its hidden costs has become as important as understanding your stack’s design.
[Governance is everything: Simo Ahava on making GTM a bridge, not a back doorSimo Ahava joins Couch Confidentials to talk GTM as a bridge between marketing and engineering, why governance beats hacks, how BigQuery replaced the GA UI for real work, and where AI helps or hurts. Practical, candid, and immediately useful.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/governance-is-everything-simo-ahava-on-making-gtm-a-bridge-not-a-back-door/)
Simo: “Flexibility doesn’t remove complexity, it only shifts where the complexity lives. You don’t get rid of the operational burden, you just bring it closer to your own teams.”
## **Where the money actually moves**
Composable stacks rarely collapse due to technology problems. They often collapse under the weight of maintenance. Each added service, connection, or pipeline introduces a small piece of overhead, none of which is significant on its own, but together they form a permanent layer of operational tax.
When companies calculate the savings from dropping enterprise suites, they often forget what replaces them: **people** & **processes**.
| **Cost type** | **How it appears** | **What’s often missed** |
| --------------------- | -------------------------------------------------------------------------------- | ----------------------------------------------- |
| **Human cost** | Data engineers, analytics engineers, DevOps, QA, FinOps, and solution architects | Ongoing skill premiums and turnover risk |
| **Architecture cost** | Cloud compute, storage, reverse-ETL runs, retries, observability | Costs scale with experimentation and API volume |
| **Integration cost** | Maintenance, schema drift, version upgrades, monitoring | Each connection becomes its own micro-project |
| **Governance cost** | Data quality checks, privacy audits, compliance | Manual oversight grows with every new tool |
Composable systems shift the financial center of gravity from licenses to operations. Vendors stop billing you for packaged services, and instead, you start billing yourself for the time and cloud cycles required to keep everything synchronized.
## **The illusion of reuse**
One of the core promises of composability is reusability, something that boils down to "build once, use everywhere".
But reusable components still require re-testing, schema validation, and API updates with each new integration. Every “plug and play” connection hides a recurring cost in QA and governance.
It saves code, not time.
Teams often discover this when onboarding new channels. What looks like an easy connection becomes another sprint’s worth of coordination between Martech, product, and data engineering.
A composable setup gives you creative freedom, but that creativity comes with the same accountability as code.
## **The human factor**
In traditional Martech suites, you pay vendors for predictability. In composable setups, you pay your people for resilience.
That change sounds empowering, and it can be, but it comes with new dependencies. Think along the lines of specialized skill sets, role overlap, and the ongoing cost of coordination.
Source: [IT Jobs Watch UK](https://www.itjobswatch.co.uk/jobs/uk/data%20engineer.do?ref=martechtherapy.com)
Source: [IT Jobs Watch UK](https://www.itjobswatch.co.uk/jobs/uk/data%20analytics%20engineer.do?ref=martechtherapy.com)
Composable teams need builders, not just operators. And builders are expensive. Salaries for experienced data engineers and analytics engineers have risen faster than SaaS inflation. Add in onboarding, knowledge transfer, and context switching between multiple tools, suddenly the “savings” from skipping a suite license disappear into payroll.
👉🏻
Flexibility is only an advantage if you have the people and process discipline to sustain it.
## **The architecture paradox**
Composable stacks start out lean and elegant. Then they grow.
Each new tool promises better control or capability, but every addition adds coordination. Over time, that coordination becomes the architecture. What was meant to be a set of modular choices turns into an ecosystem that demands constant orchestration.
\[Visual prompt: a stacked diagram showing “Data warehouse at center → Reverse ETL → Activation tools → Channels,” surrounded by monitoring and QA layers.\]
When you map total cost of ownership (TCO) over three years, the pattern often reverses expectations. Year one looks cheaper. Year two breaks even. By year three, ongoing operations surpass the old suite license.
👉🏻
Integration debt behaves like compound interest ➡️ invisible at first, costly later.
## **Control, but at what price?**
Composable systems return control to the organization, but control is not free. Every new freedom, self-hosting, custom routing, in-house identity, creates a new responsibility.
You stop paying vendors to handle risk, and start paying internal teams to carry it.
That’s not a bad trade if you need sovereignty or unique orchestration. But it changes your risk profile. Vendors have SLAs and global redundancy, while internal teams have calendars and competing priorities.
Control, in this sense, is a cost category disguised as a benefit.
## **How to calculate composable TCO**
There’s no single formula, but there are common blind spots.
Direct costs are easy, a sum of tool subscriptions and cloud usage. Indirect costs are harder. How do you put an accurate price on people, partners, downtime, and lost velocity? Then comes volatility, the rate at which these costs change with scale.
| **Cost category** | **Suite approach** | **Composable approach** | **Risk factor** |
| ----------------- | ------------------------------- | ------------------------------ | ------------------------ |
| **Licensing** | Fixed multi-year contract | Variable modular subscriptions | Predictable vs. flexible |
| **People** | Fewer, vendor-trained operators | More, engineering-heavy teams | Skill scarcity |
| **Cloud** | Included in license | Billed per run/query/storage | Volatile at scale |
| **Support** | SLA-backed vendor | Internal/partner-managed | Response time |
| **Governance** | Vendor policy | Internal compliance | Audit burden |
Treat composable adoption less like a procurement decision and more like an engineering investment. The return is flexibility, but the maintenance is forever.
## **When composable makes sense**
Composable isn’t a mistake. It’s just not a shortcut as it is often made out to be.
It works beautifully for teams with mature data infrastructure, in-house engineering talent, and the appetite to own their stack. It also fits organizations experimenting with AI-native workflows or real-time orchestration, where customization outweighs simplicity.
But for smaller teams, junior teams, or overstretched departments, composability can introduce more friction than freedom. The question isn’t “is composable better?” It’s “are we ready to operate like a software company?”.
Remember, freedom without capacity is chaos.
[Contextual CDPs: Composable, not chaoticPart 5 of 6: How to make composable CDPs context-aware without chaos. Sequence, scaffolding, and explainability are the new essentials.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/contextual-cdps-composable-not-chaotic/)
## **Some final thoughts**
In Martech, every pricing model hides a workload. Suites sell convenience. Composable platforms sell control. Either way, you pay for someone to hold the complexity, the only question is who.
Part 1 explored what pricing *says*; Part 2 has looked at what it *hides*. In Part 3, we’ll explore the middle ground: how to negotiate across both worlds, and what leverage still works when vendors start pricing in definitions instead of discounts.
## **"Negotiating the New Martech Economy" releases next week.*
Subscribe so you don't miss it 👇🏻
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
### CDP & CEP pricing strategies for the uninitiated
URL: https://www.martechtherapy.com/cdp-cep-pricing-strategies-for-the-uninitiated/
Last updated: 2025-11-12T13:31:08.000Z
Every vendor promises the same thing *“you only pay for what you use”.*
It’s a comforting line, one that suggests control and fairness. But in Martech, especially when you look at [Customer Data Platforms](https://www.martechtherapy.com/tag/customer-data-platform/) (CDPs) and [Customer Engagement Platforms](https://www.martechtherapy.com/tag/customer-engagement-platforms/) (CEPs), the definition of *use* changes depending on who you ask.
Most **CDPs** still price around data management, how many profiles you store, how many events you collect, or how many systems you connect. It’s a model born from infrastructure.
Meanwhile, **CEPs** are leading the move toward usage-based pricing, a model built on engagement itself. Platforms like [Braze](https://www.braze.com/?ref=martechtherapy.com) and [Zepic](https://www.zepic.com/?ref=martechtherapy.com) now let clients pay for *communication moments* rather than for stored data. Every push, email, or in-app message becomes a measurable transaction. Others, like [mParticle](https://www.mparticle.com/?ref=martechtherapy.com), experiment with hybrid credit systems that let you flex your budget across modules such as ingestion, activation, or AI.
At first glance, this feels more transparent. You pay for value in motion, not data at rest. But the more you study these models, the clearer it becomes, but **transparency doesn’t mean simplicity**.
[What are we even buying?Multi CDP Part 4: The CDP category reckoning is nighMartech TherapyMatthew Niederberger](https://www.martechtherapy.com/what-are-we-even-buying/)
### The geometry of pricing
Pricing in Martech mirrors how each vendor understands value.
- CDPs live close to the data layer, so cost scales with storage, volume, and transformation.
- CEPs live close to the customer layer, so cost scales with engagement frequency.
CDPs positioning has remained quite fixed, compared to CEPs reaching out towards data ingestion, identity resolution, and segmentation.
That difference sounds obvious, yet it’s the source of endless confusion. Both camps talk about *usage*, but one means *data usage* and the other means *communication usage*.
A CDP might call 10 million tracked events “usage”. A CEP might call 10 million sent messages the same thing. On paper the units look identical. In reality they describe two very different types of activity: one analytical, one experiential.
[Ten reasons to bring in outside expertise for your CDP RFP...and why your team will thank you. Not because every company will face all ten of these issues, but because most will recognize at least a few of them.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/ten-reasons-to-bring-in-outside-expertise/)
### Decoding what “usage” really means
Traditional CDPs meter value in data terms:
| **Metric** | **What it represents** |
| ------------------------------ | ---------------------------------------------------------------- |
| **Profiles / Records** | How many individuals, known and anonymous, sit in your system |
| **MTUs / MAUs** | Profiles that generated or received data within a billing period |
| **Events** | The behavioral exhaust from your apps and sites |
| **Connections / Destinations** | The number of data pipelines you maintain |
| **Modules** | Extras like AI scoring, consent, or identity graphs |
CEPs, on the other hand, meter value in engagement terms:
| **Metric** | **What it represents** |
| ------------------------------------- | ---------------------------------------------------------------------- |
| **Messages or communication moments** | Pushes, emails, in-app cards, content updates |
| **Data points** | Write actions that update customer attributes |
| **Credit pools** | Flexible budgets you can allocate toward the features that matter most |
This is the real divide. CDPs charge for the **data you hold**; CEPs charge for the **actions you take**.
### When fairness gets complicated
Usage-based pricing sounds democratic, pay only for what you use. But what you *use* depends entirely on your business model.
A travel company that tracks millions of micro-events per booking will experience event-based pricing very differently from a subscription service with a small, loyal customer base. Likewise, a brand campaigning with daily push notifications will see a very different usage curve from one that only emails monthly newsletters.
That’s why two organizations on the same platform can see wildly different bills.
**Braze**, for example, now offers some customers the option to move from its older *data-point* model to a *true usage*model. It’s flexible, and for some, fairer, but several renewal stories suggest it can be **more expensive** for brands with high automation or frequent communication cycles.
Event-based CDP pricing can show the same bias in reverse. It can be great for efficient tracking setups, but punishing for those with exploratory teams that instrument every action.
In both worlds, the model quietly rewards some business patterns and penalizes others. That’s why it’s crucial to map your pricing sensitivity to your actual communication reality before signing anything.
Because pricing isn’t only a vendor tactic, it’s a mirror of how your organization operates.
### When overages write the future
Every SaaS contract includes a “fair-use” or “burst” clause. It sounds friendly, a little cushion for growth, or initial loading of data, but that line item often defines your renewal.
A few extra million events, a coding error (*yes, been there and done that*), or a seasonal send spike can push you over your contracted threshold within weeks. Vendors will true-up the difference at renewal and quietly adjust your baseline upward. What started as a one-off success becomes a permanent price floor.
For CDPs, overages usually come from data spikes, new tracking, campaign tagging, or product instrumentation. For CEPs, they stem from engagement surges like a new messaging journey, a big sale, or a re-activation campaign.
The smartest teams negotiate **growth buffers** upfront. With that I mean predefined headroom for natural expansion that doesn’t trigger immediate penalties. Even five to ten percent can make a difference when the next product launch hits.
### Why comparisons break down
Comparing CDP and CEP pricing is like comparing the price of storage with the price of electricity. One keeps your data safe while the other powers what you do with it.
Even within the same category, language varies. Some CDPs count every anonymous profile when others only known ones. One measures events ingested and another events processed. Some CEPs bill by contact, others by message, and some by both.
Then come hybrids like [Bloomreach Engagement](https://www.bloomreach.com/?ref=martechtherapy.com), which combines a module-based subscription with expected usage levels per channel. You pay for the capability plus a forecasted volume, not for every profile or every send.
So when you stack up quotes, you’re not comparing like-for-like, you’re comparing worldviews.
### Reading a quote like a strategist
When you receive a proposal, read it backwards. Find the metric that actually drives the total cost. If it’s events, map where they come from. If it’s profiles, clarify what counts as active. If it’s usage, model your typical campaign cadence, including your peaks, not your averages.
| **Meter type** | **What it means** | **Hidden risk** | **What to clarify** |
| ------------------------------------ | -------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------------------------------- |
| **Profiles / Records** | The total number of customer identities stored in your CDP | Duplicate profiles or inactive users can inflate your bill | Define “active” and confirm if anonymous profiles are counted |
| **Events** | Every tracked behavior (click, purchase, view) captured from apps or sites | Event spikes from testing or analytics tags can trigger overages | Clarify if pricing is for events *ingested* or *processed* |
| **MTUs / MAUs** | Monthly Tracked or Active Users who generated data or were targeted | Definitions vary widely; some vendors count all data changes | Ask for written definitions and examples in your contract |
| **Messages / Communication moments** | Pushes, emails, or in-app deliveries that reach users | Frequent automation or retries can multiply billable sends | Confirm if retries, previews, or API tests count as messages |
| **Data points** | Profile write actions or updates in engagement platforms | Rapid attribute updates can consume quota quickly | Clarify if updates batch together or count individually |
| **Credit pools / Usage budgets** | Flexible credit systems you can spend across modules | Burn rate is hard to predict; costs can move between teams | Ask how credits are measured, reset, and repriced at renewal |
This exercise isn’t about catching vendors out, not in the least. It’s about understanding the rules of their economy. Once you know what moves the number, you can align your internal habits to it or negotiate the definition itself.
It’s astonishing how often definitions change mid-contract. A “tracked event” might later become a “processed event.” A “message” might expand to include in-app impressions. Having those terms locked in writing is worth more than a small discount.
### When price stops being the point
The easiest mistake in Martech is to treat cost as the enemy. Price only matters relative to outcome. If a platform helps you run smarter campaigns, shorten lead time, or reduce manual data work, the higher invoice might still represent a better deal.
Pricing, in the end, is a language for describing **value movement**. The question is whether that movement aligns with your goals.
If your CDP contract measures data quality and accessibility, invest in keeping your data clean and valuable. If your CEP contract measures communication moments, invest in relevance and efficiency so every message earns its cost.
The goal isn’t to game the model but to understand what it rewards and to **make that reward system work for you**.
### Before I go, let me leave you with this
There’s no universal “right” pricing model. Event-based, profile-based, usage-based, each has its own truth, and each exposes a different aspect of how you operate.
So, before you negotiate your next renewal, step back and ask:
- What does our current pricing model say about how we work?
- Does it still fit the way we communicate with customers?
- And if the platform truly helps us grow, at what point does the conversation shift from cost to value?
Pricing tells only half the story. Even when you understand every meter and definition, the real costs often start after the contract is signed, in the teams, tools, and cloud cycles that keep your data flowing. That’s where we’ll go next, in **Part 2: The Hidden Costs of Composability**, an inside look at why “paying less for software” can still mean spending more to make it work.
## Don't miss part 2 of this series.
Subscribe for free 👇🏻
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
### Crossing worlds: Teik Chua on Martech, culture, and the global CDP perspective
URL: https://www.martechtherapy.com/crossing-worlds-teik-chua-on-martech-culture-and-the-global-cdp-perspective/
Last updated: 2025-11-06T07:00:09.000Z
When you’ve spent most of your career in one market, it’s easy to assume Martech challenges are universal. But move across regions, and suddenly familiar frameworks start to look very different.
That’s what struck me while talking to **Teik Chua**, now Head of AdTech & Audience at **O2 Virgin Media**, who previously worked across **Southeast Asia** with **Accenture** and other large consulting projects. Teik has seen Martech maturity through several lenses, from fast-moving experimentation in Asia to slower, highly structured transformation programs in Europe.
> “Consulting gives you frameworks, but leading Martech in-house teaches you patience. You can’t just walk in and roll out a playbook. You have to learn how things really get done, who influences what, and where you can create small wins that build momentum.”
What stood out most was his calm, matter-of-fact way of describing those differences. In Asia, he said, “**experimentation comes first, governance follows**.” Teams are used to testing ideas quickly, adapting, and only formalizing processes once they’ve proven value. In contrast, European organizations tend to start with frameworks and control, often at the cost of momentum.
It reminded me of conversations I’ve had with enterprise teams here: everyone talks about agility, but very few are comfortable with the cultural discomfort that comes with it. Teik’s perspective quietly exposes that truth, that **you can buy the same tools, but you can’t buy the same culture.**
> “Transformation is often described as a technology challenge, but really it’s about comfort with change. The systems can work; the question is whether the people feel safe enough to change how they work.”
We also spoke about how his time in consulting shaped his leadership style. Frameworks and methodologies are useful, he said, but only to a point. At O2 Virgin Media, the real challenge lies in applying those frameworks in an environment where legacy systems, historical roles, and organizational politics all intersect. That’s where patience and soft influence start to matter more than strategy decks.
There’s a subtle irony in the conversation: as Martech becomes more standardized globally, its success still depends on the most unstandardized variable — people. Teams that learn to **listen across cultures**, not just departments, tend to make Martech work better.
> “Every market thinks it’s unique, but the core problems are the same: data quality, alignment, trust. What changes is how honest people are about it. In Asia, people talk about the mess openly. In Europe, it’s hidden behind slides.”
So this episode isn’t just about CDPs or transformation. It’s about learning to see beyond your own context and realizing that maturity isn’t a fixed destination, but a cultural posture.
👥 Connect with us on LinkedIn:
- Teik: [https://www.linkedin.com/in/teikchua/](https://www.linkedin.com/in/teikchua/?ref=martechtherapy.com)
- Matthew: [https://www.linkedin.com/in/matthewniederberger/](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
📲 Follow Martech Therapy on:
- Instagram: [https://www.instagram.com/martechtherapy](https://www.instagram.com/martechtherapy/?ref=martechtherapy.com)
- Youtube: [https://www.youtube.com/@martechtherapy](https://www.youtube.com/@martechtherapy?ref=martechtherapy.com)
- Bluesky: [https://bsky.app/profile/martechtherapy.bsky.social](https://bsky.app/profile/martechtherapy.bsky.social?ref=martechtherapy.com)
## Sign up for Martech Therapy
Thoughts, stories and ideas.
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
### Aampe and DOJO AI show why AI-native marketing starts with people, not tools
URL: https://www.martechtherapy.com/aampe-dojoai-why-ai-native-marketing-starts-with-people-not-tools/
Last updated: 2025-11-03T07:00:24.000Z
As I stated on LinkedIn last week, it was a wild week of news. Lee Hammond mapped the chaos in a [post on LinkedIn](https://www.linkedin.com/feed/update/urn:li:activity:7390082485067374593/?ref=martechtherapy.com) after his visit to CDP World, while [David Raab imagined the redesign](https://www.linkedin.com/feed/update/urn:li:activity:7389735950639312896/?ref=martechtherapy.com) after challenging ChatGPT. And somewhere between the two, I found myself in a demo with [Aampe](https://www.aampe.com/?ref=martechtherapy.com), realizing just how hard it is to *think* differently.
Towards the end, I stopped Aampe’s [Amaan Kulatunga](https://www.linkedin.com/in/amaan-kulatunga-79a9711b6/?ref=martechtherapy.com) and admitted, almost out loud:
> *I’m still trying to fit this into campaign logic.*
I was still thinking like a marketer from 2015\. And that, I suspect, is what most teams are struggling with right now.
0:00
/3:44
1×
Clip from my informal demo with Aampe's Amaan Kulatunga.
## **From AI as tool to AI as team member**
We’ve treated AI as the next automation layer, something to optimize what we already do. I wrote about this at length in [my previous post](https://www.martechtherapy.com/why-we-keep-solving-human-problems-with-robot-solutions/) venting some light frustration about the focus on AI as a feature, brought to market by many Martech vendors. But as Raab wrote in his recent blog post, AI-native marketing isn’t just a faster version of the old process, but rather a self-correcting system that learns and adapts (or at least, it should be). The problem is that the organization around it often doesn’t.
During the Aampe demo, which I just recorded for prosperity, not to publish on [my Youtube channel](https://www.youtube.com/@martechtherapy?ref=martechtherapy.com) (although I do have permission for the clip above), Amaan explained that their biggest investment isn’t just the reinforcement-learning engine that powers message optimization, which was very impressive in its own right. It’s the *change management process* they built around it. Their strategic consultants work directly with marketing and CRM teams to help them **shift from rules-based campaigns to adaptive, agent-driven ones**. They even have content design teams who map labels, components, and contexts to retrain creative teams for adaptive workflows.
In other words, they don’t just ship a product, *they help rewire the organization*.
And that, to me, is **the most interesting part**. Because it’s not just marketers who need to learn how to work with AI. It’s the entire company.
[Agentic AI & the art of letting goA candid chat with Aampe’s Paul Meinshausen on agentic AI, leadership, and why letting go of control might be the key to moving forward.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/agentic-ai-and-the-art-of-letting/)
View my podcast with Aampe's CEO Paul Meinshausen ☝️
## **DOJO AI and the quiet rebellion against complexity**
Aampe isn't the only one out there, because that same realization hit me again in a recent conversation with [Duarte Garrido](https://www.linkedin.com/in/duartegarrido/?ref=martechtherapy.com) and [Luke Costley-White](https://www.linkedin.com/in/lukecostleywhite/?ref=martechtherapy.com) from [DOJO AI](https://www.dojoai.com/?ref=martechtherapy.com). Duarte, a former marketer at Coca-Cola and Sky, told me:
> *“Every new tool sucked the team into its own workflows and dashboards. Martech has over-complicated the function for too long.”*
DOJO’s goal, and Aampe in their own way, is to reverse that. Their platform gives small and mid-sized teams something most enterprise stacks can’t: **freedom from the tools themselves**. Their agents connect to analytics, ads, and social data to analyze, recommend, and even execute. But they deliberately keep a *human in the loop.* Duarte told me, “We’re not building a dystopian auto-marketing system. Agents should advise and act, but marketers still steer.”
That principle, delegation with control, is at the core of what I’ve been exploring in my own writing about [AI organization charts](https://www.martechtherapy.com/new-ai-org-chart/) in my series on [Agentic AI in Marketing](https://www.martechtherapy.com/tag/agentic-ai/). The future marketing team won’t be replaced by AI, but it will be *rearranged* around it. The best marketers won’t be the ones who prompt best. They’ll be the ones who design and govern intelligent systems.
[Can an AI marketing OS really think like a CMO?Watch now | Inside my demo with DOJO AI, the all-in-one AI marketing operating system, from Lucky Saint campaigns to zebra striping trends. Is this the future?Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/can-an-ai-marketing-os-really-think/)
View my demo session with DOJO AI ☝️
## **Creativity as a side effect of delegation**
Luke’s story brings that to life. Before joining DOJO, he used the tool as a client. During the demo he told me how he built a complete campaign concept, including insights, SEO analysis, and visuals, the kind of work that might normally take an agency three months and six figures. Sooner after starting to work with the tool, he joined DOJO full-time.
When I asked if marketers are becoming more creative again, Duarte was honest: not yet.
> *“They’re still getting used to being more strategic first,”* he said. *“They’re learning to manage AI like a team of specialists. The creativity will come next.”*
That’s the wave we’re entering now. Not one of automation, but of reallocation. AI gives time back to the humans in the system. What they do with it will decide whether marketing gets smarter or just faster.
We’re entering the age of what David Raab and others call the ‘Super Agent’, a unified orchestration layer that could soon oversee most marketing actions. It’s a seductive idea for sure. An intelligent system connecting data, content, and channels in real time. But every Super Agent raises a human question. What happens when strategy becomes a dialogue instead of a hierarchy? When the work changes from execution to interpretation?
In that sense, AI doesn’t replace marketers, it demotes them from operators to editors, from rule-setters to reviewers. This should not be misunderstood and seen as a loss of power, but rather a redefinition of it.
[Agentic AI in Martech: The new org chartPart 4: Roles that emerge when AI handles executionMartech TherapyMatthew Niederberger](https://www.martechtherapy.com/new-ai-org-chart/)
Read my thoughts on how organizational roles can change with AI ☝️
## **The new gravity inside organizations**
Lee Hammond’s latest recap post of [Treasure Data](https://www.treasuredata.com/?ref=martechtherapy.com)'s CDP World 2025 event, shows how quickly tools are merging, while David Raab’s essay imagines how processes could merge. But neither map shows the hardest merge of all -> **people**.
AI doesn’t erase silos. It bends them. It pulls IT, data, and marketing into shared orbit, sometimes unwillingly. The friction we feel isn’t simply technical or stratgic, it’s gravitational. It’s what happens when decades of organizational habit collide with a system that learns faster than its managers do. And that is what fascinates me the most. AI solutions will be commoditized quicker than you can roast bread... and butter it. But organizational changes will be the key.
## **Unlearning as the real skill**
Not to sound like a broken record, but I keep coming back to that moment with Aampe. The uncomfortable pause where I realized my brain was wired for campaigns, for the status quo our works seems to be stuck in, not for adaptive systems that we are seeing today. That moment matters more than any feature list or benchmark chart. Because **before AI transforms marketing, it has to transform how we think about control, trust, and value**.
We talk about AI as if it’s going to fix marketing. I don’t think it will, not entirely, not how it is sold to us. But it might fix *how* we work, if we’re willing to unlearn what made us efficient, and start learning what makes us adaptive.
## Sign up for Martech Therapy
Thoughts, stories and ideas.
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
### Governance is everything: Simo Ahava on making GTM a bridge, not a back door
URL: https://www.martechtherapy.com/governance-is-everything-simo-ahava-on-making-gtm-a-bridge-not-a-back-door/
Last updated: 2025-10-31T06:59:59.000Z
I've been wanting to have this conversation with Simo Ahava for years. Not because I needed a hot take or a cool quote, but because Simo is one of the few people in this industry who made me better at my job without trying to sell me anything.
If you've worked with Google Tag Manager, server-side tagging, or any kind of client-side data collection in the last decade, you've probably landed on one of Simo's blog posts at 2am trying to figure out why your tracking is broken. The man has been writing technical guides, debugging walkthroughs, and JavaScript examples since before most martech vendors even existed. He's also the co-founder of [TeamSimmer.com](https://www.teamsimmer.com/?ref=martechtherapy.com), a learning platform that's become the place to actually understand how this stuff works under the hood.
We covered a lot of ground in 45 minutes, but here's what I keep thinking about.
## **Tag management solved the wrong problem**
Simo's origin story mirrors a lot of ours. Stat counters in the 90s. Google Analytics when it went free. Implementation work because, as he put it, "implementations suck." Google Tag Manager was supposed to fix that. It gave marketers the ability to deploy tags without waiting on developers. Problem solved, right?
Not exactly. What GTM really did was expose [the next layer of dysfunction](https://www.martechtherapy.com/why-we-keep-solving-human-problems-with-robot-solutions/). Now you didn't need a developer to deploy bad tracking. You could do it yourself, faster, at scale. The deployment bottleneck disappeared, but the capability gap stayed exactly where it was. And that gap is what I see every time someone calls me in to "fix" a CDP that isn't working.
## **The same problems, just migrated**
We spent a lot of time on Martech, and Simo was blunt. He's worked with a few, SaaS solutions and the pattern is always the same. The vendor shows up with a [pitch deck full of promises](https://www.martechtherapy.com/the-cdp-rfp-dating-game/). The implementation starts. Then reality hits. The data layer isn't clean. The identity stitching assumptions don't match actual user flows. The event taxonomy was designed by someone who left six months ago. And now the CDP is just another expensive pipe in a stack full of expensive pipes.
It's the exact same problem Google Analytics implementations had in 2010\. The tools got better. The organizations didn't.
## **AI won't save you if you can't define an event**
Of course we talked about AI. Simo's been teaching technical marketing for years, and his courses on BigQuery and server-side tagging are some of the most popular at Simmer. But when I pushed him on the "AI will solve martech" narrative, he was skeptical. Not because AI isn't useful, but because most companies still can't handle the basics.
If you can't design a clean data layer, AI isn't going to magically understand your business logic. If your event tracking is inconsistent, AI won't know which signals to trust. And if your org doesn't have the capability to maintain any of this, you're just adding another layer of complexity on top of an already fragile foundation.
This is something I've been circling around in my own work. The tooling isn't the bottleneck anymore. [Capability is](https://www.martechtherapy.com/before-you-deploy-your-cdp-train-your-crew/).
## **Building without data**
One of the better tangents during our talk -> Team Simmer grew almost entirely without looking at their own analytics. No dashboards. No attribution models. Just a strong personal brand, a newsletter, and courses that actually solve problems people have. They tried Google Ads once this summer. It didn't work. Too niche, too much competition with generic terms, and their brand name conflicts with a food delivery service in the US.
I love this because it's a counterpoint to the "data-driven everything" religion. Sometimes the best strategy is just to build something useful and let people find it. Especially in a niche where the alternatives are either too shallow or too expensive.
## **Why this matters**
I've been thinking a lot about capability lately. Not just skills, but organizational capability. The ability to actually execute on the tools you've bought. Simo's work, whether it's his blog, his courses, or this conversation, keeps pointing back to the same thing: the tools are fine. The vendors are fine. But if you don't have the internal capability to use them correctly, none of it matters.
CDPs are just the latest example. Tag management was the previous one. Before that, web analytics. The pattern doesn't change. We keep buying platforms that promise to solve problems we haven't actually diagnosed. And then we wonder why the implementation sucks.
Anyway, the full conversation is live now. Curious if this resonates with anyone else who's been in the repair business lately.
## Sign up for Martech Therapy
Thoughts, stories and ideas.
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
### Why we keep solving human problems with robot solutions
URL: https://www.martechtherapy.com/why-we-keep-solving-human-problems-with-robot-solutions/
Last updated: 2026-07-06T10:56:12.000Z
Ok, I need to get this off my chest. This week in Martech feels like watching an episode of the Twilight Zone. Treasure Data launches their [AI Marketing Cloud](https://www.treasuredata.com/solutions/ai-marketing-cloud/?ref=martechtherapy.com). [Hightouch teases new Agents feature](https://hightouch.com/has-martech-failed?ref=martechtherapy.com). Tealium rolls out their [Behavioral Insight Agent](https://tealium.com/blog/artificial-intelligence-ai/meet-behavioral-insight-agent-intelligence-that-lives-in-the-stream/?ref=martechtherapy.com). Meanwhile, [McKinsey drops a report](https://www.mckinsey.com/capabilities/growth-marketing-and-sales/our-insights/rewiring-martech-from-cost-center-to-growth-engine?ref=martechtherapy.com#/) essentially saying "*your technology is writing checks your operating model can't cash*", and [Hightouch's "Has Martech failed marketers" report](https://hightouch.com/has-martech-failed?ref=martechtherapy.com) includes data showing that marketers think their tools are broken.
Now take a sip of your coffee before I reveal the plot twist. Ready? Everyone's basically saying the same thing without saying it -> we have a people problem dressed up as a technology problem, and nobody wants to admit the emperor's organizational chart has no clothes.
## When data takes the fall
Hightouch's report deserves credit for uncovering an important truth: 75% of tool problems are actually data problems. That's genuinely valuable insight. But here's where it gets interesting in my opinion. Their report shows marketers can't use 70% of their stack, yet the solution being pitched is, *naturally*, better data infrastructure and, wait for it, more AI agents.
I'm not knocking the technology. These new AI capabilities are genuinely impressive, bordering on magical, and I am deploying them with my clients. But there's something almost endearing about our industry's relentless optimism that the next tool will finally be the one that **transcends organizational dysfunction**. It's like watching someone try to fix a broken marriage by buying a nicer car.
[David Chan from Deloitte](https://www.linkedin.com/in/iamdavidchan/?ref=martechtherapy.com), quoted in the Hightouch report, comes closest to naming the real issue when he talks about "leaning into collaboration with the very teams once seen as blockers." But even this frames it as an opportunity rather than what it actually is, **table stakes** for making any of this technology work.
Even McKinsey's report has some solid advice for [those struggling with the basics](https://martech.org/why-chasing-shiny-cdp-features-leaves-marketers-feeling-like-imposters/?ref=martechtherapy.com), for companies looking to jump on the AI hype-train. And I have to hand it to them, their advice is music to my ears:
> Making \[grasping Martech AI's opportunity\] happen, however, requires companies to elevate martech from a collection of disparate tools to a strategic enterprise asset that is championed by the C-suite and embedded in the organization’s long-term vision.
Besides C-suite Martech fluency, they speak of strong [data strategy](https://www.martechtherapy.com/tiankai-feng-on-why-humanity-is-the-81a/) and digital-first ways of working. Look, I don't want to label myself the Nostradamus of Martech, but these are not all really new pieces of advice, but welcome nonetheless. For those running into walls when working with Martech, it's all we have been wishing for for years.
## The pattern we refuse to see
Here's the cycle I've watched play out more times than I've seen Star Wars (and I've seen Star Wars a lot, just ask Scott Brinker, oh and Andor is the best):
> Company buys impressive martech tool. Tool requires data from multiple systems. Systems are owned by different teams. Teams have different priorities, incentives, and definitions of success. Integration stalls. Manual workarounds emerge. Tool underperforms. Vendor diagnoses "data quality issues". Company buys data solution. Rinse, repeat, retire early if you're selling the solutions.
McKinsey's report uses the phrase "technology is outpacing operating models", which is consultant-speak for "you bought a spaceship but your org chart is still designed for horses". They're not wrong, but framing it as technology moving too fast lets organizations off the hook. The technology isn't outpacing anything. Organizations are choosing to buy new tools rather than fix how they work.
## The comfortable deflection
The Martech industry has perfected the art of the comfortable deflection. When campaigns underperform, we blame attribution models. When attribution breaks, we blame data silos. When data silos persist, we blame integration challenges. When integrations fail, we blame technical debt. It's turtles all the way down, except every turtle is avoiding eye contact with the fact that marketing and IT haven't had an honest conversation since... well, I don't know when.
Last known photo of marketing and IT having an honest conversation. j/k
This isn't vendors being malicious. They're building genuinely useful tools that solve real problems, assuming those problems exist in a vacuum. The new agents from Treasure Data, Hightouch, and Tealium could absolutely transform marketing operations if marketing operations existed in a world where departments actually operated together.
But **pointing at organizational dysfunction doesn't sell software**.
You know what sells software? "Data readiness assessments". Or "AI maturity models". Maybe even "Integration roadmaps". These are things you can put in a PowerPoint and present to a board. "Your CMO and CTO need couples therapy" is not.
## Architecture as destiny
[David Joosten on the Humans of Martech podcast](https://humansofmartech.com/2025/10/28/193-david-joosten-the-politics-and-architecture-of-martech/?ref=martechtherapy.com) nailed something crucial by stating that:
> "Architecture isn't just technical infrastructure, it's the invisible scaffolding that shapes team behavior. Data teams build for accuracy and control, while marketers push for agility and access. The architecture decides which side wins." When the design prioritizes risk management, marketers spend months waiting for queries to be approved. When it prioritizes freedom without governance, trust breaks down the first time a campaign misfires. Neither version scales.
This is the mechanism behind our industry-wide dysfunction. The tension between marketing and IT isn't personality conflicts, [it's architecture manifesting as behavior](https://www.martechtherapy.com/before-you-deploy-your-cdp-train-your-crew/). We're launching AI agents into organizations still running on architectural decisions made when Facebook required a college email address.
## The humans in the machine
What's particularly rich about this moment is that we're launching AI agents, essentially artificial humans, to work around the problem that actual humans can't work together. We're building synthetic collaboration because organic collaboration is too hard. There's a science fiction novel in here somewhere, probably a dystopian one. Too bad Isaac Asimov already wrote "Foundation", because that is what we truly need.
Source: [Hightouch "Has Martech failed marketers"](https://hightouch.com/has-martech-failed?ref=martechtherapy.com)
The unnamed marketers in these reports aren't struggling because they're incompetent or because the tools are bad. They're struggling because **they're being asked to deliver integrated customer experiences using dis-integrated organizations**. They need engineering help not because they're technically deficient, but because the data they need lives behind organizational walls that require political capital, not technical skill, to breach.
## The actual solution nobody wants
Let's be honest, just for a second, and agree that everyone reading this knows what the actual solution looks like. It looks like marketing and IT sitting in the same meetings, sharing the same goals, and being measured on the same outcomes. It looks like data governance that's about enabling access, not protecting turf. It looks like incentive structures that reward collaboration over empire building.
But that's hard. That requires difficult conversations, changed job descriptions, and possibly admitting that the way we've been organizing companies for the last 20 years doesn't work anymore. It's much easier to buy another tool that promises to bridge the gap, integrate the systems, or use AI to magically surface insights across silos.
[Tiankai Feng on why humanity is the glue that holds federated data teams togetherIn Episode 4 of Couch Confidentials Powered by Martech Therapy, host Matthew Niederberger welcomes Tiankai Feng, the author of Humanizing Data Strategy. Together, they explore the intersection of data, humanity, and leadership. From responding to criticisMartech TherapyMatthew Niederberger](https://www.martechtherapy.com/tiankai-feng-on-why-humanity-is-the-81a/)
Podcast: Tiankai Feng on why humanizing data matters
## Moving forward without moving forward
I'm not suggesting vendors stop innovating or that these new AI agents aren't valuable. They really and truly are. In organizations that have done the hard work of aligning their human operating systems, these tools will be transformative. The problem is pretending the technology can skip the hard part.
The great Martech gaslight isn't that vendors are lying about what their tools can do. It's that [we've all agreed to pretend organizational problems have technological solutions](https://www.martechtherapy.com/your-cdp-is-more-than-just-a-platform/). We've created an entire industry around working around the problem instead of solving it.
Until we stop that particular charade, we'll keep having this conversation every time someone launches a new platform, CDP, agent, or whatever acronym we're genuflecting to next quarter. The tools will keep getting smarter while the organizations using them keep making the same very human mistakes.
The real innovation isn't going to be another AI agent. It's going to be the first company that admits maybe, just maybe, we should debug the humans before we deploy another robot.
## Sign up for Martech Therapy
Thoughts, stories and ideas.
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
### The great rebalance & why 2026 belongs to the mid-market CDP
URL: https://www.martechtherapy.com/cdp-cep-midmarket-predictions-2026/
Last updated: 2025-10-27T07:33:05.000Z
For most of the last decade, Customer Data Platforms (CDPs) and Customer Engagement Platforms (CEPs) have been sold as enterprise [transformation](https://www.martechtherapy.com/your-cdp-is-more-than-just-a-platform/) tools. Big budgets, big integrations, big promises. But as we move toward 2026, the energy in that market seems to be changing course. Enterprise demand is flattening, and the next wave of growth is forming lower down the ladder, in the restless, pragmatic mid-market.
## **The state of play**
Depending on whose model you trust, or whose newsletter you have subscribed to, the global CDP market will sit somewhere between **$7.5 and $9.7 billion by 2025**, growing at roughly **20 to 27 percent** annually through the rest of the decade. Add the CEP and multichannel marketing hub categories, and you get a combined segment already worth **$13 to $15 billion**. That’s impressive to say the least, but the story underneath the averages tells us more.
To crunch a few numbers, the [CDP Institute](https://www.cdpinstitute.org/?ref=martechtherapy.com) now tracks nearly **190 active vendors**, supported by roughly **17,000 employees** ([report](https://www.cdpinstitute.org/news/customer-data-platform-industry-adds-new-vendors-cdp-institute-report/?ref=martechtherapy.com)). Gartner’s 2024 [Magic Quadrant](https://www.martechtherapy.com/is-it-all-a-magical-illusion/), meanwhile, **lists only seventeen players large enough to qualify**. It’s a good snapshot of how crowded and mature the enterprise end of the market has become. [Adobe](https://business.adobe.com/products/real-time-customer-data-platform/rtcdp.html?ref=martechtherapy.com), Salesforce, and [Tealium](https://www.tealium.com/?ref=martechtherapy.com) have claimed their share. [Twilio](https://www.segment.com/?ref=martechtherapy.com), [Treasure Data](https://www.treasuredata.com/?ref=martechtherapy.com), and many more occupy the rest. The bucket, for the most part, **is full**.
[Customer.io recently announced passing $100m ARR](https://customer.io/learn/announcements/customerio-crossed-100m-note-from-ceo?ref=martechtherapy.com)
Public data makes this visible. Salesforce’s ~~Marketing Cloud~~ **Marketing Cloud Engagement** revenue growth has slowed to single digits. Adobe’s Experience Cloud floats around ten percent. In addition to Customer.io's news above, [Braze](https://www.braze.com/?ref=martechtherapy.com), one of the more agile CEPs, [reported **$593 million** in revenue last year](https://investors.braze.com/news/news-details/2025/Braze-Reports-Fiscal-Year-and-Fourth-Quarter-2025-Results/default.aspx?ref=martechtherapy.com#:~:text=Revenue%20was%20$593.4%20million%20compared,customers%2C%20upsells%2C%20and%20renewals.) and guidance that points to steady but not explosive growth. Iterable sits above **$200 million ARR (2024)**. These aren’t early-stage curves anymore, and it would be naive to think so. They’re at a minimum mature-market lines.
Source: [CDP Institute Industry Update July 2025](https://www.cdpinstitute.org/resources/industry-update-july-2025/?ref=martechtherapy.com)
And beneath all of that maturity, fewer than **five percent of vendors identify as “composable” or “warehouse-native.”** That’s where the next story begins.
## **The enterprise plateau**
Enterprise organizations have, frankly, already bought their way into the CDP category. Between 2020 and 2024, implementing a customer data platform became a strategic checkbox, not just beer talk on a Friday afternoon. Every large brand either purchased one, built its own, or embedded similar functionality into a data warehouse. Adoption isn’t the challenge anymore. Their focus is on utilization and consolidation.
Roughly **70 to 75 percent of global CDP and CEP revenue** still comes from enterprise accounts, but growth has slowed to around **8 percent CAGR**. Sales cycles regularly stretch past six months, implementation costs exceed software costs, and the ratio of services to software can reach sixty percent. Most of the innovation dollars have moved to cost optimization or AI integration rather than expansion.
At this point, the enterprise story isn’t about opportunity any more than [it is about endurance](https://www.martechtherapy.com/where-cdps-quietly-kept-working/). Mergers will thin the vendor ranks by a quarter before 2026, because let's face it, consolidation is inevitable when everyone’s fishing from the same pond.
## **The mid-market window**
The more interesting motion is happening below the Fortune 500\. Mid-market companies, those with revenues between ten million and one billion dollars, are starting to behave like the enterprises of five years ago. They’ve matured enough to need data centralization, orchestration, and automation, but they’re still nimble enough to make decisions quickly.
Source: [CDP Institute Member Survey 2024](https://www.cdpinstitute.org/resources/cdp-institute-2024-member-survey-building-on-success/?ref=martechtherapy.com)
There are around **200,000 such firms in the United States**, and the OECD suggests the global total is well above **700,000**. Even if only ten percent adopt a CDP or CEP at an average annual contract value of $120,000, that’s an **$8-billion U.S. opportunity** before you start to count Europe or Asia.
What makes the mid-market attractive isn’t just its size. These companies **close deals in under ninety days**. Their implementations are faster, their dependency on professional services is lower, and their internal politics are almost nonexistent compared to enterprise marketing teams. They buy based on fit and outcome, not procurement policy.
IDC’s mid-market studies show Martech investment growing **25 to 30 percent faster** than enterprise IT spend. In other words, they’re the right customers at the right moment, ambitious, under-served, and impatient.
## **My 2026 predictions**
If you project forward a year, the curve looks clear. Enterprise growth will hover around **eight percent CAGR**, while the mid-market share of *new bookings* rises from roughly a quarter today to about **thirty-eight percent** by the end of 2026\. The venture climate may cool, but the companies that do emerge will be aimed squarely at this segment. Probably **one in four new Martech vendors** will design specifically for mid-market buyers.
Deal sizes will come down, around twenty percent lower on average, but payback periods will shorten dramatically. A typical CDP deployment that once took nine months can now go live in half that time. Payback within **twelve to eighteen months** is becoming the new benchmark, and vendors are learning that smaller deals done faster can compound just as efficiently as long enterprise pursuits.
Existing enterprise players will follow the signal. Roughly a quarter of them will release lighter, modular versions of their platforms priced below $250,000 in annual value. Most of these will appear through **cloud marketplaces** or as **Snowflake-native apps,** low-touch, self-serve, and partner-friendly.
And the product boundary between CDPs and CEPs will continue to blur. By 2026, about **forty percent of CDPs will include core engagement features** like journey orchestration, AI-driven triggers, or outbound connectors. The CEP world will evolve in parallel, strengthening its identity and segmentation layers. What was once two categories will increasingly operate as one data-activation stack.
[MAP, CEP, or CDP? Klaviyo’s James Fang on where marketing automation is headedKlaviyo’s James Fang on CDPs, MAPs, AI, and why the future of marketing automation is about consolidation and real business impact.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/map-cep-or-cdp-klaviyos-james-fang/)
From my podcast archive: Klaviyo's James Fang
## **What vendors should take from this**
The next eighteen months won’t be about chasing bigger logos. They’ll be about **right-sizing complexity**. Vendors that learn how to package enterprise-grade capability into mid-market-ready form will gain the upper hand.
That starts with product design. Platforms need clear entry tiers that speak directly to companies of a few hundred employees, not a few thousand. Integration must default to the modern warehouse, Snowflake, BigQuery, Redshift, because that’s where mid-market data now lives.
[mParticle moving to a Hybrid form](https://www.mparticle.com/news/mparticle-snowflake-hybrid-pr/?ref=martechtherapy.com)
Don't underestimate the need for (near) real-time capabilities. AI will be most useful not as a feature badge but as a setup accelerant for actions like automated data mapping, onboarding, and use-case scoring that turns months into weeks.
[Even Hightouch had to acknowledge client real time needs](https://hightouch.com/blog/same-session-personalization?ref=martechtherapy.com)
Compliance, too, needs simplification. Mid-market buyers care deeply about GDPR, CCPA or PDPL (*enter random 4-letter acronym* 😅) but don’t have legal departments to translate them. Vendors that can make privacy *visible and usable* will win trust quickly. And finally, partnerships need to scale down, not up. The [real influence in this tier lies with boutique agencies](https://www.martechtherapy.com/ten-reasons-to-bring-in-outside-expertise/) and regional system integrators, not global consultancies.
## **The numbers behind the narrative**
If you zoom out, the pattern is easy to see. Combined CDP and CEP revenues should rise from about **$15 billion in 2024** to somewhere near **$22 billion by 2026,** a healthy twenty-plus percent compound rate. Enterprise will still represent the majority, but its share of total revenue will slide from **around seventy-two percent to roughly sixty-two**. Vendor count will tick slightly downward as consolidation plays out, while the share of composable or warehouse-native models doubles from **five to twelve percent**.
It’s not disruption so much as redistribution. Basically [growth energy](https://www.martechtherapy.com/the-real-martech-roi-equation/) migrating from the top of the pyramid to its middle layers.
## **A field note from the trenches**
In my own consulting work, that change is already visible. Enterprise projects feel more like upkeep, governance reviews, data model audits, incremental integrations. The mid-market clients, by contrast, are building momentum. They’re running smaller but cleaner stacks, making faster decisions, and treating CDPs not as transformation trophies but as practical accelerators. The budgets may be smaller, but the intent is much sharper.
## **The 2026 takeaway**
By the end of 2026, the same acronyms will still dominate Martech conversations, (Composable) CDP, CEP, DWH, but the gravity will have changed. Enterprise adoption will be stable but slow. Mid-market expansion will account for the majority of net-new growth. And the vendors who adapt their go-to-market motion, pricing, and onboarding to serve that segment will own the next phase of the category.
The enterprise party isn’t over, but the playlist has definitely changed. The mid-market after-party is where the energy, and the opportunity, now lives.
What are you predictions for 2026? Leave a comment below 👇🏻
## Sign up for Martech Therapy
Thoughts, stories and ideas.
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
### Where CDPs quietly kept working
URL: https://www.martechtherapy.com/where-cdps-quietly-kept-working/
Last updated: 2025-10-20T08:36:13.000Z
Every few months, someone posts another chart about the end of Customer Data Platforms. The logos change, the arrows move toward “composable,” and the takeaway is always the same \* *drum roll*\* **the category is over**. But when I look at what’s actually running inside mid-market marketing stacks, where I spend most of my days, the story doesn’t match the headline.
🔗
Read part 1 here: [If CDPs are dead, they’ve donated their organs...](https://www.martechtherapy.com/cdps-are-alive-as-ever/)
## **The parts that never stopped working**
What’s survived isn’t the marketing copy, that changes as often as the wind, but it’s the machinery. Ingestion, identity resolution, consent collection, and segment activation, those functions never disappeared. They were simply folded into other systems. Customer Engagement Platforms borrowed a handful. [DinMo](https://www.dinmo.com/?ref=martechtherapy.com)'s Olivier Renard [recent CDP vs CEP piece](https://www.dinmo.com/cdp/cdp-vs-crm/cdp-vs-cep/?ref=martechtherapy.com) dives into it more. Data warehouses took over storage and activation. And many mid-market CDPs just kept doing their job quietly, one integration at a time.
Source: [DinMo](https://www.dinmo.com/cdp/cdp-vs-crm/cdp-vs-cep/?ref=martechtherapy.com)
When you strip away the category debates, a pattern appears. The companies that kept their CDPs alive weren’t chasing transformation budgets. They were solving for continuity. Making sure data kept flowing between tools, even as [vendors rebranded their way through Gartner quadrants](https://www.martechtherapy.com/is-it-all-a-magical-illusion/).
## **What the mid-market understood**
Most mid-market teams didn’t buy into the idea of the CDP as a grand unifying theory. They bought it as a workflow tool. A way to connect the places where customer data lives with the places where it’s needed. They care less about architecture diagrams and more about the two hours saved every week when a list doesn’t have to be exported manually.
CDP Architecture (Source: [CDP Institute](https://www.cdpinstitute.org/cdp-institute/customer-data-platform-architecture/?ref=martechtherapy.com))
It’s not that these teams ignored innovation, but they just had a different definition of progress. For them, stability and predictability were the real modernisations. A composable stack is interesting until someone has to maintain it. The CDP that quietly works every day feels like a relief.
## **A smaller, sharper scope**
There’s something pragmatic about how the mid-market uses CDPs today, that much needs to be said. Most implementations focus on three things:
1. reliable IDs
2. permission management
3. campaign activation
No dashboards full of AI intent scores or 360-degree promises. They have not reached that station, yet. Just data that’s accurate enough to act on. The rest lives elsewhere, often inside the CEP or warehouse. And that’s fine.
This narrower scope is why CDPs in this segment tend to survive economic cycles better than their enterprise cousins. They don’t depend on transformation budgets or internal evangelists. They exist because they make something else easier, such as reporting, targeting, compliance, or collaboration.
## **The quiet evolution**
It’s easy to say CDPs lost ground to warehouses or to engagement suites. In practice, they evolved together. The boundary between these tools is porous by design. Warehouses grew activation muscles thanks to various companies that dared to challenge the status quo. In that slipstream, CEPs built simple profile stores. And CDPs, starting to feel the pressure, added outbound connectors and analytics. The convergence wasn’t a takeover in a direct sense, but more a slow migration toward whatever solved the most immediate pain.
When people talk about “embedded CDPs”, a term I heard a few weeks ago from my peer Lee Hammond after he read [my first article](https://www.martechtherapy.com/cdps-are-alive-as-ever/), this is what they mean. The underlying data logic that now lives inside other platforms. The form has changed, but the functions are familiar. That’s why when someone declares CDPs dead, most mid-market practitioners just shrug. They’re still using one, even if the vendor calls it something else.
## **Why that matters**
If there’s a lesson here, it’s that usefulness outlasts naming. Maybe that's the game that Salesforce is playing... The CDP may no longer sit at the center of every martech diagram. Still, it remains a core idea, an operational layer for unified, privacy-ready customer data, that has quietly become a default expectation. You don’t need to justify it anymore. You just need to decide where it lives.
Source: [Renameforce.com](https://renameforce.com/?ref=martechtherapy.com)
For mid-market teams, that’s the win. They’re not chasing architectural purity or future-proof tech. They’re running campaigns, staying compliant, and keeping their data in order, working with the resources they have available. In that sense, the CDP never died. It just stopped introducing itself so loudly.
In the next article, I’ll look at where these functions are headed next: CEP/CDP hybrids, warehouses with activation layers, and the practical trade-offs behind building versus adopting them.
## Sign up for Martech Therapy
Thoughts, stories and ideas.
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
### From ad servers to AI: a reality check with Infolinks Media CEO Bob Regular
URL: https://www.martechtherapy.com/podcast-infolinks-media-bob-regular/
Last updated: 2025-10-17T10:28:34.000Z
Before “programmatic” was a word, Bob Regular was already in the trenches of digital advertising. Today, as CEO of Infolinks Media, he’s seen enough hype cycles to know that progress takes patience and a sense of humor.
We talked about the rise and fall of the dot-com bubble, the long road from cookies to context, and the strange reality that AI may make media buying both smarter and more commoditized. Bob also shared a sharp view on regulation, calling out how well-intentioned privacy laws ended up suffocating smaller publishers while barely protecting users.
If you’ve ever wondered how Martech’s obsession with “outcomes” looks from the adtech side, this conversation gives you that missing perspective, calm, experienced, and quietly provocative.
👥 Connect with us on LinkedIn:
- Bob: [https://www.linkedin.com/in/rregular/](https://www.linkedin.com/in/rregular/?ref=martechtherapy.com)
- Matthew: [https://www.linkedin.com/in/matthewniederberger/](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
📲 Follow Martech Therapy on:
- Instagram: [https://www.instagram.com/martechtherapy](https://www.instagram.com/martechtherapy/?ref=martechtherapy.com)
- Youtube: [https://www.youtube.com/@martechtherapy](https://www.youtube.com/@martechtherapy?ref=martechtherapy.com)
- Bluesky: [https://bsky.app/profile/martechtherapy.bsky.social](https://bsky.app/profile/martechtherapy.bsky.social?ref=martechtherapy.com)
## Sign up for Martech Therapy
Thoughts, stories and ideas.
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
### Shopping like a human & the quiet rise of Conversational Commerce
URL: https://www.martechtherapy.com/bloomreach-clarity-and-the-quiet-rise-of-conversational-commerce/
Last updated: 2025-10-16T08:29:22.000Z
I spent yesterday morning at the Bloomreach Partner Enablement Day event in Amsterdam, where Adam Hackett spoke about conversational commerce and [the company’s new *Clarity* module](https://www.bloomreach.com/en/products/clarity?ref=martechtherapy.com). It wasn’t a pitch, more a quiet look at how online shopping is beginning to resemble an actual exchange, less filtering, more asking. The kind of conversation that once happened with a store assistant, now expressed through an interface.
[Tjeerd Brenninkmeijer](https://www.linkedin.com/in/tjeerdbrenninkmeijer/overlay/about-this-profile/?ref=martechtherapy.com) sharing Clarity at the Bloomreach Partner Enablement Day.
Bloomreach’s framing felt grounded, it really did. They’re not trying to turn shopping into a chatbot novelty, we are no longer the naive consumers we were 10-20 years ago. They’re aiming to make it feel more natural, more human. *Clarity* sits at the engagement layer, helping marketers use what they already know about customers, without adding another system to maintain.
## **From funnels to fragments**
For years, e-commerce design has followed a tidy mental model, the funnel. Discovery, consideration, purchase, retention, straight lines and clean metrics. But that’s not how people shop. We wander, compare, hesitate, and ask questions that no filter can anticipate. Then we, or I should say "I", search for that "ask your partner for permission to buy this" button. I know I am not alone in this.
“Shopping like a human” is a phrase that catches this reality. It accepts that intent is messy. Conversations meander. Decisions build slowly through questions, not just clicks.
The challenge for digital teams is that this messiness generates data that doesn’t fit into dashboards. Conversational systems change that dynamic. They collect a different kind of information, contextual, emotional, and situational. Instead of guessing what someone might want, the system can simply ask and adapt.
## **A quieter evolution**
In my earlier writing about [*Contextual CDPs*](https://www.martechtherapy.com/understanding-mcps-a-cdp-insiders/), I described how marketing technology is gradually moving from managing audiences to interpreting context. Conversational commerce is a visible sign of that same movement.
When someone asks a product question, they’re revealing more than preference. They’re exposing uncertainty, curiosity, and intent. That’s the kind of data traditional personalization engines often miss. And once captured, it can inform far more than the single interaction in front of it.
This is where Bloomreach’s approach feels pragmatic. The company isn’t promising fully autonomous sales agents. It’s giving marketers a way to listen, safely. The emphasis on brand protection, factual grounding, and tone control shows that we’ve learned from the first wave of generative AI enthusiasm. Accuracy matters more than novelty.
## **Real-time, or nothing**
Still, conversational experiences live or die on responsiveness.
- A one-second delay in a search result is acceptable.
- A two-second pause in a conversation feels broken.
Latency is part of the emotional texture of the experience.
If conversational commerce scales, infrastructure readiness will suddenly matter in ways marketing teams aren’t used to measuring. Every hesitation, every missed beat, becomes a design flaw. It’s an entirely new layer of performance pressure, not because users demand speed, but because conversation demands rhythm.
## **Beyond the chatbot cliché**
Adam shared a few examples of *Clarity* in action with contextual chat widgets that adapt to the product page, guided selling flows that mirror an in-store exchange, and conversational discovery replacing static filters.
Tips & Tricks for starting with Conversational Commerce
The intent isn’t to automate salesmanship but to recreate something human, that moment when a good store assistant notices hesitation and asks if you’d like help. Digitally, that becomes a nudge similar to *“You’ve looked at three jackets in similar colors, do you want to compare materials?”*
When done well, this kind of interaction lowers friction without feeling invasive. It also reframes personalization. The system is responding to your intent in real time.
## **What happens next?**
The natural question is how far these interfaces will spread. Will conversational discovery stay inside brand sites, or expand into broader chat ecosystems?
OpenAI’s [Apps in ChatGPT](https://openai.com/index/introducing-apps-in-chatgpt/?ref=martechtherapy.com) now lets companies like Shopify and Booking.com make their products discoverable, and even purchasable, directly inside ChatGPT conversations. That means your next brand touchpoint might not be your website at all, but a chat window that already understands your inventory, pricing, and context.
Imagine asking, *“Find me a jacket under €200 that’s breathable and suits Nordic weather,”* and ChatGPT surfaces your product with an “add to cart” button right there. The line between webshop and assistant dissolves.
At that point, sites become reference destinations. The primary sales interface might live elsewhere, inside whatever assistant the customer already trusts. It won’t happen overnight, but it changes how we think about attribution, ownership, and what it even means to “visit” a store.
## **The invisible metrics**
Near the end of his talk, Adam quoted the line often linked to Einstein: *“Not everything that can be counted, counts.”.* It landed well because conversational systems sit right at that tension. They generate enormous amounts of measurable data, yet the most valuable outcomes, trust, confidence, satisfaction, refuse to be quantified.
Maybe that’s healthy. We’ve spent years optimising for what’s easy to measure. Now, the next wave of Martech might re-introduce things that are valuable precisely because they can’t be captured in a dashboard.
A good conversation doesn’t always convert, but it does build comfort. And comfort, over time, is what drives repeat business, not just retargeting pixels.
## **Where this leaves us**
I left the event thinking less about Bloomreach’s product and more about what it represents for the industry as a whole, a quiet return to dialogue.
Martech has spent a decade trying to predict people. Conversational commerce suggests we might get better at simply talking to them instead. It humanizes it.
Adam Hackett walking us through the Conversational Commerce maturity path.
Whether this approach becomes standard or stays niche will depend on how fast organisations can adapt their data, infrastructure, and patience. Real conversations can’t be rushed, even the digital kind.
But if *Clarity* and systems like it continue to evolve, they could remind us that every click, query, and question in marketing still begins with the same impulse: someone trying to be understood.
And maybe, after years of optimisation, that’s the kind of progress that matters most.
### If CDPs are dead, they’ve donated their organs...
URL: https://www.martechtherapy.com/cdps-are-alive-as-ever/
Last updated: 2026-07-06T10:55:54.000Z
Every week a new headline drops like a bomb. This company's app just *killed* another company's app, *blew up* something else, or *declared the death* of a technology category. As a military veteran, I find it strange how casually our industry borrows the language of conflict. There’s enough of that in real life.
Take Customer Data Platforms. Depending on who you follow, CDPs are either [dead](https://hightouch.com/blog/cdps-are-dead?ref=martechtherapy.com), obsolete, or [absorbed beyond recognition](https://www.mparticle.com/blog/cdp-zero-waste/?ref=martechtherapy.com). But as Brian Blessed once roared in *Flash Gordon*, “GORDON’S ALIVE!”
If he worked in martech, he’d be shouting, “CDP’S ARE ALIVE!”
Actor Brian Blessed, what a legend!
Because they are. Their heart now beats inside Customer Engagement Platforms, their brain is wired into data warehouses, and their lungs are keeping composable stacks breathing. But let’s be honest: those organs weren’t exactly donated. They were copied, absorbed, sometimes stitched in with marketing-friendly labels. CEP vendors saw the value of unified profiles and real-time activation, and they built versions of those features into their own products. Data warehouses did the same by working closely with composable solutions. What looks like category death is really category diffusion.
## Enterprise versus the rest
So why the constant chatter that CDPs are finished? Most of it comes from enterprise IT and data leaders who’ve shifted toward composable architectures. They have the engineering depth to use Snowflake or BigQuery as the hub, plug in activation tools, and call it a day. In that context, a packaged CDP feels redundant. But this story doesn’t translate to the mid-market.
For small and mid-sized businesses, the picture looks very different. Adoption is still climbing. The CDP Institute’s most recent survey shows mid-market firms expect above-average new deployments, while the enterprise segment is flattening after earlier adoption waves.
Source: [CDP Institue Member Survey 2024](https://www.cdpinstitute.org/resources/cdp-institute-2024-member-survey-building-on-success/?ref=martechtherapy.com)
Why? Because mid-market teams don’t have ten engineers to maintain pipelines or a seven-figure budget for data infrastructure. They want solutions that **hide complexity**, control costs, and deliver fast ROI.
Source: [Tealium Future of Customer Data 2025](https://tealium.com/resource/whitepaper/2025-state-of-the-cdp/?ref=martechtherapy.com)
And this is the nuance that gets lost. The mid-market doesn’t care about category labels. They care that the functions exist, that they’re accessible, and that they fit their growth path. If those features live inside a CEP like [Braze](https://www.braze.com/?ref=martechtherapy.com), [Iterable](https://www.iterable.com/?ref=martechtherapy.com), [Bloomreach](https://www.bloomreach.com/?ref=martechtherapy.com), [ZEPIC](https://www.zepic.com/?ref=martechtherapy.com), or [Klaviyo](https://www.klaviyo.com/?ref=martechtherapy.com), that’s fine. If they come packaged in a hybrid CDP with managed services, that works too. The “death” narrative is a distraction from the real question:
> Where do you want those vital organs, those core features, to live?
## My 2 cents
**For buyers**, the takeaway is simple. Ignore the hype cycle headlines. Focus on the functions: data collection, unified profiles, consent management, segmentation, personalization. If your current team can’t maintain a composable stack, don’t force it. If you’re growing fast and have technical depth, maybe you leapfrog directly to a warehouse-native approach. Either way, **measure success by outcomes, not by whether you’re aligned with the latest analyst soundbite**.
**For vendors**, there’s a lesson too. CEPs shouldn’t pretend their CDP-like features are revolutionary. They were borrowed, and that’s okay, but market them honestly, as **growth enablers for mid-market teams who can’t justify complexity**. CDPs, on the other hand, should own the fact that their best features were valuable enough to be copied. It is not necessarily a weakness, but more proof of it’s relevance. The challenge now is to explain why you still deliver those features better, especially for customers who don’t have enterprise-sized resources.
## Don't believe the hype
So no, CDPs aren’t really dead. Their features live on, transplanted, copied, sometimes outright stolen. The need for unified customer data is very much alive, especially in the mid-market.
As [mParticle's](https://www.mparticle.com/?ref=martechtherapy.com) Michael Katz and Jason Lynn put it:
> As foundational CDP features are commoditized, the challenge for CDPs to differentiate themselves will revolve around how well they can address the "big challenges" in using customer data to solve marketing problems.
That's why, in the next piece, I’ll turn to the mid-market and what adoption looks like today, the constraints these businesses face, and how they can focus on the quick-win use cases that prove ROI.
And if you’re already feeling stuck between hype and reality, this is exactly where [structured advisory and RFP guidance](https://www.martechtherapy.com/ten-reasons-to-bring-in-outside-expertise/) can save you from expensive mistakes. That’s the work I spend most of my time on with clients.
## Sign up for Martech Therapy
Thought pieces, interviews, and demos.
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
### When a Martech guy walks into AdTech... and lives to tell the tale.
URL: https://www.martechtherapy.com/podcast-mike-hauptman-adlib-dsp/
Last updated: 2025-10-12T08:16:29.000Z
I’m a complete novice when it comes to AdTech and raising my two teenage kids. And Mike brought me up to speed on one of those topics.
Programmatic, DSPs, audience segments… it’s always sounded like a parallel universe to the Martech world I live in.
So when I sat down with **Mike Hauptman**, co-founder and CEO of **AdLib DSP**, I treated it as a chance to get schooled and he didn’t disappoint.
We talked about how programmatic advertising actually works, why it got so complicated, and how AdLib is trying to make it *as easy as Google Ads, but smarter*.
Mike’s honesty about what it takes to build a sustainable business in such a fragmented space really stood out.
> “Can you build a simple UI? Yes. Can you build a business around a simple UI? That’s way harder.” \~ **Mike Hauptman**
He also made me realize how much of AdTech’s future depends on keeping humans in the loop, even as AI starts to reshape campaign optimization and creative workflows.
> “Right now it’s like having a data scientist on hand for free — one that never gets tired, never takes a coffee break, and doesn’t mind being told to redo something ten times.” \~ **Mike Hauptman**
We also touched on the privacy and consent side of things. Where AdTech and Martech really start to overlap. And yes, I finally got a clear answer to how **first-party data, clean rooms, and DSPs** all connect (something I’d politely nodded through for years).
[Best Self-Serve Demand Side Platform | AdLib DSP Advertising | GetAdLibReach your target audience on the world’s most popular websites and apps with the best advertising platform. Try DSP advertising with AdLib platform today.AdLib DSP | Scale Smarter. Faster.](https://getadlib.com/?ref=martechtherapy.com)
Visit AdLib to learn more ⬆
What I learned?
That **AdTech isn’t as foreign as I thought,** it’s just been hiding behind its own layer of complexity.
And that entrepreneurs like Mike are building the bridges we’ll all be crossing sooner than we think.
👥 Connect with us on LinkedIn:
- Mike: [https://www.linkedin.com/in/michaeljhauptman/](https://www.linkedin.com/in/michaeljhauptman/?ref=martechtherapy.com)
- Matthew: [https://www.linkedin.com/in/matthewniederberger/](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
📲 Follow Martech Therapy on:
- Instagram: [https://www.instagram.com/martechtherapy](https://www.instagram.com/martechtherapy/?ref=martechtherapy.com)
- Youtube: [https://www.youtube.com/@martechtherapy](https://www.youtube.com/@martechtherapy?ref=martechtherapy.com)
- Bluesky: [https://bsky.app/profile/martechtherapy.bsky.social](https://bsky.app/profile/martechtherapy.bsky.social?ref=martechtherapy.com)
## Sign up for Martech Therapy
Thoughts, stories and ideas.
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
### Ten reasons to bring in outside expertise for your CDP RFP
URL: https://www.martechtherapy.com/ten-reasons-to-bring-in-outside-expertise/
Last updated: 2026-08-31T13:10:13.000Z
I’ll be honest, I usually dislike “*top ten*” style articles. They tend to oversimplify complex decisions and make it sound like ticking boxes will magically solve everything. But after publishing my last three pieces, on [*dating vendors*](https://www.martechtherapy.com/the-cdp-rfp-dating-game/)*,* [*reference calls*](https://www.martechtherapy.com/the-reference-call-that-changed-everything/)*, and* [*surviving the RFP process*](https://www.martechtherapy.com/why-skipping-the-rfp-isnt-always/), I kept hearing the same question: *why bring in outside help at all?*
So, against my better instincts, here’s a list. Not because every company will face all ten of these issues, but because **most will recognize at least a few of them**. And if even one sounds true to you, it might be the sign that your team doesn’t need another tool. It needs support to pick the right one.
# **Protecting the business**
## Risk
A CDP purchase looks straightforward on paper, but in reality it’s a high-stakes decision. If the tool underdelivers, you don’t just lose budget, you also lose momentum, and explaining that to leadership or the board is never a pleasant experience. An independent guide can’t guarantee success, but they can help you avoid the [most common pitfalls](https://www.martechtherapy.com/why-skipping-the-rfp-isnt-always/) that lead to regret.
## Money
Pricing models in this space are rarely as clear as they first appear. A contract might look reasonable in the demo stage, only for costs to balloon later through data point creep, API usage limits, monthly tracked users, active/passive profiles, or premium support tiers. Business leaders don’t mind paying for value, but they do mind nasty surprises. External expertise helps expose those surprises early, so the choice you make is one you can stand behind months down the line.
# **Supporting your people**
## Pressure on internal teams
Even when budgets are available, the real strain often shows up inside the team. Marketers are already expected to deliver more campaigns with fewer resources. Engineers are balancing backlogs that never shrink. Asking them to also run a complex RFP is like handing them a second job, and one they didn’t ask for. External support lifts that weight so the team can stay focused on delivering value instead of drowning in vendor paperwork.
## Trust
In a market full of look-a-likes and bare-knuckle marketing, a neutral voice gives teams confidence that the evaluation is fair. Instead of being pulled back and forth by sales spin or agency agendas, they can focus on the criteria that actually matter. It doesn’t mean outside help replaces internal knowledge, far from it. It means that knowledge is better protected and put to use, and not drowned out by vendor-made promises.
# **Getting it right the first time**
## Detail
What trips up many RFPs isn’t the big questions like “does it perform identity stitching” or “can I ingest data from Azure”, it’s the finer details. Contracts, permissions, integrations, service levels, the things that feel small in the moment but turn into costly blockers later. External expertise brings a kind of muscle memory to these details, making sure the i’s are dotted and the t’s are crossed before they become problems that need workarounds like you previously succumbed to.
## Experience
Most teams only go through a CDP selection once or twice in their career. That means they’re learning the hard way as they go. An advisor who has seen dozens of these cycles can spot patterns quickly. Patterns such as which vendors overpromise, which roadmaps are reliable, and which traps tend to show up in year two. That perspective helps a team avoid repeating mistakes others have already made.
## Translation
For many leaders, CDPs still feel like a fog of acronyms and bundles. External support cuts through that by putting technology into plain language. What it does, how it maps to your use cases, and whether it’s worth the investment. That “[translation](https://martechtherapy.substack.com/i/173857150/what-translation-really-means)” lets teams and executives have the same conversation, instead of speaking past one another.
# **Playing the market**
## Leverage
Every RFP plays out against a backdrop of market dynamics. [Vendors are under pressure to adjust pricing models](https://martechtherapy.substack.com/i/174319954/step-use-market-pressure-to-your-advantage), and buyers finally have leverage. Knowing what’s happening beyond your own negotiation, how other companies are paying, what “good” deals look like, which models are shifting, puts you in a stronger position. That perspective is hard to gain from the inside, but it’s exactly what external expertise brings to the table.
## Flexibility
Hiring full-time staff to run procurement or manage selection isn’t realistic for most companies. External support is project-based. You get the skills when you need them, without the long-term cost of salaries, benefits, or training. That makes it easier to move at the speed the business demands, without adding overhead you’ll be stuck with later.
## Alignment
A strong external lead helps bring the right people inside your company together. Marketing, engineering, analytics, compliance, all of them have stakes in a CDP decision, and all of them can block progress if their needs are ignored. An independent facilitator makes sure every voice is heard, turning what could be a tug-of-war into a decision the whole organization can stand behind.
# **Why outside help matters now**
When you look across these ten reasons, a pattern emerges. It’s not just about contracts or compliance. It’s about protecting the business from regret, protecting your people from overload, making decisions that stand up under scrutiny, and using the market to your advantage.
That’s why companies bring in [outside help](https://www.martechtherapy.com/what-i-do/#how-does-cdp-selection-actually-go). It is not because they can’t run an RFP, but because they can’t afford to get it wrong. An independent lead brings **perspective**, **structure**, and **experience that saves money**, **saves time**, and **saves teams** from the kind of mistakes that don’t show up until it’s too late.
This is the work I do. If your team is preparing for a CDP or CEP decision, and you want the process to be fair, thorough, and built around your use cases, get in touch.
The tools will keep changing.
The stakes will keep rising.
What doesn’t change is the need for someone in your corner.
[Reach out to me on LinkedIn](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
Or subscribe to my Substack and stay up to date on all things Martech 👇🏻
### Can an AI marketing OS really think like a CMO?
URL: https://www.martechtherapy.com/can-an-ai-marketing-os-really-think/
Last updated: 2025-10-10T07:21:23.000Z
I sat down with **Duarte Garrido** and **Luke Costly-White** to see what [**DOJO AI**](https://www.dojoai.com/?ref=martechtherapy.com) calls an “*all-in-one AI Marketing Operating System*”. Big claims, but then again, these are undoubtedly “big claim” days we are living in, so I wanted to see what that actually looks like in practice.
Luke’s story already makes this demo interesting. Luke began as a DOJO power user, then became an angel investor, and now works at the very company he backed (for those who read my piece on [reference calls with angel investors](https://open.substack.com/pub/martechtherapy/p/the-reference-call-that-changed-everything?r=3i8xzy&utm%5Fcampaign=post&utm%5Fmedium=web&showWelcomeOnShare=false): this one isn’t on the sidelines anymore).
The demo itself was striking. They chose [**Lucky Saint**](https://luckysaint.co/?ref=martechtherapy.com), a non-alcoholic beer brand that isn’t even a customer, as the live case. In about 30 minutes, DOJO pulled:
- Voice of customer research from Reddit and LinkedIn conversations
- Discovery of an emerging behavioral trend: [*zebra striping*](https://www.drinkaware.co.uk/news/what-is-zebra-striping-and-why-is-it-becoming-popular?ref=martechtherapy.com) (alternating alcoholic and non-alcoholic drinks, this was new to me)
- Sentiment analysis showing Gen Z adoption and TikTok chatter
- SEO/AEO gaps where Lucky Saint was absent but competitors like Athletic Brewing were present
- A mocked-up campaign image, the classic Lucky Saint can re-imagined with zebra stripes, ready for social or PR angles
DOJO AI: From research, to strategy, to preparation, to execution.
All of this happened inside DOJO’s platform, without Lucky Saint’s first-party data. The promise is crystal clear → speed, integration, and strategic lift for smaller teams that can’t afford a 50k/month agency retainer.
Yes, the product is still young. But the vision of turning marketers back into strategists (not dashboard operators) feels like a future worth watching especially in how it might start to level out the playing field.
[Learn more about DOJO AI](https://www.dojoai.com/?ref=martechtherapy.com)
👥 Connect with us on LinkedIn:
- Duarte: [https://www.linkedin.com/in/duartegarrido/](https://www.linkedin.com/in/duartegarrido/?ref=martechtherapy.com)
- Luke: [https://www.linkedin.com/in/lukecostleywhite/](https://www.linkedin.com/in/lukecostleywhite/?ref=martechtherapy.com)
- Matthew: [https://www.linkedin.com/in/matthewniederberger/](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
📲 Follow Martech Therapy on:
- Instagram: [https://www.instagram.com/martechtherapy/](https://www.instagram.com/martechtherapy/?ref=martechtherapy.com)
- Youtube: [https://www.youtube.com/@martechtherapy](https://www.youtube.com/@martechtherapy?ref=martechtherapy.com)
- Bluesky: [https://bsky.app/profile/martechtherapy.bsky.social](https://bsky.app/profile/martechtherapy.bsky.social?ref=martechtherapy.com)
Want to see more informal demos of niche Martech solutions? Subscribe for free 👇🏻
### From particle physics to privacy-first analytics
URL: https://www.martechtherapy.com/mitzu-composable-analytics/
Last updated: 2025-10-10T06:38:52.000Z
From CERN’s particle accelerators to the messy world of marketing data, István Mészáros has seen it all. In this episode of Couch Confidentials, we trace his path from working on the Large Hadron Collider to building Mitzu, a startup rethinking how companies approach composable analytics.
We talk about why centralizing KPIs matters more than shiny dashboards, how enterprise data culture often lags behind the technology, and why privacy is becoming as big a driver as scale.
I loved how István described the “people-pleaser” instinct that shaped his career, always chasing faster answers for colleagues, which eventually grew into a product vision. It’s a reminder that some of the best Martech ideas start not with code, but with a simple obsession to make life easier for others.
Listen in if you’ve ever spent half a meeting arguing about mismatched KPIs instead of solving problems. Spoiler: you’re not alone, and there’s a way out.
👥 Connect with us on LinkedIn:
- István: [http://linkedin.com/in/imeszaros/](http://linkedin.com/in/imeszaros/?ref=martechtherapy.com)
- Matthew: [https://www.linkedin.com/in/matthewniederberger/](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
📲 Follow Martech Therapy on:
- Instagram: [https://www.instagram.com/martechtherapy/](https://www.instagram.com/martechtherapy/?ref=martechtherapy.com)
- Youtube: [https://www.youtube.com/@martechtherapy](https://www.youtube.com/@martechtherapy?ref=martechtherapy.com)
- Bluesky: [https://bsky.app/profile/martechtherapy.bsky.social](https://bsky.app/profile/martechtherapy.bsky.social?ref=martechtherapy.com)
Receive my next podcast episode in your inbox? Subscribe for free below 👇🏻
### Why skipping the RFP isn’t always an option and how to avoid the biggest traps
URL: https://www.martechtherapy.com/why-skipping-the-rfp-isnt-always/
Last updated: 2025-10-30T07:09:03.000Z
If you have been following my latest articles, [The CDP RFP Dating Game](https://open.substack.com/pub/martechtherapy/p/the-cdp-rfp-dating-game?r=3i8xzy&utm%5Fcampaign=post&utm%5Fmedium=web&showWelcomeOnShare=false) and [The Reference Call That Changed Everything](https://open.substack.com/pub/martechtherapy/p/the-reference-call-that-changed-everything?r=3i8xzy&utm%5Fcampaign=post&utm%5Fmedium=web&showWelcomeOnShare=false), you will understand this article even more. This article, a follow-up in a sense, eventhough my goal was not to make a series, was partly inspired by [Tealium](https://tealium.com/?ref=martechtherapy.com)’s [Jay Calavas](https://www.linkedin.com/in/jaycalavas/?ref=martechtherapy.com) comment on my LinkedIn post, stating:
> “Skip the RFP and focus on use cases and measurable outcomes!”
Read the original comment [here](https://www.linkedin.com/feed/update/urn:li:activity:7375792415439478784?commentUrn=urn%3Ali%3Acomment%3A%28activity%3A7375792415439478784%2C7375882031685115904%29&dashCommentUrn=urn%3Ali%3Afsd%5Fcomment%3A%287375882031685115904%2Curn%3Ali%3Aactivity%3A7375792415439478784%29&ref=martechtherapy.com).
And I’ll be frank, Jay is right: **use cases should lead**. I’ve even worked on projects where we skipped the RFP entirely and validated tools against use cases first. But many teams can’t avoid the RFP step, especially when procurement and compliance need a seat at the table. For them, the question isn’t “*RFP* or *no RFP*?” but
> “*How do we run an RFP without walking into the usual traps*?”
This article offers four practical moves I’ve seen work in real projects. They won’t make the process easy, but they will make it fairer, and far less costly.
### Step 1: Ask the right questions in the first conversations
The first conversations with a vendor are often the most revealing, yet too many teams treat them as casual introductions. In reality, they set the tone for everything that follows. This is where you can uncover how a product is truly built, how it has evolved, and whether the promises being made will stand up under scrutiny.
One of the most important questions is about the product’s foundation. Was it built from the ground up as a single platform, or is it the result of a series of acquisitions stitched together over time? That difference shows up later when integrations become brittle or when support teams struggle to cover gaps. Don’t be afraid to dig into the origin story, because it tells you more than the demo ever will.
It also helps to ask vendors to walk you through their own history. “What was this product called before, and what has actually changed beyond the name?” If they hesitate or dance around the answer, that tells you something too. Finally, pin down the reality of today versus the promise of tomorrow. What features are truly available right now, and which ones are still sitting on the roadmap? **If something is critical to your use cases, you need it in writing, not as a maybe for the future**.
### Step 2: Get references you can trust
Reference calls are supposed to provide confidence, yet too often they are carefully stage‑managed extensions of the sales process. Teams walk away reassured, but only because they heard exactly what the vendor wanted them to hear.
To avoid this, start by asking for more than one name. If a vendor only offers you a single client to speak with, that’s a red flag. When you do speak with references, make sure you open with a simple question: “Do you have any financial ties to this vendor?” You don’t want to discover at the end of the call that the glowing review came from someone with a stake in the company.
[The reference call that changed everythingLast week, after publishing The CDP Dating Game, my LinkedIn inbox lit up, and the number of subscribers to this Substack jumped. Marketers on the brand side reached out privately with a mix of relief and frustration. Heck, I even spoke to a few at theMartech TherapyMatthew Niederberger](https://www.martechtherapy.com/the-reference-call-that-changed-everything/)
Even when the person on the other end is a genuine customer, don’t settle for polished success stories. Push for the messy details: what were their use cases, what slowed the project down, what costs appeared that weren’t expected, what they would do differently if they had to start over. These are the insights that help you prepare for what’s ahead.
And don’t forget that **you can find references yourself**. We live in a connected world. LinkedIn, industry Slack groups, and even informal conversations at conferences often yield more candid feedback than any vendor‑arranged call. Those unfiltered stories can save you from repeating someone else’s painful mistakes.
### Step 3: Use market pressure to your advantage
Pricing is often treated as the final step in negotiations, but it can also be one of the strongest signals of where the market is heading. Right now, the direction favors buyers, if you know how to use it.
My [post on the changing form of pricing](https://www.linkedin.com/feed/update/urn:li:activity:7373066293064654848/?ref=martechtherapy.com) in CDP and CEP-type products.
There has been growing frustration with “data point creep,” where costs balloon simply because more data flows through the system, even if campaign activity stays the same. That model is under pressure. [Braze](https://braze.com/?ref=martechtherapy.com), for example, has confirmed it will move to message credits, which means paying for what you actually send rather than every single record that passes through. Other vendors are feeling the same push from customers and will likely follow.
Braze representative Martin Brown is confirming the shift to message credits.
When you go into pricing discussions, bring this up. **Ask directly how the vendor is thinking about usage‑based models and what that means for your deal**. Use the current buyer’s market as leverage. **Push for ramp pricing or pilot phases instead of committing to a big contract from day one**. And always make sure the model fits your reality, your actual use cases and volumes, rather than the vendor’s ideal adoption curve.
### Step 4: Don’t let marketing carry the load alone
One of the easiest mistakes to make in an RFP is treating it as a marketing project. Marketing may lead the process, but the outcomes affect engineering, analytics, and leadership just as much. When only one group is at the table, the blind spots multiply.
**Bring engineering in early**, even if it feels like it slows things down. They are the ones who will have to deal with integrations, technical debt, and scalability issues. **Involve your data and analytics teams** as well. They can tell you whether the platform is capable of delivering the reporting, segmentation, and governance you need. And don’t overlook procurement, because that is where the fine print lives, e.g. data protection agreements, audit rights, SLAs etc. These details rarely show up in demos but can make or break an implementation.
Whatever promises are made along the way, capture them. If a vendor says something in a meeting, write it down, even record all the meetings for reference, and make sure it makes its way into the contract. Otherwise, it doesn’t exist. When different functions inside your company evaluate a solution together, the odds of success improve. Marketing avoids being blamed for missing features, engineers avoid patchwork solutions, and executives avoid pouring money into something that can’t deliver. **That’s how you protect the whole organization, not just one team.**
### The bottom line → protect your team & your budget
None of these steps make an RFP fun. But they do tilt the balance back toward the buyer. They help you get straight answers instead of sales theater, see through rebrands and roadmaps, use market changes to your advantage, and protect the whole organization, not just the marketing team.
These moves stem from real conversations I have had in the past and continue to have today, not a simple theory. They’re the same tactics I’ve used with clients to cut through vendor tricks and avoid costly mistakes.
And this is where independent guidance makes the difference in a complex world of customer data. A structured RFP led by someone outside the vendor or agency, with close partnerships to a specific vendor loop, keeps the odds fair. It ensures the right questions are asked, promises are captured, and decisions are made on your terms, not the vendor’s.
That’s the work I do. If your team is preparing for a CDP or CEP decision and wants to run an RFP that’s fair, thorough, and designed around your use cases, get in touch.
[Connect with me on LinkedIn](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
You don’t need another vendor pitch. You need someone in your corner.
### The reference call that changed everything
URL: https://www.martechtherapy.com/the-reference-call-that-changed-everything/
Last updated: 2025-10-09T19:46:59.000Z
Last week, after publishing [*The CDP Dating Game*](https://www.martechtherapy.com/the-cdp-rfp-dating-game/), my LinkedIn inbox lit up, and the number of subscribers to this Substack jumped. Marketers on the brand side reached out privately with a mix of relief and frustration. Heck, I even spoke to a few at the [Martech World Forum](https://www.martechtherapy.com/martech-world-forum-london-2025-review/) who reacted in the same manner. Relief that someone had finally put words to what they’d been experiencing. Frustration that they’re stuck in a market where even defining what a CDP is has become an impossible task.
One marketer admitted in confidence that they no longer bother correcting their leadership team when a vendor changes the name of its platform, “it’ll just be something else again in six months”. That says it all. The people who actually have to deliver campaigns are too busy fighting for velocity to keep up with the branding gymnastics.
Source: [Twistellar](https://twistellar.com/blog/salesforce-data-cloud-features?ref=martechtherapy.com)
And Salesforce is a perfect example. Over the last few years, their CDP has undergone more name changes than most people have email addresses: Customer 360 Audiences, Salesforce CDP, Genie, and now Data Cloud. Each time the announcement lands with a big push, like this is the one that will change everything. But for the people actually working with it, the name swap doesn’t bring a fair view. It just adds more confusion. If you’ve ever had to explain to your boss why the tool they signed off on suddenly has a new label, you know the feeling. It’s like trying to follow directions with a map where the street names change every time you look up.
### That one single reference call…
The consequences aren’t just theoretical. When you work in an industry long enough, you’ll see everything cross your plate. The following is based on a true story.
I once joined a client during their CDP RFP process, a type of contract that I am most often involved in, where they had already been in conversations with a vendor. To their credit, they asked for a reference call with one of the vendor’s existing clients, a smart step in any evaluation.
The call went smoothly, full of glowing stories about the platform. Critical questions answered to the CTO’s satisfaction. But only at the very end did the person on the other end mention that **he wasn’t just a client, he was also an angel investor in the vendor**. That small detail instantly reframed everything we’d just heard.
Scooby Doo or not, this was a true story.
It was a reminder that even when teams do their homework, the deck can still be set up unfairly. What feels like a peer-to-peer conversation may not be as objective as it seems. This is the kind of trickery I described in [*The CDP Dating Game*](https://www.martechtherapy.com/the-cdp-rfp-dating-game/), and it doesn’t stop with RFP paperwork. Even reference calls, which should give an honest picture, can be wired.
### The toll on teams that vendors don’t realize
If you’ve ever felt like [the ground was shifting under your feet](https://martech.org/why-chasing-shiny-cdp-features-leaves-marketers-feeling-like-imposters/?ref=martechtherapy.com) while trying to keep a campaign on track, you’re not imagining it. The confusion is baked into the way this market operates. And it’s terribly exhausting.
Marketers are already balancing too many platforms while being held accountable for growth. Engineers want to build things that last, but rarely get the time or cover to do so. Business leaders are expected to sign off on investments with less transparency than they’d accept in almost any other area of the business. If you’ve ever doubted yourself while evaluating CDPs, you’re not alone, you’re dealing with a system designed to keep you off balance.
Source: [ChierMartec (2019)](https://chiefmartec.com/2019/02/4-facts-martech-stacks/?ref=martechtherapy.com)
Last week, during the Martech World Forum, I heard a fantastic perspective about the “toll on teams”. Let’s use the above chart as a reference, even if it is outdated. Small companies use, on average, 40 SaaS solutions. Of those 40, 15 are actively used for day-to-day operations. Now, if these vendors release one major new feature or update per quarter, that would mean that a business will need to deal with 60 major updates per year. **That equals more than 1 update per week.** One update that a team will need to evaluate, integrate, enable, and maintain per week. Work that distracts them from their daily tasks. This is unattainable, even for the best of businesses.
### What translation really means
This is why translation matters. Teams don’t need to be fluent in every vendor’s vocabulary or enable every feature. They need a way to filter the noise and connect it back to the use cases they care about most.
When that happens, things shift. Campaign teams can focus on creativity rather than decoding acronyms. Data teams can design integrations that serve the business instead of patching broken promises. Executives can weigh trade-offs in cost, effort, and risk without relying on sales theater. Does everybody win?
Independent guidance brings these perspectives into the same room. It replaces confusion with straight answers so technology choices are made on the company’s terms, not the vendor’s. And it replaces second-guessing with confidence that decisions are grounded in what actually matters.
### Pricing tells its own story
And right now, there’s another reason teams need that clear understanding. Pricing tells its own story. [Industry voices have been debating data point creep, and even Braze has confirmed it’s moving to message credits, pay only for what you send.](https://www.linkedin.com/feed/update/urn:li:activity:7373066293064654848/?ref=martechtherapy.com)
That change goes beyond a billing update that can catch even the most experienced CFO off guard. It signals that buyers finally have leverage. For any company entering the CDP or CEP market today, that leverage can mean the difference between being boxed in by legacy models or securing a deal that actually fits how they work.
### Clearing the path forward
The CDP market will keep rebranding again and again. That won’t stop. But brand-side teams don’t have to accept being led in circles while everyone else sets the terms.
In my next article, I’ll go beyond exposing the problem. I’ll share specific ways teams can protect themselves during RFPs, reference calls, and pricing negotiations, the kind of moves that keep you from being boxed in and help you use today’s buyer’s market to your advantage.
If you’ve read this far, you already know how costly confusion can be. Don’t miss the follow-up, subscribe to get it straight in your inbox when it drops.
Subscribe for free, here 👇🏻
The conversations in my inbox have made one thing crystal clear → teams don’t need another round of sugar coated vendor pitches. They need someone in their corner who helps them see things for what they are, and gives them the confidence to act.
### Martech World Forum, London, looking back
URL: https://www.martechtherapy.com/martech-world-forum-london-2025-review/
Last updated: 2025-10-09T19:47:06.000Z
When I fly into London, I always do four things.
1. I make sure to take a flight from my nearby airport, Rotterdam.
2. Once on board, I’ll have a gin & tonic (no, not in the morning, you animals!).
3. I listen to the entire album of [Breakbeat Era’s Ultra Obscene](https://open.spotify.com/album/51aFwDck8urC5HfpXJ3e6J?ref=martechtherapy.com), an album I bought back in London when it was released in 1999, a true classic.
4. When the tires hit the tarmac, I’ll jump on the DLR and head into town.
Hold your horses, don’t go shouting “classic OCD”! It’s a ritual I picked when working as Head of Analytics at Thomas Cook, supporting the head office in their migration from Adobe Analytics to Google Analytics, where I would travel to London every week.
This time round, on my way to the [Martech World Forum](https://themartechweekly.com/martech-world-forum/?ref=martechtherapy.com) to host an on-stage interview with James Schlesinger, things were different. Tube strike ([data on impact](https://www.independent.co.uk/bulletin/news/london-tube-strike-tfl-restaurants-b2825299.html?ref=martechtherapy.com)). As much as I found myself challenged by where I was going, I support the workers in their cause. Uber prices were off the charts by the time I landed, and only got worse after I took this screenshot (rates went 3x easily). But I digress…
Supply & Demand in action.
I got to the event the day before it started. I did end up having some drinks and bites to eat with some great minds in the industry, like Gareth Chilton, Neill Brookman, my guest James Schlesinger, and Amaan Kulatunga (who told me how to pronounce Aampe, call me if you want to know 😉), before the main event kicked off.
But as the old adage goes, a picture is worth a thousand words, I thought I’d share those instead of forcing you to read an entire novel of my experience at and insights of the Martech World Forum London. I took photos of slides I personally found interesting. **I am a big fan of learning people’s real-world experiences**, and often frameworks, too. I managed to take a lot of photos, but not all of them. This in no way means other speakers’ content was less informative. I was most likely distracted.
Here we go 👇🏻
Credits where credits are due… the photo gallery above displays slides from speakers like Keanu Taylor, Małgorzata Marcinkowska, Gianfranco Cuzziol, Jaunita Draude, David Norris, Diana Comsa, Jean De Bressy, James Taylor, Silvia Sartori, and Rasmus Houlind.
The common theme, well, that at least feeds my confirmation bias, is that:
> As much as AI is getting all the attention, it is the core principles in terms of human skills and cross-departmental collaboration, and technology, as in a strong foundation and centralized data, that are screaming to be taken care of.
The sooner the better, at least if you want to remain competitive. As much as AI has positively influenced my productivity and many others, it lives on what you feed it. And if you feed it a S\*\*\* (James Taylor told me this is Finance code for ‘*shed*’), you will be given S\*\*\* in return. So don’t go running down that rabbit hole just yet.
In the end, a week later, **I can best describe my visit to London, to the Martech World Forum, as a Swedish smörgåsbord**.
I came home invigorated by all the experiences some speakers shared, sympathetic to the concerns brands confided in me, and motivated to do better to help them. Listening to all the wonderful speakers, meeting many others outside of the event, and the stories from brands, from my peers, told me one thing. Change is taking place in Martech, and although I appreciate all the advances in technology, we are missing many of the basics. Poor foundations and a fragmented understanding are what need our attention now more than ever to help companies gain the most value from the technology at hand.
I got Juan to take a normal photo with me, mission accomplished.
A warm thank you to The Martech Weekly crew, Juan, Keanu, Jacqueline, Adam, and Julia for inviting me to their event. Bringing these great minds of Martech together in London is a feat in itself, let alone having such a strong turnout during a tube strike.
Also, thank you being such wonderful people in real life, too: Gareth, James (2x), Diana, Hazem, Rasmus, Jomar, Teik, Adrian, Ana, Martha, Javier, Neill, Amaan, Georgina, and many many more.
Want to stay up to date on the real ife of Martech? Subscribe for free below 👇🏻
### Why the next five years of data strategy will make the last look easy
URL: https://www.martechtherapy.com/the-next-five-years-of-data-strategy-will-make-the-last-five-years-look-easy/
Last updated: 2025-09-16T06:01:12.000Z
When [Zack Wenthe](https://www.linkedin.com/in/zackwenthe/?ref=martechtherapy.com) from [Tealium](https://tealium.com/?ref=martechtherapy.com) told me, “*the next five years of data strategy will make the last look like child’s play*”, I felt both intrigued and uneasy. Intrigued because Zack has been around long enough in the CDP world to know what he’s talking about. Uneasy because if the last few years already left most teams exhausted, what’s coming next?
We circled around two big forces → privacy and AI. Not in the shallow “*AI will optimize your campaigns*” sense, but in the way these forces are already reshaping human behavior. Zack made the point that customers will increasingly “*show up out of nowhere and disappear again*”. And he’s right. AI-driven search, agentic browsers, and on-device models are tilting the balance of power away from brands and toward individuals.
What stuck with me most was his reminder that buying decisions often come down to fatigue. People stop searching, stop comparing, and just buy. Brands have relied on that for decades. AI changes that dynamic, and it won’t be to the brand’s advantage.
I enjoyed this conversation for another reason, too. Zack approaches AI with a sober mindset. This is something I noticed in [a previous podcast episode with Tealium](https://www.martechtherapy.com/are-mcps-the-usb-c-of-ai-tealium/) [Sav Khetan](https://www.linkedin.com/in/savkhetan/?ref=martechtherapy.com) and [B.J. Allmon](https://www.linkedin.com/in/bjallmon/?ref=martechtherapy.com). No magic wand talk. Just a simple truth “*good AI comes from good data*”. It’s the foundation for everything else.
It was a pleasure to record this one. If you care about where customer data is heading, you’ll find Zack’s perspective sharp, practical, and maybe a little unsettling in the best way.
👥 Connect with us on LinkedIn:
- Zack: [https://www.linkedin.com/in/zackwenthe/](https://www.linkedin.com/in/zackwenthe/?ref=martechtherapy.com)
- Matthew: [https://www.linkedin.com/in/matthewniederberger/](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
📲 Follow Martech Therapy on:
- Instagram: [https://www.instagram.com/martechtherapy/](https://www.instagram.com/martechtherapy/?ref=martechtherapy.com)
- Youtube: [https://www.youtube.com/@martechtherapy](https://www.youtube.com/@martechtherapy?ref=martechtherapy.com)
- Bluesky: [https://bsky.app/profile/martechtherapy.bsky.social](https://bsky.app/profile/martechtherapy.bsky.social?ref=martechtherapy.com)
Receive my next podcast episode in your inbox? Subscribe for free below 👇🏻
### The CDP RFP Dating Game
URL: https://www.martechtherapy.com/the-cdp-rfp-dating-game/
Last updated: 2026-08-31T13:10:14.000Z
On paper, a Request for Proposal (RFP) looks like the fairest way to choose a Customer Data Platform, or anything else for that matter. I am sure if my wife had known about RFPs when we met, I would have been on the receiving side of one. Good thing she didn’t. An RFP is an attempt to make sense of vastly complex and different products through structure, neutrality, and vendor A vs vendor B data in neat columns. But if, like myself, you’ve been in this business for a while, you know the truth 👇🏻
> Most RFPs are wired before the first line is even written.
If choosing a CDP feels like playing a dating game, that’s because it often is. Vendors put on their best smile, agencies play matchmaker, analysts whisper advice from the sidelines, and executives sometimes play the role of overbearing parents. It makes for good theater, but the risks are real. Just ask Netflix, which turned *The Dating Game* into *Woman of the Hour*, a chilling reminder that surface charm can hide much darker realities. Now, I’m not saying CDP vendors and agencies are serial killers, but I’ve seen how far people will go for financial gain.
I can say that because I’ve been on all sides of the table. Agencies, vendors, end users, and now as an independent contractor. I’ve collected the “been there, done that” t-shirts… and socks. I still, to this day, get asked to work for agencies. And I’ve seen the same games play out again and again.
Better to wear socks than get tattoos in this fast-changing market 😎
If you find yourself on the brink of starting an RFP, here’s my free advice 👇🏻
> Please don’t assume the process itself guarantees fairness.
The stories that follow are firsthand experiences and are here to help you recognize where the process often gets bent out of shape, and why independence makes all the difference.
🛑 Wait, before we continue, please let me emphasize that I am not here to burn bridges. **I am here to let you all know that we can do better**. Better for the customer, better for continued business, better for trust.
### **Agencies aren’t neutral, they’re invested**
Agencies love to pitch themselves as impartial advisors. But when I worked for one, an analytics agency around 15 years ago, the game was obvious. We had a sweetheart deal with an analytics vendor. We bought “hits” in bulk, literally the golden currency at the time, at a massive discount, then resold the tool cheap to clients. Looked like a bargain.
The real money? Consultancy. Those tools were a nightmare to implement, and clients were barely out of the starting blocks in terms of maturity. We’d parachute in our consultants at high margin, and that’s where the profit came from. To this day, I can still recognize an implementation by the first three letters of the account ID and know instantly which agency did it and what kind of mess the client is in.
Fast forward twenty years. The Wild West model is gone, but the principle remains. The big consultancies you come across every day don’t survive on regular partner referral fees of, let’s say, 10%. They survive on license reselling worth millions, often in cases where they know deep inside the product they push is not the best match.
In a recent project, Adobe RT CDP was pushed by a big consultancy with **zero alternatives presented**. Let that sink in: *an uncontested process*. Due to decision fatigue on the client side, they were unwilling to spend more time and energy conducting two or three additional three-month risk assessments, so the solution was adopted. Payment started on day one, and there are no people around to implement until day 90\. Again, true story.
> Is this the client’s, the vendor’s, or the agency’s fault?
But let’s be honest, those dinners, Beyoncé tickets, all expenses paid invites to major conferences don’t come cheap, but they tend to sway many decision makers. Anything to get the contract signed. Independence? Forget it.
And just so I’m clear, I’ve taken referral fees in the past, too. I have tried this way of working. That’s how the industry works. But I came to the conclusion that independence is the only way you can look a client in the eye and tell them the truth. No kickbacks. No hidden incentives. Just the problems that need solving.
Also, let’s be rational and acknowledge that not all agencies are bad actors. I have had plenty of experiences with good ones in the past, Etribes being the most recent one. However, I have noticed that the more invested they are with a specific vendor, the greater the chance of kickbacks is.
### **Vendors play the language game**
Even if you keep the agencies out, you’re left with vendor marketing. And let’s be blunt, I hope you see a recurring theme revealing itself in how I think about the industry, vendors are masters of renaming old things to sound new.
Take reverse ETL. To an engineer, that’s perfectly clear. It’s about moving data from a warehouse into downstream systems like Meta, Google Ads, or an email platform. But marketers? Total blank. So the vendors rebranded it as “activation.” Same process, same mechanics, just wrapped in icing that feels strategic instead of technical and tastes sweet.
Or as one [Redditor](https://www.reddit.com/r/dataengineering/comments/1g6me2j/explain%5Flike%5Fi%5Fam%5F5%5Fwhats%5Freverse%5Fetl/?ref=martechtherapy.com) put it:
> *It’s a made up marketing term to try and make people believe that there’s some new data management requirement that needs a new toolset to manage it. ETL says nothing about what your source and target are, it is just moving data from A to B or B to A. So Reverse ETL is a meaningless term as ETL has no implicit direction.*
I love the quote because of the last three words, “no implicit direction”. It’s a matter of perspective, but my friends, that’s the game. One vocabulary for engineers, another for marketers, a third for executives. Everyone walks out thinking they’ve been promised something different, when in reality, it’s all the same pitch in different clothes. Look, I don’t blame vendors, but I think they can do better at being honest. **If people don’t understand what you are trying to sell, educate.**
This is where you need a translator, not the Google Translate app type of translation, but someone who doesn’t get dazzled by the jargon and can cut through the icing to the cake underneath.
### **Analysts live in bubbles**
Then there’s the analyst reports. [Slick quadrants, clean waves, a comforting sense of authority](https://www.martechtherapy.com/is-it-all-a-magical-illusion/). Except most of the input comes from vendors, with a few carefully orchestrated customer references sprinkled in.
[When the customers speak, even Gartner listensGartner released its 2025 Voice of the Customer report for CDPs at the end of August, and, well, I don’t want to say I told you so, “this was identified early on as a likely outcome”.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/when-the-customers-speak-even-gartner/)
I’ve heard from highly respected vendor-side people who’ve traveled to these analyst offices and briefed analysts and realized, mid-conversation, that the analyst barely understood the product. Hardly their fault. Martech evolves faster than analyst cycles. When it takes 18 months to produce a report, the market has already sprinted ahead. By the time you’re reading their “latest insights,” half of it, if not more, is obsolete.
👉🏻 So are they useful as a list of logos to start with? Sure.
✋🏻 Are they the right source to guide a multi-million dollar CDP decision? Not a chance.
At a minimum you need to consider the opinions of actual customers.
### **Politics trumps process**
And finally, the politics. Man, oh, man… the source of many of my grey hairs. You can run a tight RFP, narrow the field to three vendors, line up the demos, score them against requirements. All neat, all fair.
Barney says: “True story.”
Until a board member gets a call from a major vendor and decides their favorite should be back on the shortlist. I’ve seen it multiple times. I'm sure some of you have, too. In any case, we reopened the process, reran the demos, and rescored everything. And guess what? The team rejected the vendor again.
The only thing that changed was the delay, more time, more money, and more frustration. Because one person higher up the ladder wanted to look like they’d “done their due diligence.” Sometimes I wonder if RFP really stands for **R**eal **F**ucking **P**olitics. Pardon my French… or maybe the P in CDP quietly stands for Politics, too.
Like the dating game, politics adds another layer of performance, who gets to look good, who gets to play kingmaker, and who gets to bend the process. But in the end, it’s still theater, and theater rarely delivers the right long-term partner.
### **Why independence is the only way forward**
Put it all together, the agencies with hidden incentives, vendors playing language games, analysts trapped in their bubbles, executives bending the rules, and you wonder why so many CDP selections go wrong.
This is where independence makes the difference. No vendor ties, no referral fees, no boardroom politics. Just a laser focus on the actual problems you need to solve. **A bullshit filter with enough experience to recognize the games, because I’ve played them, seen them, and moved on from them.**
And here’s the part most buyers underestimate. The real challenge begins after the contract is signed. A CDP is only as strong as the crew running it. I’ve written before about [the importance of training your team before implementation](https://www.martechtherapy.com/before-you-deploy-your-cdp-train-your-crew/), because no vendor demo prepares you for the day-to-day grind of making data usable. The great thing is that independent guidance doesn’t need to stop at procurement. It extends to helping your crew actually sail the “customer data” ship.
### **A better way forward**
So look, choosing a CDP isn’t just about picking technology. [It’s a mirror held up to your organization](https://www.martechtherapy.com/the-cdp-reboot-the-disillusionment/). Do you have the discipline to focus on the right problems, the strength to push back on salesmanship, the humility to admit you need [outside help](https://www.martechtherapy.com/what-i-do/)?
If the answer is no, you’ll end up with the flashiest demo or the highest quadrant ranking, and six months later, a very expensive headache. If the answer is yes, you’ll end up with a CDP that actually works for your business.
At the end of the day, everyone should work with the partner they feel comfortable with. Someone competent and objective enough to guide them toward a solution that meets their needs, not a vendor’s quarterly goals. Because the right CDP isn’t the one that checks the analyst boxes, it’s the one that actually works in the real world.
**And getting there requires someone in the room who isn’t selling you anything except the truth.**
[Need independent guidance?](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
Subscribe for free to hear more independent advice on Martech topics, including CDPs and CEPs, straight from the source 👇🏻
## Sign up for Martech Therapy
Thoughts, stories and ideas.
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
### When the customers speak, even Gartner listens
URL: https://www.martechtherapy.com/when-the-customers-speak-even-gartner/
Last updated: 2025-10-09T19:47:08.000Z
Gartner released its 2025 Voice of the Customer report for CDPs at the end of August, and, well, I don’t want to say I told you so, “*this was identified early on as a likely outcome*”.
As I suggested in [my earlier pieces on Gartner and the CDP market](https://www.martechtherapy.com/is-it-all-a-magical-illusion/), where, based on Peer Insights, I generated a ‘review-driven’ alternative quadant, Hightouch scored a ‘Leader’ position compared to being completely excluded from the original report.
Based on the newly published official ‘review-driven’ quadrant, Hightouch has now earned a Strong Performer recognition. It’s always interesting when predictions line up with reality, especially when the validation comes from customers rather than analysts.
Source: [Gartner’s Voice of the Customer for Customer Data Platforms 2025](https://www.gartner.com/doc/reprints?id=1-2LS73XSM&ct=250902&st=sb&ref=martechtherapy.com)
We all know the weight analyst reports carry. The Magic Quadrant remains one of the most influential documents in Martech. Vendors chase it, execs lean on it, and shortlists are often built straight from the grid. But as I’ve written before, these reports tend to narrow the field, sometimes to the point where buyers forget there are other viable options.
The Voice of the Customer report flips the script. Instead of analyst framing, it draws from Gartner Peer Insights reviews, which are based on the experiences of people who actually use the technology day in and day out. And surprise, surprise, customers don’t always agree with the analysts. Some vendors left out of the Magic Quadrant altogether end up shining here, with reviews that highlight real satisfaction and value delivery.
Now, a key nuance to keep in mind is that vendors don’t appear in the Voice of the Customer simply because Gartner analysts chose to exclude them. According to [their publicly available methodology](https://gpivendorresources.gartner.com/en/articles/6746287-voice-of-the-customer-methodology?ref=martechtherapy.com), there are thresholds. To qualify, vendors need at least 20 eligible reviews (with 15 or more capability and support ratings) from companies above $50M in revenue over an 18-month window. If you don’t hit that bar, you don’t show up, regardless of customer sentiment. **This is why the Voice of Customer should be read as a peer-based snapshot, not a census of the entire market.**
When looking at the scores, it does raise questions about why Salesforce is recognized as the ‘Customers’ Choice.’ Do 31 more reviews really outweigh a 12‑point gap in willingness to recommend? From experience working with qualitative data, I’d argue they shouldn’t. That’s my main point of contention with this report and one I wish Gartner would clarify.
And that tension is exactly what makes Hightouch’s Strong Performer recognition notable. By Gartner’s methodology, Strong Performer means scoring above the market average on Overall Experience (a composite of overall rating, capabilities, and support) but below average on User Interest and Adoption. In Hightouch’s case, that lower placement is driven largely by review volume and breadth across industries and regions, despite having the highest willingness to recommend score among peers. In other words, the customers they do have rate them highly, even if their footprint is smaller than the big incumbents. *That nuance matters.*
I’ve seen it play out too many times, still to this very day. Companies selecting a CDP based solely on a Magic Quadrant placement, only to end up with a misfit for their data models and team maturity. I’ll admit, Voice of the Customer reports aren’t perfect, reviews are self-selected (*confirmation bias*), and recent ones carry more weight, but they bring a badly needed counterweight. They remind us to **listen to peers, not just to analysts**.
So no, this isn’t about cheerleading a single vendor. It’s about acknowledging that there needs to be a balance. Analyst views will always, well, at least for now, shape the category, but customer sentiment tells us where the real wins are happening. And when the two diverge, as they just did with Hightouch, and Treasure Data for that matter, it’s worth paying attention.
Want to read more about my opinions on Martech and CDPs, more specifically? Make sure to subscribe for free 👇🏻
### From economics to Martech: Ana Mourão on wins, governance, and positivity
URL: https://www.martechtherapy.com/from-economics-to-martech-ana-mourao/
Last updated: 2025-10-09T19:47:09.000Z
I had such a pleasant conversation with Ana Mourão on Couch Confidentials. She has this rare combination of sharp Martech expertise and an optimistic outlook, even when talking about the messy side of digital transformation.
What struck me most was how Ana sees Martech not just as a stack of tools, but as a system of people and processes where small wins can make a huge difference. From building 7 million profiles globally to navigating the “Groundhog Day” of transformation projects, she’s found ways to stay positive and drive impact.
Thanks again, Ana, for sharing your experience and your energy. It’s the kind of perspective that makes you believe Martech really can be both structured and human.
👥 Connect with us on LinkedIn:
- Ana: [https://www.linkedin.com/in/anamourao/](https://www.linkedin.com/in/anamourao/?ref=martechtherapy.com)
- Matthew: [https://www.linkedin.com/in/matthewniederberger/](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
📲 Follow Martech Therapy on:
- Instagram: [https://www.instagram.com/martechtherapy/](https://www.instagram.com/martechtherapy/?ref=martechtherapy.com)
- Youtube: [https://www.youtube.com/@martechtherapy](https://www.youtube.com/@martechtherapy?ref=martechtherapy.com)
- Bluesky: [https://bsky.app/profile/martechtherapy.bsky.social](https://bsky.app/profile/martechtherapy.bsky.social?ref=martechtherapy.com)
Want to hear from more Martech professionals? Subscribe for free, today 👇🏻
### The real Martech ROI equation
URL: https://www.martechtherapy.com/the-real-martech-roi-equation/
Last updated: 2025-11-25T08:16:56.000Z
Have you ever seen this quote:
> “The first time you go through it, you don't understand it at all. The second time you go through it, you think you understand it, except for one or two small points. The third time you go through it, you know you don't understand it, but by that time you are so used to it, it doesn't bother you anymore.”
If you are reading this article, you might be inclined to think that this quote is from some notable Martech leader describing your Martech stack. Nothing is further from the truth. The quote is from [Arnold Sommerfeld](https://en.wikipedia.org/wiki/Arnold%5FSommerfeld?ref=martechtherapy.com), a German theoretical physicist, describing thermodynamics. And before you think you have landed on the wrong blog, bear with me as I try to explain its link to marketing technology.
## Second Law of Thermodynamics and your Martech stack
Marketers talk about ROI as if it’s just revenue minus license costs. If only it were that simple. The real drag on a Martech stack isn’t just the costs you incur for MTUs, connections, API volume, and so on. It’s the energy we spend holding the whole thing together, like duct tape. Governance meetings, patchwork integrations, cleanup projects, the hidden costs that never appear in the budget but always show up in the results, and your performance report.
[C.P. Snow](https://en.wikipedia.org/wiki/C.%5FP.%5FSnow?ref=martechtherapy.com) once said about the second law of thermodynamics that “*you can’t break even*”. You never defeat entropy, you only buy yourself time (*I sugarcoated it a bit to make his quote sound less existential*). I wasn’t triggered to dig deeper into the similarities between Martech stacks and entropy until just a few weeks ago. While driving along in my car, I came across a track on Spotify called *The Second Law of Thermodynamics* by NoNameLeft. Being the nerd I am, I had to listen to it.
The track includes a voice, a British lecturer (*definitely not Feynman*) talking about, you guessed it, the second law of thermodynamics, wrapped into an amazing techno track. Yes, I was the guy who got his Martech metaphors from a rave playlist.
I’ll admit, I never properly understood the second law of thermodynamics when I first read about it. Too abstract, too many (probability) equations. A bit like Arnold Sommerfeld’s quote. It finally clicked years later, not in a physics lab, only when I applied it to Martech, and later when I saw Brian Cox describe it with a sandcastle in that soothing voice of his.
Watching stacks drift into this natural chaos was the best crash course I could have asked for. Honestly, if schools really want teenagers to grasp entropy, they should skip the textbooks and hand them a marketing automation platform. Ten minutes of abandoned campaigns and broken integrations, and the concept explains itself. No kidding.
That said, I did enjoy physics in school, mostly thanks to my teacher, Steve Wetherall. But my real interest in the subject only deepened when I read [Isaac Asimov’s ](https://www.amazon.com/Isaac-Asimovs-Guide-Earth-Space/dp/0449220591/?ref=martechtherapy.com)[*Guide to Earth and Space*](https://www.amazon.com/Isaac-Asimovs-Guide-Earth-Space/dp/0449220591/?ref=martechtherapy.com). Watching and listening to great storytellers like Brian Cox and Carl Sagan did more than any classroom ever could. To this day, I still stand outside when comets pass, when planets align in conjunction, and I watch almost every hard sci-fi film and series I can find. It’s no wonder entropy and gravity keep sneaking into my, and other people’s, Martech metaphors.
## Entropy in the stack
Back to the story… the second law of thermodynamics says that **systems tend to move from order to disorder unless new energy is added**. You don’t need a physics degree to see that in Martech.
A carefully integrated customer journey map turns into spaghetti the moment two new tools promise “seamless” connections. An expensive analytics platform quietly dies when its champion leaves post-implementation. Tags and pixels pile up like forgotten sandcastles, leaving ghost data for the next team to trip over.
It isn’t that marketers are careless. It’s that the stack behaves like a physical system. The more moving parts, the more ways for entropy to sneak in, which only proves that we need to put energy into it to maintain the status quo, at a minimum.
A quick question before we move on:
> Does technical debt, as described above, increase the chaos?
## Martech leaders and Maxwell’s demon
When researching for this article, I came across an old thought experiment called [Maxwell’s Demon](https://en.wikipedia.org/wiki/Maxwell%27s%5Fdemon?ref=martechtherapy.com). Picture a tiny creature sitting at a gate between two chambers of gas, letting fast molecules through one way and slow molecules the other. If it worked, the demon could create order without effort, which physics tells us is impossible.
In Martech, leaders try to play that role, and no, they aren’t demons. But they do sit at the gate, deciding which projects get priority, which tools get retired, which integrations matter. In theory, they’re trying to resist entropy. In practice, they burn enormous energy just doing the sorting steering committees, maintaining governance docs and processes, and endless reviews. If Maxwell’s Demon wore a hoodie, it would probably be a Martech program manager.
## Entropy, a friend or foe?
I’ve said before that [CDP implementations act like stress tests for digital transformation](https://www.martechtherapy.com/your-cdp-is-more-than-just-a-platform/). And CDPs are not immune to entropy, but remain a great place to witness the second law of thermodynamics in Martech first-hand. Every inconsistency in identity data, every governance gap, every process shortcut, it all shows up at once. Order to disorder, order to chaos.
Some leaders often blame the vendor or the tool, but that’s rarely the real culprit. It’s the second law of Martech at work. [A CDP, as I’ve said repeatedly, is just the mirror to the inner workings of your organization](https://www.martechtherapy.com/the-cdp-reboot-the-disillusionment/). What you see in it is your own entropy, staring back.
Entropy isn’t always bad. In physics, it’s the reason heat spreads, life emerges, and stars eventually burn out. In Martech, a bit of disorder sparks innovation, or at least curiosity. Side projects in well-structured environments, messy pilots that expose organizational shortcomings, even “rogue” tools sometimes create breakthroughs.
The trick is knowing when entropy is useful exploration and when it’s just corrosion. Innovation thrives at the edges; operations rot at the core if not maintained. If you’ve ever found a brilliant use case hiding in someone’s unsanctioned spreadsheet or Notion workspace, you know what I mean.
So how do you resist entropy? Not by wishing it away, and definitely not leaving it to its own devices. You resist it with energy. You resist it by putting effort into the processes: pruning unused features, monitoring integrations, documenting workflows, making governance more than a quarterly slide you share up the chain.
It’s invisible work. Nobody gives you a standing ovation for deleting 400 stale tags. But when nobody does it, the whole stack starts to crumble.
## The real ROI equation
Now a show of hands of people who have seen the following calculation in RFPs. Contrary to what we often think, ROI isn’t just revenue minus license fees and hosting costs. If you really want the equation, it looks more like this:
The stack costs are the obvious ones: licenses, infra, and professional services. But the real drag comes from the human energy we spend holding things together: the people running governance meetings, the operators patching integrations, the specialists rewriting documents, the team leads training new hires. This is something I like to refer to as EDE, or Entropy Delaying Energy (because remember, there is not stopping it). That investment rarely shows up as a neat line item, but it eats into ROI just the same. And if you starve it, entropy charges you in other ways, outages, rework, broken journeys, lost revenue, simply called REL, or Residual Entropy Loss.
Too little energy and the stack collapses under its own weight, under built up REL. Too much energy and you drown in bureaucracy. The ROI sweet spot is somewhere in between, where you put in just enough effort to keep the sandcastle standing and balance out EDE and REL. More on these calculations in future articles.
## Sandcastles in the wind
In a sense Snow was right. There’s no final victory, just the temporary order we buy with attention and effort. The Martech stack is a sandcastle, and the wind is always blowing. Just like [Juan Mendoza and Jacqueline Freedman discussed in their podcast](https://themartechweekly.com/trouble-at-yotpo-litmus-ai-is-a-drug-and-analyst-firms-future/?ref=martechtherapy.com) when discussing business, nothing lasts forever. Everything will eventually collapse. We need to be realistic about that.
Maybe the strategy isn’t to pretend we can stop entropy. Maybe it’s to accept that order is temporary, and to find a rhythm of building, repairing, and rebuilding. That isn’t failure, but without the realization that human energy is needed to maintain effectiveness, it will all collapse.
To quote Arnold Sommerfeld again “*thermodynamics is a funny subject*”, but so is Martech. We think we understand it, but every there is something new to learn, and apply.
So the real question is this:
> **How much energy are you spending holding the sandcastle together, and is it giving you the ROI you think it is?**
Want a front row seat at reading my thoughts on Martech? Subscribe for free 👇🏻
## Sign up for Martech Therapy
Thoughts, stories and ideas.
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
### From psychology to Spryker: Guido Jansen on community, automation, and AI in B2B
URL: https://www.martechtherapy.com/from-psychology-to-spryker-guido/
Last updated: 2025-08-29T11:40:44.000Z
In this episode of *Couch Confidentials*, I sit down with Guido Jansen, Spryker’s Global Business & Technology Evangelist, and someone with one of the longest job titles I’ve ever introduced on the podcast. Guido’s path is unusual: a background in applied cognitive psychology, years building the Magento community, and now leading community and customer success efforts at Spryker.
We discuss what it means to build ecosystems that last and how feedback loops from hackathons and developer meetups inform Spryker’s product direction. Guido also shares his experiments with **n8n**, vibe coding, and MCP integrations, as well as what happens when you proudly demo something your audience isn’t ready for.
The conversation ties back to themes I’ve been writing about in the **Contextual CDPs** and **Agentic AI in Martech** series: how much trust can you place in AI, what guardrails are needed, and why adoption lags behind the hype. Guido warns about the risks of workflows that work “95% of the time,” and reflects on what the rise of AI means for junior developers entering the field.
If you’re curious about where automation meets community, and how enterprise clients balance innovation with risk, this episode offers a grounded perspective.
👥 Connect with us on LinkedIn:
- Guido: [https://www.linkedin.com/in/gxjansen/](https://www.linkedin.com/in/gxjansen/?ref=martechtherapy.com)
- Matthew: [https://www.linkedin.com/in/matthewniederberger/](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
📲 Follow Martech Therapy on:
- Instagram: [https://www.instagram.com/martechtherapy/](https://www.instagram.com/martechtherapy/?ref=martechtherapy.com)
- Youtube: [https://www.youtube.com/@martechtherapy](https://www.youtube.com/@martechtherapy?ref=martechtherapy.com)
- Bluesky: [https://bsky.app/profile/martechtherapy.bsky.social](https://bsky.app/profile/martechtherapy.bsky.social?ref=martechtherapy.com)
Get notified when episode 3 drops. Subscribe for free below 👇🏻
### Before you deploy your CDP, train your crew
URL: https://www.martechtherapy.com/before-you-deploy-your-cdp-train-your-crew/
Last updated: 2025-10-09T19:47:11.000Z
I’ve said this before, but it bears repeating → CDP projects don’t just test your tech stack, they test your team. And most of the time, that test happens in real time, under pressure, with stakes that no one thought to rehearse.
After I published the piece on [CDPs as a kind of digital transformation stress test](https://open.substack.com/pub/martechtherapy/p/your-cdp-is-more-than-just-a-platform?r=3i8xzy&utm%5Fcampaign=post&utm%5Fmedium=web&showWelcomeOnShare=false), the comments and direct messages lit up with something that felt oddly familiar. People weren’t just reacting to the tech insights; the internet is filled to the brim with those. They were describing moments of confusion, panic, last-minute scrambles, and hard lessons. And that took me back to my days before data, even before Salesforce was founded.
Back to a different kind of readiness drill.
On board the USS Dwight D. Eisenhower in 1994
In my earlier post, [*This is me, who are you?*](https://open.substack.com/pub/martechtherapy/p/this-is-me-who-are-you?r=3i8xzy&utm%5Fcampaign=post&utm%5Fmedium=web&showWelcomeOnShare=false), I wrote about my time in the military. What I didn’t fully explain there was how structured our preparation had to be. Before every deployment, we trained like hell. Weeks, sometimes months, of work-ups. No real missions, just simulation after simulation… after simulation. We were running drills in our dreams. Real pressure, imagined stakes. Everyone in sync.
You weren’t just practicing your own role. You were learning how your actions, or inaction, affected the next person. You drilled communications, reactions, fallback plans. You trained for the fire that never broke out. For the flooding that never happened, which of course was simulated \*sigh\*. For the equipment failure that, thankfully, stayed hypothetical. Because you didn’t want to figure that out for the first time when it was real.
And we didn’t do it alone. As part of a NATO member country’s military, as a dual citizen I served in both the US Navy and Royal Dutch Navy, we worked closely with allied forces. Some of them were better trained for certain things, ASW, AEW, AAW, fire control, damage containment, and when it mattered, we brought them in. They didn’t run the show. They helped us sharpen our edge and they did not kid around. You fail, you start over.
Towards the end of my military career, I served as a non-commissioned officer in communications, working with everything from semaphore and signal flags to LF/HF/UHF radios and encrypted satellite systems. My role was to process and distribute high-clearance message traffic across the command, in peacetime and in wartime simulations. There was zero room for guesswork… Crimson Tide anyone?
Everyone needed to know their role like the back of their hand and their responsibility when things got loud, fast, and unpredictable… you know, *shit-hits-the-fan* level events.
Some of our most intense drills took place at [Flag Officer Sea Training in Plymouth](https://www.royalnavy.mod.uk/locations-and-operations/bases-and-stations/fost?ref=martechtherapy.com), renamed to Fleet Operational Standards & Training and relocated to Portsmouth, FOST for short. It was where ships went to prepare for real deployment, and where we were pushed to operate as one unit under extreme pressure. The goal wasn’t perfection. It was cohesion. Readiness to the extreme. Knowing what to do when systems fail and time runs out is crucial. How do you fight a fire when you have lost water pressure throughout the ship?
That’s where the link back to my current work clicked into place.
## Most companies love the kickoff, not the training
Here’s the thing that I have seen repeated in the research I have been doing this past year, and in discussions in my podcast, in dealings with customers, **most teams don’t prepare. They kick off.**
There’s a project lead, a few department heads, maybe a Notion doc or some RACI chart that looks like it means something. Then they hit the ground running, straight into integration problems, ownership confusion, data issues, and activation mistakes. And suddenly everyone’s scrambling to figure out who does what when the alarms go off.
But the issues, as I have been saying over and over again, are *rarely technical*. They’re team issues. Behavioral. Cultural. Collaborative. Everyone assumes someone else has trained for this. That the process is known. That the structure will hold.
It usually doesn’t.
I’ve seen [CDP implementations stall](https://open.substack.com/pub/martechtherapy/p/the-cdp-reboot-the-stall?r=3i8xzy&utm%5Fcampaign=post&utm%5Fmedium=web&showWelcomeOnShare=false) because the CRM team didn’t know what "consent sync" meant, or because marketing assumed engineering had QA’d the event stream. And I’ve seen the aftermath of a misfire, or should I say misfires, a customer journey trigger gone rogue, identity mismatches causing real brand damage, activation campaigns pulled mid-flight. These are preventable errors. They’re the result of engaging in ‘battle’ before training.
And while the Martech world obsesses over composability and favorite flavor of AI, *mine is Claude by the way*, most teams I see still haven’t practiced the basics. With that, I mean **working together under pressure**.
If I learned anything from my time in uniform, it’s this:
> Pressure doesn’t create discipline. It reveals it.
## What a work-up could look like in business
Let’s imagine we took preparation seriously.
Before going live with a new CDP, or rolling out a major Martech initiative, the team would run structured drills. Not more alignment meetings, but actual dry runs:
Run a simulation where the identity graph breaks. See what happens when a field gets dropped from the data layer. Practice escalation when a campaign goes out to the wrong segment. Not just post-mortems after failure, pre-mortems before launch.
You’d get marketing, data, CRM, product, and compliance in a room, not to agree on vision, but to **respond to a scenario**. Work out protocols, communication plans, first response mechanisms. You’d find out quickly whether roles are understood, whether systems talk to each other, and whether the trust is there when things get messy.
And yes, you might bring in outside help. Not to run the project, but to help simulate failure, surface blind spots, and speed up the learning curve. The same way we brought in allies during our work-ups who had deeper experience in certain failure scenarios.
Please, don’t consider this a luxury you cannot afford. Consider it a form of respect. For the project. For the customer. For your own team.
## Why I still work like a NATO partner
This is where it gets personal again. Because these days, I often find myself playing a familiar role. Not part of your standing crew, I have not done that in over 10 years, but not just an outsider either. I come in to help sharpen the edge before it gets real.
Sometimes that means running drills with your data team. Sometimes it’s helping marketing and product rehearse a crisis response. And sometimes it’s just being there to spot the blind spots that haven’t surfaced yet, the ones that usually wait until things go live.
Like those NATO allies we used to train with, or the instructors at FOST, I’m not there to run your ship. Your team needs to learn that. I’m temporarily attached to your crew. My job is to challenge internal assumptions, improve collaboration, and help your people prepare for the mission ahead. Because you don’t build readiness by reading a deck. You build it by rehearsing what might go wrong.
Because it always does.
And when it does, you don’t want your first real test to also be your last chance to get it right.
[Need Martech support, let's connect!](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
*This article also marks a turning point in how I think about the project I am developing. Beyond structure, capability, and process, I’m starting to believe that response readiness, the ability to function as a team under pressure, may be the true indicator of maturity. More on that soon.*
If you found this helpful, you can subscribe to my Substack and learn more about my vision of maximizing Martech value for your company. It’s free 👇🏻
### MAP, CEP, or CDP? Klaviyo’s James Fang on where marketing automation is headed
URL: https://www.martechtherapy.com/map-cep-or-cdp-klaviyos-james-fang/
Last updated: 2025-08-21T07:00:56.000Z
Season 2 of *Couch Confidentials* opens with [James Fang, Director of Product Marketing](https://www.linkedin.com/in/james-fang-88bb703/?ref=martechtherapy.com) at [Klaviyo](https://www.klaviyo.com/?ref=martechtherapy.com) and former VP at [mParticle](https://www.mparticle.com/?ref=martechtherapy.com). We get into the weeds of Martech terminology, such as CEP, MAP, CDP, and whether those labels still mean anything when platforms are converging. James shares why Klaviyo positions itself as a *B2C CRM* built on a shared data platform, and how that ties into the wider trend of commoditized CDP features.
We also discuss the consolidation wave I’ve written about in the [**CDP Reboot**](https://www.martechtherapy.com/the-cdp-reboot-the-promise/) and [**Multi-CDPs**](https://www.martechtherapy.com/is-the-cdp-binary-broken/)series, with James pointing to real-world cases where companies are questioning the need for standalone CDPs. From AI-driven recommendations for small marketing teams to MCP-based integrations for enterprise clients, Klaviyo is positioning itself across the spectrum.
It’s a wide-ranging conversation touching on industry upheavals (like [Yotpo](https://www.yotpo.com/?ref=martechtherapy.com)’s retreat from email/SMS), the future role of AI agents in marketing, and whether CDPs risk being reduced to integration middleware. For anyone following my writing on composability, suites vs. warehouses, or agentic AI in Martech, this episode connects those threads with a practitioner’s view from the product side.
👥 Connect with us on LinkedIn:
- James: [https://www.linkedin.com/in/james-fang-88bb703/](https://www.linkedin.com/in/james-fang-88bb703/?ref=martechtherapy.com)
- Matthew: [https://www.linkedin.com/in/matthewniederberger/](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
📲 Follow Martech Therapy on:
- Instagram: [https://www.instagram.com/martechtherapy/](https://www.instagram.com/martechtherapy/?ref=martechtherapy.com)
- Youtube: [https://www.youtube.com/@martechtherapy](https://www.youtube.com/@martechtherapy?ref=martechtherapy.com)
- Bluesky: [https://bsky.app/profile/martechtherapy.bsky.social](https://bsky.app/profile/martechtherapy.bsky.social?ref=martechtherapy.com)
Sign up for free to receive the next episode directly in your inbox 👇🏻
### Beyond the Gartner Magic Quadrant
URL: https://www.martechtherapy.com/beyond-the-gartner-magic-quadrant/
Last updated: 2025-10-09T19:47:11.000Z
The Gartner Magic Quadrant has been a familiar reference point for most of my career, and if you are reading this, your career, too. It condenses months of evaluation into a neat two-axis diagram where vendors are split into sections labeled Leaders, Visionaries, Challengers, and Niche Players. It’s comforting in its simplicity, and funnily enough, complimentary wherever you find yourself on it. But as I’ve learned from working both inside companies and as a consultant, that neatness is part of the problem.
As we have seen, excluding some cultures, real buying decisions rarely happen in a vacuum. They’re shaped by hallway conversations, Slack threads, and increasingly, whatever AI puts in front of us when we start our research. And here’s where I think the buying game is changing.
### The Gartner Magic Quadrant under pressure
Gartner’s process still carries weight, I will have to admit that. The analyst interviews, vendor briefings, and reference checks all add rigor to an already established and trusted process. But in Martech, especially in areas like API-led platforms or composable architectures, change moves faster than the update cycle, and analyst firms seem to be struggling. By the time the latest quadrant lands, a vendor might already have launched three major features that never made it into the assessment.
I’ve also witnessed the complete disconnect between a vendor’s quadrant position and how it actually performs on the workfloor. Some platforms sitting in the “Leader” box are barely used for the capabilities that supposedly earned them that spot. Meanwhile, others that practitioners rely on daily for orchestration or identity resolution might scarcely register on the chart or, if I can be brutally honest, remain hidden in the shadows.
### AI as the first analyst, and why that matters
Like it or not, AI is now acting as the first analyst in many buying processes. I’ve tested this myself, ask a large language model to “recommend a CDP” based on a set of requirements and existing platform information, and it will pull from public documentation, blog posts, case studies, and, increasingly, review sites. This means your shortlist might already be shaped before a single human analyst has a say.
The trouble? AI is only as good as its source material. Peer reviews can be gold, when they’re genuine, detailed, and recent. But I’ve been in this industry, including that of user experience research, long enough to know that reviews are often incentivized, coached by customer success teams, or written at the honeymoon stage of a deployment. That’s not a full picture. And definitely not the ‘picture’ you should base your investments on.
### Review gravity and the risk of shallow summaries
Review gravity, the weight that volume, recency, and specificity carry, can determine how AI describes a vendor. A thin review profile produces a shallow AI summary, which in turn lowers the odds of being shortlisted. This can sideline solid products simply because they didn’t generate enough “review noise.”
And let’s be honest, incentivized reviews aren’t going away, no matter how subtle. They’re part of the marketing playbook now and will be pushed to the frontline faster than you can say “dark pattern marketing sucks”. Which is why I tell clients: treat AI summaries as an *indicator*, as an unveiling of strategies and solutions that could potentially work for you. Do not treat it as a verdict.
### From quadrant to evidence pack
For me, the **fundamental necessary change** is moving from a single reference point, whether that’s a quadrant or an AI output, to an evidence pack. My advice, that I want to share with you, is that if you find yourself with a Martech use-case that needs solving:
- use analyst insights for the macro view
- balance those insights with peer and practitioner feedback
- use partner ecosystem checks for integration confidence
- demand an effective proof of concept and test performance with real data
It’s in connecting these dots that real confidence emerges.
So yes, keep the Gartner Magic Quadrant in your toolkit if you feel compelled to do so. But remember it’s just one lens. AI can help surface options quickly, but human expertise, people who’ve seen these tools succeed and fail in the wild, is what keeps you from making a costly mistake.
Choosing solutions to serve your use-cases is difficult. Today’s technologies are challenging enough to operate, let alone choose. Add on to that internal complications, such as siloed teams and no management support, and you find yourself in a predicament you find difficult to control.
And if that sounds like a pitch for why you should have someone like me in the conversation… well, maybe it is. Thanks for following a long in the series. If you would like to connect with me, you can [find me on LinkedIn](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com).
---
**Read the other parts in this Rethinking the Quadrant series**
- [Part 1: Why the Magic Quadrant no longer reflects CDP reality](https://www.martechtherapy.com/is-it-all-a-magical-illusion/)
- [Part 2: When definitions stop matching reality](https://www.martechtherapy.com/the-real-battle-for-cdp-relevance/)
---
Make sure to subscribe if you want to be notified when I publish my next Martech series. It’s free 👇🏻
### Hotel 626 was “fun” until the phone rang
URL: https://www.martechtherapy.com/hotel-626-digital-marketing-dark-patterns/
Last updated: 2025-10-09T19:47:11.000Z
A couple of weeks ago, I was sitting on the couch with my son, letting Youtube autoplay its way into the stranger corners of the internet, when we landed on a video from the channel **Visual Venture**. It was a video titled “Kids Games Too Disturbing For Kids” which [included a piece on a sinister game from 2008 called ](https://youtu.be/rn41jqk%5FdAU?t=1536&ref=martechtherapy.com)[*Hotel 626*](https://youtu.be/rn41jqk%5FdAU?t=1536&ref=martechtherapy.com).
He laughed at the grainy graphics and theatrical jump scares. Don’t judge him, he was born in 2013 and never experienced graphics like we did. I sat there thinking, *this was the kind of lead magnet marketers could only dream of*. The campaign, focused on bringing two flavors **back from the dead**, reportedly cost around $500,000… a hefty budget for a snack promotion, but in hindsight, they got a lot of data for their money.
### **The game that played you back**
*Hotel 626* was a Doritos promotion that ironically didn’t feature chips at all. Instead, you “checked in” by handing over your name, email, and date of birth. The game then prompted you for webcam and microphone access, pitched as “making the experience scarier”. And in its final moments, if you were in the United States, you could enter your phone number to receive a live call with whispered instructions on how to escape. I mean, W\*&… **that would have given me many sleepless nights**.
The 2009 sequel, yes, they did it again, *Asylum 626*, went even further. This time, you could log in with Facebook or Twitter, and the game would weave your social graph into the horror, even posting content on your behalf. You read that correctly. “The more access you grant”, the experience promised, “the more intense the game”.
One section of the 2011 FTC complaint (which is no longer available online) against Doritos’ parent company, PepsiCo/Frito-Lay, described this approach bluntly:
> “The site encourages teens to provide personal information and access to their social networks in order to enhance gameplay.”
From a marketing standpoint, it was precisely what the campaign playbook preached at the time: *“Make the experience personal by harnessing the potential of media and technology.”* And they did. Brilliantly, and maybe a little too well.
### **Activation without guardrails**
Looking back at it now, it’s hard to overstate how much was packed into that one campaign. It captured identifiers, behavioural data, device information, and, in the sequel, social graph data. It blurred the line between entertainment and surveillance, all wrapped in the thrill of a late-night horror story.
The previously mentioned FTC complaint also noted:
> “Visitors are not provided with clear notice of how their information will be used, nor is parental consent obtained for those under age.”
Back then, this was framed as imaginative targeting, stating the obvious that *“really understanding your target audience and creating imaginative content is a critical element in any marketing campaign.”* And it did just that, often by leaning on persuasion triggers that Robert Cialdini would recognise instantly. Scarcity in the form of a 6 pm–6 am play window, commitment once you’d already shared some personal details, and even a dose of authority when the game told you what to do next. It was textbook influence, just wrapped in a haunted hotel lobby.
### **Then versus Now**
Back in 2008, *Hotel 626* only opened its doors between 6 pm and 6 am, asking for your name, email, date of birth, and sometimes your phone number, without specifying how long this information would be kept. Today, that would mean explicit consent, a clear purpose, and a disclosed retention period. Well, if you are doing it right.
Webcam and microphone access came bundled into the experience. Remember, we are talking about an online game. Now, those would need to be optional, requested only when necessary, and explained in the moment.
The sequel’s Facebook and Twitter logins gave posting permissions and access to your social graph with little warning. It wasn’t exactly a Cambridge Analytica moment, but you could see how the same mechanics, data pulled in under the guise of fun, could become a problem in less playful hands. Now, surprise posting is a non-starter, and social access needs a separate, transparent opt-in.
Its teen appeal came with no parental consent flow. Today, COPPA in the US and GDPR Article 8 in the EU demand age verification and extra safeguards.
Even the “more access makes it scarier” mechanic, celebrated in 2009, would now be seen as a dark pattern. And that mysterious phone call? These days you’d have to tick a box, read a privacy notice, and confirm your number twice. By the time it rang, the only thing left to fear would be missing your next meeting or, in case you're still living at home, your mother calling you to dinner for the 5th time.
Which leaves us with the bigger question:
> If every twist and turn in a modern activation has to survive a compliance obstacle course, how far can we really take it before the spark that made it memorable burns out?
### **The edges haven’t disappeared**
What kept me thinking about the video the most after watching it was how familiar the instincts still are. Brands still push the edges of what’s permissible. They’ve just traded the overt creepiness of a phone ringing in the dark for quieter, more pervasive tactics. Now the intrusion might take the form of an ad appearing in your feed right after you’ve had a private conversation about the topic. Most platforms deny “listening in,” yet whether it’s device microphones, aggressive contextual targeting, or probabilistic identity stitching, the effect is the same → it feels like someone is in the room.
Some practices take it even further, like building shadow profiles for people who never signed up to a service, inferring interests and connections from the data of friends or family. Others use precise location data to quietly trigger ads based on where you’ve been, or tap into vast broker networks to enrich customer profiles with details the individual never knowingly provided.
I agree, it’s less theatrical than a horror game calling your phone, but the reach, subtlety, and deniability make it far more pervasive and far harder for people to recognise when the line has been crossed. And with “going digital” having *“lowered the barriers to entry for creating compelling, tailored and interactive content significantly”*, it’s not just global brands who can play at these edges anymore… almost anyone can.
### **Where’s your line?**
We live in a world of privacy laws, compliance frameworks, and regulatory watchlists. A modern version of *Hotel 626* would be hard to build with the prevalent presence of AI without triggering multiple legal tripwires. But that doesn’t mean the temptation is gone.
With generative AI, a “Hotel 626” moment could be rebuilt in weeks, not months, and for a fraction of that $500k price tag. The question is whether marketers will check in for the creativity, or be checked out for the creepiness.
Thanks for reading Martech Therapy! Subscribe for free to receive new posts and support my work.
### The real battle for CDP relevance
URL: https://www.martechtherapy.com/the-real-battle-for-cdp-relevance/
Last updated: 2025-10-09T19:47:12.000Z
If you follow [the CDP Institute’s definition](https://www.cdpinstitute.org/learning-center/what-is-a-cdp/?ref=martechtherapy.com), there are four non-negotiable traits for a platform to be considered a Customer Data Platform. But there’s a huge problem. **Those traits are no longer exclusive to CDPs**. Customer Engagement Platforms like Braze, Bloomreach, Customer.io, Klaviyo, and ZEPIC, or composable vendors like Hightouch, are ticking the same boxes. Some were never meant to be in the CDP category, yet they’re already competing for the same budget lines.
It’s too late to say that it is purely theoretical. We have already crossed that bridge. It’s what I see in real RFPs and platform migrations. Clients weighing an AI Decisioning-first CEP against a so-called Leader in the Gartner Magic Quadrant. **If the outcomes are similar, the definition starts to matter less.** And when definitions become elastic, quadrants lose their sharpness.
### The invisible layer of competition
In [part 1 of this series “](https://www.martechtherapy.com/is-it-all-a-magical-illusion/)[*Is it all a magical illusion?*](https://www.martechtherapy.com/is-it-all-a-magical-illusion/)[”](https://www.martechtherapy.com/is-it-all-a-magical-illusion/), we looked at the disconnect between Gartner’s Magic Quadrant for CDPs and how real-world teams experience these platforms. [Peer Insights painted a very different picture](https://www.gartner.com/reviews/market/customer-data-platforms?ref=martechtherapy.com), not perfect, but far closer to the day-to-day truth. The missing piece? Many vendors shaping the customer data space aren’t even in that Magic Quadrant.
Some of this invisibility is by design, some of it, in my honest opinion, is bureaucratic. The Magic Quadrant, as I stated in part 1, is built to evaluate a defined market category, and it rewards scale, stability, and enterprise polish. That’s why suite vendors like Adobe, Salesforce, and Oracle show up year after year. But it also means that players who innovate around the edges, whether it’s reverse ETL, AI-powered identity, or CEP-driven orchestration, often remain off the radar.
When you speak with teams who’ve switched from a suite-based CDP to a CEP with CDP-like capabilities, they’re not talking about missing out on a quadrant position. They’re talking about cost savings, faster iteration, and better integration with the rest of their stack. I’ve seen this shift play out in both European enterprise migrations and mid-market adoption in the Middle East.
### The architecture vs. usage problem
Here’s where the conversation needs to evolve, if there is still time. The Magic Quadrant, by design, is architecture-centric. It’s about what the platform *can* do in theory, not necessarily what it *will* do in your environment with your team and governance in place. That’s why the Leaders box can be full of platforms that, once deployed, fail to deliver the agility or operational fit customers actually need.
This is [something I touched on in the multi-CDP series](https://www.martechtherapy.com/is-the-cdp-binary-broken/): ownership, governance, and workflow fit determine far more about success than category alignment. In practice, the question isn’t
> “What architecture is best?”
but rather
> “What architecture do we have the people, process, and operational maturity to make work?”
### The missing perspective in Magic Quadrant scoring
One of the recurring points in my conversations with industry peers, including a recent discussion with a major vendor (that actively works for its placement in the quadrant), is that while the Magic Quadrant is useful for understanding enterprise-scale capability, it’s not weighted to reflect mid-market priorities or regional buying patterns. That’s a blind spot worth calling out, even if it is just by me.
A CMO in the UAE choosing a CDP to anchor a retail media network is making a fundamentally different set of trade-offs than a global bank’s marketing operations lead in London. Yet the scoring doesn’t reflect that diversity of decision-making. The result? The Magic Quadrant can unintentionally reinforce a one-size-fits-all perception that doesn’t hold up in real operations.
### A live example of sentiment shifting, even beyond culture
Ironically enough, Juan Mendoza, CEO of *The Martech Weekly*, [recently posted on LinkedIn](https://www.linkedin.com/feed/update/urn:li:activity:7361163261183995907/?ref=martechtherapy.com) about reading the life story of Gideon Gartner, just as Gartner’s stock was taking a sharp dive (*I had no idea* [*part 1 of this series*](https://www.martechtherapy.com/is-it-all-a-magical-illusion/) *would have such an effect, just kidding, I hope…*). In his post, he reflects on how the company was once groundbreaking in its ability to analyse the market from the perspectives of investors, customers, and vendors, but is now struggling to stay relevant in an AI-driven, information-saturated era.
He notes how younger Martech executives are starting to say things like:
> "Who's Gartner?"
> "This MQ doesn’t help my technology decisions."
> "I haven’t read a Gartner report in years."
The post is a real-time observation that even the most established names in tech advisory are no longer guaranteed influence. It’s a reminder that the disconnect we’re seeing in the CDP Magic Quadrant isn’t an isolated case. It’s part of a broader pattern where industry authority is being tested in public, and in some cases, in the stock market too.
### Where we go from here
If part 1 was about showing the gap between analyst-driven rankings and practitioner experience, part 2 is about recognising that the real competitive map is bigger than the Magic Quadrant. That includes CEPs, composable vendors, and emerging players whose innovation is often invisible to the quadrant, but not to the teams using them.
I’m not arguing that Gartner’s Magic Quadrant should suddenly open the floodgates and throw every tangential player into the mix. But if we’re serious about giving buyers a tool that reflects the market they actually operate in, the scope needs to evolve. That could mean, for instance:
- supplementing the Magic Quadrant with architecture-agnostic usage maps
- making regional weighting part of the scoring
- acknowledging where category lines have blurred to the point of irrelevance
The alternative is to keep using a map that shows the biggest cities and misses the fastest-growing towns. Which, if you’ve been following the [CDP Reboot](https://www.martechtherapy.com/the-cdp-reboot-the-promise/) or [multi-CDP](https://www.martechtherapy.com/is-the-cdp-binary-broken/) discussions, is exactly how categories start to lose their relevance.
---
**Read the other parts in this Rethinking the Quadrant series**
- [Part 1: Why the Magic Quadrant no longer reflects CDP reality](https://www.martechtherapy.com/is-it-all-a-magical-illusion/)
- [Part 3: What buyers really trust now](https://www.martechtherapy.com/beyond-the-gartner-magic-quadrant/)
---
If you like what you are reading and want to be notified when the final part in this Gartner Magic Quadrant for CDPs series drop, subscribe for free below 👇🏻
### Is it all a magical illusion?
URL: https://www.martechtherapy.com/is-it-all-a-magical-illusion/
Last updated: 2025-10-09T19:47:14.000Z
Gartner’s Magic Quadrant is treated like gospel in boardrooms from Dubai to Düsseldorf. A single position in that familiar matrix can nudge millions in Martech budgets from one vendor to another. The thing to keep in mind is that the Quadrant doesn’t measure what many buyers think it does. It rewards size, vision, and analyst choreography, and not necessarily real-world usability, implementation speed, or practitioner satisfaction. It reflects power structures, and rarely performance.
This first part in the *Rethinking the Quadrant* series takes aim at the mechanics behind those polished charts and asks a blunt question:
> What kind of success are we actually rewarding and at what cost to innovation, efficiency, and relevance?
---
**Author’s note:* This article is not a statement of fact about Gartner as a whole, but rather an individual perspective based on publicly available information and my own professional experience. It is not affiliated with or endorsed by any vendor or analyst firm mentioned or implied. The views in this article are my own, shaped by years of hands-on Martech work across regions and verticals. I was prompted to explore this topic by recurring themes in community forums and practitioner groups, as well as my direct experience helping clients in Europe migrate away from companies labeled as 'Leaders' in the analyst charts to tools that solved their specific problems. That said, I’ve also worked closely with C-level decision-makers, particularly in the Middle East, who rely heavily on analyst validation for strategic procurement.*
***I understand and acknowledge why Gartner’s Magic Quadrant carries weight.***
*My goal here isn’t to dismiss it outright, but to *open a more grounded discussion* about how it’s used, where it helps, and where it doesn’t.*
---
### How the Quadrant gets made (and who gets left out)
Let’s start with how a vendor gets placed on the Magic Quadrant in the first place. The evaluation process isn’t as neutral as it looks. Inclusion requires hitting revenue thresholds, participating in months-long briefings, submitting detailed documentation and recorded videos, and lining up customer feedback. In theory, this ensures quality. In practice, it filters for size, polish, and the ability to play the game.
As [Brightwork Research notes](https://www.brightworkresearch.com/how-to-view-gartners-financial-bias-in-favor-of-large-vendors?ref=martechtherapy.com) in a 2019 article:
> "Gartner’s content clearly shows a significant vendor bias... **small innovative guys are running uphill against the Gartner wind**."
That uphill climb often begins before the product is ever evaluated at the threshold of who even gets a seat at the table.
Prominent vendors have entire teams dedicated to analyst relations. They know how to speak the language of "completeness of vision". They prepare meticulously for every briefing, craft layered narratives around long-term strategy, and come equipped with roadmap slides that stretch five years into the future. Whether those promises are deployable or will be “GA” (generally available) within six months is a different question.
And then there’s the “execution” axis. Contrary to the name, it isn’t just about feature delivery or user success. Execution includes market presence, sales reach, brand power, and, yes, marketing muscle. It’s entirely possible to land in the Leader quadrant while your product is still in flux, as long as the story is compelling enough and your customer logos are prominent. This is how we end up with tools that win analyst accolades but confuse actual users or worse, stall projects before value is delivered.
Some vendors even optimize their product development roadmaps around what will impress analysts, not end users. A few visible AI features, bundled integrations, or cloud-native claims can sometimes sway more influence than six months of genuine usability work.
### Why vision wins over usability (and what that costs us)
Gartner isn’t alone in this. Most analyst frameworks reward the same behaviors, including maturity, revenue, enterprise focus, and cross-sell potential. But that means the most hyped products are often those that already dominate the enterprise landscape. Innovation, modularity, usability- these matter less than platform sprawl and strategic vision.
Let’s not pretend it’s just about features, or even to be named a Leader in an analyst report. Gartner’s CDP Magic Quadrant, for instance, repeatedly elevates vendors that check the right boxes on breadth, not depth. This has led to some absurd outcomes, including tools with patchy real-time orchestration, confusing identity resolution, or high setup friction, still show up as Leaders, while composable, high-performing alternatives (even some CEPs/MAPs with similar features) are left out entirely for not hitting minimum revenue thresholds.
Source: [Martech Map](https://martechmap.com/?ref=martechtherapy.com)
It’s not always malicious, and I want to make that very clear. It is not easy to build insights like this for an industry that never rests. In Gartner’s defense, placing 100+ vendors on the quadrant would only increase the confusion. It’s just baked into an existing scoring system, which I feel cannot keep pace with the changes in the market. *A new form of Martech’s law, but for analyst firms, perhaps?* The Gartner Magic Quadrant gives weight to criteria that vendors with large sales teams, acquisition capital, and decades of category presence more easily fulfil. That shapes the playing field long before the buyer sees the grid.
One practitioner put it this way on a [Reddit thread discussing CDP selection](https://www.reddit.com/r/marketingtechnology?ref=martechtherapy.com):
> "If you can afford to dance the analyst dance, you’re already two quadrants ahead."
That’s pattern recognition if I ever saw it, voiced by someone who’s seen how procurement really works in enterprise Martech, maybe just as you have.
### Why other CDP feature-filled tools rarely make the grid
Rarely, if ever. Composable vendors and Marketing Automation Platforms (MAPs) \*\* have seen significant market traction, particularly with mid-market and modern data teams. But because they don’t package themselves as suite platforms or because they’re intentionally lean, modular, and in the case of composable CDPs, warehouse-native, they often miss the Magic Quadrant cutoff.
\*\* Tools like Braze seem to be categorized under **Multi Channel Marketing Hubs**, while Bloomreach is seen as **Customer Engagement Platform**. Categories get confusing and are often not related to features built-in to the various solutions.
And if they’re not on the quadrant, they’re not even considered in RFPs where Magic Quadrant inclusion is a requirement (*I will touch more on that in part 2*). It’s a self-fulfilling loop that keeps newer entrants out and entrenched incumbents looking shiny. This is particularly frustrating for buyers who are actually trying to move away from monolithic systems.
The irony? These composable tools and CEPs/MAPs with CDP features built-in are often the ones fixing the problems that initially led to the suites, like rigid workflows, black-box identity graphs, overpriced licensing, and year-long implementations. As one vendor engineer noted on a LinkedIn thread, "we’re often brought in after a monolithic CDP failed to deliver in time for a product launch." They’re solving for transparency, agility, and developer control, but none of that shows up in the chart.
Composable vendors also challenge the very idea of a suite-based CDP. Many buyers now prefer using their own data warehouse with flexible activation tools. But because that model doesn’t fit cleanly into the traditional CDP narrative, it is often overlooked by legacy frameworks. In a way, **the quadrant doesn’t just exclude new tools… it excludes new thinking**. And it is how this propagates to boardrooms that worries me.
### Why this pattern repeats across Martech
If it were just about CDPs, we could write this off as a niche Martech frustration. But the same structural issue shows up in every analyst-led category: MAPs, DAMs, CRMs, CMS platforms. The bigger the vendor, the more points they can rack up for strategy. Meanwhile, **buyers assume that ‘Leader’ = best product, best results**.
That assumption, unquestioned in too many executive meetings, is costing teams time, energy, and ultimately, effectiveness. Tools get chosen because they look good in a boardroom, not because they solve problems quickly or scale with evolving needs.
It also reinforces a dangerous procurement shortcut → if it’s in the upper right quadrant, buy it. That’s a simple abdication and a risky reliance on external insights. And it creates a false sense of consensus around tools that many practitioners quietly struggle to use. Behind closed doors, even on platforms like LinkedIn, you’ll hear stories of CDPs that took 12 months to deploy and still can’t build a basic customer journey. But those stories rarely make it into analyst briefings.
Even [Gartner’s own Peer Insights platform](https://www.gartner.com/reviews/market/customer-data-platforms?ref=martechtherapy.com) hints at this disconnect. Several top-ranked Magic Quadrant vendors receive mixed or lukewarm reviews from real users, flagging complexity, setup delays, or mismatched expectations. But since Peer Insights plays no direct role in quadrant placement, these voices rarely shift perception at the board level.
A rendered image simulating the overlaying of the existing Magic Quadrant for CDPs (02/2025) with aggregated scraped data from Gartner Peer Insights review data. Not all vendors from the Peer Insights reviews are listed. The data has not been independently verified and is **used for illustrative purposes only**.
But before you go cheering the Peer Insights initiative, it seems better than nothing… true, but note that Gartner gives money incentives to elicit reviews from end users, and vendor influence of the same is a black hole all of itself. I have worked with qualitative data solutions in the past, and incentives are rarely unavoidable and come with a plethora of problems.
The Peer Insights, to a large extent, seem to be genuine, but some do make you think. As one commenter on [last week’s LinkedIn post announcing the series](https://www.linkedin.com/posts/matthewniederberger%5Fi-am-working-on-a-new-series-for-my-substack-activity-7356978938914455555-VUi8?utm%5Fsource=share&utm%5Fmedium=member%5Fdesktop&rcm=ACoAAACEYHcBK5DlgsJ%5FgicIWSce8EBSwO4medQ) noted:
> “*Also, if you look at some of the peer reviews, you will see that there are other issues with the way they are rated. For example, if a vendor has 50 perfect reviews with 100% willingness to recommend.*“
Below are some examples of Peer Insights likes and dislikes for three vendors:
Salesforce Data Cloud
Treasure Data
Twilio Segment
Hightouch
Right off the mark, and as stated earlier, these reviews feel relatable, human, and are filled to the brim with feedback that helps individuals working with the solutions.
Additionally, and I consider this to be a little tongue-in-cheek irony, I observed how Gartner distances itself from the weight many executives place on its charts. The fine print reads:
> *“Gartner disclaims all warranties, expressed or implied, including any warranties of merchantability or *fitness for a particular purpose*.”*
In other words, they’re not saying these tools will actually work for you. They’re saying these are the vendors who play the analyst game best. The fact that this disclaimer often goes unnoticed only deepens the problem: the quadrant presents a veneer of certainty where none exists.
So, what are we really measuring when we reward platform breadth over operational fit? What does it say about our industry that execution is conflated with expansion, and vision is judged by slide decks more than live deployments? As Tony Byrne of [Real Story Group](https://www.realstorygroup.com/?ref=martechtherapy.com) put it,
> "*none of these \[suite vendors\] have ever won out when empirically tested by a serious enterprise buyer*"
A pointed reminder that what looks good on a quadrant may not hold up under scrutiny.
In part 2, we’ll look at how this dynamic plays out differently depending on where you are and who you are. Because the Magic Quadrant doesn’t mean the same thing in the C-suite as it does to someone trying to build a working segment in less than 10 clicks.
---
**Read the other parts in this Rethinking the Quadrant series**
- [Part 2: When definitions stop matching reality](https://www.martechtherapy.com/the-real-battle-for-cdp-relevance/)
- [Part 3: What buyers really trust now](https://www.martechtherapy.com/beyond-the-gartner-magic-quadrant/)
---
Want to share your own experience of being led or misled by the quadrant? I’m gathering stories from the field. [Reach out via LinkedIn](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com) or reply on Substack.
Want to receive part 2 in your inbox next week? Make sure to subscribe for free 👇🏻
### What are we even buying?
URL: https://www.martechtherapy.com/what-are-we-even-buying/
Last updated: 2025-10-09T19:47:14.000Z
Let’s be honest with ourselves, this was never just about software.
If you’ve made it through parts [1](https://open.substack.com/pub/martechtherapy/p/is-the-cdp-binary-broken?r=3i8xzy&utm%5Fcampaign=post&utm%5Fmedium=web&showWelcomeOnShare=false), [2](https://open.substack.com/pub/martechtherapy/p/same-stack-different-worlds?r=3i8xzy&utm%5Fcampaign=post&utm%5Fmedium=web&showWelcomeOnShare=false), and [3](https://open.substack.com/pub/martechtherapy/p/whos-actually-in-charge?r=3i8xzy&utm%5Fcampaign=post&utm%5Fmedium=web&showWelcomeOnShare=false) of this series, you’ve seen how most organizations don’t run on a single CDP, but on a patchwork of tools that reflect team priorities, governance gaps, and the relentless pressure to just keep moving.
The industry has started catching on. In the July 2025 [*CDP Institute Industry Update*](https://www.cdpinstitute.org/resources/industry-update-july-2025/?ref=martechtherapy.com), David Raab offered a sharp summary of where we’ve landed:
> “The term CDP has become a catch-all that includes everything from CRM-lite orchestration tools to complex, privacy-centric identity engines.”
Or as [Kristina Kalpokaite recently wrote it in her article on MarTech.org “Nobody knows what a CDP is anymore — and that’s the problem”.](https://martech.org/nobody-knows-what-a-cdp-is-anymore-and-thats-the-problem/?ref=martechtherapy.com) In her article, she correctly describes how CDPs lost touch with what companies need and can deal with:
> “One new invention triggered a new requirement, which triggered another invention. A cycle of constant addition, chasing competitive parity, not actual utility.”
It’s not that the tools don’t work; they obviously do when you look at investment projections. It’s that the term **CDP** now stretches so far it can describe:
- A batch modeler syncing audiences to ad platforms
- A warehouse-native connector layer
- A full-blown real-time decisioning system
- A regional campaign tool with basic profiles
And yes, sometimes all of those exist in the same company, but do they need all the features? Or as Kristina would most likely put it, “*do they know what it even does?*”.
### The false promise of consolidation
From the beginning, CDPs were sold as the antidote to Martech sprawl. A central source of truth. One platform to rule them all.
But it was always more of a hope than a plan. Governance isn't something you can buy. And coordination doesn't automatically emerge just because you routed events to the same endpoint.
In reality, most CDPs were adopted **adjacent to** other systems, not instead of them. CRM, ESP, data warehouse, digital analytics, tagging systems... the CDP sat alongside them, trying to harmonize what was already too fractured.
So when we see companies using 2.1 CDPs on average, it doesn’t necessarily mean consolidation has failed. It often reveals what actually happens when you try to serve multiple teams with one platform… and fall short.
### Not one thing, but many
What we’re seeing now isn’t really a directional change. It’s a realization, an awakening that **CDPs are not a product category**, they’re a set of overlapping capabilities that have been marketed as such. And that companies assemble those capabilities based on:
- Their organizational model
- Their technical maturity
- Their channel mix
- Their leadership’s appetite for control vs. flexibility
- Their budget
The tools haven’t changed as much as the expectations around them. And when real-time engagement became the new default, even composable vendors like *Hightouch* and *Snowplow* began expanding into more activation-friendly territory. It’s more than a product roadmap tweak. They simply acknowledge the demands and dynamics of the Engagement Zone.
So if CDPs were born in the Data Zone and later pulled toward Engagement, what we’re really witnessing has less to do with deliberate expansion and more to do with how teams and needs have gradually pulled CDPs into new territory.
Kristina put it succinctly: “*The category’s splintering, the label is losing meaning and vendors are scrambling for new names.*”
As David Chan’s Dual Zone framing reminds us, the internal tensions we’re seeing aren’t new. They’re just more visible now and are making us think twice about our next step, maybe even adjusting our expectations of what CDPs can deliver in a positive way. And stop wondering what category label even means at this point?
### Where this leaves us
If you’re working in Martech in 2025, remember, you don’t need another category definition. Frans Riemersma and Scott Brinker are busy enough with the 15.000+ solutions in the market as of this year. What you need is a way to understand what your stack actually does and what it doesn't. And that starts by asking:
- What job does each CDP (or CDP-like tool) actually do?
- Who relies on it, and for what outcomes?
- What happens when it fails?
- And is there a better way to draw the zones on paper, not in theory?
I won’t pretend there's a clean solution because every company is unique. But I’ve seen better questions bring better decisions. And in most organizations, that’s more useful than one more CDP replacement project.
Thanks for sticking with me through this four-part series. If any of it hits a nerve or sounds like what’s happening in your world, drop me a line. I work with organizations across verticals and geographies, helping make sense of CDPs and the tangled architectures around them. Whether you’re in B2C, B2B, or something in between, there’s usually a path forward once the real questions surface. Always happy to compare notes.
[Connect with me on LinkedIn](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
Or follow me here on Substack for more therapeutic insights on Martech 👇🏻
### Your CDP is more than just a platform
URL: https://www.martechtherapy.com/your-cdp-is-more-than-just-a-platform/
Last updated: 2026-08-31T13:10:12.000Z
I just got back from a family trip to Paris, which was mostly great except for the hour I spent in a queue under the Eiffel Tower with my daughter constantly requesting more screentime on her phone, my wife and son (afraid of heights… like me) trying to find shade at a local cafe, and my brain, entirely on its own, thinking about CDPs and digital transformation. Because of course it did.
That moment, standing between chaos and culture, reminded me that CDP implementations are like tiny, well-lit previews of the digital transformation mess most companies are too scared to look at directly. If your CDP rollout is going sideways, chances are your transformation dreams are headed the same way, just more expensively and agonizingly slowly 🐌
### The false promise of platform fixes
We’ve all seen the cycle: [new platform, big promises, a few hopeful decks](https://www.martechtherapy.com/the-cdp-reboot-the-promise/), and then six months later… [disillusionment](https://www.martechtherapy.com/the-cdp-reboot-the-disillusionment/). CDPs have followed that pattern too often. Despite their strategic potential, most don’t deliver because the organization around them can’t.
Source: [LXA’s 2025 State of Martech & Marketing Operations survey](https://www.lxahub.com/state-of-martech-marketing-technology?ref=martechtherapy.com)
[LXA’s 2025 State of Martech & Marketing Operations survey](https://www.lxahub.com/state-of-martech-marketing-technology?ref=martechtherapy.com) found that 61% of organizations still struggle to effectively activate their data, despite widespread CDP adoption and the emergence of composable stacks. That gap isn’t about software. It’s about structure, ownership, and follow-through… things under human control. The CDP makes those dynamics visible, and the stacks continue to grow.
### CDPs surface the truth faster
Digital transformation is broad and slow-moving. CDPs are compact and immediate. They force decisions quickly such as:
- Who owns identity?
- What’s the definition of consent?
- Which data is reliable?
- How do we activate use cases across silos?
…and more
If you’ve tried to implement a CDP and discovered internal blockers, misaligned teams, unclear KPIs, or suddenly everyone pointing fingers at data quality, I want you to know that, first and foremost, that’s not a failure. That’s honest feedback. That’s your organization showing you, very efficiently, what will also derail your next big transformation initiative.
David Chan captured this perfectly in 2024 when he wrote in [his “](https://medium.com/%40iamdavidchan/why-do-most-cdp-projects-fail-bdbd6ecb974c?ref=martechtherapy.com)[*Why do most CDP projects fail?*](https://medium.com/%40iamdavidchan/why-do-most-cdp-projects-fail-bdbd6ecb974c?ref=martechtherapy.com)[” post on Medium](https://medium.com/%40iamdavidchan/why-do-most-cdp-projects-fail-bdbd6ecb974c?ref=martechtherapy.com):
> "Most CDP projects fail because companies skip the hard parts: designing the operating model, managing expectations, and investing in internal readiness."
LXA’s report backs that up. It describes CDPs as reflections of the broader martech stack. If the CDP doesn’t work, the rest likely won’t either. It’s a mirror, not a mistake.
### Failure patterns match almost perfectly
Let’s compare CDPs and full-scale digital transformation efforts. Both promise a lot. Both tend to underdeliver. And both fail for almost identical reasons:
The only real difference? CDPs surface these problems in months. Transformation projects take years, and millions, before anyone admits they’re broken.
### The stress test metaphor
So what if we stopped treating CDPs as magic data platforms and started seeing them as stress tests for organizational readiness?
They’re just big enough to touch everything that matters, data, identity, privacy, content, orchestration, but small enough to implement in a reasonable timeframe and require a considerable investment. If your organization can’t align across teams to activate even two CDP use cases, why would a full-blown digital transformation work any better?
LXA hits this point hard:
> *“Operational maturity in martech increasingly depends on how well organisations can align teams, data, and goals, not just how many tools they have.”*
It’s about the “connective tissue” between strategy, execution, governance, and capability. A CDP implementation stretches that tissue just enough to see where it tears.
That’s useful.
And if you're seeing signs such as fractures in ownership, stalled activation, questionable data, or no time for governance, those are transformation warnings. And the good news? It’s not too late to do something about it.
As James Robert Lay, author of Banking on Change, puts it, education is what enables human transformation, in and of itself (and in my personal opinion) a prerequisite for digital transformation.
### A quick note, in case this feels familiar
If you’re stuck in the CDP fog, wondering if it’s the platform, your team, or your roadmap, [I help companies work through exactly this](https://www.martechtherapy.com/what-i-do/). Sometimes that means diagnosing the organizational tensions. Sometimes it’s getting use cases moving again. Occasionally, it’s helping teams admit they skipped a few steps.
No drama. Just help.
And now, if you’ll excuse me, I have a stack of Eiffel Tower souvenir photos to delete.
[Connect with me on LinkedIn](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
Or subscribe for free to follow my thoughts and opinions on Martech 👇🏻
### Who’s actually in charge?
URL: https://www.martechtherapy.com/whos-actually-in-charge/
Last updated: 2025-10-09T19:47:16.000Z
You can tell a lot about a company by how it answers one deceptively simple question: **Who owns the CDP?**
Not the license. Not the roadmap. The actual thing. The model that sits between what marketing wants and what the data team tolerates. The implementation that touches consent flags, event structures, identity graphs, and half a dozen teams trying to ship something yesterday. The reality is that ownership, when it exists, is rarely stable. It shifts and changes shape over time as initiatives develop, teams restructure, or priorities float between the many others on people’s lists.
Across the last few years, I’ve seen it play out the same way more than once. A client asks me to “fix” the CDP. Or to assess whether it’s working. But under the surface, the request is always about ownership. Not just who owns the tool, but who owns the decisions, the blind spots, the mounting workarounds. The whole kit and caboodle.
Because the CDP isn’t broken. The contracts between teams are.
[LXA’s ](https://www.lxahub.com/state-of-martech-marketing-technology?ref=martechtherapy.com)[*State of Martech & Marketing Operations*](https://www.lxahub.com/state-of-martech-marketing-technology?ref=martechtherapy.com) *(free and worth a read)* report backs this up:
> only **22%** of respondents say Martech is owned by a single team
The rest? Shared, fractured, or unclear. And where ownership is unclear, so is direction.
So we get two tools solving the same problem in parallel. Campaign teams add an activation layer because the official CDP can’t move fast enough. Data teams throttle usage to protect quality. Product might even be building their own event system on the side. And someone eventually builds a spreadsheet to stitch it all back together.
I am afraid to say it, but this is more often than not the default.
### The Mirror in the middle
[David Chan’s Dual Zone](https://medium.com/@iamdavidchan/the-dual-zone-manifesto-an-approach-to-cdp-that-goes-beyond-hybrid-2f4484c4f1e8?ref=martechtherapy.com) model helps here. Not because it’s a new concept, but because it gives teams language for something they already feel. Zone One (Data) wants durable models. Zone Two (Engagement) wants flexible execution. The CDP, as a corporate-wide concept, sits between them, and without a clear contract, it gets pulled in both directions.
What gets lost is the connective layer, the orchestration membrane, a shared agreement, if you will. And most companies don’t have one.
In those gaps, things fall apart slowly:
- Segment definitions diverge
- Identity mappings don’t sync
- A/B tests break across tools
- Teams route around each other
- Reporting loses trust because definitions don't match
- Velocity drops as handoffs require escalation or patchwork fixes
Everyone’s just trying to hit their numbers. But no one’s responsible for the handoffs. And over time, those handoffs become bottlenecks.
This is what I’ve started calling **ownership dispersal**, when no single team owns the middle, and so everyone builds their own logic around it. Like a slow-moving fork in the repo, everyone’s copy starts to look a little different.
And like [David Raab recently pointed out to me on LinkedIn](https://www.linkedin.com/feed/update/urn:li:activity:7354439334151790592?commentUrn=urn%3Ali%3Acomment%3A%28activity%3A7354439334151790592%2C7354479594290176003%29&dashCommentUrn=urn%3Ali%3Afsd%5Fcomment%3A%287354479594290176003%2Curn%3Ali%3Aactivity%3A7354439334151790592%29&ref=martechtherapy.com), the market now expects activation to be bundled in. Even though the [CDP Institute](https://www.cdpinstitute.org/?ref=martechtherapy.com) defines the category strictly around profile building, **75% of vendors** now include activation capabilities too.
That means companies don’t just *accidentally* end up with multiple CDPs. They’re sold them that way. Each department buys **the piece that works for them**. Each ends up with a tool that fits their rhythm, their reporting, and their definition of done.
You don’t unwind that with a migration deck.
"Even if there were no organizational/political issues, the money saved by consolidation is usually less than the added labor cost and lost revenue from using a sub-optimal system." \~ David Raab
In other words: the mess makes sense. Especially in large or federated organizations where tooling maps to budget lines and headcount, not just capability need.
### What can actually help?
This isn’t a call for another committee. It’s a nudge to make the handoffs visible. Here’s how I usually help teams surface the real contracts under the stack:
- **Draw your zones.** Literally, whiteboard what sits in the Data Zone vs. the Engagement Zone. Which tools? Which teams? What flows between them?
- **Mark your fragilities.** Where are things brittle? Where’s orchestration “someone’s job” but not in their title?
- **Find the drift.** Which tools overlap? Where do teams disagree on source of truth? Which use cases fall through the cracks?
- **Check for duplicate ambition.** Do two tools try to segment? Trigger? Model?
It’s not governance theater and this has nothing to do with perceived ranks or seniority internally. It’s a way to name where CDP ownership is fuzzy so the team, the people involved within a company, can choose: do we define this together, or live with it as-is?
When done well, these conversations don’t just improve stack architecture and understanding, they significantly improve team trust. People stop fighting the tool and start seeing the tool as a mirror of how they collaborate.
### Where we’re headed
In Part 4, we’ll change it up a little and move from describing the mess to asking what it means. Because CDPs, as we are all aware by now, were supposed to consolidate, simplify, centralize. But that promise never fit the politics, incentives, and working rhythms of most companies.
Maybe it’s time to stop measuring CDPs against ideals they were never designed to reach and instead measure them against the actual cross-team orchestration they enable (or don’t).
More on that soon.
If any of this sounds a little too familiar and you're wondering where to even start, I'm always up for a conversation. Sometimes it just takes an outside view to spot where the real friction is hiding.
[Connect with me on LinkedIn](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
## **Read the previous parts**
1. [Is the CDP binary broken?](https://www.martechtherapy.com/is-the-cdp-binary-broken/)
2. [Same stack, different worlds.](https://www.martechtherapy.com/same-stack-different-worlds/)
---
## **Connect with me on LinkedIn:**
- Matthew: [https://www.linkedin.com/in/matthewniederberger/](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
## **Follow Martech Therapy on:**
- Instagram: [https://www.instagram.com/martechtherapy/](https://www.instagram.com/martechtherapy/?ref=martechtherapy.com)
- Youtube: [https://www.youtube.com/@martechtherapy](https://www.youtube.com/@martechtherapy?ref=martechtherapy.com)
- Bluesky: [https://bsky.app/profile/martechtherapy.bsky.social](https://bsky.app/profile/martechtherapy.bsky.social?ref=martechtherapy.com)
### Same stack, different worlds
URL: https://www.martechtherapy.com/same-stack-different-worlds/
Last updated: 2025-10-09T19:47:17.000Z
If you’ve ever heard someone say, “*We already have a CDP*,” it’s worth asking two questions:
1. What exactly do you mean by *CDP*?
2. And who is “we” in this scenario?
Because most of the time, what one team considers *the* CDP is just a feature to another. And what’s sold as a single platform rarely acts like one across an entire company.
This is where [David Chan’s Dual Zone model](https://medium.com/@iamdavidchan/the-dual-zone-manifesto-an-approach-to-cdp-that-goes-beyond-hybrid-2f4484c4f1e8?ref=martechtherapy.com) starts to feel less like a theory and more like an MRI. The Data Zone and the Engagement Zone reflect how stacks are split in real life. How org charts shape data pipelines. And how different teams define success.
Marketing wants action. The ability to launch campaigns, test messages, and personalize quickly. The Data Zone wants precision with clean joins, durable identity, and compliance.
And so we get two CDPs. Sometimes more.
Not always by design, but rarely by accident.
[As I mentioned in Part 1](https://www.martechtherapy.com/is-the-cdp-binary-broken/), what might look like redundancy is often just role-based architecture. Most stacks aren’t built to be clean. They’re built to survive the way teams actually work.
## **Four patterns I keep seeing**
You don’t need to squint to spot these. They show up again and again in different forms. See if one hits close to home:
- **Primary + Backup**: The official CDP handles governance. Meanwhile, marketing uses another tool, quietly or officially, for campaign targeting and personalization.
- **Split-Zones**: One CDP handles tagging, identity, and event ingestion. Another handles journeys and segmentation. Both get called “the CDP” in different meetings.
- **Regionality**: Each region, market, or brand picks its own stack. The global team tries to enforce standards from afar, with mixed results.
- **Composable**: A set of warehouse-native tools (like reverse ETL, identity resolution, and activation UIs) stitched together. It works. But only because someone’s connecting them behind the scenes.
Personally, regionality is the most common one I see, especially among enterprises. But don’t get me wrong, these patterns merely reflect how tools are bought and deployed. As noted in [LXA’s State of Martech and Marketing Operations 2025](https://www.lxahub.com/state-of-martech-marketing-technology?ref=martechtherapy.com) study, “Vendors are building tools to solve very different problems for different buyers. The expectation that these will somehow function as a coherent stack is… optimistic.”
I made a similar point in the [*CDP Reboot*](https://www.martechtherapy.com/the-cdp-reboot-the-promise/)[ series](https://www.martechtherapy.com/the-cdp-reboot-the-promise/), what’s sold as a platform often ends up functioning more like a collection of buyer-aligned feature sets. This is what happens when purchasing reflects organizational complexity.
[The CDP Reboot: The PromiseThis is Part 1 of my four-part #CDPReboot series, where I take a critical look at the evolution, saturation, and potential rebirth of the Customer Data Platform (CDP) category.Martech TherapyMatthew Niederberger](https://www.martechtherapy.com/the-cdp-reboot-the-promise/)
As Alexander Dean from Snowplow recently put in a comment on LinkedIn:
> “If you have one ‘CDP’ doing digital user personalization, and another ‘CDP’ doing customer master data management, do you really have 2 x CDPs?”
Fair question. But maybe a better one is:
> If the setup works, do we care what we call it?
## **What this means for vendors and everyone else**
Composable stacks were supposed to simplify things. Plug into the warehouse, sync your segments, let every team work off the same clean base. But that’s not how things tend to play out.
Real teams don’t wait for elegance. They push for what works. And vendors have noticed.
Hightouch added [same-session personalization](https://hightouch.com/blog/same-session-personalization?ref=martechtherapy.com). [Snowplow launched Signals](https://snowplow.io/signals?ref=martechtherapy.com) for real-time enrichment. These are responses to the tension between data governance and delivery speed, and last but definitely not least… customer demand, and budget.
Composability doesn’t need to be torn down in these scenarios, but without coordination, it often ends up shifting the mess sideways, down unintended paths. It assumes shared governance. It assumes operating models are already in sync.
Usually, they’re not.
So if you’re evaluating or trying to wrap your head around a CDP stack, a few useful questions you should ask yourself are:
- Which zone is this tool meant to serve?
- Who owns it day-to-day?
- What’s the handoff to the other side look like?
You might not get clean answers. There are too many influencing factors, but conversations will grow, and seeds will be planted.
## **Where we go next**
Patterns like these help us see *how* stacks form. But they don’t tell us *who’s responsible* when things diverge. And when no one owns the flow across tools, timing, and teams, it shows, and you end up reading blogs like this.
That’s where we’re headed in Part 3.
## Read the previous parts
1. [Is the CDP binary broken?](https://www.martechtherapy.com/is-the-cdp-binary-broken/)
---
## Connect with me on LinkedIn:
- Matthew: [https://www.linkedin.com/in/matthewniederberger/](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
## Follow Martech Therapy on:
- Instagram: [https://www.instagram.com/martechtherapy/](https://www.instagram.com/martechtherapy/?ref=martechtherapy.com)
- Youtube: [https://www.youtube.com/@martechtherapy](https://www.youtube.com/@martechtherapy?ref=martechtherapy.com)
- Bluesky: [https://bsky.app/profile/martechtherapy.bsky.social](https://bsky.app/profile/martechtherapy.bsky.social?ref=martechtherapy.com)
Make sure not to miss the next part on multi-CDP setups. Subscribe for free 👇🏻
### What do PUBG Mobile and Martech consulting have in common?
URL: https://www.martechtherapy.com/what-do-pubg-mobile-and-martech-consulting/
Last updated: 2025-10-09T19:47:17.000Z
I’m a gamer. I love playing games to unwind. Some cook, some garden. I game. One of the games I started playing with my son several years ago was PUBG Mobile. Together, we would drop into maps and get busy looting and dominating.
I’ve played thousands of matches, and Erangel is my go-to map when I want to level up or test my skills. The game rewards strategic thinking, precise timing, and, above all, effective team coordination.
Was I any good? Well, when I find time to play these days, I can reach the higher tiers with relative ease. I usually stop when I reach the Ace Dominator level. When I do, I notice a few things start working differently.
What's remarkable at this level is that you can drop into a squad of three total strangers, often from different countries, and without a single word exchanged, you’ll still play like a team. No language, no introductions, no instructions. And yet, there's a shared sense of what needs to be done. One flanks, one covers, one scopes the high ground, and another watches the zone. It’s not perfect, but it's efficient, and it's effective.
This unspoken collaboration is especially interesting when you consider how chaotic lower levels can be. New players often play for themselves, wander off alone, or hoard loot. However, at higher tiers, there’s an implicit agreement → *loot is shared so the entire team can gear up evenly*. A better-equipped team survives longer. You don't hoard scopes or hog medkits, you pass them around. **The collective strength of the squad matters more than individual advantage**.
There’s something beautifully selfless about that, and it reminds me a lot of high-level Martech consulting I have seen and participated in.
When you’re dropped into a company as a seasoned consultant, what I’d call Ace Dominator level, you often don’t get a pre-game briefing. You’re landing cold, and the zone’s already shrinking. But the instincts kick in. You scan the field, understand the objective without needing to be told, and start acting in ways that improve the team’s position. The aim isn’t mere survival. It’s a coordinated push toward victory.
Experienced consultants don’t wait to be handed a plan. They construct one from the fragmented signals in front of them. Roles emerge through action rather than assignment. Weak spots in coverage are addressed before they turn into problems. Movement happens with intention, not hesitation. And crucially, you know when to stay quiet and when to make the call.
This is what I call the **Experienced Player Effect**. It goes far beyond skill.
An experienced player brings a few things to the playing field:
- **P**ositioning: they know where to place themselves to be useful fast, whether in the war room or in the weeds.
- **U**nspoken awareness: they read the room and the context without waiting for explicit direction.
- **B**alance: they prioritize the team's performance over personal wins, ensuring everyone is equipped and aligned.
- **G**rit: they stay calm under pressure, keep moving forward when things go sideways, and never lose sight of the objective.
In PUBG, this is the teammate who rotates early, drops a medpack for the player he just revived, and picks the right fights. **In Martech, it's the consultant who keeps things moving, avoids ego traps, and gets the whole squad through the storm.**
More subtly, they model what "good" looks like. The way they share information, make trade-offs, and anticipate failure modes sets a tone for others. Others begin to mirror it. It doesn’t need to be explained. It just becomes part of the match, a team ethos.
Still, PUBG isn’t a solo shooter. And Martech isn’t either.
Even when I’m playing well in Erangel, I can’t carry a squad of three who refuse to move, hide in buildings, or keep running into open fields. **Success in both worlds demands a willingness to play the game right**. The best consultants I know thrive in cross-functional teams, not because they dominate the conversation, but because they elevate it.
**Hiring an experienced consultant isn’t about plugging in a hero.** We’re still human, trust me. It only works if the rest of the team is ready to adapt. That means being open to learning by doing, willing to shift roles when the terrain changes, and hungry to improve their own situational awareness. The best teams are fluid. And that fluidity is something that both experienced consultants require and foster.
If you're building a Martech team, especially under pressure to deliver, you have a choice. You either train everyone on the fly and hope for the best, or **bring in someone who has already survived 100 endgames. An experienced consultant won’t just help you win the current round. They’ll raise the game of your entire squad.**
And when the final circle closes in, that might be the difference between heading back to the lobby or sharing that Chicken Dinner, evenly looted and hard-earned.
Want to play a game of PUBG Mobile with me, or need an experienced consultant to help gain control of your business battleground? **Subscribe for free** 👇🏻
### Is the CDP binary broken?
URL: https://www.martechtherapy.com/is-the-cdp-binary-broken/
Last updated: 2025-10-09T19:47:18.000Z
There was a time, brief and overly PowerPointed, when the Customer Data Platform (CDP) was sold as the answer to everything: clean data, unified profiles, cross-channel orchestration, even internal peace treaties between marketing and IT.
One platform. One profile. One truth.
And then reality showed up.
Not with a bang, but with two CDPs.
The [CDP Institute’s 2024 Member Survey reports an average of ](https://www.cdpinstitute.org/resources/cdp-institute-2024-member-survey-building-on-success/?ref=martechtherapy.com)[**2.1 CDPs per company**](https://www.cdpinstitute.org/resources/cdp-institute-2024-member-survey-building-on-success/?ref=martechtherapy.com)**,** and [Simon Data observes a drop from ](https://www.simondata.com/blog-posts/cdp-graveyard-martechs-solution-lost-touch-purpose?ref=martechtherapy.com)[**2.9 to 2.1**](https://www.simondata.com/blog-posts/cdp-graveyard-martechs-solution-lost-touch-purpose?ref=martechtherapy.com) based on that data. That might look like consolidation (down from 2.9 the year before), but it isn’t necessarily simplification. Teams weren’t aiming for complexity to begin with. They were responding to gaps in their requirements, and with time equaling money, they often grabbed whatever they could to get the job done.
One CDP lacked the flexibility they needed, and layering in a second (or a third) became the workaround that stuck. So teams are keeping the ones that serve their needs, and ditching the rest.
Stack drift doesn’t happen in a vacuum. It’s the natural result of teams pulling in different directions, each adopting tools that reflect their own priorities and ways of working. And that split maps almost perfectly to what David Chan has laid out in the [**Dual Zone model**](https://medium.com/@iamdavidchan/the-dual-zone-manifesto-an-approach-to-cdp-that-goes-beyond-hybrid-2f4484c4f1e8?ref=martechtherapy.com): a **Data Zone** built for identity, modeling, and governance, and an **Engagement Zone** for personalization, journey logic, and activation.
Source: [Updated 2024: The Dual Zone Manifesto](https://medium.com/@iamdavidchan/updated-2024-the-dual-zone-manifesto-an-approach-to-cdp-that-goes-beyond-hybrid-732cf2436e4f?ref=martechtherapy.com)
These setups aren’t new. They’ve been evolving for years, usually out of necessity and without the owners knowing what to call it. The data team anchors on quality and governance. Marketing wants segmentation and speed. Add a regional or brand-specific stack already in play, and suddenly you’ve got a Multi-CDP organization. Whether you intended to or not.
In one stack, you’ll see a CDP focused on identity resolution. Elsewhere, it might be tagging or orchestration that dominates. Sometimes, it’s just about pushing segments into ad platforms because the other systems move too slowly. Each of these tools was brought in to solve a specific need, whether it was unifying profiles, improving real-time responsiveness, or enabling marketing teams to launch campaigns without waiting for a new data pipeline to be configured.
Derek Slager of Amperity, [during my podcast with him earlier this year](https://www.martechtherapy.com/has-the-cdp-category-failed-amperity/), put it plainly from what he is seeing in the market:
> “You see identity as a technical challenge, but it’s also **a political one**. It defines who gets to act on the data, and when. And if you get that wrong, good luck making anything else work.”
You don’t get fragmentation because someone planned poorly. You get it because the business outpaced the operating model, and the stack tried to catch up.
Additionally, on meeting requirements within companies, Neill Brookman said to me while giving a [demo of MetaRouter](https://www.youtube.com/watch?v=BAtKrABF5hk&ref=martechtherapy.com):
> “I don’t care what the vendor calls it. If I need real-time data for personalization and that’s not in my CDP, I’m going to go around it. That’s how **‘shadow CDPs’** are born.”
### What this series will explore
*The Multi-CDP Reality* picks up where [*CDP Reboot*](https://www.martechtherapy.com/the-cdp-reboot-the-promise/) and [*Contextual CDPs*](https://www.martechtherapy.com/understanding-mcps-a-cdp-insiders/) left off. This series takes a closer look at what’s really been built in practice and how organizations ended up with the stacks they now rely on.
We’ll explore how CDP setups tend to reflect the zones they serve, some optimized for data, others for delivery. We’ll dig into how composable stacks often drift into multi-CDP territory. We’ll spend time on the friction that emerges when ownership isn’t clearly defined, especially across marketing and data teams. And we’ll look at what vendors like Hightouch and Snowplow are now quietly admitting by stepping into real-time engagement.
Most of all, we’ll ask a better question, not
> “How many CDPs do you have?”
but
> “What is each one actually doing, and who is it really for?”
That’s where the real story starts. And where this series begins.
## **Read the entire series**
- [Same stack, different worlds](https://www.martechtherapy.com/same-stack-different-worlds/)
---
## **Connect with me on LinkedIn:**
- Matthew: [https://www.linkedin.com/in/matthewniederberger/](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
## **Follow Martech Therapy on:**
- Instagram: [https://www.instagram.com/martechtherapy/](https://www.instagram.com/martechtherapy/?ref=martechtherapy.com)
- Youtube: [https://www.youtube.com/@martechtherapy](https://www.youtube.com/@martechtherapy?ref=martechtherapy.com)
- Bluesky: [https://bsky.app/profile/martechtherapy.bsky.social](https://bsky.app/profile/martechtherapy.bsky.social?ref=martechtherapy.com)
Receive Part 2 for free in your inbox. Subscribe today 👇🏻
### Everyone wants clean data, no one wants to take out the trash
URL: https://www.martechtherapy.com/everyone-wants-clean-data-no-one/
Last updated: 2025-10-09T19:47:19.000Z
There’s a certain absurdity to how we talk about data. We obsess over real-time pipelines, predictive models, AI \*cough\* that promise to know our customers better than we know ourselves… and then completely sidestep the question of who’s actually responsible for the data in the first place.
And this is why [Avo’s latest announcement](https://www.avo.app/blog/introducing-actionable-data-ownership?ref=martechtherapy.com) matters more than it probably should. “**Actionable Data Ownership**” isn’t a sexy product drop, I mean it does contain the letters **‘A’** and **‘I’**, but it’s a blunt instrument aimed at one of the most deeply neglected problems in Martech.
⚠️ This post is in no way sponsored or influenced by Avo. I have been a **HUGE** fan of their product for years and always recommend it where I can.
While most of the industry is playing with yet another set of audience templates or chasing AI-based personalization for audiences they barely understand, Avo is out there doing something radical: **focusing upstream**. First with data quality. Now with data ownership. And not in that vague governance-deck kind of way we have become used to. In a *real*, this-will-make-your-product-managers-sweat kind of way. And I for one, LOVE IT!
## **Whose data is it, anyway?**
Be honest, this isn’t a new question, you have most likely even asked it yourself. People like [Tiankai Feng](https://www.humanizingdatastrategy.com/?ref=martechtherapy.com) have been wrestling with the human side of data strategy for years. In his book, he describes how teams tend to treat data as a communal resource → used by many, **owned by none**. The result? No one feels responsible when things go sideways.
Sound familiar?
It should. Because this is exactly what’s happening inside your average CDP implementation. Or CDI. Or CEP. Heck, even CDWs aren’t immune. (At this point, anything that deals with is guilty until proven otherwise. Data is a people problem.)
## **CDPs aren’t broken, we are**
In my last post, I made the case that [CDPs have become the ](https://www.martechtherapy.com/dont-let-your-cdp-become-the-fall-guy/)[**fall guy**](https://www.martechtherapy.com/dont-let-your-cdp-become-the-fall-guy/)[ of the stack](https://www.martechtherapy.com/dont-let-your-cdp-become-the-fall-guy/). Not because they’re flawed technology, but because we expect them to fix years of neglect... by us. If your source data is a mess, your segment logic is a pile of IF statements glued together, and your consent records live in four different systems, don’t go crying that it is the CDP’s fault.
Blame the vacuum of ownership that let it get that way.
Avo’s move matters because it inserts responsibility exactly where it’s been missing: *at the point where data is created*. They have been fighting for this for years. And if I may be so blunt, I think it’s **an absolute power move**. Instead of making engineers and product teams guess what marketing might need later, Avo connects the dots between what’s tracked and what’s actually used. And now, who owns it.
Ownership isn’t tagging someone in a Slack thread. It’s making sure someone is on the hook when a field is deprecated, a naming convention drifts, or a signup event stops firing on mobile for three weeks. It’s not glamorous, it never will be. But it’s how real systems get better.
## **The battle nobody asked for**
To be clear: this isn’t the fun part of Martech. It’s not where the awards are. So put your fancy shoes back in the closet. One thing it is, it *is* where the pain starts, and where the healing has to begin if we ever want to do anything genuinely useful with customer data.
Avo is doing the hard, tedious, necessary work that the rest of the ecosystem quietly avoids. And they’re not just talking about it in principle. They’re shipping features that push accountability upstream, to the source, before the data enters the glow of a CDP dashboard or an AI orchestration engine.
Honestly, I mean, from the core of my being, I know it’s the kind of product thinking we need more of. The in-your-face, hands-on, slightly annoying (*in a good way*), and unafraid to call BS on how our industry actually operates.
Let me tell you this before I end the post → I’m a little jealous. Maybe it’s the clean Icelandic air. Maybe it’s the skyr. Or maybe you need to live near volcanoes to develop a proper respect for what happens when you ignore small warning signs.
Either way, Avo is building a *responsibility infrastructure*. If you work with CDPs, CDIs, CEPs, or frankly anything with a database and a dream, you should be paying attention.
Watch my previous podcast with [Avo CEO Stefania Olafsdottir](https://www.linkedin.com/in/stefaniabjarneyolafsdottir/?ref=martechtherapy.com) 👇🏻
[How to avoid data chaos, one sunny walk at a timeData chaos doesn’t wait for a boardroom. So we took this Couch Confidentials special episode outside, wandering the streets of Amsterdam with Stefania Olofsdottir during Measurecamp. We talk about the origins of Avo, trusting teams with their own datasets, and how her journey from Iceland to analytics has always centered around making data meaningfulMartech TherapyMatthew Niederberger](https://www.martechtherapy.com/how-to-avoid-data-chaos-one-sunny/)
---
Receive my newsletter in your inbox for free. Subscribe below 👇🏻
### Agentic AI in Martech: The Handoff
URL: https://www.martechtherapy.com/agentic-ai-in-martech-the-handoff/
Last updated: 2025-10-09T19:47:19.000Z
After five posts exploring the theoretical challenges of agentic AI, scale, complexity, conflicts, roles, and trust, I want to end this series with something more practical. If you're convinced that agentic systems represent the future of Martech but aren't sure where to start experimenting, what's the actual first step?
Based on the patterns I've observed and my own experiments, I think the answer lies in designing deliberate handoff protocols. Not grand AI strategies or comprehensive automation plans, but careful experiments in delegation that help you learn how to work with autonomous systems.
## Starting with low-stakes decisions
The teams that seem most successful with agentic AI start with decisions that matter but don't catastrophically damage anything if they go wrong. Email send time optimization is a classic example. If the AI chooses poorly, you might see slightly lower open rates, but you're not going to lose customers or damage your brand.
I've been experimenting with this linear approach in my own work. Instead of jumping straight to complex personalization or customer journey automation, I started with simple delegation boundaries: let the AI optimize the timing of my newsletter sends based on subscriber engagement patterns, but keep human control over content and audience selection.
The results have been mixed, which is exactly what you'd expect. Some weeks the AI picks better send times than I would have chosen. Some weeks it makes choices that seem obviously wrong in hindsight. But the key insight is that I'm learning to distinguish between AI decisions I trust and ones that trigger my skepticism.
## Building confidence through reversibility
One pattern that's worked well is focusing first on highly reversible decisions. If the AI chooses the wrong email send time, I can adjust the timing for next week. If it picks the wrong subject line variant in an A/B test, I can update the approach for the next campaign.
This reversibility creates a safe space for both human and AI learning. The AI gets to experiment with different approaches and learn from the results. I get to observe its decision-making patterns and calibrate my trust accordingly.
Some teams are taking this further by creating explicit "learning periods" where agentic systems are given autonomy to experiment, but with the understanding that humans will review the results and potentially override the AI's learning if it heads in problematic directions.
## Boundary definitions
Before handing any decision to an agentic system, I've found it useful to explicitly define the boundaries of acceptable behavior. This is about clarifying your own decision-making philosophy upfront.
For example, when experimenting with AI-driven email frequency optimization, I had to define what "too much" communication actually means. Is it more than five emails per week? More than three emails in a single day? Does it depend on the customer's engagement level? Their subscription preferences? Their purchase history?
These questions force you to articulate business logic that was previously implicit. The process of defining boundaries for AI delegation often reveals assumptions you didn't know you were making about customer preferences, brand voice, or business priorities. Luckily enough we can do that in our new preferred programming language… English.
## Monitor intent
Traditional marketing analytics focus on outcomes, open rates, click rates, and conversion rates. But when working with agentic systems, I've learned to monitor intent as well. What patterns is the AI detecting? What correlations is it acting on? What strategies is it developing?
This requires different dashboards than most teams are used to building. Remember those ‘reasoning dashboards/monitors’ I mentioned earlier in the series? Instead of just showing what happened, these interfaces need to show what the AI thinks is happening and why it's making certain choices.
Some teams are experimenting with these "AI reasoning logs" that capture not just the decisions the system made, but the patterns and correlations that influenced those decisions. This creates a kind of audit trail for AI thinking that helps humans understand whether the system is learning useful patterns or getting distracted by spurious correlations.
## When and how…
One of the most important aspects of any handoff protocol is defining when and how to escalate decisions back to humans. This needs to be more sophisticated than simple rule-based triggers, because the most interesting agentic decisions often involve novel situations that wouldn't trigger predefined rules.
I'm experimenting with confidence-based escalation, where the AI flags decisions it's uncertain about for human review. Because at the end of the day, most of this is about propensity. But calibrating these confidence thresholds is tricky. Set them too high, and you get escalations for every minor decision; set them too low, and you miss the cases where human judgment would actually be valuable.
Some teams are building escalation triggers around customer value or business impact. Decisions involving high-lifetime-value customers get human review. Choices that significantly deviate from historical patterns get flagged. Actions that could affect brand perception require approval.
## Be surprised
Perhaps the most important skill I've developed while working with agentic systems is learning to distinguish between surprising decisions that indicate good AI learning and surprising decisions that indicate AI confusion.
Good surprises often involve the AI discovering patterns you hadn't noticed. Maybe it realizes that customers who engage with content on mobile devices respond better to shorter subject lines, or that certain customer segments prefer educational content over promotional messages.
Bad surprises usually involve the AI acting on spurious correlations or optimizing for metrics that don't actually matter. Maybe it starts sending emails at 3 AM because it detected a tiny uptick in open rates during overnight hours, ignoring the fact that most people don't check email at that time.
Building this intuition takes time and requires accepting that you'll sometimes get it wrong. But I've found that teams develop better judgment about AI behavior when they're actively experimenting with delegation rather than just theorizing about it.
## Feedback loop
Successful handoff protocols require designing good feedback loops between human oversight and AI learning. When you override an AI decision, the system needs to understand why. When the AI discovers something useful, you need mechanisms to reinforce that learning.
This is harder than it sounds because human feedback often involves context that's difficult to encode in ways AI systems can use. You might override an AI's email timing decision because you know there's a company holiday that week, but teaching the AI to consider company holidays in future decisions requires updating its training data or decision framework.
Some teams are experimenting with structured feedback systems where humans provide not just approval or disapproval, but reasoning that helps the AI learn better patterns. Instead of just saying "don't send emails on Friday afternoons," you might specify "avoid Friday afternoons during summer months when engagement typically drops."
## Give it a go yourself
If you're ready to start experimenting with agentic AI delegation, I recommend beginning with this framework:
1. Choose one low-stakes, reversible decision that you make regularly.
2. Define clear boundaries for acceptable AI behavior.
3. Implement monitoring that shows both outcomes and AI reasoning.
4. Design escalation triggers that flag decisions for human review.
5. Create feedback mechanisms that help the AI learn from your overrides.
Start small, learn actively, and expand gradually as you build confidence in both the AI's capabilities and your own ability to work effectively with autonomous systems.
The future of marketing operations will likely involve extensive collaboration between humans and agentic AI. The teams that start experimenting with this collaboration now will have significant advantages over those who wait for the technology to become more predictable.
Because agentic AI will probably never be fully predictable. But it might become productively unpredictable in ways that create new possibilities for marketing effectiveness.
And learning to work with productive unpredictability feels like a valuable skill to develop.
---
*What's your first agentic AI experiment going to be? Are there specific delegation boundaries or escalation triggers you're considering? I'm curious about what others are discovering as they start handing decisions over to autonomous systems.*
---
- Part 1: [*The billion decision problem*](https://www.martechtherapy.com/agentic-ai-in-martech-the-billion/)
- Part 2: [*From complicated to complex*](https://www.martechtherapy.com/agentic-ai-in-martech-from-complicated/)
- Part 3: [*When agents disagree*](https://www.martechtherapy.com/agentic-ai-in-martech-when-agents/)
- Part 4: [*The new org chart*](https://www.martechtherapy.com/new-ai-org-chart/)
- Part 5: [*Trust without understanding*](https://www.martechtherapy.com/agentic-ai-in-martech-trust-without/)
---
👥 Connect with me on LinkedIn:
- Matthew: [https://www.linkedin.com/in/matthewniederberger/](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
📲 Follow Martech Therapy on:
- Instagram: [https://www.instagram.com/martechtherapy/](https://www.instagram.com/martechtherapy/?ref=martechtherapy.com)
- Youtube: [https://www.youtube.com/@martechtherapy](https://www.youtube.com/@martechtherapy?ref=martechtherapy.com)
- Bluesky: [https://bsky.app/profile/martechtherapy.bsky.social](https://bsky.app/profile/martechtherapy.bsky.social?ref=martechtherapy.com)
Thanks for reading Martech Therapy! Subscribe for free to receive new posts and support my work.
### Survey Announcement: How Martech gets done in 2025
URL: https://www.martechtherapy.com/martech-resources-survey-2025/
Last updated: 2025-10-09T19:47:19.000Z
This has been on my mind a lot lately. I’ve spoken with clients who are tightening budgets, vendors who are reshaping their services teams, and contractors who are either flooded or forgotten. At the same time, AI is quietly replacing some of the guidance people used to pay for.
So I built a survey to explore it all → rates, friction, perceived value, stack maturity, and the subtle power shifts happening between contractors, agencies, clients, and vendors.
It’s short, anonymous (unless you opt in or stay subscribed here), and open to anyone working in or around Martech:
→ [Start the survey here](https://docs.google.com/forms/d/e/1FAIpQLSd-%5FAWYG%5FQv6HNfwNY-9UsADSdx-40KSAm7KWyMxlPvdHV0YQ/viewform?ref=martechtherapy.com)
With your help and input I hope to uncover:
- Are rates really dropping or just budgets?
- Where do clients see value, and where do they get burned?
- Is AI changing how we staff and scope Martech projects?
- What’s actually working, and what’s holding us back?
If you’re in this space, as a solo, in-house (client or agency), or platform-side, I’d love your perspective.
I’ll publish the results here first, followed by a deeper breakdown on LinkedIn and possibly a roundtable or podcast. If you opt in at the end of the survey, I’ll send the full report directly.
Thanks for contributing and sharing, if you think others might have something to add.
Share this post with others to make the survey as significant as possible 👇🏻
### Don’t let your CDP become the Fall Guy
URL: https://www.martechtherapy.com/dont-let-your-cdp-become-the-fall-guy/
Last updated: 2025-10-09T19:47:20.000Z
The CDP market is taking a breather.
I was recently speaking to an industry leader who told me:
> “I think the whole CDP space has quietly ground to a halt… We’re seeing no more than 3–5 new opportunities per quarter. Lowest number ever.”
Funding has dried up, unless you are adding the “AI” label to a new feature. Sales cycles have slowed. Implementations are dragging. And the next big thing? It’s not here yet. AI might be “*le mot du jour*” (French for “word of the day”) of the moment, but it’s not the thing replacing your CDP. At best, it’s a feature set waiting on your stack to get its act together.
So what now?
Here’s what I think. I think that this is exactly the right moment to get more value out of the investment you already made. Especially when it comes to **data quality**, the part everybody tries to avoid like the plague, until everything breaks.
## **Shelfware is a data problem, not a platform problem**
If your CDP feels underwhelming, vibes of which I seem to be picking up, it’s probably not because you bought the wrong tool. It’s because you haven’t given it the fuel it needs.
The hard truth is we must all face is that most CDPs don’t fail because of bad tech. In most cases, they fail because the data flowing into them is incomplete, unstructured, duplicated, misnamed, undocumented, or just stale.
And AI? Repeat after me → AI.DOES.NOT.FIX.BAD.DATA. (should .com this? 😉). It just automates more decisions *based* on that bad data, faster, at scale, and with even less explainability.
At some point, every CDP becomes the fall guy. (No offence to Ryan Gosling.)
But maybe we should stop blaming the platform and start fixing what feeds it.
That’s why now, in this moment where CDP development has stalled, is the time to make your data quality someone’s job again.
## **Five things you can do while the industry stalls**
Trust me on this, you don’t need a 12-month roadmap. You need a few weeks of focused effort and some elbow grease. These aren’t sexy projects by any means. But they’re the difference between a CDP that drives value and one that quietly rots on the shelf… and gets pushed off of it.
### **1\. Run a “data purpose audit”**
Ask a simple question: *why are we collecting this data point*? If you don’t know what it powers, who needs it, kill it or quarantine it. You’ll reduce noise and improve downstream trust.
### **2\. Fix your identity graph hygiene**
Attention is increasing on improving Identity Resolution. Deterministic was the way to go, now probabilistic means have entered the race. But there is no immediate rush to join that conga line. Just remember, if you’re still relying on default merge rules or have user profiles with five IDs, it’s time to get serious. Resolve duplicates, revisit stitching logic, and make your identity model predictable.
### **3\. Clean up your taxonomy**
Data catalogue, anyone? Yeah, just about as well-known as some washed-up actor in a C-list movie. No offense intended, but ask yourself this → are your event names, properties, and trait labels consistent across tools? Probably not. Settle on a naming convention that survives handovers and doesn’t require an archaeologist to interpret.
### **4\. Automate freshness checks**
Which sources haven’t sent data in 30 days? Which sources do you have (*my favorite question of all time to make people realize what is at stake*)? Which traits haven’t been updated since last year? Set up monitoring and alerting, or accept that you’re flying blind.
### **5\. Write it down, like someone new is joining**
As a good friend of mine often says, “*document or die*”… well, he doesn’t say it, but he has a cool decal of it. Most CDP setups live inside one person’s head. If you are lucky, it is someone internal and not a contractor like myself. Not documenting your CDP setup is a monumental a risk. Take a moment to consider the follow → If you had to hand this over tomorrow, could someone else keep it running? If not, fix that.
## **It’s the foundation**
Better data makes every part of your stack smarter. It fuels better segments, more reliable experiences, cleaner handoffs to downstream systems, and yes, makes AI features actually usable.
The irony? Most companies already have the tools. They just don’t have the habit of maintenance.
That’s the opportunity right now. Not a change of vendor. Not a platform rip-and-replace. But a return to basics, while everyone else waits for the next thing to arrive.
## **You’re already sitting on a goldmine**
As I said to that industry leader I mentioned at the beginning:
> “Many companies still need to realize the gold mines they are sitting on. Maybe that’s the ‘next best action’, take action while the industry is taking a breather.”
Look, your CDP isn’t broken. It’s just buried under too many things you stopped looking at.
If you’re trying to figure out where to dig or how to stop the data rot before it spreads, this is precisely the kind of thing I help clients with at **Martech Therapy**. One part strategy, one part therapy, and a lot of time spent with logs, identities, and unloved schemas.
Sometimes, making sense of a CDP means stepping outside the platform for a moment.
And sometimes, it means not blaming the fall guy.
### Can identity resolution work without AI? Steven Renwick from Tilores explains
URL: https://www.martechtherapy.com/can-identity-resolution-work-without/
Last updated: 2025-07-02T08:46:23.000Z
There’s a lot of noise around AI and identity right now.
**Hightouch** just launched Adaptive Identity Resolution, **Meiro** is leaning hard into real-time CDP-native matching, and **Amperity** continues to push its probabilistic + deterministic blend for enterprise brands. But when someone asked me whether GenAI could *solve* identity resolution, I went straight to someone who’s seen the inside of the problem: **Steven Renwick**, co-founder and CEO of **Tilores**.
Steven and his team aren’t building another black box, they’re focused on traceability, reversibility, and real-time performance for messy, high-volume data. In this episode, we dig into what that actually means in practice.
💬 Topics we cover:
- Why Tilores avoids GenAI for core matching—and where it *does* use LLMs
- Entity graphs, not vector embeddings
- Using RAG (retrieval augmented generation) to query resolved identities
- Matching for fraud use cases, telecom mergers, and multi-brand insurance data
- Why explainability still beats hype in regulated industries
> **“Fraudsters aren’t always smart. They just hope your data isn’t smart either.”**
We also touch on identity matching horror stories, Cockney rhyming slang, and why test data is the silent killer of your data quality.
Learn more about Tilores → https://tilores.com/
---
👥 Connect with us on LinkedIn:
- Steven: [https://www.linkedin.com/in/stevenrenwick/](https://www.linkedin.com/in/stevenrenwick/?ref=martechtherapy.com)
- Matthew: [https://www.linkedin.com/in/matthewniederberger/](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
📲 Follow Martech Therapy on:
- Instagram: [https://www.instagram.com/martechtherapy/](https://www.instagram.com/martechtherapy/?ref=martechtherapy.com)
- Youtube: [https://www.youtube.com/@martechtherapy](https://www.youtube.com/@martechtherapy?ref=martechtherapy.com)
- Bluesky: [https://bsky.app/profile/martechtherapy.bsky.social](https://bsky.app/profile/martechtherapy.bsky.social?ref=martechtherapy.com)
Support my therapeutic work and subscribe for free!
### Agentic AI in Martech: Trust without understanding
URL: https://www.martechtherapy.com/agentic-ai-in-martech-trust-without/
Last updated: 2025-10-09T19:47:21.000Z
My Tesla occasionally does something that makes me question everything I think I know about driving. Since I have owned it, there have been numerous times when it suddenly slammed on the brakes while on autopilot, no visible obstacles, no construction signs, perfect weather. Just [phantom braking](https://www.abc.net.au/news/2025-06-11/tesla-phantom-braking-australia-class-action-lawsuit/105395490?ref=martechtherapy.com), the phenomenon that’s been getting Tesla scrutinized by government agencies.
My wife hates when this happens. She’s made it very clear that I shouldn’t rely on autopilot when the family is in the car, both for safety reasons and because she’d prefer I not sleep on the couch.
8-car phantom braking crash in San Francisco in November 2022\. ([Electrek](https://electrek.co/2023/01/11/footage-tesla-phantom-braking-causing-8-car-crash-pile-up/?ref=martechtherapy.com))
This captures something fundamental about working with agentic AI systems. Although we often discuss them positively, what we need to acknowledge is that sometimes they make decisions that seem wrong and actually are wrong, but you can’t predict when. The challenge isn’t just understanding those decisions, it’s designing *for trust* in systems that operate beyond your comprehension and occasionally betray it in unpredictable ways.
This is something I started exploring in the [*Contextual CDPs*](https://www.martechtherapy.com/trust-as-a-feature/)[ series](https://www.martechtherapy.com/trust-as-a-feature/). There, trust was framed as something built not through control, but through *contingency*. The idea that you could design a system where trust doesn’t mean “knowing exactly why” but “knowing when to intervene, and when not to.” That framing is becoming even more relevant now.
## **Explainability as a Service**
Most discussions about AI governance start with explainability. We want systems that can tell us why they made specific decisions, show us their reasoning, and walk us through their logic step by step.
This makes intuitive sense for simple AI applications. If your lead scoring model gives someone a high rating, you want to know it’s because they visited your pricing page three times and downloaded two whitepapers, not because their email address contains the letter ‘Q’.
Example of stored reasoning for post processing review.
But explainability breaks down once systems become agentic. The logic behind any individual decision might be distributed across thousands of micro-updates, model weights, and cross-context correlations. As I argued in the [*Trust as a feature*](https://www.martechtherapy.com/trust-as-a-feature/)[ post from the Contextual CDP series](https://www.martechtherapy.com/trust-as-a-feature/), the more expressive a system becomes, the harder it gets to map one input to one output in a way that makes human sense. You don’t get a flowchart. You get a shadow.
## **Building trust through outcomes**
So I’ve been shifting the *trust* question. Instead of asking *why* the AI made a specific choice, I ask *whether* those choices, over time, drive outcomes I care about. Trust, in that sense, becomes pattern-based.
You’re no longer judging individual decisions. You’re watching the system’s trajectory. Does it consistently learn in a direction that aligns with your goals? Does it adapt in ways that make your orchestration better, not weirder?
This is a big change from traditional governance and it is a pattern we see starting to emerge in tools like [Hightouch’s AI Decisioning](https://hightouch.com/platform/ai-decisioning?ref=martechtherapy.com), and [Aampe’s](https://aampe.com/?ref=martechtherapy.com) core offering. It requires moving beyond reports that show “what happened” to observability models that detect *how the system is evolving*. It’s about observing learning.
## **Confidence calibration problem**
Like many salespeople, agentic systems love being confident. Sometimes, weirdly so.
An AI might be 97% sure that sending a promotional email at 3:47 AM on a Tuesday is optimal for a customer, based on dozens of variables and millions of interactions. But, like my Tesla’s phantom braking problem, that confidence might rest on a spurious correlation involving nothing more than timezone anomalies and a broken event tag.
That’s why outcome monitoring has to include *calibration*. Is the system as good at knowing *when it’s right* as it is at being right? In other words, does confidence correlate with correctness?
If not, trust can’t scale. You’re not building a system, you’re betting on a gambler.
## **Designing trust boundaries**
In the [*Letting Go of Control*](https://www.martechtherapy.com/letting-go-of-control/) article, I introduced the idea of *delegation design*. You don’t trust an agent by default, you trust it *within bounds*. These bounds aren’t static rules but operational guardrails, shaped by context, stakes, and reversibility.
Some are obvious, such as don’t send more than X emails, don’t discount more than Y percent. But others are more dynamic. Something along the lines of escalate if recent support tickets exist, override if confidence drops below a threshold, or route to human judgment when a decision breaks from historical precedent.
Agentic AI demands a new kind of policy architecture, what Paul Meinshausen and I discussed as *meta-logic*: rules about when rules need to be negotiated. Think more like air traffic control, less like campaign workflows.
## **Trust through reversibility**
I’ve found one of the best proxies for safe autonomy is reversibility. If a decision can be undone quickly with minimal impact, you can afford to let agents experiment. If not, you need to contain or delay that autonomy.
Trust in Agentic AI comes in many shapes and sizes.
This principle, trust the system more when failure is cheap, has quietly been a guiding force in agentic deployments. You start with email timing, not price modeling. You scale from button color to bundling logic. It’s about aligning trust with stakes.
Reversibility is organizational. Who owns the override? How fast can recovery happen? What signals trigger rollback?
## **The learning partnership model**
This brings me back to the idea of *co-evolution*. In the [Contextual CDPs series](https://www.martechtherapy.com/understanding-mcps-a-cdp-insiders/), I described a trust model where AI systems and human teams evolve together. The AI detects subtle patterns. Humans evaluate their usefulness. Feedback flows in both directions.
Paul put it this way:
> Agentic systems don’t eliminate business logic, they *expand* it.
They move you **from rule-based control to pattern-based influence**. That means trust becomes less about authority and more about adaptation.
But adaptation only works when both sides are learning. AI can’t just execute. Humans can’t just override. The loop is the thing.
## **Accepting productive uncertainty**
The more I work with agentic systems, the more I realize that perfect understanding isn’t the goal. What matters is *productive uncertainty*, systems that surprise you in useful ways, not just weird ones.
That’s where the trust architecture really changes. You stop treating explainability as a requirement and start treating responsiveness as a capability. You design for reversibility. You monitor for pattern drift. You establish feedback rituals that evolve alongside the system.
It’s about designing environments where new logic can emerge, safely, directionally, and occasionally insightfully.
Even if it means braking for something you can’t see.
---
Read the Agentic AI in Martech series:
- Part 1: [*The billion decision problem*](https://www.martechtherapy.com/agentic-ai-in-martech-the-billion/)
- Part 2: [*From complicated to complex*](https://www.martechtherapy.com/agentic-ai-in-martech-from-complicated/)
- Part 3: [*When agents disagree*](https://www.martechtherapy.com/agentic-ai-in-martech-when-agents/)
- Part 4: [*The new org chart*](https://www.martechtherapy.com/new-ai-org-chart/)
- Part 6: [*The Handoff*](https://www.martechtherapy.com/agentic-ai-in-martech-the-handoff/)
---
👥 Connect with me on LinkedIn:
- Matthew: [https://www.linkedin.com/in/matthewniederberger/](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
📲 Follow Martech Therapy on:
- Instagram: [https://www.instagram.com/martechtherapy/](https://www.instagram.com/martechtherapy/?ref=martechtherapy.com)
- Youtube: [https://www.youtube.com/@martechtherapy](https://www.youtube.com/@martechtherapy?ref=martechtherapy.com)
- Bluesky: [https://bsky.app/profile/martechtherapy.bsky.social](https://bsky.app/profile/martechtherapy.bsky.social?ref=martechtherapy.com)
Thanks for reading Martech Therapy! Subscribe for free to receive new posts and support my work.
### What if there isn’t a method?
URL: https://www.martechtherapy.com/what-if-there-isnt-a-method/
Last updated: 2025-10-09T19:47:22.000Z
There’s a genre of professional content I’ve come to recognize instantly. It begins with confidence, proceeds with certainties, and ends with a prescription. Or worse, “Comment \[*enter random term*\]”.
- Here’s the method.
- Here’s what works.
- Here’s how to win.
And every time I see it, a small part of me cries inside.
Not because I think they’re wrong, but because I’ve been inside enough organizations to know that none of this unfolds in a vacuum. Advice that sounds brilliant on a whiteboard often dissolves the moment it hits budget constraints, team friction, or the fifth tool no one dares deprecate.
So when people ask me, “What’s the right way to do this?” my honest answer is:
**It depends.** And that’s not a cop-out, but I did copy it off of Luke Wroblewski. In all honesty, it’s the beginning of the real work.
> There is no single method. Just methods that work *in a specific context, for a while, until something changes.*
That’s not exactly a bestselling title. But it’s the only claim I can stand behind.
Source: [Luke Wroblewski](https://www.linkedin.com/posts/lukew%5Factivity-7059203051919704064-issr/?ref=martechtherapy.com)
### **Context is the story.**
You can’t copy-paste someone else’s Martech success. You don’t inherit team readiness by buying the same stack. You don’t get orchestration just because you licensed a Journey Builder. And yet, we keep getting articles and keynote slides that flatten all this into clean stages and tidy diagrams.
What’s missing is a willingness to stay in the ambiguity. To admit that Martech success is often shaped less by tools than by timing, culture, tradeoffs, and inertia. And that what worked once may not work again.
When I wrote the [**CDP Reboot**](https://www.martechtherapy.com/the-cdp-reboot-the-promise/), I wasn’t mapping the future of the category. I was holding up a mirror to the chaos many teams live through, and still somehow function within.
With the [**Contextual CDPs**](https://www.martechtherapy.com/understanding-mcps-a-cdp-insiders/)[ series](https://www.martechtherapy.com/understanding-mcps-a-cdp-insiders/), I wanted to explore how the same stack can produce radically different outcomes depending on what surrounds it. Things like artificial intelligence, org structures, incentives, data policies, leadership habits.
Now, in the [**Agentic AI in Martech**](https://www.martechtherapy.com/agentic-ai-in-martech-the-billion/)[ series](https://www.martechtherapy.com/agentic-ai-in-martech-the-billion/), I’m wrestling with a different kind of complexity → delegation. Not just which team owns what, but how decision-making flows when AI enters the loop, quietly steering systems in ways humans barely trace.
Each of these projects started from a similar impulse:
> Not to define a new method, but to ask whether we’re even asking the right questions.
### **What I believe, for now**
I believe there’s no universal method, and I have always been outspoken about this.
Only moments of fit, where the structure, team, tooling, and goals line up *just enough* to create movement.
And that movement is usually short-lived. Something shifts, someone leaves, another platform launches, and we’re back to adapting.
But don’t despair, my Martech friend. This is not a sign of failure or incompetence. That’s what it means to work in a complex system.
So rather than handing out answers, I try to play the role of Leonardo Di’Capprio in Inception, and plant ideas such as:
- What friction are you learning to tolerate instead of solve?
- What kind of control are you seeking, and who benefits from it?
- Which team’s pain is loudest right now, and is that distorting your priorities?
These aren’t questions you see or think of every day, but they need to be there in the back of your mind. They’re the kind that might lead you to a version of success that’s actually your own.
### **What comes next**
For now, I’m still writing. Still exploring.
The *Agentic AI in Martech* series is halfway through.
*A series on Multi CDP setups will follow soon.*
Both are rooted in the same hesitation that shaped this post. Not just to describe what’s happening, but to resist the urge to pretend it’s simple.
And I get it. Certainty is easy to sell. But too much of it is leaving teams with beautiful decks and broken implementations.
So no, I won’t give you the method.
But I will give you questions.
I’ll show you what I’ve seen.
And I’ll be honest about what’s still unclear, even to me.
Because that’s the only kind of Martech advice I trust.
---
👥 Connect with me on LinkedIn:
- Matthew: [https://www.linkedin.com/in/matthewniederberger/](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
Subscribe for free and receive updates instantly.
### Agentic AI in Martech: The new org chart
URL: https://www.martechtherapy.com/new-ai-org-chart/
Last updated: 2025-10-09T19:47:23.000Z
A friend recently asked me what a marketing ops manager actually does when AI agents are handling campaign execution, optimization, and conflict resolution. It's a fair question. If systems are making billions of decisions autonomously, what's left for us mortal humans?
My first instinct was to give the standard consultant answer about "strategic oversight" and "creative direction." But the more I thought about it, the more I realized that's probably wrong. The interesting human roles in an agentic world are likely to be things we haven't fully invented, yet.
## Beyond the "Human in the Loop" fiction
Most discussions about AI and jobs fall into two camps: either AI will replace everyone, or humans will always be "in the loop" providing oversight and approval. Both seem misguided when you [consider the math we covered in Part 1](https://www.martechtherapy.com/agentic-ai-in-martech-the-billion/).
If your AI is making 200 billion decisions per week, you're not in the loop. You can't be. The loop is happening too fast and at too large a scale for meaningful human participation in individual decisions.
But that doesn't mean humans become irrelevant. It means human work evolves to operate at different scales and different timeframes than the AI work.
## The Emerging Roles
Based on conversations with teams experimenting with agentic systems, I'm seeing several new categories of human work emerge that I would like to share with you. Now, these job titles are all suggestive, but like anything new, we need to start somewhere, to see where it ends:
- **Context Architects** design the frameworks within which agents operate. They don't make individual campaign decisions, but *they define what good outcomes look like and create the measurement systems that help agents learn*. They're essentially building the environment that shapes AI behavior rather than controlling specific AI actions.
- **Agent Whisperers** specialize in *understanding how individual AI systems "think" and helping them work together more effectively*. When agents conflict or produce unexpected results, these people can interpret what the system was optimizing for and adjust its parameters or training data accordingly.
- **Outcome Guardians** focus on monitoring the cumulative effects of billions of micro-decisions. They're less concerned with why the AI chose to send a particular email and *more focused on whether the overall pattern of decisions is moving business metrics in the right direction*.
- **Exception Handlers** deal with the edge cases and novel situations that fall outside the AI's training. When the system encounters something genuinely new, these people *provide judgment and help the AI learn how to handle similar situations in the future*.
## The pattern recognition shift
What strikes me about these roles is how they're **all about pattern recognition rather than task execution**. Humans become responsible for recognizing patterns that operate above the level of individual decisions, meta-patterns about how the AI is learning, how different systems are interacting, how customer behavior is evolving.
Examples of current AI-related job titles. Still far from where we need to be.
This requires a different kind of analytical thinking than traditional marketing ops. Instead of optimizing campaigns, you're optimizing the systems that optimize campaigns. Instead of segmenting customers, you're designing the frameworks that help AI discover better segmentation strategies.
It's a bit like the difference between playing chess and coaching a chess player. The coach doesn't make moves during the game, but they shape how the player thinks about strategy, help them learn from mistakes, and prepare them for situations they haven't encountered before.
## Delegation design
One of the most interesting challenges is figuring out what to delegate and what to keep. It's a business design problem that requires understanding both AI capabilities and organizational dynamics.
Some teams are experimenting with progressive delegation, where they gradually expand the scope of decisions they're comfortable outsourcing to AI. They might start with email send time optimization, then move to subject line testing, then to audience selection, then to offer personalization.
Others are taking a domain-based approach, where certain business areas (like customer retention) become fully autonomous while others (like brand messaging) remain human-controlled.
But perhaps most intriguingly, some teams are designing what I think of as "collaborative domains" where AI handles execution while humans handle strategy and exception management. The AI runs the day-to-day optimization, but humans design the experiments, interpret unusual results, and adjust the overall direction.
## Calibrating trust
All of these new roles share a common challenge: calibrating trust appropriately. You need to trust the AI enough to let it operate autonomously, but not so much that you stop paying attention to what it's doing.
This is harder than it sounds because AI systems can be simultaneously incredibly reliable and completely unpredictable. They might optimize email campaigns flawlessly for months and then suddenly start recommending bizarre send times because they detected a pattern in the data that doesn't actually exist.
The humans who work well with agentic systems seem to develop an intuitive sense for when AI behavior feels "off" even when the metrics look fine. They're not monitoring individual decisions, but they're monitoring the system's overall behavior patterns for signs of drift or confusion.
## Skills translation for us humans
Traditional marketing ops skills don't disappear in an agentic world, but they do translate differently. Understanding segmentation logic helps you design better frameworks for AI-driven personalization. Knowing how email deliverability works helps you set appropriate guardrails for AI-generated send strategies.
But there are also entirely new skills emerging. People need to understand how to interpret AI confidence scores, how to design effective feedback loops, how to debug systems that learn and adapt autonomously.
I'm convinced that some of the most valuable marketing professionals in the coming years will be those who can bridge between traditional marketing intuition and AI system behavior. They'll understand both what good marketing feels like and how to shape AI systems to consistently deliver that feeling.
## The collaboration evolution
Perhaps the biggest change is that **working with agentic AI starts to feel less like using tools and more like managing a very strange team**. You can't micromanage AI agents any more than you can micromanage talented employees. But you can set clear expectations, provide good feedback, and create environments that encourage the behavior you want.
This requires developing new management intuitions. How do you motivate a system that doesn't have emotions? How do you provide feedback to something that learns differently than humans? How do you build trust with a team member that makes decisions at superhuman speed but sometimes for incomprehensible reasons?
These questions don't have established answers yet, which makes this an interesting time to be experimenting with agentic systems. The teams that figure out effective human-AI collaboration patterns early will have developed valuable organizational capabilities that are hard for competitors to replicate.
Of course, all of this assumes you can actually trust systems you can't fully understand, which brings us to an even more fundamental challenge about building confidence in autonomous agents.
---
*What new roles are emerging in your organization as AI takes on more execution? Are you seeing different patterns of human-AI collaboration? I'm especially curious about how teams are handling the transition from direct control to outcome-focused oversight.*
---
Read the Agentic AI in Martech series:
- Part 1: [*The billion decision problem*](https://www.martechtherapy.com/agentic-ai-in-martech-the-billion/)
- Part 2: [*From complicated to complex*](https://www.martechtherapy.com/agentic-ai-in-martech-from-complicated/)
- Part 3: [*When agents disagree*](https://www.martechtherapy.com/agentic-ai-in-martech-when-agents/)
- Part 5: [*Trust without understanding*](https://www.martechtherapy.com/agentic-ai-in-martech-trust-without/)
- Part 6: [*The Handoff*](https://www.martechtherapy.com/agentic-ai-in-martech-the-handoff/)
---
👥 Connect with me on LinkedIn:
- Matthew: [https://www.linkedin.com/in/matthewniederberger/](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
📲 Follow Martech Therapy on:
- Instagram: [https://www.instagram.com/martechtherapy/](https://www.instagram.com/martechtherapy/?ref=martechtherapy.com)
- Youtube: [https://www.youtube.com/@martechtherapy](https://www.youtube.com/@martechtherapy?ref=martechtherapy.com)
- Bluesky: [https://bsky.app/profile/martechtherapy.bsky.social](https://bsky.app/profile/martechtherapy.bsky.social?ref=martechtherapy.com)
Be the first to know when part 5 drops. Subscribe for free today 👇🏻
### Humans, not tools - A Martech podcast about the real stuff
URL: https://www.martechtherapy.com/humans-not-tools-a-martech-podcast/
Last updated: 2025-10-09T19:47:24.000Z
Phil Gamache said, “I ask questions like an analyst, but I listen like an operator.” And that’s exactly why I invited him onto Couch Confidentials, for quotes like that. At the end of the day we are all trying to achieve the same.
He doesn’t just host Humans of Martech, he’s built a platform that holds up a mirror to the way we actually work. The late-night migrations. The marketing ops arguments. The tools that break quietly while no one’s watching. His podcast is not about frameworks or vendor checklists, it’s about people trying to do the job in the real world.
We talked about how podcasting has shaped his thinking, why he now screens guests by asking what irritates them, and how multi-touch attribution might be the fax machine of measurement. The episode is full of sharp moments, but what I liked most is Phil’s understanding of what this work is really about. Not thought leadership for its own sake. Not riding the next acronym. But making sense of the messy middle.
Martech is wild right now. This one helped me feel a little more sane.
---
👥 Connect with us on LinkedIn:
- Phil: [https://www.linkedin.com/in/gamacp/](https://www.linkedin.com/in/gamacp/?ref=martechtherapy.com)
- Matthew: [https://www.linkedin.com/in/matthewniederberger/](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
📲 Follow Martech Therapy on:
- Instagram: [https://www.instagram.com/martechtherapy/](https://www.instagram.com/martechtherapy/?ref=martechtherapy.com)
- Youtube: [https://www.youtube.com/@martechtherapy](https://www.youtube.com/@martechtherapy?ref=martechtherapy.com)
- Bluesky: [https://bsky.app/profile/martechtherapy.bsky.social](https://bsky.app/profile/martechtherapy.bsky.social?ref=martechtherapy.com)
Thanks for reading Martech Therapy! Subscribe for free to receive new posts and support my work.
### This is me. Who are you?
URL: https://www.martechtherapy.com/this-is-me-who-are-you/
Last updated: 2025-10-09T19:47:25.000Z
I was scrolling through Youtube comments under a video by Anthropic where someone wrote: *“you say wow way too much”* And I froze. Because I knew, I do that. If you have seen or listened to any of my podcasts, you will know that I’m the guy saying “wow” or “that’s amazing,” asking follow-up questions, leaning in a little too much. Trying to show I care. Trying to bond.
The spark.
At Navy boot camp, back in 1993, there were eighty of us in the end-of-training company photo, looking smart in our dress blues. Only one smiling face… mine. I caught hell for that. But I couldn’t help it. That smile was real. I was proud to be there. That’s always been my instinct: be open, connect, be enthusiastic, stay curious.
Some of that started early. My brother, Mark, died when I was eleven. He was fourteen and had been diagnosed 18 months earlier with an aggressive brain tumor. I went from younger sibling to only child overnight, but my mother (my parents were divorced) did the best she could. But something cracked open in me, a void appeared, a deep ache to be part of something bigger, to not feel so alone, even if it meant carrying more than I should.
My brother (right) and I in Dallas, circa 1984.
Having watched Top Gun and Navy Seals many times over (again, I was young and naive at the time, seeking excitement and new levels of greater), the Navy felt like the right answer in 1993\. Nine years of chasing that feeling of brotherhood. There was good work and hard work. Humanitarian missions, drug interdictions, long deployments under the NATO flag. But the stuff that sticks isn’t in the mission logs or commendations. It’s the sound of someone’s voice breaking after hearing their kid was rushed to the hospital thousands of miles away, with no way home. It’s the suicide attempts. The ones we stopped. The ones we didn’t. The ones where someone just couldn’t take it anymore.
These things bonded us, sure, but the connection always felt temporary. Contingent on crisis. If things were calm, we drifted. And when I left the service, two Captain’s masts later, that drift felt permanent.
A treasured letter from Jesse, 4 years before he died.
Jesse was the exception. He was my buddy, my brother in arms. A friend who saw the whole mess and still showed up, and more importantly, introduced me to the Beastie Boys. Then, not long after I left the Navy, Jesse died, under circumstances too close to how I lost my brother. It hollowed me out, again. I got to say farewell to him at his home in South Carolina a month before he passed, but the PTSD I’d been ignoring came roaring back. I drank more. Got into debt more, to feed that retail therapy beast. I disappeared into places I didn’t remember arriving, literally, and figuratively. What used to be dark comedy among veterans became something else entirely. A slow-motion unraveling.
And the cruelest part? I wanted love, connection, belonging… but pushed it all away the second it got close. Depression will do that. It teaches you to flinch before you’re even touched. To say goodbye before anyone asks you to stay. Something I still catch myself doing to this day.
Then I met someone who saw all of that and didn’t run. My wife didn’t try to fix me. She just made therapy non-negotiable. Not as an ultimatum, but as a condition of building something real. And she was right. And we did.
There was a turning point during one EMDR session where I recalled the image of my brother setting the table, crawling over the floor from the kitchen to the dining table, with the cutlery in his bathrobe pocket, while being paralyzed on one side. The pain of not helping him, being lazy, and taking it for granted, the drive and will within him. The feeling that I could never match up to that. It should have been me. I felt the weight I’d carried since eleven, this grief-disguised-as-drive, finally shift a little. Not vanish. But loosen its grip on me.
Still, I needed something. Some community. A way to connect that wouldn’t put me at risk of getting hurt again.
Interestingly, I discovered it in digital analytics around 2005, shortly after I met my wife.
There’s something about this corner of the industry, whether it's martech, data, analytics, or whatever, that felt human in ways I hadn’t expected. People didn’t pretend to have it all figured out. They admitted mistakes. For many it was and remains a case of learn and move on. They taught without condescension. They asked questions that felt honest, not performative.
That generosity gave me room to breathe. It reminded me that maybe not all connection has to be temporary. And that changed something.
But I still keep some distance. That’s why I freelance now after having tried agency and client-side jobs for 10 years. The freedom of contracting keeps me in balance. It lets me be there for my family, with our eldest son who around 10 years ago was diagnosed with a benign brain tumor, the sick irony of life, but I was more resilient this time around.
Contracting allows me to be fully present at work, yet still hold back just enough. I can contribute, connect, and help build something, but I don’t have to stay. I don’t have to belong fully. That sounds sad, but it’s safer. I’ve had contracts where it genuinely hurt to say goodbye, and that pain reminded me why I draw lines the way I do. That’s what I keep convincing myself of, though. The jury is still out on that one.
At nearly 50, I’m the sum total of everything I’ve seen. But it’s not just a sum, it’s addition, subtraction, multiplication, and division. Some experiences added to me. Some took pieces away. Some split me open. Others multiplied the meaning of things I thought I understood. All of it shaped me.
Which brings me to my son, our youngest.
He’s what the school system politely calls “gifted,” though he doesn’t fit the model. He learns fast, obsesses over things, and melts down when he hits walls. He doesn’t slot neatly into social groups. Just does his own thing, tries to be himself. Which, again, sounds familiar.
He got deep into manga and asked me to take him to ComicCon. I’m a lifelong sci-fi fan. Fallout, The Expanse, Star Wars’ Andor, so I was game. But I had assumptions about cosplay and the people who do it. I thought it took wild courage to wear that kind of outfit in public.
Turns out, I had it backwards.
ComicCon wasn’t about extraordinary bravery. It was about ordinary acceptance. People weren’t trying to stand out, they were finally able to just be themselves. The costumes weren’t rebellion. They were belonging.
And my son? He thrived. Talked to strangers like it was the most natural thing in the world. Got respect from the jump. Found his people. For once, he wasn’t the weird kid. He was just a fan among fans.
Watching him, I realized I knew this feeling. I’d found it in our professional community. The one we build in chat threads, conference calls, and post-conference hotel bars. The one where you can say, “I’m not sure,” and no one punishes you for it. Where vulnerability isn’t a weakness, it’s credibility.
ComicCon and our little corner of martech, digital analytics, and our common love for data share something rare: they assume you belong until you prove otherwise. Not the other way around.
For years, I thought belonging meant finding people who were just like me. Same experiences, same wiring. The Navy gave me that for a while, but only under pressure. What I’ve learned since is that real belonging isn’t about sameness. It’s about shared values. At ComicCon, that’s enthusiasm. In our world, it’s curiosity.
The people who show up damaged but still willing to try? They’re the ones others gravitate toward. Not because they’ve got all the answers, but because they don’t pretend to.
So yeah. **This is me.**
Someone who lost too much too young. Who made mistakes, repeatedly, and tried to hide. Who spent years chasing a connection while also running from it at the same time. Who found a strange kind of home in professional communities that value honesty more than polish. Someone still learning how to stay in the room when things get quiet. Someone who says, and will continue to genuinely say, ‘wow’ often.
My son showed me what it looks like to walk into a space and just *assume* you belong. No armor. No apology.
That’s what I’m working on. Being human, being me.
**Who are you?**
---
**Connect with me on LinkedIn:**
- Matthew: [https://www.linkedin.com/in/matthewniederberger/](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
**Follow Martech Therapy on:**
- Instagram: [https://www.instagram.com/martechtherapy/](https://www.instagram.com/martechtherapy/?ref=martechtherapy.com)
- Youtube: [https://www.youtube.com/@martechtherapy](https://www.youtube.com/@martechtherapy?ref=martechtherapy.com)
- Bluesky: [https://bsky.app/profile/martechtherapy.bsky.social](https://bsky.app/profile/martechtherapy.bsky.social?ref=martechtherapy.com)
### Shopify isn’t enough
URL: https://www.martechtherapy.com/shopify-isnt-enough/
Last updated: 2025-10-09T19:47:25.000Z
There’s a moment that creeps in somewhere between “should I try another email pop-up plugin?” and “why don’t my reports ever answer real questions?” It’s a quiet realization. The platform that made it beautifully easy to launch your store might not be built to help you scale your marketing or understand your customers beyond last Tuesday’s sale.
Shopify does many things well. It’s clean, manageable, and doesn’t ask you to learn code or bribe a developer friend. It’s perfect for what it is: a commerce platform. Not a data platform. Not a campaign engine. And certainly not a customer brain.
Which brings us to the apps.
### **App store as life raft**
If you’ve ever stared into the [Shopify App Store](https://apps.shopify.com/?ref=martechtherapy.com) looking for “just a bit more insight,” you’re not alone. These apps promise that final nudge from chaos to control. Install [Klaviyo](https://www.klaviyo.com/?ref=martechtherapy.com), and suddenly you’re sending abandoned cart flows like a seasoned growth hacker. [Add Piwik PRO](https://apps.shopify.com/piwik-pro?ref=martechtherapy.com) and suddenly you’re a data privacy champion with funnel tracking to match.
But let’s not skip over a few realities.
Yes, these apps can be installed with a click. And yes, many of them, like Klaviyo, [Bloomreach](https://bloomreach.com/?ref=martechtherapy.com), [ZEPIC](https://zepic.com/?ref=martechtherapy.com), Piwik PRO, are purpose-built to slot neatly into Shopify’s ecosystem. [Klaviyo even got a hundred million dollar thumbs-up from Shopify](https://techcrunch.com/2022/08/02/shopify-makes-100m-strategic-investment-in-marketing-automation-startup-klaviyo/?ref=martechtherapy.com) itself and now wears the title of “strategic email partner for Shopify Plus.” [Piwik PRO just launched their own native app with a full analytics suite, a cookieless CDP, and zero-touch setup](https://piwik.pro/blog/piwik-pro-app-for-shopify/?ref=martechtherapy.com). You can go from zero to tagged in under an hour.
But that’s just the on-ramp. The actual driving? That’s still on you.
### **The difference between ‘installed’ and ‘used well’**
Here’s the thing you need to keep in mind → one-click install doesn’t mean one-click results.
You can install a CDP, sure. But what data do you actually want to capture? Do you know what a “high-value visitor” looks like on your store? Have you thought about segment decay? Consent expiry? Do you need to? You bet ya!
Even email automation tools like Klaviyo, for all their prebuilt flows and plug-and-play templates, still require judgment. Timing. Copywriting. Common sense. Do you really want to re-engage a customer who bought one candle in 2019 and hasn’t opened a message since?
What I’m saying is, these apps don’t replace strategy. They operationalize it.
Without a clear understanding on what you’re trying to fix or improve, you might just end up with a stack of disconnected tools and dashboards that look impressive but tell you little. Like installing a smart thermostat in a house with no insulation. You’ll know the temperature, just not how to change it.
### **Where Shopify’s built-ins start to bend**
Look, this isn’t a Shopify takedown. Their native tools are fine for what they are. I would even use them if I wanted to start a webshop. You can run basic newsletters through Shopify Email. You can track basic product and order analytics. You can get a general sense of how your store is doing.
But if you start asking more sophisticated questions such as:
- Who are my most profitable customers?
- Which channel brings in high-LTV shoppers?
- What behaviors lead to repeat purchases?
…you quickly outgrow those defaults.
Shopify doesn’t give you cross-channel attribution. It doesn’t offer behavioral segmentation. Its automations are improving, but still live mostly in the shallow end. And if you’re trying to orchestrate campaigns across email, SMS, ads, and maybe even in-store? You’re reaching for more than Shopify offers out of the box.
At that point, tools like Klaviyo, Bloomreach, ZEPIC or Piwik PRO aren’t “nice-to-haves.” They’re gap-fillers. They become necessary because your business has outpaced the basics. That’s a good problem to have. But pretending the basics will keep up forever? That’s how businesses plateau.
### **When it’s time to go beyond… and how to not mess it up**
Adding a martech app should feel like progress, not panic. But I’ve seen merchants rush into five new tools at once, thinking more dashboards equals more insights. What they got instead was duplicated tracking, consent conflicts, and a monthly invoice that looked like a phone book.
If you’re thinking of installing something like Piwik PRO or Bloomreach, start with one clear problem. Maybe it’s attribution. Maybe it’s campaign automation. Maybe it’s understanding your customers beyond just name, email, and last order.
From there, yes → choose the tool. But also plan the setup. Connect it properly. Configure it based on actual business questions. And please: delete the half-working apps you’ve forgotten about. They’re not helping, and they’re definitely slowing your store down.
Lastly, check the permissions. Not all apps play nicely with your data. Reputable vendors will tell you where data lives, how it’s used, and how it can be removed. Others might… not.
### **You’re not failing. You’re evolving.**
Most Shopify merchants aren’t marketers by trade. You’re product people. Founders. Hustlers. That’s why Shopify works so well, because it doesn’t get in your way. But as your customer base grows, the stack that helped you start will start to strain.
The good news is that it is fixable. The better news? You don’t need an enterprise IT team to fix it.
You just need to be clear on what you’re trying to do. Don’t install a CDP because someone said CDP. Install one because you want a better understanding of your customer journey and the native tools aren’t giving it to you.
And if you’re not sure where to start, or what app makes sense, or whether that shiny analytics suite is overkill? That’s what people like me do. Not to sell you software. To keep you from drowning in it.
---
**Connect with me on LinkedIn:**
- Matthew: [https://www.linkedin.com/in/matthewniederberger/](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
**Follow Martech Therapy on:**
- Instagram: [https://www.instagram.com/martechtherapy/](https://www.instagram.com/martechtherapy/?ref=martechtherapy.com)
- Youtube: [https://www.youtube.com/@martechtherapy](https://www.youtube.com/@martechtherapy?ref=martechtherapy.com)
- Bluesky: [https://bsky.app/profile/martechtherapy.bsky.social](https://bsky.app/profile/martechtherapy.bsky.social?ref=martechtherapy.com)
---
Want to read more of my opinions on Martech and how they can help you achieve more? Subscribe for free today 👇🏻
### Agentic AI in Martech: When agents disagree
URL: https://www.martechtherapy.com/agentic-ai-in-martech-when-agents/
Last updated: 2025-10-09T19:47:26.000Z
Picture this scenario: your personalization AI decides that Sarah (Conner? 😅), a loyal customer, should receive a premium upgrade offer because her engagement scores have been climbing. Simultaneously, your churn prevention AI flags Sarah as a retention risk and recommends a discount promotion to keep her engaged. Meanwhile, your email frequency optimization AI determines Sarah is approaching communication fatigue and suggests suppressing all promotional messages for the next week.
Three different systems, three different conclusions, one very confused customer experience.
Thanks for reading Martech Therapy! Subscribe for free to receive new posts and support my work.
This is the multi-agent conflict problem, and I'm convinced it's going to become one of the defining challenges of agentic AI in Martech. When individual systems start making autonomous decisions, conflicts become inevitable. The question becomes: who wins?
## The democracy problem
Traditional marketing automation avoided this issue through hierarchy. You had one system making decisions, or you had clear rules about which system took precedence. Email marketing trumped display advertising. Retention offers override acquisition campaigns. Simple.
Multi Agent Workflows (Source: [LangGraph](https://blog.langchain.dev/langgraph-multi-agent-workflows/?ref=martechtherapy.com))
But agentic systems complicate this hierarchy because they're all optimizing for outcomes, sometimes across different timeframes and different definitions of success. Your personalization AI might optimize for immediate engagement. Your lifetime value AI optimizes for long-term revenue. Your brand sentiment AI optimizes for customer satisfaction.
When these systems disagree, you can't just flip a coin or fall back on "first come, first served." Each agent has reasoning behind its recommendation, often based on patterns the others haven't considered.
## Speed vs. Deliberation
Here's where [the scale problem from Part 1](https://www.martechtherapy.com/agentic-ai-in-martech-the-billion/) resurfaces. These conflicts happen at machine speed across millions of customers simultaneously. You can't exactly call a meeting to hash out whether Sarah should get the upgrade offer or the retention discount.
I've been thinking about this in terms of conflict resolution architectures. Some teams are experimenting with hierarchy-based systems where certain agents get priority in specific scenarios. Others are building consensus mechanisms where agents essentially vote on the best action.
But both approaches feel clunky when you consider that these systems are processing decisions at the 15-200 billion per week scale we discussed earlier. Democracy might work for humans, although the current political climate begs to differ, but it doesn't scale well when participants are making thousands of decisions per second.
## The context coordination challenge
The deeper issue is that each agent operates with its own view of the customer context. Your personalization AI knows about browsing behavior and engagement patterns. Your churn prevention AI focuses on satisfaction scores and support interactions. You catch my drift.
They're all looking at the same customer through different lenses, optimizing for different outcomes, working with different data priorities. In isolation, each agent's recommendation makes perfect sense. The problem emerges when they need to coordinate.
This reminds me of the parable about blind people describing an elephant. Each person touches a different part and comes away with a completely different understanding of what they're dealing with. The trunk feels like a snake, the leg feels like a tree, the ear feels like a fan. They're all correct within their limited context, but none has the complete picture.
## Designing conflict resolution
I believe the most interesting work happening right now involves teams designing conflict resolution protocols that can operate at machine speed while preserving the intelligence of individual agents.
One pattern I've heard about involves creating meta-agents whose job is specifically to arbitrate between other agents. These arbitration systems don't make marketing decisions themselves. They just resolve conflicts between systems that do. Think of them as extremely fast, extremely specialized mediators.
Another approach involves contextual hierarchies that change based on customer state. If someone just submitted a support ticket, the customer satisfaction agent gets priority. If they're in an active purchase cycle, the personalization agent takes precedence. The hierarchy adapts to the situation rather than remaining fixed.
But perhaps the most elegant solution I've encountered is what some teams call "[collaborative optimization](https://medium.com/data-science/a-comprehensive-guide-to-collaborative-ai-agents-in-practice-1f4048947d9c?ref=martechtherapy.com)." Instead of having agents compete for control, they're designed to jointly optimize for combined outcomes. The personalization AI shares its engagement predictions with the churn prevention AI, which factors them into its retention strategies. The frequency optimization AI provides fatigue scores that influence both personalization and retention timing.
## The human arbitration fallback
Of course, there's always the option to escalate conflicts to human decision-makers. But remember our math from Part 1, if your systems are making billions of decisions weekly, human arbitration becomes a bottleneck that defeats the purpose of autonomous systems.
[Building Human-in-the-loop AI agents by Avi Chawla](https://blog.dailydoseofds.com/p/copilotkit-coagents-build-human-in?ref=martechtherapy.com)
Some teams are experimenting with selective escalation, where only conflicts above certain thresholds or involving high-value customers get human review. Others are building learning systems that capture human arbitration decisions and use them to train automatic conflict resolution.
The unexpected benefit of agent conflicts is that they often reveal business logic you didn't know you had. When your personalization AI and your brand consistency AI disagree about message tone, it forces you to clarify what your brand voice actually means in practice.
These conflicts surface assumptions and priorities that were previously implicit. Do you optimize for immediate revenue or long-term satisfaction? Do you prioritize engagement or respect for customer preferences? Do you value personalization or consistency?
Agentic systems make these trade-offs explicit because they force you to design clear conflict resolution rules. In a way, building multi-agent systems becomes an exercise in clarifying your own business philosophy.
## Tomorrow's orchestration
I suspect we're moving toward a future where marketing orchestration looks less like a single conductor leading an orchestra and more like a jazz ensemble where individual musicians improvise within agreed-upon structures. The agents have autonomy to make decisions within their domains, but they're also listening to each other and adapting their actions to create coherent customer experiences.
This requires a different kind of system design. One that emphasizes coordination and communication between agents rather than centralized control. It also requires new kinds of monitoring and debugging tools, because understanding what went wrong becomes much more complex when multiple autonomous systems are involved.
The teams that figure this out first are going to have a significant advantage. But it's going to require rethinking some fundamental assumptions about how marketing technology should work.
Next week… what happens to human roles when AI handles most of the execution? Because if agents are making the decisions and resolving their own conflicts, what exactly are the humans supposed to be doing?
---
*Have you encountered conflicts between different AI systems in your stack? How are you handling coordination between autonomous agents? I'm particularly curious about escalation protocols and where human judgment still feels essential.*
---
Read the Agentic AI in Martech series:
- Part 1: [*The billion decision problem*](https://www.martechtherapy.com/agentic-ai-in-martech-the-billion/)
- Part 2: [*From complicated to complex*](https://www.martechtherapy.com/agentic-ai-in-martech-from-complicated/)
- Part 4: [*The new org chart*](https://www.martechtherapy.com/new-ai-org-chart/)
- Part 5: [*Trust without understanding*](https://www.martechtherapy.com/agentic-ai-in-martech-trust-without/)
- Part 6: [*The Handoff*](https://www.martechtherapy.com/agentic-ai-in-martech-the-handoff/)
---
👥 Connect with me on LinkedIn:
- Matthew: [https://www.linkedin.com/in/matthewniederberger/](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
📲 Follow Martech Therapy on:
- Instagram: [https://www.instagram.com/martechtherapy/](https://www.instagram.com/martechtherapy/?ref=martechtherapy.com)
- Youtube: [https://www.youtube.com/@martechtherapy](https://www.youtube.com/@martechtherapy?ref=martechtherapy.com)
- Bluesky: [https://bsky.app/profile/martechtherapy.bsky.social](https://bsky.app/profile/martechtherapy.bsky.social?ref=martechtherapy.com)
Thanks for reading Martech Therapy! Subscribe for free to receive new posts and support my work.
### The evolution of Omni-Man
URL: https://www.martechtherapy.com/the-evolution-of-omni-man/
Last updated: 2025-10-09T19:47:26.000Z
I finally sat down with Adam Greco for what turned into one of those conversations that explains how we got to this beautiful disaster we call modern martech.
Adam earned the nickname "Omni-Man" back when he was basically Adobe Analytics incarnate, the guy who could fix your broken implementations and somehow make eVars seem less like a cruel joke played on marketers by bored engineers. For years, he was the poster child for mastering one platform completely.
Which makes his current crusade for composable CDPs either beautifully ironic or perfectly logical, depending on whether you've had your coffee yet.
His origin story reads like accidental industry prophecy: customer #5 at Omniture when Web Trends ruled the earth (and told you absolutely nothing useful), hired because he understood their product better than their own employees, which, honestly, explains a lot about early 2000s SaaS. He accidentally discovered his company was being acquired while working at Salesforce, because apparently that's just how Tuesdays went back then.
Now he's at Hightouch making the case for warehouse-centric CDPs with the kind of logic that makes you wonder why anyone thought otherwise: if companies spend millions getting clean data into warehouses for literally every other business function, why do marketers insist on maintaining separate, inferior datasets? It's like insisting on using a flip phone because you've gotten really good at T9 texting.
We covered his theory of "micro composability" (best-of-breed within best-of-breed, because apparently we're not done breaking things apart yet), why data teams have become the unlikely heroes of martech, and his prediction that AI will eventually choose your entire channel strategy. Either brilliant or terrifying, possibly both.
The man has lived through every iteration of our industry's collective learning disabilities and can explain complex martech architectures without making your brain leak out your ears.
Worth your time if you've ever wondered why your martech stack feels like it was assembled during a vendor conference happy hour by consultants who communicate exclusively in acronyms.
### Agentic AI in Martech: From complicated to complex
URL: https://www.martechtherapy.com/agentic-ai-in-martech-from-complicated/
Last updated: 2025-10-09T19:47:26.000Z
Last week I wrote about [the scale problem with agentic AI](https://www.martechtherapy.com/agentic-ai-in-martech-the-billion/), how systems making billions of decisions weekly break traditional governance models. But there's another dimension to this. One that goes beyond just volume.
It's about predictability. Or rather, the slow erosion of it.
> Your Martech stack used to be a Ferrari. Now it's a rainforest.
[Scott Brinker](https://www.linkedin.com/in/sjbrinker/?ref=martechtherapy.com) and [Frans Riemersma](https://www.linkedin.com/in/fransriemersma/?ref=martechtherapy.com) used this metaphor in the [State of Martech 2025 report](https://content.martechday.com/state-of-martech-2025.pdf?ref=martechtherapy.com) to explain how AI is changing martech systems from "complicated" to "complex." They were focused on the technical implications. I want to explore what this means for governance and delegation.
Source: [State of Martech 2025 report](https://content.martechday.com/state-of-martech-2025.pdf?ref=martechtherapy.com)
I realize that sounds like the kind of consultant nonsense that makes people roll their eyes, but the distinction explains why most discussions about AI governance in marketing miss the point entirely.
Let me build on that metaphor Scott and Frans used. A Ferrari is complicated. It has thousands of precisely engineered parts, intricate systems, and complex interactions between components. But it's also deterministic. When something breaks, a skilled mechanic can trace the problem back to its source. The **behavior is predictable** once you understand the engineering.
Most Martech stacks have worked like Ferraris. Complicated? Absolutely. Expensive to maintain? You bet. But fundamentally predictable. When something goes wrong, you can usually figure out why. The campaign didn't send because someone changed a field mapping. Attribution is broken because a JavaScript tag got corrupted. The customer journey failed because a developer updated the API without telling anyone. Debugging these issues can take weeks, but there's a logical path from cause to effect.
A rainforest, on the other hand, has emergent behaviors, pull the wrong branch and you might wake up something you didn't know was there.
## The predictability gradient
I'm convinced there's a predictability gradient that's easy to miss until you're already halfway down it.
At first, the AI feels like sophisticated automation. It optimizes send times based on historical engagement patterns. It personalizes subject lines using customer attributes, and so on, and so on.
All of this feels familiar because you can trace the logic from input to output.
Source: [Marketoonist](https://marketoonist.com/2024/11/ai-generated-homogeneity.html?ref=martechtherapy.com)
Then something subtle happens. The system starts finding patterns you didn't expect. It discovers that customers who engage with emails on Tuesday mornings are more likely to upgrade their accounts, but only if they've visited the pricing page in the last 48 hours, and only if it's not a holiday week. These aren't rules you programmed with your team of experts after a weekend retreat to get together and decide on a growth strategy. They're correlations the system surfaced from data.
But calm down, you're still in Ferrari territory here. Complicated, but explicable.
Then the system starts acting on these discoveries. It begins treating Tuesday-morning-email-engagers differently. It creates micro-segments you never defined. It adjusts timing, frequency, and messaging based on patterns that exist in dimensions you can't easily visualize.
Welcome to the rainforest.
## When systems surprise you
The unsettling part about complex systems is that they optimize for things you didn't explicitly tell them to optimize for. My wife seems pretty adept at this because after 4 years into our relationship, I started cooking every meal. 16 years later, I am still baffled how I ended up as the family chef.
All joking aside, though, a few months ago, I heard about a team whose AI had started suppressing promotional emails to a specific customer segment. When they dug into it, they discovered the system had identified these customers as having higher lifetime value when they received fewer promotional messages.
The AI wasn't following a rule about email frequency. It wasn't even optimizing for email engagement rates. It was optimizing for long-term customer value and had discovered that sometimes less communication leads to more value. The team never programmed that insight. The system learned it by observing outcomes across thousands of customer interactions.
“You tell it the goal. And it agentically figures out the best way to achieve it by combining multiple tactics, whether it’s experimentation, propensity models, reinforcement learning — which kind of ties it all together — even LLMs for some of the reasoning in the wild.”
Tejas Manohar, [Hightouch](https://hightouch.com/?ref=martechtherapy.com) in State of Martech 2025
That's rainforest behavior. The system developed a strategy that humans hadn't considered, based on patterns they couldn't see, optimizing for outcomes across timeframes they weren't tracking.
## The emergence problem
What makes this challenging is that emergent behaviors are actually the point. The whole purpose of agentic AI is discovering strategies and optimizations that humans miss. But emergence, by definition, can't be predicted from the individual components.
You can understand every piece of your customer data platform, every rule in your orchestration engine, and every model in your machine learning pipeline, and still be surprised by what the combined system does when it starts learning and adapting autonomously.
This is where most governance frameworks break down. They're designed for complicated systems where you can trace causation from decision to outcome. They assume that understanding the parts means understanding the whole. In complex systems, that assumption collapses.
## Learning to think in systems
I've been experimenting with a different approach to understanding these systems. One that focuses on patterns rather than individual decisions. Instead of asking "*Why did the AI send this specific email to this specific customer?*" I'm learning to ask "*What patterns is the system optimizing for, and are those patterns aligned with our goals?*"
This requires a different kind of monitoring. Traditional dashboards show you what happened in the form of open rates, click-through rates, conversion rates. But in complex systems, you need dashboards that show you how the system is thinking and report on what patterns it's detecting, what correlations it's acting on, what new strategies it's developing.
Some teams are starting to build what I think of as "intention dashboards". Interfaces that surface the AI's current hypotheses about what works and why. Or at least, they better be, because traditional dashboards quickly become useless when systems start making decisions based on patterns you can't see. These don't show you individual decisions, but they show you the system's evolving understanding of your customers and your business.
## Designing for emergence
The more I think about this, the more I suspect that working with agentic AI requires a fundamental design philosophy change, if not an organizational one, too. Instead of trying to control every decision, you focus on setting good boundaries and creating feedback loops that help the system learn the right things.
It's less like programming a computer and more like training a very fast, very focused, very caffeinated team member who never forgets anything and can process information at inhuman scales.
You can't tell them exactly how to do their job, but you can be clear about what success looks like. You can provide them with good data and good tools. You can create systems that help them learn from mistakes and build on successes. And you can design feedback mechanisms that keep their learning aligned with your goals.
Almost sounds human, doesn’t it?
But you have to accept that they're going to surprise you. The question becomes whether those surprises move you toward your objectives or away from them.
## The Ferrari mindset trap
The hardest part about this transition might be [letting go of the Ferrari mindset](https://open.substack.com/pub/martechtherapy/p/letting-go-of-control?r=3i8xzy&utm%5Fcampaign=post&utm%5Fmedium=web&showWelcomeOnShare=false). There's something deeply satisfying about understanding exactly how your marketing systems work. There's comfort in being able to trace every customer interaction back to a specific rule or decision tree.
But that comfort might be holding us back from leveraging the real power of agentic systems. The most interesting capabilities emerge when you give the AI enough autonomy to discover patterns and strategies that humans miss.
I'm still trying to understand how to balance that autonomy with accountability. But I suspect the answer lies in designing better boundaries and feedback mechanisms from the start.
Which brings me to next week’s topic. What happens when you have multiple agentic systems making autonomous decisions about the same customer? Because if individual AI agents can surprise you, wait until they start disagreeing with each other.
---
*Are you seeing emergent behaviors in your Martech stack? How are you balancing AI autonomy with the need for predictable outcomes? I'm curious about what patterns others are discovering as these systems get more sophisticated.*
---
Read the Agentic AI in Martech series:
- Part 1: [*The billion decision problem*](https://www.martechtherapy.com/agentic-ai-in-martech-the-billion/)
- Part 3: [*When agents disagree*](https://www.martechtherapy.com/agentic-ai-in-martech-when-agents/)
- Part 4: [*The new org chart*](https://www.martechtherapy.com/new-ai-org-chart/)
- Part 5: [*Trust without understanding*](https://www.martechtherapy.com/agentic-ai-in-martech-trust-without/)
- Part 6: [*The Handoff*](https://www.martechtherapy.com/agentic-ai-in-martech-the-handoff/)
---
👥 Connect with me on LinkedIn:
- Matthew: [https://www.linkedin.com/in/matthewniederberger/](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
📲 Follow Martech Therapy on:
- Instagram: [https://www.instagram.com/martechtherapy/](https://www.instagram.com/martechtherapy/?ref=martechtherapy.com)
- Youtube: [https://www.youtube.com/@martechtherapy](https://www.youtube.com/@martechtherapy?ref=martechtherapy.com)
- Bluesky: [https://bsky.app/profile/martechtherapy.bsky.social](https://bsky.app/profile/martechtherapy.bsky.social?ref=martechtherapy.com)
Or **subscribe here for free** today and get notified when I publish part 3 👇🏻
### Data is boring. And by extension, CDPs are kind of boring too
URL: https://www.martechtherapy.com/data-is-boring-and-by-extension-cdps-are-boring-too/
Last updated: 2025-10-09T19:47:27.000Z
[CDP Institute](https://www.cdpinstitute.org/?ref=martechtherapy.com)’s David Raab coined the term *Customer Data Platform,* which makes him either the godfather of modern Martech or the guy responsible for every PowerPoint slide with a data unification triangle on it. Possibly both.
In this episode of *Couch Confidentials*, we talk about the slow death of [CDP hype](https://www.martechtherapy.com/why-im-rebooting-the-cdp-conversation/), why AI is just a mirror for your data mess, and why companies keep renaming “data plumbing” as “activation” in hopes it’ll feel more important.
We also cover how vendors are racing to [bolt AI onto every surface](https://www.martechtherapy.com/understanding-mcps-a-cdp-insiders/) like it’s a startup-themed version of Iron Man, why investing in data quality is like flossing (nobody’s excited, but it still matters), and how even David can’t explain his job at dinner parties without giving up halfway through.
If you work in Martech and occasionally wonder *“Why is everything still so hard?”* grab a coffee, sit, and listen. You are not alone. And if you are feeling bold, forward it to your boss, your privacy officer, or your cousin who thinks CDPs are just glorified CRMs.
---
👥 Connect with us on LinkedIn:
- David: [https://www.linkedin.com/in/david-raab-22146b/](https://www.linkedin.com/in/david-raab-22146b/?ref=martechtherapy.com)
- Matthew: [https://www.linkedin.com/in/matthewniederberger/](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
📲 Follow Martech Therapy on:
- Instagram: [https://www.instagram.com/martechtherapy/](https://www.instagram.com/martechtherapy/?ref=martechtherapy.com)
- Youtube: [https://www.youtube.com/@martechtherapy](https://www.youtube.com/@martechtherapy?ref=martechtherapy.com)
- Bluesky: [https://bsky.app/profile/martechtherapy.bsky.social](https://bsky.app/profile/martechtherapy.bsky.social?ref=martechtherapy.com)
Don’t miss my next podcast with the infamous **Adam Greco** 👇🏻
### Agentic AI in Martech: The billion decision problem
URL: https://www.martechtherapy.com/agentic-ai-in-martech-the-billion/
Last updated: 2025-10-09T19:47:28.000Z
I've been having a strange, recurring thought lately. It started after [my conversation with Paul from Aampe](https://www.martechtherapy.com/agentic-ai-and-the-art-of-letting/), when he mentioned their AI agents handle somewhere between 15 and 200 billion decisions every week.
I love astronomy and the awe-inducing scale of the universe. Nevertheless, that number still amazed me, probably because I couldn't quite wrap my head around it. So I did what any reasonable person would do. I grabbed a calculator and started doing some deeply unnecessary math.
Let's say you're a marketing ops manager making about 50 meaningful decisions per day. Which segment gets the email blast, what time to send it, which creative variant to test, and whether to suppress that angry customer from the promotion. Fifty decisions feels reasonable, maybe even conservative.
At that pace, you'd make roughly 18,000 decisions per year. To match what Aampe's systems do in a single week, let's use the conservative 15 billion figure. You'd need about 833,000 years. If we go with their upper range of 200 billion weekly decisions, you're looking at 11 million years of human decision-making compressed into seven days.
For context, 11 million years ago, our ancestors were still figuring out how to walk upright.
Carl Sagan, the first person to make me feel small in our universe. Is AI doing it again?
This feels like more than a productivity improvement. This feels like crossing some kind of threshold, a [black hole’s event horizon](https://en.wikipedia.org/wiki/Event%5Fhorizon?ref=martechtherapy.com), if we’re sticking to the astronomy analogy, where the old rules stop applying entirely.
Which got me thinking about what happens when we reach that threshold. Over the next few posts, I aim to explore how marketing teams are actually working with, or considering working with, agentic AI systems. Not just vendor demos or conference presentations, but the seriously messy reality of designing around systems that operate at scales we can't directly observe. I'm genuinely curious about this space (*pun intended*), and I suspect I'm going to learn as much from writing about it as anyone learns from reading it.
## When volume breaks everything
I've also been thinking about this in the context of Paul's subway map metaphor. He described how traditional marketing automation works like the New York subway map → simplified, predictable, designed by experts who compressed complex reality into something humans could navigate. You can look at that map and trace exactly how you'll get from Brooklyn to the Bronx.
The London Underground map, from simplified to a realistic. (Source: [Reddit](https://www.reddit.com/r/dataisbeautiful/comments/b8ihhr/comparison%5Fbetween%5Fthe%5Flondon%5Ftube%5Fmap%5Fand%5Fits/?ref=martechtherapy.com))
But what happens when your system is making billions of routing decisions every week, each one slightly different based on real-time context that changes faster than any human could track?
You end up with something more like Google Maps during rush hour in a thunderstorm. The system considers traffic patterns, weather conditions, construction updates, and probably a dozen other factors you might never think to include, such as someone’s preferred route or an extra stop for an unexpected errand. It's making constant micro-adjustments based on information streams that would overwhelm any human trying to follow along.
The difference is that with Google Maps, you can still see the route it's taking. With agentic AI in Martech, you're often flying blind at 30,000 feet while the system handles everything below the clouds.
## The governance illusion
Here's what's been bothering me about most conversations around AI governance in marketing. Sorry, I just need to vent some steam. Bear with me. We need to really look beyond the fanfare and overnight self-proclaimed AI gurus, I won’t name names. We're still designing oversight frameworks as if humans can meaningfully monitor these systems. Board presentations still include slides about "human in the loop" controls and approval workflows.
But how exactly do you audit 15 billion decisions? Even if you could review one decision per second, working 24 hours a day with no breaks, you'd need about 475 years to get through a single week's worth of choices. And by then, the system would have made roughly 2.4 trillion more decisions while you weren't watching. I mean, come on… 🤯
This mathematical reality suggests we might need to rethink what governance means when systems operate at these scales. Traditional approval processes become impractical. Audit trails become overwhelming. The very concept of human oversight starts to bump against basic math.
## Beyond human comprehension
What strikes me most about this scale problem is how [it challenges basic assumptions about control and responsibility](https://www.martechtherapy.com/letting-go-of-control/). If your agentic AI is optimizing customer journeys based on real-time sentiment analysis, behavioral pattern recognition, and contextual signals across dozens of touchpoints, the resulting decisions exist in a space that's beyond human intuition.
A marketing manager might understand why they chose to send an email at 14:00 (or 2 PM for my US readers) on Tuesday. But how do you understand a system that's simultaneously optimizing send times for millions of individual customers based on their personal engagement patterns, current emotional state, recent purchase behavior, and predicted life events?
You can't. And maybe that's the point.
How a game of tic-tac-toe, Dr. Falken (Source: Wargames)
According to Paul, agentic systems don't just execute plans; **they develop their own strategies** (*hence my reference to the movie Wargames above, tic-toc-toe FTW 🎉*). They learn what works and adjust their approach accordingly. In some ways, they're less like tools and more like extremely fast, extremely focused employees who never sleep and never forget anything.
Except these employees are making decisions at a volume that exceeds human comprehension, using context that changes faster than human analysis, optimizing for outcomes across timeframes that span microseconds to months.
## The uncomfortable questions
This scale reality forces some uncomfortable questions that I'm still working through. Are you ready? It’s time for “Who wants to be a Martech-millionaire?” 👇🏻
- If your AI makes 200 billion decisions while you make 250, who's really running your marketing operation?
- When systems adapt their strategies faster than humans can evaluate them, what does accountability even mean?
- How do you take responsibility for outcomes you literally cannot track back to specific decisions?
I don't have answers to these questions yet. I am not exactly the Nostradamus of Martech. However, I suspect they're the right questions to ask as more teams experiment with agentic systems.
The Martech industry loves to talk about AI as an enhancement to human capabilities. But when you dig into the actual numbers, it starts looking less like enhancement and more like a fundamentally different approach to marketing operations.
I'm starting to think the interesting question might not be how to control these systems, but **how to work with them**. That requires rethinking some basic assumptions about oversight, delegation, and what collaboration looks like when your AI partner operates at inhuman scales.
I'm still figuring out what that looks like in practice. But I'm pretty sure it starts with accepting that some problems are too big for human-scale solutions.
And 200 billion weekly decisions definitely qualifies as too big.
---
*What's your experience with high-volume AI decision-making? Are you seeing similar scale challenges in your Martech stack? I'm curious whether other teams are grappling with these governance questions or if I'm overthinking the math.*
---
Read the Agentic AI in Martech series:
- Part 2: [*From complicated to complex*](https://www.martechtherapy.com/agentic-ai-in-martech-from-complicated/)
- Part 3: [*When agents disagree*](https://www.martechtherapy.com/agentic-ai-in-martech-when-agents/)
- Part 4: [*The new org chart*](https://www.martechtherapy.com/new-ai-org-chart/)
- Part 5: [*Trust without understanding*](https://www.martechtherapy.com/agentic-ai-in-martech-trust-without/)
- Part 6: [*The Handoff*](https://www.martechtherapy.com/agentic-ai-in-martech-the-handoff/)
---
👥 Connect with me on LinkedIn:
- Matthew: [https://www.linkedin.com/in/matthewniederberger/](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
📲 Follow Martech Therapy on:
- Instagram: [https://www.instagram.com/martechtherapy/](https://www.instagram.com/martechtherapy/?ref=martechtherapy.com)
- Youtube: [https://www.youtube.com/@martechtherapy](https://www.youtube.com/@martechtherapy?ref=martechtherapy.com)
- Bluesky: [https://bsky.app/profile/martechtherapy.bsky.social](https://bsky.app/profile/martechtherapy.bsky.social?ref=martechtherapy.com)
Or **subscribe here for free** today and get notified when I publish part 2 👇🏻
### Contextual CDPs: Contextual Fluency
URL: https://www.martechtherapy.com/contextual-cdps-contextual-fluency/
Last updated: 2025-10-16T15:12:50.000Z
Over the last five posts, we’ve moved from speculative to strategic to practical. We’ve looked at how memory, inference, and model context protocols can enhance personalization, orchestration, governance, and architecture in and around the CDP. So, where does that leave us?
Right here.. yes, with the last post in the series, but more importantly, with the people, with YOU!
Because it’s one thing to build a system that *can* understand context. It’s another thing entirely to make that understanding usable across your organization. That’s what this final piece is about, turning contextual awareness into team capability.
## Context fluency is a human skill
We often talk about customer context as if it’s a tech layer. And in some ways, it is. But context only becomes valuable when someone uses it to shape a decision.
This is why contextual fluency, the ability to read, interpret, and apply dynamic customer signals, is just as critical as the tooling itself. And it’s surprisingly rare.
A parody of course, but ****context fluency** is not a joke.
You can give a team the world’s best memory layer, but if no one knows how to work with its output, it doesn’t improve the customer experience. If the orchestration logic surfaces a new intent indicator, but that indicator is ignored in favor of “the usual” flow, the value disappears.
The nightmares called “Digital Transformation”, anyone?
Which is why your rollout plan shouldn’t stop at data engineering or AI model integration. It should keep going, into training, collaboration, process redesign.
And not just for operational teams. Senior leadership needs to understand what it means to manage context over time. Strategy depends on continuity. Without shared understanding of how context changes, executive planning quickly falls back into static segmentation and campaign-centric thinking.
## Make context a first-class citizen in decisions
When you look at your current marketing, support, or product flows, where is context being used well? And where is it being bypassed?
Some systems only use context at the surface level, say, to personalize a subject line or tweak a greeting. That’s not a bad start. But it misses the point. The real opportunity is deeper: in shaping logic, timing, modality, tone.
Source: [Marketoonist](https://marketoonist.com/2022/03/artificial-intelligence.html?ref=martechtherapy.com)
Imagine a retention playbook where outreach timing isn’t based on subscription age, but on behavioral momentum. Or a support follow-up that adapts not just to resolution outcome, but to *how* the customer felt about the interaction.
To build this kind of responsiveness, your teams need to know where context is coming from, how fresh it is, and what signals it reflects. They don’t need to be data scientists. But they do need to be conversant in the language of signals and shifts.
This often involves knowing when context should *not* be used. Just because we can detect sentiment or predict churn doesn’t mean we should act on it immediately. Teaching teams when to hold back is just as important as teaching them when to act.
## Build shared awareness, not just dashboards
Too often, teams build context into systems but forget to build it into their communication. The AI layer gets smarter, while the human layer stays in catch-up mode.
Avoid this trap by embedding context into your rituals. Add a “what’s changing?” check-in to your campaign planning. Include inferred signals in your customer journey reviews. Encourage teams to annotate customer context when they spot gaps or contradictions.
This doesn’t require massive retraining. It just requires an expectation that context is part of the conversation. That expectation, reinforced by clear examples, can shift how teams think and collaborate.
When one team improves a memory model or identifies a new intent signal it’s a cross-functional asset and a win. Share it accordingly.
And share the blind spots, too. The places where context is stale, conflicting, or misleading. Building a culture where gaps in context are openly acknowledged creates stronger feedback loops and fewer false positives.
## End with intent
This series started with a hypothesis → that most CDPs aren’t limited by the data they collect, but by the context they can apply.
What we’ve uncovered together is that model context protocols offer a way forward, technically, yes, but also strategically and organizationally. They give us tools to build CDPs that don’t just store information, but understand it in the moment. They help us get closer to that ideal of a system that remembers what matters, adapts as it learns, and communicates transparently.
But context is not magic. It’s not something you buy, plug in, and walk away from. It’s something you build, cultivate, and distribute.
If you want a customer experience that feels intelligent, human, and coherent, you need a system that’s context-aware and a team that’s context-fluent.
Start there. Then keep listening.
The signs are already speaking. Your people just need to be ready to hear them.
- Part 1: [*Contextual CDPs, is this the next-gen?*](https://www.martechtherapy.com/understanding-mcps-a-cdp-insiders/)
- Part 2: [*Memory, not identity, is what makes context work*](https://www.martechtherapy.com/contextual-cdps-memory-is-what-makes-context-work/)
- Part 3: [*Trust as a feature*](https://www.martechtherapy.com/trust-as-a-feature/)
- Part 4: [*Building the bridge*](https://www.martechtherapy.com/contextual-cdps-building-the-bridge/)
- Part 5:[ ](https://www.martechtherapy.com/contextual-cdps-composable-not-chaotic/)[*Composable, not chaotic*](https://www.martechtherapy.com/contextual-cdps-composable-not-chaotic/)
Thanks for reading this series! Subscribe for free to receive notifications on the new Martech series that I am working on.
## Sign up for Martech Therapy
Thoughts, stories and ideas.
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
### The trophy analyst, the hippo CMO, and the myth of “just one more tool”
URL: https://www.martechtherapy.com/the-trophy-analyst-the-hippo-cmo/
Last updated: 2025-10-09T19:47:29.000Z
Some conversations catch you off guard in the best possible way. This one with Steen did exactly that.
We were meant to talk about analytics, why it still doesn’t deliver on its promise, despite all the new tools and fancy dashboards. And we did. But what surprised me was how personal it got. Not emotional, but honest in a way that made me uncomfortable in a good way. The kind of uncomfortable that makes you realize how often we’re just going through the motions, pretending things are working because admitting otherwise might mean admitting we don’t really know what to do next.
Steen has this way of naming the things you’ve always felt but never quite said out loud. About how we hire analysts like trophies, how we switch platforms like changing outfits, and how most of us are too busy maintaining broken systems to even think about value. And maybe the most brutal part was how often we choose a new tool just so we don’t have to admit the last one never worked.
This isn’t a neat little “here’s what we learned” episode. It’s a mirror into your organization, something I have spoken about in my [CDP Reboot](https://www.martechtherapy.com/why-im-rebooting-the-cdp-conversation/) series (technology has a funny way of exposing these weaknesses). And depending on where you are right now, you might not like the reflection. I didn’t always. But I’m glad we recorded it. It reminded me that analytics isn’t broken because the tech is bad. It’s broken because we keep pretending it’s someone else’s job to make it useful.
So yeah, this one stayed with me. Maybe it’ll stay with you too.
---
👥 Connect with us on LinkedIn:
- Steen: [https://www.linkedin.com/in/steenrasmussen/](https://www.linkedin.com/in/steenrasmussen/?ref=martechtherapy.com)
- Matthew: [https://www.linkedin.com/in/matthewniederberger/](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
📲 Follow Martech Therapy on:
- Instagram: [https://www.instagram.com/martechtherapy/](https://www.instagram.com/martechtherapy/?ref=martechtherapy.com)
- Youtube: [https://www.youtube.com/@martechtherapy](https://www.youtube.com/@martechtherapy?ref=martechtherapy.com)
- Bluesky: [https://bsky.app/profile/martechtherapy.bsky.social](https://bsky.app/profile/martechtherapy.bsky.social?ref=martechtherapy.com)
Don’t want to miss the next conversation? Subscribe, it’s free 👇🏻
### Letting go of control
URL: https://www.martechtherapy.com/letting-go-of-control/
Last updated: 2025-10-09T19:47:30.000Z
I used to think I understood AI agents. In Martech, we talk about them all the time. Tools that take action based on data, automate tasks, score leads, and optimize send times. That’s what we call an agent, right? A helpful script or model that executes a narrow task faster or more accurately than humans can.
Then I had a conversation with [Aampe](https://aampe.com/?ref=martechtherapy.com)’s CEO [Paul Meinshausen](https://www.linkedin.com/in/paulmeinshausen/?ref=martechtherapy.com) on [my podcast Couch Confidentials](https://martechtherapy.substack.com/podcast), and something clicked. Paul introduced a distinction I hadn’t fully grasped. An AI agent follows instructions. Agentic AI operates with goals, persistence, and the ability to revise its own strategies. That revelation made me realize I’d been clinging to something familiar that would be critical to move further: control.
Most marketers are comfortable with automation. We accept AI that assists, even when we don’t fully understand its inner workings. But **agentic AI makes decisions**. It changes tactics. It remembers what it’s done and adjusts accordingly. That goes beyond tooling. It introduces a kind of relationship. And that’s where it gets uncomfortable.
Paul reframed the issue for me. This is no longer about technical feasibility. Surprise, surprise, **it is about leadership**. Are we prepared to delegate meaningful decisions to AI systems? Can we trust something to act even when we’re not watching every move?
To understand why this change in perspective feels so significant, at least to me, it helps to ask what makes agentic AI different under the hood. Traditional AI agents are optimized to execute predefined actions based on a limited set of conditions. They don’t learn across sessions or revise their approach unless a human retrains the model.
Agentic AI, on the other hand, builds upon architectural elements such as memory, multi-step planning, and sometimes reinforcement learning. These features allow it to do things like pursue open-ended goals. Evaluate outcomes over time and then adjust strategies based on performance.
Simple chatbot examples: AI Agents vs Agentic AI
In short, it reasons, not like a person, but like a system designed to operate persistently across continuously changing contexts. And reasoning is what makes it feel risky. We’re no longer dealing with a tool that does what it’s told. We’re working with something that may choose *how* to help.
This is where the fear creeps in. Not because the AI will fail, but because it might succeed, in ways we didn’t predict or control.
A good analogy, other than the above displayed chatbot example, came to me while driving in my relatively modern electric vehicle. A GPS gives directions, will update based on traffic, and the car’s software can keep you in your lane and keep a safe distance from other cars, but you’re still in control. If you don’t take the exit, you have a problem. The car won’t correct your error. Of course, you can ignore it, disable driving assistance, take a detour, or stop for coffee. That’s an AI agent. But a self-driving car? That’s agentic AI. It doesn’t just advise, its purpose is to act. And trusting it to get you there safely means giving up the wheel, at least partially. That’s where most of us hesitate, especially when it comes to our business.
That anxiety is familiar to anyone who’s built a team. Early on, founders do everything themselves. Messaging, pricing, outreach, operations. Control is tight because there’s no other choice. But as the company grows, control becomes a liability. You have to delegate. You have to let people own decisions. You have to trust the team to deliver on outcomes you care about, even if they approach the problem differently.
Agentic AI asks us to revisit that same leadership question:
> “What are we willing to let go of in order to scale what we care about?”
In Martech, this question is already surfacing. Some systems adapt campaigns based on intent signals. Others reshape customer journeys without anyone manually triggering those changes. These systems are showing the early traits of agency. They aren’t just reactive. They’re persistent, context-aware, and increasingly able to handle ambiguity.
This doesn’t mean handing over control entirely. It means establishing clear parameters and then allowing systems to operate within them. The role shifts from micromanager to designer. We build the framework and let the AI navigate within it.
The most significant change we need to address is cultural. Our current Martech systems are built around explicit instructions. But if we want to work with more autonomous AI, we need to embrace a new mindset. One that values outcomes over rigid control.
“What might that look like?”, I hear you asking. To help get you started, consider these three steps:
- Define the scope of decisions we’re comfortable outsourcing
- Create evaluation methods that assess judgment, not just output
- Think less about control and more about cooperation
That change won’t come easily, and I expect resistance from leaders worried about their positions. But it’s necessary if we want AI to move from utility to partnership in the real world and stop hiding behind hypotheses.
If you’ve found yourself unsure about what separates agents from truly agentic systems, you’re not alone. I was in the same place until I asked a better question. Not what this AI can do, but what I’m willing to let go of.
Would you like to receive more opinion pieces on Martech? Make sure to sign-up 👇🏻
### Contextual CDPs: Composable, not chaotic
URL: https://www.martechtherapy.com/contextual-cdps-composable-not-chaotic/
Last updated: 2025-10-16T15:12:00.000Z
By now, we’ve explored what context can unlock in a CDP, from dynamic profiling to real-time orchestration and trust. We’ve talked about layering memory and inference without blowing up your current stack. So in this fifth part, let’s look at what happens when you want to make these contextual layers stick… *without making everything feel like a pile of duct-taped services.*
Because that’s the risk. Composability gives us incredible flexibility, but without some architectural discipline, it becomes hard to explain, harder to maintain, and impossible to govern.
Let’s explore how to structure context-aware systems in ways that are powerful, portable, and above all, comprehensible.
## The overlay, not the overhaul
One of the smartest decisions a team can make early on is to treat contextual intelligence as an overlay, not a core rewrite. Your CDP, CRM, or warehouse continues doing what it does best 👉🏻 storing, syncing, and distributing customer data. What you add are services that make that data *situationally relevant*.
These services might live in a middle layer, close to decision engines or channel orchestration tools. Or they may be situated in the infrastructure itself [as Databricks has shown us with their Data Intelligence for Marketing](https://www.martechtherapy.com/if-the-warehouse-can-think-whats/). Or they may run alongside UX components such as support dashboards, analytics views, and journey builders while offering real-time summaries or memory-derived nudges.
Source: [Databricks](https://www.databricks.com/solutions/industries/marketing?ref=martechtherapy.com)
The key is separation of roles. You want your core data systems to stay stable. You want your context layers to be modular, easy to test, and able to evolve as the use cases do.
## Don’t just stack… Sequence
Composable architectures can turn into sprawl if each tool works in isolation, but that defies the purpose of the core composable principle. What’s missing in most setups isn’t another connector (*every vendor offers 200+ of these, according to most websites); it’s the choreography to make it flow in a way that keeps it* relevant and valuable.
Contextual systems can be sequenced into existing flows.
Contextual systems work best when they follow a deliberate sequence. First retrieve context, then resolve identity, then score intent or emotional state, then pass a recommendation into the execution layer.
This doesn’t need to be linear or hardcoded. But if there’s no shared flow, the AI that personalizes a push notification could be operating on a different memory set than the one triaging a support ticket. And that’s how customer trust gets chipped away, slowly, and often invisibly.
Using multiple memories for context for the same user brings risks.
So the architecture needs a way to carry context forward, not just from database to tool, but from tool to tool, moment to moment. We should be acting surprised here, we have been trying to break down silos for decades. Will AI finally get it done?
## Context coordination roles
This is the part we talk about less: the team practices that go with contextual systems. Someone needs to be thinking not just about data models or message timing, but about **context handoff**.
For example, does your personalization team know what your support team just inferred about a customer’s frustration level? If not, why not? Where should that knowledge live? How should it be framed, as structured tags, maybe natural language notes, or something else entirely?
These are coordination questions that extend beyond architecture. The most effective answers often come from roles that combine product intuition with data fluency. You don't necessarily need to create new departments. What you need are people who can connect the dots. Ambassadors anyone?
## The Audit-friendly stack
The more inference and memory you introduce, the more you’ll need transparency. Not because something will go wrong, but because sooner or later, someone will ask:
> *Why did the system do that?*
That means your architecture should support narrative debugging. Logs that don’t just show inputs and outputs, but decision paths. Context snapshots. Memory traces.
Many teams are already capturing this implicitly through prompt history or vector search metadata. The next step is making it navigable for both humans and compliance.
When composable systems can explain themselves, they earn the right to keep growing.
## Wrapping up (and looking outward)
If you’ve read this far, you probably don’t need convincing that context matters. You want to know what it takes to do it responsibly, without overcomplicating your stack.
The truth is, most organizations are closer than they think. They already have the signals, the decision points, the customer feedback. What’s missing is a way to link it all 👉🏻 cleanly, repeatably, and transparently.
In the final post, I’ll explore what it might look like to design for *contextual fluency* across teams, tools, and customer touchpoints. Because building smarter infrastructure is only half the story. The other half is making it usable by the people who turn context into action. People like yourself.
More on that soon.
- Part 1: [*Contextual CDPs, is this the next-gen?*](https://www.martechtherapy.com/understanding-mcps-a-cdp-insiders/)
- Part 2: [*Memory, not identity, is what makes context work*](https://www.martechtherapy.com/contextual-cdps-memory-is-what-makes-context-work/)
- Part 3: [*Trust as a feature*](https://www.martechtherapy.com/trust-as-a-feature/)
- Part 4: [*Building the bridge*](https://www.martechtherapy.com/contextual-cdps-building-the-bridge/)
- Part 6: [*Contextual Fluency*](https://www.martechtherapy.com/contextual-cdps-contextual-fluency/)
Want to get notified when I publish the **final part in this series**? Subscribe today 👇🏻
## Sign up for Martech Therapy
Thoughts, stories and ideas.
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
### Agentic AI & the art of letting go
URL: https://www.martechtherapy.com/agentic-ai-and-the-art-of-letting/
Last updated: 2025-12-02T07:30:45.000Z
Paul suggested the idea of doing something different. No intro. No big kickoff. Just two people talking.
That’s how this episode with [**Paul Meinshausen**](https://www.linkedin.com/feed/?ref=martechtherapy.com) (CEO at [**Aampe**](https://www.linkedin.com/feed/?ref=martechtherapy.com)) started and I’m glad it did. Because I fumbled at the beginning (you can skip ahead in the podcast...).
Feeling like a one-trick pony, I tried to steer the conversation toward my usual topics: CDPs, AI, use cases, and organizational challenges. But it quickly became clear I was trying to force an idea, a vision, onto something I hadn’t fully wrapped my head around yet. Paul helped me take a step back. Not to simplify, because there is a lot to this, but to rethink.
Unlike what we often do when considering new technology, use cases are not the primary consideration we should make when considering agentic AI. Paul argued that it is control, and how so many leaders fear giving it up when adopting AI. But maybe that’s the wrong lens through which leaders view the world of opportunities.
With agentic AI, it’s not about losing control. It’s about setting the principles and boundaries, and then letting the system operate within them. In the same way that leadership evolves as companies grow. You don’t micromanage every action, you shape the environment.
Honestly, this was one of those moments where I felt more like a student than a host. And I’m okay with that. We’re all learning. We should be learning.
So here’s an official, yet unpolished, deeply valuable episode, one I almost didn’t want to share, but really glad I did. We are all in this together.
A big thank you to Paul for explaining the challenges and opportunities from his perspective, as well as for the time, generosity, and space to think out loud.
👥 Connect with us on LinkedIn:
- Paul: [https://www.linkedin.com/in/paulmeinshausen/](https://www.linkedin.com/in/paulmeinshausen/?ref=martechtherapy.com)
- Matthew: [https://www.linkedin.com/in/matthewniederberger/](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
📲 Follow Martech Therapy on:
- Instagram: [https://www.instagram.com/martechtherapy/](https://www.instagram.com/martechtherapy/?ref=martechtherapy.com)
- Youtube: [https://www.youtube.com/@martechtherapy](https://www.youtube.com/@martechtherapy?ref=martechtherapy.com)
- Bluesky: [https://bsky.app/profile/martechtherapy.bsky.social](https://bsky.app/profile/martechtherapy.bsky.social?ref=martechtherapy.com)
Feel like getting notified when a new episode drops? Subscribe today 👇🏻
## Sign up for Martech Therapy
Thoughts, stories and ideas.
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
### If the warehouse can think, what’s left for the CDP?
URL: https://www.martechtherapy.com/if-the-warehouse-can-think-whats/
Last updated: 2025-10-09T19:47:32.000Z
Nope, this isn’t an analysis of a press release. We’ve seen all Databricks partners do that generously all over LinkedIn. It’s a reflection, a personal one (I had some spare time over the weekend), on something that’s been building quietly in the background and what it means now that someone has taken a concrete step forward. That someone is **Databricks**.
Last week, Databricks launched something called [*Data Intelligence for Marketing*](https://www.databricks.com/company/newsroom/press-releases/databricks-unveils-data-intelligence-marketing?ref=martechtherapy.com). And sure, you could skim the headline and file it under “AI feature drop.” But that’s not what caught my attention.
What stood out was where the intelligence lives. Not in a standalone product. Not in a middleware layer. But deep in the warehouse, close to the data, fused with the infrastructure.
For anyone building around CDPs, it means that it is time to pay attention.
Let me walk you through why.
Composable CDPs offer incredible freedom. But freedom has a cost. These stacks often rely on a distributed memory. Data here, identity there, orchestration somewhere else. Intelligence floats above it all, hoping everything syncs on time.
In my [*Contextual CDP*](https://www.martechtherapy.com/understanding-mcps-a-cdp-insiders/)[ series](https://www.martechtherapy.com/understanding-mcps-a-cdp-insiders/), I’ve argued that composability without context leads to superficial decisioning. And nothing robs context faster than latency and fragmentation. You can quote me on this.
Which brings me to Keanu Taylor’s *Data Gravity*. In [Essay 200 of The Martech Weekly](https://themartechweekly.com/data-gravity/?ref=martechtherapy.com) (subscription required, but definitely worth it), he framed it perfectly:
> Data doesn’t want to move. Apps, services, and intelligence migrate toward the warehouse.
This isn’t a futuristic idea. It’s already reshaping the Martech ecosystem, I mean it is one of the core drivers of composable to begin with. Warehouses like Snowflake and Databricks are creating marketplaces, embedded logic, and native app ecosystems designed to pull intelligence inward. You know, like a black hole.
So what happens to the CDP when the intelligence no longer lives at the edges?
I don’t think this ends with CDPs disappearing into the void, although past mergers and acquisitions do tend to make you think that. And, well, the category is sure on the brink of slipping into a black hole. Good thing the technology is solid. But it does change their posture. They become delivery layers, not decision layers. Surfaces, not systems of record. And that reframes what we should expect from them.
Databricks didn’t announce a CDP, and perhaps rightfully so, given their partner ecosystem. Although they do have an interesting job opening on their site. I am thinking that the goal is to convince more companies to move to a composable CDP solution, most likely (I was unable to verify this) through partners.
[See this unique job opening](https://www.databricks.com/company/careers/marketing/principal-industry--solutions-marketing-manager-cdp-7932277002?ref=martechtherapy.com)
Moving on, Databricks showed what happens when you remove the need for one to think externally. And for those of us working in Martech strategy, implementation, and architecture, that creates a question worth asking:
> If the warehouse becomes the engine for decision-making and data unification, where does that leave CDPs in terms of identity, activation, and all the rest?
I explore this in more detail in the previously released video [**Did Databricks just make CDPs smarter?**](https://youtu.be/ODFrFqG4yWY?ref=martechtherapy.com)However, I wanted to use this space to open the door a bit wider for responses and hopefully for conversation.
If someone from Databricks wants to join me on the podcast, I’m ready.
And if you’re building Martech infrastructure, I’d love to hear how you’re thinking about this next layer.
Until then, keep building with intent.
[Connect with me on LinkedIn](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com) if you want to talk further about this.
📲 Follow Martech Therapy on:
- **Instagram**: https://www.instagram.com/martechtherapy/
- **Youtube**: https://youtube.com/@martechtherapy
- **Bluesky**: https://bsky.app/profile/martechtherapy.bsky.social
Want to stay up-to-date with my thoughts on Martech? Make sure to subscribe 👇🏻
### Are MCPs the USB-C of AI? Tealium Thinks So
URL: https://www.martechtherapy.com/are-mcps-the-usb-c-of-ai-tealium/
Last updated: 2025-10-09T19:47:32.000Z
In this episode of Diagnosis Demo, I sit down with Sav Khetan and BJ Allmon from [Tealium to explore their recent implementation of MCPs](https://tealium.com/developer-center/bridging-ai-and-customer-data-platforms-with-mcp/?ref=martechtherapy.com) (Model Context Protocols). We discuss what MCPs mean for real-time AI integration, how Tealium positions itself as an AI enabler, and why the future might just belong to multi-agent architectures. We also demo a real use case that shows how fast and powerful Tealium's setup really is.
Watch to see:
- A working demo using Tealium’s Moments API and MCP integration in a simple chatbot
- The difference between MCP and A2A protocols
- Why data orchestration, not models, is the AI differentiator
Connect with us to learn more:
- Sav Khetan ([LinkedIn](https://www.linkedin.com/in/savkhetan/?ref=martechtherapy.com))
- B.J. Allmon ([LinkedIn](https://www.linkedin.com/in/bjallmon/?ref=martechtherapy.com))
- Matthew Niederberger ([LinkedIn](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com))
Get notified when new demos are published 👇🏻
### Contextual CDPs: Building the bridge
URL: https://www.martechtherapy.com/contextual-cdps-building-the-bridge/
Last updated: 2025-10-16T15:10:07.000Z
If the first three parts of this series explored what’s possible when context becomes the driving force behind customer data, then this one asks a more grounded question:
> *How do we actually get there?*
I’ve spoken with teams who are genuinely excited by the idea of using memory, inference, and context to make their CDPs smarter. But many feel stuck between inspiration and implementation. They see the potential, but don’t quite know where to start.
Let’s be honest, the martech stack is already complex enough. The last thing anyone wants is to bolt on a new set of speculative features without knowing whether they’ll break the flow or muddy governance. So what does a practical path forward look like?
## Think in layers, not replacements
You don’t need to reinvent your CDP. You need to extend its awareness.
Most current platforms do well at storing and activating structured data. But the moment you ask them to interpret or recall patterns over time, they fall short. This is where contextual add-ons come in. Think of them as small, composable services that sit just outside the core CDP and help it "think" a little more like a person.
Source: State of Martech Report 2025 by Scott Brinker and Frans Riemersma
Example: a lightweight memory service that summarizes support interactions and flags emotional tone. It doesn’t change the CDP’s schema. It simply offers context to the tools that need it, your support dashboard, your outbound campaign planner, your preference center.
The same goes for RAG-style retrieval services. Instead of forcing every profile query through a rigid API, you can set up a context agent that knows how to pull the right customer fragments depending on what the asking system needs.
Personalized email? Fetch behavior summaries.
Support ticket triage? Pull recent complaints and loyalty status.
Different tools, different context views.
## Start with what you know (and own)
It’s tempting to chase external enrichment or LLM-powered features out of the gate, but the most valuable context often lives right under your nose. Your CRM notes, NPS responses, support call transcripts, live chat logs, all of that is context just waiting to be shaped.
Simple chatbot inference for CDP enrichment example (green = new layer)
And shaping doesn’t require massive AI investments. In many cases, simple embeddings and summary layers are enough to create a memory scaffold that gives other tools more awareness of the customer’s current state.
I’ve seen teams use this to improve everything from suppression logic to churn prediction, all without overhauling their stack. The trick is to make these memory and inference layers available where decisions are being made, not buried in a back-end data warehouse.
## Real teams, real boundaries
Let’s talk about the human side for a moment. Most martech teams aren’t staffed to build and maintain full-scale contextual infrastructure. And that’s okay. The goal isn’t to go from zero to omniscient AI in a quarter. The goal is to make slightly better decisions, based on slightly better context.
That starts with shared language. Are your data, marketing, and engineering teams aligned on what "context" even means in your organization? Do they know what kind of memory would actually support your use cases? Are there already conversations happening where someone says, “If only the system remembered X...”?
Start there. Then ask what’s currently missing from the decision moment. That missing piece is often the first place a context protocol or memory layer can add value.
## Context is an interface, too
The part that often gets missed is that context should be treated not only as data, but as an integral part of the user experience. If your internal tools or customer-facing systems don’t reflect a shared understanding of the customer, the context work stays invisible.
This doesn’t mean every UI needs a timeline or AI-generated summary, but it does mean giving operators and end-users the ability to adjust, annotate, or even push back on what the system believes about someone. That dialogue is where trust gets built, both internally and externally.
Some of the most interesting work I’ve seen involves internal agent tools that surface a real-time context panel beside every action. Not to tell the operator what to do, but to offer a sense of the moment. A customer’s last mood. Their likely goal. The patterns that matter.
When teams can see context, they start to build with it.
## Looking ahead
The tools are catching up. The interest is there. What’s needed now is more imagination paired with more grounded experimentation. You don’t need permission to explore these ideas. You need a use case, a memory scaffold, and a question worth answering.
In Part 5, I’ll take a closer look at some speculative architectures and zero-in on how teams might structure these contextual overlays without creating a mess of one-off systems. Because composability is only valuable when it stays coherent.
For now, I’ll leave you with this: you don’t need a perfect plan to get started. You just need to believe that your customer data has more to say, if only your systems could listen better.
---
- Part 1: [*Contextual CDPs, is this the next-gen?*](https://www.martechtherapy.com/understanding-mcps-a-cdp-insiders/)
- Part 2: [*Memory, not identity, is what makes context work*](https://www.martechtherapy.com/contextual-cdps-memory-is-what-makes-context-work/)
- Part 3: [*Trust as a feature*](https://www.martechtherapy.com/trust-as-a-feature/)
- Part 5: [*Composable, not chaotic*](https://www.martechtherapy.com/contextual-cdps-composable-not-chaotic/)
- Part 6: [*Contextual Fluency*](https://www.martechtherapy.com/contextual-cdps-contextual-fluency/)
Want to get notified when I publish Part 5 in this series? Subscribe today 👇🏻
## Sign up for Martech Therapy
Thoughts, stories and ideas.
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
### Can your data tell a story? Multiplied shows how personalized media really works
URL: https://www.martechtherapy.com/can-your-data-tell-a-story-multiplied/
Last updated: 2025-10-09T19:47:33.000Z
In this special *Diagnosis Demo* episode, we sit down with Lloyd Hofmeyr, co-founder of [Multiplied](https://multiplied.co/?ref=martechtherapy.com), to explore what happens when brand storytelling meets hyper-personalized media at scale. Forget the usual "Dear {first\_name}" stuff, Lloyd walks us through real campaigns for BMW, financial apps, e-commerce brands, and more, showing how smart data and creative vision can turn abandoned cart emails into moments that *actually* convert.
We cover:
- The difference between generative AI and brand-consistent personalization
- Multiplied’s creative-meets-automation approach
- Why year-end wrap videos shouldn’t start in December
- Examples of transactional moments turned into brand storytelling gold
- The case for quality data and graceful fallbacks
And yes, we also talk about what happens when Mr. Hassan gets an email meant for Matthew.
This episode is full of GIFs (literally) and insights (figuratively).
---
If you enjoyed this episode and want to see more demos the please subscribe and support me here on Substack.
### Contextual CDPs: Trust as a feature
URL: https://www.martechtherapy.com/trust-as-a-feature/
Last updated: 2025-10-16T15:11:14.000Z
In [Part 1](https://www.martechtherapy.com/understanding-mcps-a-cdp-insiders/), I looked at how model context protocols could reshape the customer profile, from static to dynamic, from collected to interpreted. In [Part 2](https://www.martechtherapy.com/contextual-cdps-memory-is-what-makes-context-work/), I spoke about how that same shift could drive smarter, more human orchestration across channels and touchpoints.
But there’s a deeper layer we need to talk about. Not tech. Not tactics. **Trust**.
Because when our systems start *inferring*, *remembering*, and *deciding →* the stakes change. And our responsibilities as builders shift right along with them.
## Dynamic Context == Dynamic Responsibility
With great memory comes great obligation.
Sorry, Uncle Ben.
When we move from static profiles to real-time contextual understanding, we’re generating interpretations. We’re creating *soft data* based on tone, inferred sentiment, purchase cadence, churn risk, even emotional state.
That’s powerful. But it also puts us squarely in the domain of probabilistic personalization, where nothing is absolute, and context is everything.
Which means we owe it to our users to be transparent about:
- What is inferred versus explicitly stated
- When memory is being used to influence decisions
- How long that memory lasts, and why
And let’s be clear… inferred context often moves beyond metadata and starts influencing how systems operate in real time. A misinterpreted tone could result in a missed opportunity or, worse, a message that feels cold or out of place. These small mistakes erode trust faster than most dashboards will ever catch.
This is where design and governance need to meet in the middle. Because as systems grow smarter, our margin for being careless shrinks.
## Governance beyond the checkbox
Too much governance talk still circles around checkboxes and audit logs. But context-aware systems need something more fluid. For instance, think of:
- **consent-aware prompting:** retrieval and inference layers that *check* permission before surfacing or using certain attributes
- **policy-injected context:** decision logic that includes guardrails like “avoid upsell offers within 48 hours of a support complaint”
- **user-facing context cards:** imagine giving customers a peek into what your system remembers or assumes about them. → “Here’s what we think you care about, let us know if that’s off.”
These mechanisms keep your legal team happy and they build credibility. Especially in environments where customer attention is scarce and brand trust is fragile.
Hightouch’s tracking ‘reasoning’ in their AI Decisioning feature.
Governance can also mean having escalation paths. If an AI makes a questionable inference, how can it be flagged, corrected, or quarantined from acting on it again? These feedback loops shouldn’t only exist for edge cases, they should be an everyday part of orchestration hygiene.
The goal is to be inclusive and by no means flawless. Let users participate in shaping how decisions are made. Let them in, not to micromanage, but to nudge. That kind of participation is where modern trust lives.
## Data Enrichment or Data Projection?
We love to talk about data enrichment, filling gaps in profiles, adding new signals, layering in third-party insight. But when AI gets involved, that enrichment can start to look more like projection.
When a system infers that I’m price-sensitive, based on my open rates or chat language, is that an enrichment or a bias?
These are uncomfortable questions, but they’re essential. Because with every inference comes a shadow of interpretation. And if that interpretation is off, if the AI got it wrong, what’s our correction mechanism?
Memory systems will need forgetting protocols. Inference pipelines will need audit trails. And organizations will need to invest in *narrative debugging,* tools that help humans understand *why* the system said what it said.
This is especially important when inferred context crosses into sensitive territory, health, finances, beliefs. That’s where regulatory frameworks are headed, and where customer expectations already are.
Another way to think about this: inference is a story layer. Every system that infers something about a customer is writing a version of their story. And we have a responsibility to make sure it’s not fiction or worse, a bad one.
## Trust is the interface
Here’s the big idea → in a context-rich, memory-aware customer system, trust isn’t a compliance feature. It *is* the user interface.
The most forward-thinking organizations won’t just ask, “What can we predict?” They’ll ask something along the lines of:
- “Can we explain why we predicted that?”
- “Can the user push back, correct, or opt out?”
- “Are we remembering things that are helpful or just convenient?”
Designing for trust means creating moments of certainty e.g. notifications that explain why a recommendation appeared, preference centers that show more than toggles, and human-readable summaries of what the system ‘knows.’
This is a meme… or isn’t it?
Trust isn’t built in a privacy policy (when is the last time you read one fully?). It’s built in a dozen micro-moments where the system behaves as expected or graciously when it doesn’t.
Edge cases? Hardly. These are foundational design questions. Because the more our CDPs interpret, the more they need to *communicate*.
And when customers feel seen *and* safe, everything else gets easier, including conversions, retention, advocacy. **Trust becomes the multiplier**.
## Toward a trustworthy CDP
If you’ve been following along with this series and the broader [CDP Reboot](https://www.martechtherapy.com/why-im-rebooting-the-cdp-conversation/) work, you’ve probably seen the pattern:
First, make the profile contextual.
Then, make the orchestration responsive.
Finally, make the whole system accountable.
That’s what trust looks like. Not a dashboard, but a design philosophy.
In future pieces, I’ll explore specific mechanisms to build that trust into your stack, without slowing it down or watering it down. Things like transparency dashboards, memory boundary protocols, and contextual consent flows.
But for now, here’s the takeaway 👇🏻
Memory systems, inference layers, and orchestration engines are *power tools*. And like all power tools, they need safeguards, clear instructions, and a healthy respect for what can go wrong.
The good news? When done well, they also build something deeper than personalization.
They build relationships.
And in a world where customer expectations are growing faster than most systems can keep up, *that* might be the most valuable thing you can offer.
- Part 1: [*Contextual CDPs, is this the next-gen?*](https://www.martechtherapy.com/understanding-mcps-a-cdp-insiders/)
- Part 2: [*Memory, not identity, is what makes context work*](https://www.martechtherapy.com/contextual-cdps-memory-is-what-makes-context-work/)
- Part 4: [*Building the bridge*](https://www.martechtherapy.com/contextual-cdps-building-the-bridge/)
- Part 5:[ ](https://www.martechtherapy.com/contextual-cdps-composable-not-chaotic/)[*Composable, not chaotic*](https://www.martechtherapy.com/contextual-cdps-composable-not-chaotic/)
- Part 6: [*Contextual Fluency*](https://www.martechtherapy.com/contextual-cdps-contextual-fluency/)
Want to get notified when I publish Part 4 in this series? Subscribe today 👇🏻
## Sign up for Martech Therapy
Thoughts, stories and ideas.
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
### CDP Reboot: Where are we now?
URL: https://www.martechtherapy.com/cdp-reboot-where-are-we-now/
Last updated: 2025-05-06T07:01:17.000Z
In this latest installment of [the CDP Reboot series](https://open.substack.com/pub/martechtherapy/p/the-cdp-reboot-the-promise?r=3i8xzy&utm%5Fcampaign=post&utm%5Fmedium=web&showWelcomeOnShare=false), I sat down with [Dylan Flye](https://www.linkedin.com/in/dylanflye?ref=martechtherapy.com) (Simon Data) and [Oussama Ghanmi](https://www.linkedin.com/in/oussama-ghanmi-48140b66/?ref=martechtherapy.com) (DinMo) for a brutally honest discussion about the current and future state of Customer Data Platforms.
What started as a debate about the fate of the CDP category quickly turned into something more revealing. We explored why the original promise of CDPs may have overreached, how warehouse-native models and modularity are rewriting the rules, and why AI might not be the silver bullet, but still changes the game.
We didn’t always agree. But we did converge on one thing: **the CDP category needs more transparency, education, and realism**. It's not about package vs. composable. It's about maturity, ownership, and value.
The future of CDPs is up for debate and this conversation lays it all out clearly.
👥 Connect with us on LinkedIn:
- Dylan: [https://www.linkedin.com/in/dylanflye](https://www.linkedin.com/in/dylanflye?ref=martechtherapy.com)
- Oussama: [https://www.linkedin.com/in/oussama-ghanmi-48140b66/](https://www.linkedin.com/in/oussama-ghanmi-48140b66/?ref=martechtherapy.com)
- Matthew: [https://www.linkedin.com/in/matthewniederberger/](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)
📲 Follow Martech Therapy on:
- Instagram: [https://www.instagram.com/martechtherapy/](https://www.instagram.com/martechtherapy/?ref=martechtherapy.com)
- Youtube: [https://www.youtube.com/@martechtherapy](https://www.youtube.com/@martechtherapy?ref=martechtherapy.com)
- Bluesky: [https://bsky.app/profile/martechtherapy.bsky.social](https://bsky.app/profile/martechtherapy.bsky.social?ref=martechtherapy.com)
---
By subscribing for free, you support this newsletter immensely.
### Contextual CDPs: Memory, not identity, is what makes context work
URL: https://www.martechtherapy.com/contextual-cdps-memory-is-what-makes-context-work/
Last updated: 2025-10-16T15:10:33.000Z
In [Part 1](https://www.martechtherapy.com/understanding-mcps-a-cdp-insiders/), I explored how model context protocols (MCPs) could shift CDPs from passive data stores into dynamic context engines. Profiles that update themselves in the moment, based on intent, tone, and history. Not just segments, but signals. And now? Let’s see what happens when those signals actually *drive decisions…* in real time, across multiple touchpoints.
Because here’s the next big unlock: context-aware orchestration.
## Real-time isn’t just about speed
Let’s be honest, "real-time" has been one of those buzziest of buzzwords we’ve collectively abused for years. It often means “fast batch,” or “eventual personalization.” What we really mean when we say real-time (or should mean) is *right time*.
Context-aware decisioning isn’t only about speed, it’s about understanding recent events in context, knowing what matters in the moment, and anticipating what’s likely to happen next. This is where MCPs really prove their value.
Imagine your orchestration engine has access not only to recent events and attributes, but also to a memory layer that understands the emotional temperature of a support call from earlier today. Or a RAG module that fetches the latest product interactions and social sentiment when deciding how to follow up.
This isn’t speculation. Companies like [Urban Company are already using LLM-based systems](https://medium.com/uc-engineering/leveraging-llms-at-scale-for-real-time-business-critical-decisioning-40df73c2a8c1?ref=martechtherapy.com) to decide, mid-interaction, whether a customer issue is due to internal fault or user error, *in context*, and at scale.
Urban Company LLM enhanced Journey Orchestration Flow
## Channel fluidity and the new journey logic
Let’s say a customer starts browsing on mobile, chats with support, and then disappears. Most orchestration tools would fall back on timers and triggers. But what if your orchestration logic could remember the chat’s tone, retrieve inferred intent, and decide that now isn’t the time to nudge *or* that the best nudge is a proactive SMS with an apology and solution?
With memory systems and contextual retrieval, we stop relying on generic flowcharts and start reacting to nuance. The result feels more human.
This is where the old journey orchestration model starts to crumble. Instead of “if user does X, send Y,” we start building orchestration logic that reasons: “Given everything I know right now, what would be most helpful to this customer?”
## Memory as an orchestration layer
Here’s a simple framing: real-time orchestration gets smarter when it *remembers* more of the right things. And memory systems, whether session-based, long-term, or retrieved on demand, make that possible.
A few speculative but plausible applications:
- In-session memory that adjusts messaging if a customer seems confused or frustrated
- Long-term memory that flags historical churn risk patterns across interactions
- Retrieval systems that surface policy constraints, loyalty status, or recent objections before a new message is sent
Think of them less as full-blown AI agents and more as orchestration systems enhanced by memory scaffolding → focused, contextual, and purpose-built. Lightweight, contextual, and composable.
## Governance in the Moment
The real magic (and real risk!) is that context can change fast. One minute a user is a happy advocate, the next they’re angry on Twitter… or X, or Xitter, or whatever it’s called this week. Your orchestration engine needs to *know* that. Or at least, know enough to tread carefully.
MCPs can play a key role in governance by surfacing dynamic context. Think of it as real-time compliance meets empathy: “This customer has opted out of SMS,” or “This customer’s tone just shifted to negative → delay the promo.”
You don’t need a crystal ball. You need just enough context to make *slightly better decisions*, moment to moment.
## Where this fits in the CDP Reboot
If the first phase of the [CDP Reboot](https://www.martechtherapy.com/why-im-rebooting-the-cdp-conversation/) was about reconnecting data with purpose, this second phase is about making that purpose *responsive*. Orchestration powered by context is more aware.
It’s the difference between shouting into a void and actually listening before you speak.
In Part 3, I’ll explore how all of this changes our responsibility as data stewards. Because when systems start to infer, remember, and act, we’d better know how they’re doing it.
And we’d better build in a way that earns trust, not just attention.
---
- *Part 1:* [*Contextual CDPs, is this the next-gen?*](https://www.martechtherapy.com/understanding-mcps-a-cdp-insiders/)
- Part 3: [*Trust as a feature*](https://www.martechtherapy.com/trust-as-a-feature/)
- Part 4: [*Building the bridge*](https://www.martechtherapy.com/contextual-cdps-building-the-bridge/)
- Part 5:[ ](https://www.martechtherapy.com/contextual-cdps-composable-not-chaotic/)[*Composable, not chaotic*](https://www.martechtherapy.com/contextual-cdps-composable-not-chaotic/)
- Part 6: [*Contextual Fluency*](https://www.martechtherapy.com/contextual-cdps-contextual-fluency/)
Want to get notified when I publish Part 3 in this series? Subscribe today 👇🏻
## Sign up for Martech Therapy
Thoughts, stories and ideas.
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
### Are we overestimating AI? Or underestimating what's coming?
URL: https://www.martechtherapy.com/are-we-overestimating-ai-or-underestimating/
Last updated: 2025-10-09T19:47:35.000Z
What happens when the tools we think are helping us today aren't ready for the future we’re speeding into?
In this episode of Couch Confidentials, Michael Katz (CEO of mParticle) joins me to talk about where AI is *really* at, why most CDPs are stuck in the past, and why success in Martech now depends less on the tech itself and more on how you think about it.
We dive into:
- Why **"People overestimate where we are today and underestimate how fast this stuff progresses."**
- The two very different paths CDPs are taking (and why one is a race to the bottom)
- What companies miss when they don't look at the *real* cost of "composable" architectures
- How AI might finally force Martech to grow up
Pull up a seat. This one gets real fast.
---
👥 Connect with us:
- Michael: https://www.linkedin.com/in/michaelskatz/
- Matthew: https://www.linkedin.com/in/matthewniederberger/
📲 Follow Martech Therapy on:
- Instagram: https://www.instagram.com/martechtherapy/
- Bluesky: https://bsky.app/profile/martechtherapy.bsky.social
- Youtube: https://youtube.com/@martechtherapy
Make sure to subscribe and not miss my next podcast with… 👇🏻
### Contextual CDP, let me explain why...
URL: https://www.martechtherapy.com/contextual-cdp-let-me-explain-why/
Last updated: 2025-04-25T19:23:57.000Z
I’ve just kicked off [a new blog series](https://www.martechtherapy.com/understanding-mcps-a-cdp-insiders/) on something I’ve been thinking about a lot lately: how customer data platforms could work if they were built around context, not just profiles.
This short video (<4 minutes) is a personal reflection on what led me to write the series, what I’m exploring, and how memory, inference, and nuance might change the way we think about CDPs.
Curious what you think. Watch the video, then let me know what questions it raises for you.
### Contextual CDPs, is this the next-gen?
URL: https://www.martechtherapy.com/understanding-mcps-a-cdp-insiders/
Last updated: 2025-10-16T15:09:43.000Z
There’s been a lot of noise lately about context windows, model memory, RAG systems, and how all these emerging AI patterns might play out across industries. And if you’re working in customer data or Martech, you’ve probably felt a mix of curiosity and overwhelm. I know I have.
So let’s slow it down for a moment and approach this from a different angle. I’m not an MCP expert, far from it. This series is more about curiosity than conclusions. It’s a way for me to explore how these ideas could apply to CDPs and the messy, fascinating work of customer data. Here’s the question I’ve been asking myself:
What happens when we stop thinking of a CDP as a static profile store and start treating it like a dynamic context engine?
Because the answer opens up a whole world of possibilities, ones that go far beyond better segmentation or audience targeting. We're talking about profiles that adapt in real time, decisions that reflect actual customer intent, and systems that can remember nuance.
## From static profiles to dynamic context
The traditional promise of the CDP has been pretty consistent: unify customer data into a single profile, stitch events across systems, make that profile available to your tools. But lately, I’ve been wondering if that framing is starting to show its age.
Modern customer experiences are happening in real-time, across fragmented ecosystems, with constantly shifting context. And yet most CDPs are still acting like a slow-moving ledger, great for recordkeeping, less great for interpretation. It’s like using a filing cabinet to run a conversation.
This is where model context protocols (MCPs) come in.
Technologies like memory systems, retrieval-augmented generation (RAG), and context window management aren’t just useful for chatbots or generative apps. They point to a new way of thinking: one where *context is not stored*, it’s *reconstructed and interpreted* on demand. And that principle? It could be game-changing for the next generation of CDPs.
If we can reimagine context as a fluid layer that adapts to the task at hand, whether it’s support, personalization, compliance, or analytics, we can start to build systems that are genuinely customer-aware.
## How model context protocols could rethink the CDP stack
Let’s get a bit imaginative.
What if, instead of only storing hard attributes and recent events, your CDP also worked with a memory system that could summarize the sentiment and needs expressed in a customer’s recent support call? Maybe even flag that this customer is getting frustrated, before they churn.
Or what if your identity resolution engine used a RAG pattern to dynamically retrieve fragments of a customer’s profile from different systems, based on what’s relevant to the moment, not just what’s stored in the core schema?
These aren’t technical fantasies. Tools like [Tilores](https://tilores.io/?ref=martechtherapy.com) are experimenting with RAG-based resolution techniques. [Tealium](https://tealium.com/developer-center/bridging-ai-and-customer-data-platforms-with-mcp/?ref=martechtherapy.com) recently announced a formal integration of Model Context Protocols into their CDP stack, specifically to support real-time personalization, memory layering, and smarter orchestration.
I asked Tealium for a response to the series, and to their press release:
“As AI frameworks and design patterns proliferate, organizations need the ability to fuel their own AI models with clean, consented, and context-rich data. With Model Context Protocol (MCP) compatibility, Tealium empowers customers to stream real-time data into their AI stack using Tealium's Moments APIs → enabling more intelligent, privacy-compliant personalization across every touchpoint.”
\~ [BJ Allmon](https://www.linkedin.com/in/bjallmon/?ref=martechtherapy.com) | Tealium
That’s a strong signal, not just experimentation, but a deliberate architectural choice to make customer data context-aware.
[Hightouch](https://hightouch.com/platform/ai-decisioning?ref=martechtherapy.com), for comparison, is exploring reinforcement learning to drive agent-led decisioning. And while platforms like [Amperity](https://amperity.com/platform/customer-data-cloud?ref=martechtherapy.com) and [Treasure Data](https://www.treasuredata.com/product/artificial-intelligence/?ref=martechtherapy.com) have begun embedding intelligence across their ecosystems, it’s not yet clear whether they’ve adopted MCP principles or are building along adjacent paths.
What’s interesting here is less the tech, and more the implication: the customer profile becomes less of a static truth and more of a *real-time construct*, composed contextually, based on purpose.
Think about that for a second. A profile that can adapt itself depending on whether you’re personalizing a landing page, replying to a support request, or handling a privacy query. That’s a very different beast than the CDPs most teams are currently running.
It also changes how we think about orchestration. If every touchpoint has access to a slightly different "view" of the customer, tailored to the channel, the timing, and the intent, we move away from the myth of a single golden record and toward something more flexible, even empathetic.
## The power (and risk) of inferred data
Here’s where things get interesting, at least for the seasoned professional. As soon as we let our CDP ecosystem start interpreting data, not just collecting it, we open up new opportunities *and* new responsibilities.
For example, memory systems can help us derive useful summaries: "This customer often responds well to direct messaging." Or, "They’ve repeatedly flagged sustainability as a key concern." These aren’t attributes someone manually entered into a CRM (we have definitely passed that opportunity). They’re *inferred* from tone, patterns, behavior.
This kind of contextual enrichment can massively improve how we engage. But it also needs to be transparent, ethical, and (where required) revocable. After all, if we’re building dynamic profiles from fuzzy memory, we’d better be able to explain what the AI remembered... and why.
Inferred data might also raise tensions internally: How do you explain to marketing that an AI thinks a customer prefers a certain tone of voice, based on a chatbot interaction from three months ago? That’s where interpretability and traceability become core features.
There’s a whole governance angle here, and I’ll get into that more in a later post because consent-aware prompting is going to matter a lot.
## From golden record to contextual fragments
If we embrace the idea that a customer profile is no longer a single source of truth but a fluid, situation-dependent construct, we also have to let go of the notion that there’s one definitive view to maintain across all systems.
That golden record we’ve all been chasing? Maybe it was a useful metaphor when customer journeys were simpler. But today, it’s more like chasing a mirage, a record that’s always just a few interactions behind.
Instead, what we need are contextual fragments. Bits of insight that can be retrieved, interpreted, and composed on demand, depending on what the system, or the team, is trying to achieve. These fragments don’t live in one place. They’re distributed across systems: support logs, transaction histories, product usage, survey responses. MCPs don’t unify them into a giant data blob. They help us stitch together just what’s relevant for the moment.
Think of it like building a sentence instead of reciting a script. Every touchpoint forms its own version of the customer narrative → not arbitrarily, but purposefully. That kind of assembly demands new retrieval logic, trust models, and a willingness to accept that profiles are partial by nature.
And that’s okay. In fact, it might be the only way to keep up.
## Looking ahead
In the next post, I’ll dig into how these ideas play out in real-time decisioning and cross-channel orchestration. And how memory systems can make that orchestration feel a whole lot more human.
But for now, just sit with this: your customer profile doesn’t have to be static. It can be fluid. Contextual. A living, partial truth that adapts to the moment.
And maybe that’s exactly what we need.
We don’t need more data. We need systems that *understand* the data we already have, moment to moment, and customer to customer.
I’m just scratching the surface here, but if this resonates, there’s more to come.
- Part 2: [*Memory, not identity, is what makes context work*](https://www.martechtherapy.com/contextual-cdps-memory-is-what-makes-context-work/)
- Part 3: [*Trust as a feature*](https://www.martechtherapy.com/trust-as-a-feature/)
- Part 4: [*Building the bridge*](https://www.martechtherapy.com/contextual-cdps-building-the-bridge/)
- Part 5:[ ](https://www.martechtherapy.com/contextual-cdps-composable-not-chaotic/)[*Composable, not chaotic*](https://www.martechtherapy.com/contextual-cdps-composable-not-chaotic/)
- Part 6: [*Contextual Fluency*](https://www.martechtherapy.com/contextual-cdps-contextual-fluency/)
Want to get notified when I publish Part 2 in this series? Subscribe today 👇🏻
## Sign up for Martech Therapy
Thoughts, stories and ideas.
Subscribe
Email sent! Check your inbox to complete your signup.
No spam. Unsubscribe anytime.
### Behind the scenes of Measurecamp with Kevin Swelsen
URL: https://www.martechtherapy.com/behind-the-scenes-of-measurecamp/
Last updated: 2025-10-09T19:47:35.000Z
This week, I sat down with [Kevin Swelsen](https://www.linkedin.com/in/kevinswelsen/?ref=martechtherapy.com), longtime friend, freelance digital analytics and CDP consultant, and one of the organizers behind [Measurecamp Amsterdam](https://amsterdam.measurecamp.org/?ref=martechtherapy.com). We dive into how the event was born, what makes it work, and why community still matters in a vendor-heavy Martech world.
Kevin shares how a trip to [Measurecamp London](https://london.measurecamp.org/?ref=martechtherapy.com) inspired a decade of volunteering, what it means to remain independent in a field full of tech stacks and sales pitches, and yes, he confirms the existence of the mythical Measurecamp socks.
Subscribe to tune into future episodes of Couch Confidentials 👇🏻
### The CDP Reboot: The Turning Point
URL: https://www.martechtherapy.com/the-cdp-reboot-the-turning-point/
Last updated: 2025-10-09T19:47:36.000Z
So, here we are. Part 4\. If you've made it this far through the CDP Reboot series, you’ve seen the full arc, from [promise](https://www.martechtherapy.com/the-cdp-reboot-the-promise/) to [stall](https://www.martechtherapy.com/the-cdp-reboot-the-stall/) to [disillusionment](https://www.martechtherapy.com/the-cdp-reboot-the-disillusionment/). And now? Now we look at the turning point.
This isn’t the part where I tell you which platform to buy, or what checkbox to look for on a vendor RFP. If anything, the last three parts should’ve made it clear that’s exactly the wrong mindset.
This is about the future of the category itself. What happens next, and what should happen if we’re honest about the role CDPs were meant to play in the first place.
Because here’s the uncomfortable truth: if we’re still arguing about what a CDP is in 2025, the debate is already over. The market moved on. It just didn’t leave a forwarding address.
---
**How did we get here (a fast recap)**
Maybe you are starting the series here, in that case, let me give you a quick recap on how we got here:
- CDPs were born from fragmentation. Too many data sources, not enough cohesion.
- They promised a unified customer view. Fast, marketer-owned, flexible.
- Vendors rushed in. Definitions diverged. Features blended. Labels blurred.
- Buyers got confused. Projects stalled. Trust eroded.
Now, we’re in a place where CDPs still exist.. but often as features in larger platforms, components in composable stacks, or part of “digital experience” suites.
The category didn’t die. *It just dissolved into the rest of Martech*.
---
**Three futures for the CDP category**
Let's see where we are headed without wasting any more of your time. From here, I see three likely paths for the CDP category:
1. **Absorbed** –> CDPs lose their standalone status and become native features of cloud data platforms, marketing clouds, or experience orchestration tools. We stop buying “a CDP” and start expecting CDP-like capabilities wherever customer data is stored.Case in point: Databricks recently announced (April 2025) that it is now hiring a *Principal Industry and Solutions Manager, CDP*. They’re not building a CDP, they’re folding CDP use cases into a broader AI-native Lakehouse narrative. That’s not a death knell for the category. It’s proof that CDP capabilities are now foundational to broader enterprise architecture, and vendors are embedding them under new names and with new ambitions.
2. **Redefined** –> A more focused definition emerges: CDPs aren’t everything; they’re one specific thing (e.g., real-time activation layer, consent-aware profile service, first-party audience manager, or dare I say it, a more contextually focused engine for the next generation of CDPs). Niche players double down, and new leaders emerge with clarity.
3. **Rebranded or Replaced** –> The term CDP becomes too muddied to recover. The tech remains, but the label changes, maybe into Customer Data Infrastructure, Decisioning Layer, Contextual Data Infrastructures, or something we haven’t coined yet. Something that sounds new enough to clear the slate.
None of these outcomes are bad. But each requires us to be honest about what the tech can do, and what organizations can realistically support.
---
**What this means for buyers**
If you’re evaluating CDPs today, or trying to figure out how to resuscitate an implementation that went flat, here’s the advice I’d offer:
Start by ignoring the label and focusing on what your team actually needs to do. Can you describe the capabilities you’re missing without reaching for buzzwords?
Good, now be honest about your maturity. If your data’s a mess and your teams are misaligned, buying more tech won’t solve it.
Maybe you need a stack.
Maybe you need a simpler piece of it.
Either way, no single platform will make your customer data problems disappear. And no one vendor gets to own the customer experience, not entirely. It’s shared. That’s where the hard work starts.
Oh—and ask this at every vendor meeting: *“What won’t this tool do well?”* If they can’t answer, they’re not helping you. They’re selling you.
---
**What this means for vendors**
CDP vendors have a choice to make:
Do they fight to defend a blurry category?
or
Pivot to become part of something larger and better defined?
There’s nothing wrong with focusing on one piece of the puzzle, identity, consent, profile storage, and activation. But trying to do it all with the same half-baked feature set will not work.
The winners in the next phase will not only have APIs but also opinionated architectures, contextual data layers, clear roles, and pricing that reflects use rather than ambition.
If that sounds more like infrastructure than software, that’s because it is. And that’s okay. Being part of the plumbing means you’re necessary rather than irrelevant.
---
**What this means for consultants and analysts**
Let’s be real: we’ve helped create the mess. Overpromising. Oversimplifying. Encouraging RFPs before strategy. Hiding the boring, but essential, parts like governance and integration.
It’s time to shift from frameworks to fluency. From defining categories to helping orgs understanding and preparing for them.
We don’t need a new quadrant. We to share a clearer message and realistic outlook. And humility.
---
**CDPs didn’t fail. We just uutgrew the illusion**
The idea behind CDPs still matters. Unified profiles. Smart activation. Control over your own customer data.
But categories don’t succeed just because the tech is useful. They succeed when there’s shared understanding. Governance. Accountability.
Maybe we don’t need a new CDP category. Maybe we just need new expectations.
> *“CDP? That’s what we used to call it. These days, it’s just the data layer.”*
> \~ a recent client, who’s not wrong
So here’s to the reboot. Not just of the category, but of how we think about data, ownership, and what it takes to turn potential into practice.
New name. New owner. Same problem …and now Databricks is getting in line to claim a slice of the action saying the quiet part out loud: *the CDP is no longer a product. It’s a use case.*
Let’s solve it better this time.
---
**Series Recap:**
- Part 1: [*The Promise – Why CDPs Were Supposed to Fix Everything*](https://www.martechtherapy.com/the-cdp-reboot-the-promise/)
- Part 2: [*The Stall – When Every CDP Started to Look the Same*](https://www.martechtherapy.com/the-cdp-reboot-the-stall/)
- Part 3: [*The Disillusionment – Why the Tech Wasn’t the Problem*](https://www.martechtherapy.com/the-cdp-reboot-the-disillusionment/)
Want more opinion pieces on Martech, on CDPs, from someone in the trenches? Subscribe today 👇🏻
### How to avoid data chaos, one sunny walk at a time
URL: https://www.martechtherapy.com/how-to-avoid-data-chaos-one-sunny/
Last updated: 2025-10-09T19:47:36.000Z
Data chaos doesn’t wait for a boardroom. So we took this Couch Confidentials *special episode outside*, wandering the streets of Amsterdam with Stefania Olofsdottir during Measurecamp. We talk about the origins of [Avo](https://avo.app/?ref=martechtherapy.com), trusting teams with their own datasets, and how her journey from Iceland to analytics has always centered around making data meaningful *before* it breaks things downstream.
☀️ Recorded on a sunny stroll.
📍 Measurecamp Amsterdam.
🧠 Powered by Avo’s mission to fix bad data before it breaks your stack.
---
📄 Download Avo’s whitepaper: https://www.avo.app/resources/data-mesh-for-event-based-data
---
👥 Connect with us:
- Stefania: https://www.linkedin.com/in/stefaniabjarneyolafsdottir/
- Matthew: https://www.linkedin.com/in/matthewniederberger/
---
📲 Follow Martech Therapy on:
- Instagram: https://www.instagram.com/martechtherapy/
- Substack: https://martechtherapy.substack.com/
- Bluesky: https://bsky.app/profile/martechtherapy.bsky.social
Want to enjoy more Walk & Talk style podcasts? Make sure to subscribe and let me know what you think of this style of interviews.
### The CDP Reboot: The Disillusionment
URL: https://www.martechtherapy.com/the-cdp-reboot-the-disillusionment/
Last updated: 2025-10-09T19:47:36.000Z
You bought the platform. You connected the data. The vendor promised it would all come together.
But somehow... it didn’t.
Thanks for reading Martech Therapy! Subscribe for free to receive new posts and support my work.
Welcome to Part 3 of the #CDPReboot series. This one’s about the part no one really wants to admit: that the technology mostly worked, but the context around it didn’t. And that’s where things started to fall apart.
This is not an exposé of CDPs. It’s a wake up call to challenge our expectations. Not the kind you can patch with a dashboard or a training session, but the kind that go unspoken in kickoff meetings and quietly erode confidence six months later.
---
**The false hope of tooling**
I’ve lost count of how many times I’ve heard some variation of: *“Once we have a CDP, we’ll finally be able to…”* (Insert your favorite Martech dream sequence here.) And I will admit, I did share that Kool-Aid around many years ago.
And then reality hits. The platform is live. The dashboards are technically working. But somehow, the outcomes aren’t there.
Why? Because we keep expecting software to fix strategy. Or worse… culture.
A CDP doesn’t magically rewrite your campaign briefs. It doesn’t reorganize your teams. It doesn’t fix a broken definition of what “customer-centric” actually means. It simply reflects the structure it’s plugged into, and that reflection isn’t always flattering.
Think of it like this: buying a high-end espresso machine doesn’t make you a barista. It just gives you more expensive mistakes. I should know, I still can’t match my son’s skills… with the same machine.
*“Sometimes you need to take a hard look at yourself and say… *why is this not delivering any value*? In too many of those cases, it’s not the technology.”*
\~ Mike Ferguson, [Couch Confidentials episode 9](https://www.martechtherapy.com/cdp-chaos-are-businesses-optimizing-bd8/)
And in many cases, that value gap isn’t even discovered until much later, after enthusiasm has cooled and internal credibility has taken a hit.
---
**The stuff they didn’t tell you in the demo**
No one ever says “you’re not ready for this platform” during a sales call. But maybe they should.
Here’s what doesn’t usually make it into the pitch deck:
- You’ll need a consistent event taxonomy or build one from scratch
- You’ll be normalizing payloads for months
- Half your marketing team will log in once and never return
- Someone will ask “can we connect this to Power BI?” at least twice
- You will absolutely underestimate the work needed to activate even one campaign
CDPs require alignment before they deliver value. Not just technical alignment, but organizational. Process alignment. Expectations alignment. And let’s be honest, budget realism.
I’ve worked with companies that had best-in-class tools and zero activation. The blocker wasn’t the software. It was the disconnect between what teams *thought* they’d bought and what they were actually capable of using.
*“You need to understand how you’re going to use it in the business. You need demand somewhere. You don’t want to track everything.”*
\~ Mike Ferguson, [Couch Confidentials episode 9](https://www.martechtherapy.com/cdp-chaos-are-businesses-optimizing-bd8/)
And still, this detail never makes it into the shiny vendor brochure or the ROI calculator. It lives in the footnotes of implementation decks, if it’s acknowledged at all.
---
**Org chart limbo**
If the CDP had a real job title, it would be:
“**U*nclaimed *P*latform *F*loating *B*etween *D*epartments.*” 😅
IT doesn’t fully own it. Marketing’s too busy. Data teams feel territorial. And product wants nothing to do with anything involving email.
The result? CDPs become the junk drawer of Martech. Everyone throws data into it, but no one wants to be responsible for what comes out.
And because CDPs touch so many systems, they expose every misalignment in your organization: outdated schemas, campaign planning bottlenecks, unclear data ownership, misfired personalization logic.
You didn’t buy a CDP. You bought a mirror.
*“There’s always politics in organizations. You walk in and marketing’s been doing things the same way for years. The idea of taking a risk on something else is scary.”*
\~ Mike Ferguson, [Couch Confidentials episode 9](https://www.martechtherapy.com/cdp-chaos-are-businesses-optimizing-bd8/)
In other words, the CDP didn’t create the chaos. It just revealed how embedded that chaos already was.
---
**The overpromise feedback loop**
It goes like this:
1. Vendors promise the world to get through procurement
2. Buyers believe the tool will unlock magical use cases
3. The implementation team inherits a vague strategy and a list of half-formed ideas
4. Nothing meaningful goes live for six months
Eventually, a consultant is brought in to “optimize the stack,” which usually translates to: “tell us what we actually bought and whether we’re using it right.”
*“You bought a tool. You needed a strategy.”*
And by the time the CDP finally does something useful, no one remembers what the original plan was. Worse, the internal champions may have already moved on, or moved out.
The result? A functioning tool that nobody trusts, feeding dashboards that nobody reads.
---
**It’s not the tech. It’s the operating system**
Good tech reveals bad process. And CDPs are excellent at surfacing how misaligned most teams really are.
It’s not that your CDP failed. It’s that your campaign team didn’t know what data was available. Your analytics team didn’t trust the segments they were handed. Your legal team vetoed half the use cases during review. Your data team was already burned out from the last Martech rollout. And your CMO? They didn’t back the project beyond the kickoff meeting.
CDPs aren’t magic. They’re amplifiers. And if the underlying structure is a mess, the amplification just makes it louder.
*“In general, we see this kind of two-phased implementation. The data team owns the first part, then hands off to marketing. That model is deeply flawed.”*
\~ James McDermott, [Couch Confidentials episode 3](https://www.martechtherapy.com/lytics-ceo-talk-xcdp-real-time-user-1f7/)
CDPs highlight the gaps between departments in a way no one really asks for, but everyone eventually has to reckon with.
---
**So what would make it work?**
Here’s what I’ve seen in projects that actually delivered:
- Clear, *prioritized* use cases (not a 48-item wishlist)
- Executive sponsorship (not just budget approval)
- A shared definition of “customer profile”
- Cross-functional commitment to feeding, monitoring, and governing the platform
- Realistic timelines and flexible scoping that account for data maturity
In short: **CDPs work when treated as infrastructure, not as initiatives**. You don’t need another platform. You need alignment, accountability, and a long-term commitment to making customer data operational.
The disillusionment phase isn’t failure, it’s a sign that we can and must do better. And it sets the stage for something better.
In Part 4 of the #CDPReboot series, I’ll look at what’s next. Because despite everything, the idea behind CDPs still has value. But it might need a new name, and a new owner.
---
**Further reading:**
- [Part 1: ](https://open.substack.com/pub/martechtherapy/p/the-cdp-reboot-the-promise?r=3i8xzy&utm%5Fcampaign=post&utm%5Fmedium=web&showWelcomeOnShare=false)[*The Promise – Why CDPs Were Supposed to Fix Everything*](https://www.martechtherapy.com/the-cdp-reboot-the-promise/)
- [Part 2: ](https://www.martechtherapy.com/the-cdp-reboot-the-stall/)[*The Stall – When Every CDP Started to Look the Same*](https://www.martechtherapy.com/the-cdp-reboot-the-stall/)
- [Part 4: ](https://www.martechtherapy.com/the-cdp-reboot-the-turning-point/)[*The Turning Point – Will CDPs Evolve, Dissolve, or Disappear?*](https://www.martechtherapy.com/the-cdp-reboot-the-turning-point/)
One part to go. Make sure to subscribe 👇🏻
### “Who's winning the AI agent war in Martech?”
URL: https://www.martechtherapy.com/whos-winning-the-ai-agent-war-in/
Last updated: 2025-10-09T19:47:36.000Z
This one’s been a long time coming. After a few reschedules, I finally had the pleasure of chatting with Michele Nieberding, and we went straight into the deep end of AI agents, the chaos of MCPs, and why marketers need to stop slapping "AI" on triggers and calling it innovation. We covered everything from Salesforce’s latest moves to why Aampe might just be the next unicorn in Martech.
Michele shares how product marketers are finding their way in the new wave of agentic thinking, what companies are getting wrong about AI observability, and her predictions on who’s next in the CDP acquisition game ( get your bingo cards ready).
So, are you trying to make sense of the swirling mess of AI, CDPs, and what it means to be a marketer in 2025? Make sure to listen in.
## Lets connect 🔗
- Connect with Michele on LinkedIn: https://www.linkedin.com/in/michele-nieberding/
- Connect with me on LinkedIn: https://www.linkedin.com/in/matthewniederberger/
## Follow me on social media
- Follow me on Youtube: https://www.youtube.com/@martechtherapy
- Follow me on Instagram: https://www.instagram.com/martechtherapy/
- Follow me on BlueSky: https://bsky.app/profile/martechtherapy.bsky.social
Want to know when my next podcast episode is uploaded? Subscribe today 👇🏻
### Measurecamp Amsterdam: The (un)conference that brought it all back
URL: https://www.martechtherapy.com/measurecamp-amsterdam-the-unconference/
Last updated: 2025-10-09T19:47:36.000Z
After 20+ years in digital analytics and Martech, I thought I’d seen it all. But my first [Measurecamp Amsterdam](https://amsterdam.measurecamp.org/?ref=martechtherapy.com) was a reminder of everything that still excites me about this field.
No fixed agenda. No stages or egos. Just brilliant people posting their ideas on a board and running with them. From analytics therapy to building your own tracking stack, to hard truths about data quality. It was a refreshing mix of energy and honesty.
And then there were the people. Old friends, new voices, and moments that will stay with me for a long time. I even recorded a podcast on a sunny Walk & Talk with Stefania from AVO, and (after a brief mix-up) won the unPub Quiz.
This post is my way of saying thanks and planting the seed for next year’s edition where I will definitely attempt to get my session on the board. If there’s one (un)conference you attend in the data world… make it Measurecamp.
Want to stay up to date on future events I attend, make sure to subscribe 👇🏻
### The CDP Reboot: The Stall
URL: https://www.martechtherapy.com/the-cdp-reboot-the-stall/
Last updated: 2025-10-09T19:47:38.000Z
Welcome to Part 2 of the #CDPReboot series. In [Part 1](https://www.martechtherapy.com/the-cdp-reboot-the-promise/), I unpacked the promise that made Customer Data Platforms (CDPs) one of the most hyped Martech innovations of the past decade. This time, I’m digging into what happened when the hype peaked, the market flooded, and suddenly... every CDP looked exactly like the next one.
Let’s just say it wasn’t pretty. But it was predictable. And frankly, we all saw it coming. When a technology trend catches fire and every vendor wants in, you don’t get clarity. You get conformity.
---
**A feature list you’ve seen 100 times**
Identity resolution. Unified profiles. Segmentation. Activation.
That’s the core feature set of nearly every CDP you’ll find in a demo room or vendor slide deck. And it’s been that way for years.
At some point, the differentiation game shifted from substance to semantics. Vendors started competing on who could say "real-time" the most, or who had more integrations listed on their website (even if half were in beta or built six years ago).
Suddenly, “real-time” meant anything from 10 milliseconds to overnight batch processing. “Unified profile” meant either a graph-based ID system or a glorified email lookup table. Buyers were left guessing. And when everything sounds the same, nothing stands out.
Even more confusing? Every vendor claimed they were unique because of *how* they did the same things. As if rearranging the words on a pitch slide suddenly turned identity stitching into innovation.
It all began to feel like comparing smartphones by how sharp their corners are.
“If all you need is some data movement, you don’t need us. Go with whatever the cheapest possible solution is and don’t spend more than 10 grand a year.” \~ **Michael Katz**
**The RFP theater**
This feature parity created what I call **RFP Theater**.
Everyone looks great on paper.
Everyone checks the same boxes.
Everyone says yes to everything.
Until the ink dries, and then you find out your CDP can’t support your actual data model, or the integration you were promised is held together with API duct tape, or the entire solution needs a six-month implementation just to send a segment to Facebook.
I’ve seen smart teams burned not because they chose the wrong CDP, but because they were evaluating sameness with no meaningful filter. It’s like trying to pick a favorite from a lineup of clones in slightly different hoodies.
In some cases, the CDP was selected because of one slide showing integrations, only for the team to realize that those “native” integrations were actually one-way data pushes with no error logging.
This kind of gap between promise and practice became standard. And it eroded trust across the board.
---
**Analysts and acronyms to the rescue (kind of)**
As confusion grew, analysts stepped in. And in fairness, they tried to bring structure to the chaos. Forrester built waves. Gartner split CDPs into subtypes. The CDP Institute published taxonomies.
But here’s the thing. Analysts are great at naming things. They’re not always great at clarifying them.
Suddenly we had “packaged CDPs,” “composable CDPs,” “smart hubs,” and “real-time customer engines.” All vaguely true and all increasingly interchangeable.
Meanwhile, vendors played both sides. Some positioned themselves as composable when talking to IT. The same week, they pitched themselves as plug-and-play to marketing. One slide *to rule them all*, unfortunately not what Tolkien had in mind.
As a result, stakeholders inside companies began to disagree on what kind of CDP they were buying, or worse, what they’d already bought.
*"I see a lot of customers that have three or four CDPs... and in some sense, that sounds ridiculous. But if one’s for routing, one for foundation, one for orchestration, it starts to make sense. You just have to throw out the category definition."*
\~ **Derek Slager**, Amperity
([*Couch Confidentials Episode 16*](https://open.substack.com/pub/martechtherapy/p/has-the-cdp-category-failed-amperity?r=3i8xzy&utm%5Fcampaign=post&utm%5Fmedium=web&showWelcomeOnShare=false)*) 👇🏻*
Analyst reports started sounding more like menus than evaluations. Instead of filtering for fit, many teams used them to justify a decision they’d already made.
---
**Why this hurt buyers**
This saturation didn’t just make life hard for vendors trying to stand out. It made life impossible for buyers trying to make a smart decision.
Marketers were told CDPs were essential. But which kind? For which use case? And what would it take to actually get one working?
“One of the challenges that I see with organizations is that it probably crosses organizational boundaries. You need a bit of IT, data engineering, analytics… then you need a business team. And does analytics sit in business or IT? Depends on which business you're in. That's always a bit crazy.”
**\~ Mike Ferguson**, RedPoint Global
([Couch Confidentials Episode 9](https://open.substack.com/pub/martechtherapy/p/cdp-chaos-are-businesses-optimizing-bd8?r=3i8xzy&utm%5Fcampaign=post&utm%5Fmedium=web&showWelcomeOnShare=false)) 👇🏻
I’ve worked with companies who burned six figures on a CDP they couldn’t activate. Not because the tech was broken, but because no one realized they’d need to rebuild their entire data model or hire two engineers just to normalize event payloads across their stack.
Others had the right tech, but lacked executive sponsorship. Or they underestimated how much work was required to get good data in, and how little their activation tools could actually do with it.
“Why are you limiting the use of customer data just to marketing?” \~ **Kazuki Ohta**
This isn’t failure. This is misalignment. A lot of teams bought into a category without fully understanding what they were getting or what was required to make it work.
It also led to internal politics. Marketing wanted agility. Data teams wanted structure. IT wanted security. And the CDP sat in the middle like an underloved, overhyped mediator with no real owner.
---
**The turning point: When everyone hit pause**
By 2022, something changed. RFPs slowed down. CDP pilots stalled. Some companies got rid of or deprioritized their CDP projects altogether.
Not because CDPs lost relevance, but because the air was thick with sameness and sales fatigue. Buyers needed clarity. What they got was recycled clichés and overstuffed product sheets.
Some decision-makers started asking: “Do we even need a CDP? Or did we just get caught up in the hype?”
At some point, every category goes through this phase. But for CDPs, it came fast. The very thing that made the idea powerful, its universality, became a liability. Everyone needed a CDP. No one agreed on what that meant.
There’s still value in the idea, but the delivery needs a serious rethink.
In Part 3 of the #CDPReboot series, I’ll dive into why the real problem wasn’t the platforms at all. It was us, our blind spots, our structures, and our unwillingness to admit that no piece of software could save a dysfunctional operating model. CDPs didn’t fail. They just revealed the cracks we were hoping to pave over with tech. And once the illusion wore off, all that was left was the hard part: facing the reality of our own Martech decisions. It was us: the buyers, the teams, the org charts, the expectations.
CDPs didn’t fail. They just weren’t magic.
Interested in reading Part 3 of this series? **Subscribe and get notified** when it’s published. 👇🏻
**Further Reading:**
- [Part 1: ](https://www.martechtherapy.com/the-cdp-reboot-the-promise/)[*The Promise – Why CDPs were supposed to fix everything*](https://www.martechtherapy.com/the-cdp-reboot-the-promise/)
- [Part 3: ](https://www.martechtherapy.com/the-cdp-reboot-the-disillusionment/)[*The Disillusionment - Why tech wasn’t the problem*](https://www.martechtherapy.com/the-cdp-reboot-the-disillusionment/)
- [Part 4: ](https://www.martechtherapy.com/the-cdp-reboot-the-turning-point/)[*The Turning Point - Will CDPs evolve, dissolve, or disappear?*](https://www.martechtherapy.com/the-cdp-reboot-the-turning-point/)
### Is it still safe to trust US cloud tools with your data?
URL: https://www.martechtherapy.com/is-it-still-safe-to-trust-us-cloud/
Last updated: 2025-10-09T19:47:38.000Z
What happens when your customer data is governed by the wrong jurisdiction?
In this episode of *Couch Confidentials*, I sit down with , CEO and co-founder of DinMo, a composable CDP vendor headquartered in Paris. With growing political tensions between the US and Europe, and cities like Amsterdam actively moving away from US-hosted platforms, I wanted to understand whether it’s still safe—or smart—for European companies to continue relying on US-based cloud tools.
Oussama offers a candid look at the risks European businesses face when their data leaves the continent, and why composable, locally governed architectures are gaining traction. We also talk about building privacy-first tools, data sovereignty, and what it takes to offer enterprise-grade CDP capabilities without compromising on control.
This episode is equal parts geopolitics, growth strategy, and a reminder that where your data lives, really does matter.
🇫🇷 Bonus: Oussama might just convince you to drop by his Paris office—if the croissants don’t lure you in first.
## Useful links:
- Learn more about DinMo: https://www.dinmo.com/
- Follow me on LinkedIn: https://www.linkedin.com/in/matthewniederberger/
---
Don’t miss my next podcast, subscribe today 👇🏻
### The CDP Reboot: The Promise
URL: https://www.martechtherapy.com/the-cdp-reboot-the-promise/
Last updated: 2025-10-09T19:47:38.000Z
This is Part 1 of my four-part #CDPReboot series, where I take a critical look at the evolution, saturation, and potential rebirth of the Customer Data Platform (CDP) category.
In this article, I explore the promise that launched the CDP category: what it was supposed to solve, why it caught fire so quickly, and how that same momentum led us into murkier territory. It all started with good intentions, a mess of Martech tools, and a lot of scattered data pipelines.
---
**The Context: Data fragmentation was killing marketing**
So, in the early 2010s, I watched marketing departments struggle with a brutal paradox. More digital touchpoints than ever (websites, apps, social, email, CRM, in-store, IoT), yet fewer meaningful insights. Customer data was locked in silos. Each team owned a piece of the puzzle, but no one had the full picture.
The rise of the cloud didn’t fix the fragmentation. Let’s be honest, it made it worse. Tools like Salesforce, Google Analytics, Mailchimp, Shopify, and Zendesk helped teams move faster, but also created dozens of parallel universes of customer data. Each team had its own login, its own reports, its own version of the truth.
This led to conflicting metrics, duplicated messaging, and a creeping sense that despite all our fancy tools, we were flying blind. What we needed wasn’t another dashboard. We needed a customer brain. Something to connect the dots across systems and tell us who we were talking to, where, and why it mattered.
And we needed it yesterday. Marketing wanted a miracle; IT offered a backlog ticket.
---
**Enter the CDP: A unifying vision**
In 2013, David Raab coined the term "Customer Data Platform" to describe a new kind of system: one that could collect, unify, and activate customer data—with marketing in the driver’s seat.
A CDP, as originally defined, would:
- Ingest first-party data from multiple sources
- Build persistent, unified customer profiles
- Make those profiles accessible to other systems for activation
- Be owned and operated by the marketing team
Not by IT. Not by data science. Not by a product manager three levels removed from campaign goals. Finally, marketing could own its data, its audiences, and its outcomes.
This wasn’t just another analytics tool. It was pitched as the operational layer we’d been missing. A system of record for audiences. A control tower for customer experiences.
By 2016 to 2017, early players like BlueConic, mParticle, Tealium, Lytics, and Segment started gaining traction. Some leaned developer-friendly, others emphasized marketer accessibility. But they all promised to solve the same existential problem: your customer data is a mess, and we’re here to clean it up.
---
**Why the promise resonated so strongly**
Timing was everything. GDPR was looming. Third-party cookies were showing cracks. Most stacks had more overlap than a bad Venn diagram.
CDPs didn’t just sound useful. They sounded urgent. And they offered enough flexibility to appeal across the board:
- If you were data-driven, CDPs looked like a warehouse-lite
- If you cared about compliance, CDPs promised consent-aware activation
- If you were campaign-led, CDPs enabled real-time segmentation
For enterprise buyers, it felt like data independence, without a six-quarter IT roadmap. For mid-market brands, it was a way to move faster, look smarter, and finally stand out in crowded inboxes and ad auctions.
Even analysts started paying attention. Forrester published waves. Gartner invented acronyms. By 2018, CDPs weren’t just another tool. They were a category.
If you didn’t have a CDP slide in your board deck, were you even doing Martech?
> “I’m not even sure CDP should be called a category. It’s a weird label that tries to cast too wide a net—just because it all deals with customer data.” `~ `**Keanu Taylor**
---
**The cracks behind the curtain**
Even at the height of CDP-mania, the cracks were visible.
“The big problems of yesterday are today’s small problems.” \~ **Michael Katz**
There was no shared definition. Some vendors called themselves CDPs because they collected events. Others because they managed segments. Some leaned hard into activation. Others tried to swallow your entire data stack.
Let’s be honest. More than a few tools started slapping “CDP” on their homepage like it was a clearance sticker at a data warehouse fire sale without changing much else. Tag managers called themselves CDPs. Email tools did it too. One platform basically renamed its audience table and declared itself reborn.
Confusion was inevitable. Worse, it was profitable. So it spread.
---
**And yet... it worked (at first)**
Despite all this, early adopters did see results. Retailers used CDPs to improve cart recovery. Travel companies built dynamic journeys. Media brands centralized consent and preferences.
These weren’t flukes. They proved that the core concept had legs, even if execution varied wildly. The trouble wasn’t that CDPs didn’t work. It was that they started working differently for everyone, and no one could quite explain why.
So where does that leave us? Somewhere between optimistic and over it. The category didn’t implode—but something in us shifted. The doubt set in, and the pattern started to repeat. We’d seen this before.
In Part 2 of the #CDPReboot series, I’ll take a closer look at what happened when the hype peaked and differentiation collapsed. CDPs went from rising stars to lookalike vendors in record time. I’ll dig into the bloat, the confusion, and the paralysis that crept in for buyers.
---
Make sure to **subscribe and get notified** when Part 2 of The CDP Reboot is published 👇🏻
**Further Reading:**
- [Part 2: ](https://www.martechtherapy.com/the-cdp-reboot-the-stall/)[*The Stall - When every CDP started looking the same*](https://www.martechtherapy.com/the-cdp-reboot-the-stall/)
- [Part 3: ](https://www.martechtherapy.com/the-cdp-reboot-the-disillusionment/)[*The Disillusionment - Why tech wasn’t the problem*](https://www.martechtherapy.com/the-cdp-reboot-the-disillusionment/)
- [Part 4: ](https://www.martechtherapy.com/the-cdp-reboot-the-turning-point/)[*The Turning Point - Will CDPs evolve, dissolve, or disappear?*](https://www.martechtherapy.com/the-cdp-reboot-the-turning-point/)
### Has the CDP category failed? Amperity’s CTO Derek Slager weighs in.
URL: https://www.martechtherapy.com/has-the-cdp-category-failed-amperity/
Last updated: 2025-10-09T19:47:39.000Z
Nine years ago, nobody had a unified customer view, yet every consumer brand wanted one. So why was it so hard to build?
In this episode of [**Martech Therapy**](https://www.linkedin.com/feed/?ref=martechtherapy.com)'s podcast Couch Confidentials, I sit down with [**Derek Slager**](https://www.linkedin.com/feed/?ref=martechtherapy.com), Co-Founder and CTO of [**Amperity**](https://www.linkedin.com/feed/?ref=martechtherapy.com), to dive deep into the evolution (and limitations) of Customer Data Platforms. Derek shares how Amperity grew out of the frustration that no one had truly solved the “customer 360” problem, and why that challenge still haunts brands today.
**“We’ve always been a little out of place in the CDP category. Our obsession is getting the data right, not just activating it.” \~ Derek Slager**
We talk about what sets Amperity apart from the typical CDP crowd, and how the Seattle tech mindset, laid-back but deeply technical, influenced the way his team built a durable foundation for customer data.Curious about what we talked about?
- Why Amperity didn’t start with a CDP label
- How the market converged into a CDP “black hole”
- The messy truth about data quality in AI
- Seattle vs. Silicon Valley tech culture (and why one prefers Subarus)
- What’s next for the Customer Data Cloud
And yes, we pronounce “Slager” the Dutch way 🇳🇱
Don’t miss my next episode. 👇🏻
### Why I’m rebooting the CDP conversation...
URL: https://www.martechtherapy.com/why-im-rebooting-the-cdp-conversation/
Last updated: 2025-10-09T19:47:39.000Z
The Customer Data Platform (CDP) category was built on a promise, clean, unified data and a single view of the customer. For a while, it looked like it might actually deliver. Then came the vendor land grab, the copycat features, and the acronyms no one could keep straight.
As a longtime CDP consultant, I’ve seen the best and worst of it, on the ground, inside orgs, in meetings where the tech made sense and where it absolutely didn’t.
So I’ve decided to do something about it.
This four-part blog series, ***The CDP Reboot***, dives into how we got here, what went wrong, and what comes next. It’s written for marketers, data folks, and tech buyers who want more than vendor gloss.
**Here’s what the series covers:**
- Part 1: [***The Promise***](https://www.martechtherapy.com/the-cdp-reboot-the-promise/)[ *| Why CDPs were supposed to fix everything*](https://www.martechtherapy.com/the-cdp-reboot-the-promise/)
- Part 2: [***The Stall***](https://www.martechtherapy.com/the-cdp-reboot-the-stall/)[ *| When every CDP started to look the same*](https://www.martechtherapy.com/the-cdp-reboot-the-stall/)
- Part 3: [***The Disillusionment***](https://www.martechtherapy.com/the-cdp-reboot-the-disillusionment/)[ *| Why the tech wasn’t the problem*](https://www.martechtherapy.com/the-cdp-reboot-the-disillusionment/)
- Part 4: [***The Turning Point***](https://www.martechtherapy.com/the-cdp-reboot-the-turning-point/)[ *| Will CDPs evolve, dissolve, or disappear?*](https://www.martechtherapy.com/the-cdp-reboot-the-turning-point/)
You can expect straight talk, light sarcasm, real-world insight, and the occasional quote from my podcast, *Couch Confidentials*. The goal: give you clarity in a category that’s become anything but.
[Subscribe now](#/portal/signup)
📬 **Subscribe now** to get each part as it drops.
🎙️ **Podcasts** are [live on Substack](https://martechtherapy.substack.com/podcast) now too.
Thanks for reading. And if you’ve already had a run-in with “RFP Theater,” I’d love to hear your story.
### Is your website privacy compliant? 74% aren’t. Privado's Vaibhav Antil tells all.
URL: https://www.martechtherapy.com/is-your-website-privacy-compliant-1e0/
Last updated: 2025-10-09T19:47:39.000Z
Is your website privacy compliant? 74% aren’t. Privado's Vaibhav Antil tells all.
0:00
/200
1×
Had a great chat with Vaibhav Antil, co-founder of Privado.ai, about the evolving role of privacy in digital marketing—and why it’s no longer just a checkbox. We explored how Privado is helping brands operationalize privacy at the code level, detect silent compliance failures, and shift from reactive governance to embedded safeguards. Vaibhav offered a sharp take on the tension between marketing, legal, and engineering—and why privacy is fast becoming a foundational layer for customer trust, not a post-launch fix. We also touched on the surprising results from their State of Website Privacy report, the quiet rise of privacy litigation in the U.S., and why consent banners are often false comfort.
A few quotes still echo:
- “Privacy is like nutrition labeling for your digital product.”
- “Marketing creates the risk. Legal owns it. But neither controls it. That’s broken.”
- “Companies are blocking scripts and losing data, but they’re still non-compliant.”
- “Marketers need tools, not legalese. Privacy needs to run in the background, not hijack campaigns.”
Listen in and let me know—how privacy-ready is your stack?
#martech #privacylaws #cdp #digitalcompliance #privado #privacyengineering #cookieconsent #firstpartydata #couchconfidentials #marketingtechnology #podcast
### Is AI the end of Martech complexity? Dojo AI founders explain
URL: https://www.martechtherapy.com/is-ai-the-end-of-martech-complexity-8d1/
Last updated: 2025-10-09T19:47:39.000Z
Is AI the end of Martech complexity? Dojo AI founders explain
0:00
/200
1×
In this episode of **Couch Confidentials**, I sat down with **Duarte Garrido** and **Antonio Alegria** from **Dojo AI** to talk about one of the biggest problems in marketing today—**too many tools, not enough results**. With over **15,000 marketing technology solutions** on the market, are we actually making things better, or just making marketing more complicated?
**What We Covered in This Episode:**
**Are Martech tools helping marketers—or making them data engineers?** Right now, marketing teams spend more time fixing broken tracking, debugging integrations, and managing data than actually crafting campaigns. AI might finally put an end to this.
**Why “integrated marketing” is still a myth.** Everyone talks about omnichannel strategies, but in reality, most marketing stacks are **fragmented and disconnected**. We discuss whether AI can finally bridge the gap and make true integration possible.
**CMOs have the shortest tenure in the C-suite.** With unrealistic expectations, endless data challenges, and increasingly complex tech stacks, marketing leaders are often set up to fail. But what if AI could automate the grunt work and free them up to focus on **growth, creativity, and strategy**?
**Do we really need 15,000 Martech tools?** We even joked about **calling Scott Brinker** to verify just how many tools are out there. But the real question is: do we need **more** tools, or do we just need better ways to make them work together?
### Marketers are ignoring 95% of their customers – Are you one of them? (Feat. Tommy Sowerby)
URL: https://www.martechtherapy.com/marketers-are-ignoring-95-of-their-add/
Last updated: 2025-10-09T19:47:40.000Z
Marketers are ignoring 95% of their customers – Are you one of them? (Feat. Tommy Sowerby)
0:00
/200
1×
In this episode of Couch Confidentials, I sit down with Tommy Sowerby to challenge everything we think we know about anonymous users in marketing. With 85-95% of website visitors remaining unidentified, are we missing massive opportunities by focusing too much on known users?
Tommy, a SaaS marketing expert with experience at Tealium and Relay42, shares his candid take on:
✅ Why anonymous users are an untapped revenue goldmine
✅ How attribution and personalization are evolving in a privacy-first world
✅ The real impact of third-party cookie deprecation (and what marketers should do next)
✅ Whether we’re heading towards a Europe-only SaaS ecosystem
If you’re still relying on old-school marketing attribution models, this episode is for you!
Listen now and let us know: Are marketers too obsessed with tracking identity instead of engaging the right audience? Drop your thoughts in the comments!
Don’t forget to like, subscribe, and hit the bell icon so you never miss an episode of Couch Confidentials!
Follow Tommy Sowerby [https://www.linkedin.com/in/tommysowerby/](https://www.linkedin.com/in/tommysowerby/?ref=martechtherapy.com)
Podcast Playlist ➡️ https://www.youtube.com/playlist?list=PLyI45T6PyFaKznamDXT4EwbeHUPmZywwd Follow me on LinkedIn for More Martech Insights! ➡️ https://www.linkedin.com/in/matthewniederberger/
### Marketing Operations isn’t just about tools, it’s about strategy, people & process!
URL: https://www.martechtherapy.com/marketing-operations-isnt-just-about-43a/
Last updated: 2025-10-09T19:47:40.000Z
Marketing Operations isn’t just about tools, it’s about strategy, people & process!
0:00
/200
1×
In this episode of *Couch Confidentials*, I sit down with **Odd Morten Sørensen**, Marketing Operations Consultant at PlayMOps, to talk about the **real challenges of Martech implementation**. But before we even got into that, we had an unexpected personal connection—turns out we had a **mutual friend in the Norwegian Navy**! I shared a short clip of that moment yesterday, but the full conversation is even better.
**What we covered in this episode:**
•The **SOPP framework**: Strategy, Organization, People, Process
• Why **marketing strategy should never exist in isolation** from the business strategy
•The biggest **reasons Martech investments fail** (hint: it’s usually not the tech!)
• The problem with **cross-department misalignment and “the whisper game” effect**
• Why **KPIs often work against collaboration** instead of supporting it
Too many companies think a **new tool will fix everything**, but as Odd puts it, **“What gets measured gets delivered”**—and if your org isn’t measuring the right things, the tech won’t save you. We also talk about **how to break down silos, get leadership buy-in, and ensure Martech is actually delivering business value**.
This one is packed with insights for **Marketing Ops leaders, CMOs, and anyone frustrated by tech that doesn’t live up to its promise**. Hit play and let’s dive in!
**Timestamps:**
0:00 - Welcome & Intro
1:30 - The Norwegian Navy story (how we realized we had a mutual friend!)
4:45 - Why SOPP (Strategy, Organization, People, Process) matters more than the latest tool
12:15 - How cross-functional silos kill Martech success
19:30 - What KPIs should actually measure
26:40 - Leadership buy-in and the future of Marketing Ops
### Treasure Data didn’t start as a CDP—we evolved into one. And that makes a huge difference.
URL: https://www.martechtherapy.com/treasure-data-didnt-start-as-a-cdpwe-047/
Last updated: 2025-10-09T19:47:40.000Z
Treasure Data didn’t start as a CDP—we evolved into one. And that makes a huge difference.
0:00
/200
1×
Had an incredibly insightful conversation with **Kazuki Ohta**, the co-founder and CEO of **Treasure Data**, about the evolving CDP landscape, the ambitious **Trade-up Program**, and even some surprising macroeconomic insights into Japan’s workforce and AI.
Kazuki’s unique perspective on the **real role of a CDP** (hint: it’s much more than just marketing) and his approach to solving **failed implementations** makes this one a must-listen for anyone in MarTech and data.
We covered a lot of ground, from how **Treasure Data scales globally**, to **why CDPs fail**, to **what Japan’s declining birth rates mean for AI adoption in the workforce**. A true thought leader, Kazuki didn’t hold back on sharing his vision.
### Let's talk about the outcome economy! My chat with Alistair Croll & Sean Power
URL: https://www.martechtherapy.com/lets-talk-about-the-outcome-economy-e69/
Last updated: 2025-10-09T19:47:40.000Z
Let's talk about the outcome economy! My chat with Alistair Croll & Sean Power
0:00
/200
1×
In this conversation, Alistair Croll and Sean Power discuss the challenges and changes in the publishing industry, particularly focusing on the disconnect between authors and their audiences. They explore the financial implications of traditional publishing models, the potential of direct sales, and the evolving landscape of content consumption, including audiobooks and the impact of AI on copyright and content ownership. The discussion also touches on the importance of web analytics and customer data in understanding market dynamics and driving innovation. In this conversation, the speakers explore the themes of innovation, education, and the impact of AI on human creativity and the economy. They discuss the importance of system awareness, the role of education in fostering creativity, and the challenges posed by risk-taking in business. The conversation also delves into the attention economy in an AI-driven world, the shift towards outcome-based learning, and the evolving relationship between humans and AI. Ultimately, they emphasize the need for a shared understanding of values and goals in navigating the complexities of the modern information landscape.
### CDP Chaos: Are businesses optimizing or abandoning their investments? A chat with Mike Ferguson
URL: https://www.martechtherapy.com/cdp-chaos-are-businesses-optimizing-bd8/
Last updated: 2025-10-09T19:47:41.000Z
CDP Chaos: Are businesses optimizing or abandoning their investments? A chat with Mike Ferguson
0:00
/200
1×
Had the pleasure of sitting down with **Mike Ferguson** from **Redpoint Global** for a relaxed but insightful conversation on Couch Confidentials. We dove into the *three R’s of customer experience*—**Recognition, Relevance, and Right Time**—and how they shape the way brands interact with their customers in real time .
Mike shared some great insights on **how CDPs can directly impact paid media match rates**, demonstrating how enhancing customer data leads to higher targeting accuracy and better campaign ROI . We also tackled some critical industry questions:
•**Are CDPs delivering on their promise?** Many companies struggle to extract full value from their investments—should vendors be doing more to ensure success?
•**Is the CDP market in turmoil?** As implementation rates decline, are businesses optimizing what they already have instead of adopting new solutions?
•**What’s next for customer data management?** With AI and real-time data processing advancing, how will personalization evolve beyond just identifying customers?
And of course, we had some laughs along the way—especially about *whether brands actually recognize you when you walk in or if they just pretend after you leave* .
Would love to hear your thoughts! Are brands truly getting better at *right-time* engagement, or is it just better tracking in disguise?
### Timo Dechau on why analytics tracking is a design problem, not a technical one
URL: https://www.martechtherapy.com/timo-dechau-on-why-analytics-tracking-474/
Last updated: 2025-10-09T19:47:41.000Z
Timo Dechau on why analytics tracking is a design problem, not a technical one
0:00
/200
1×
In this conversation, Matthew Niederberger and Timo discuss the complexities of data analytics, emphasizing the importance of creating effective tracking plans and analytics setups. They explore the evolution of data collection strategies, the significance of aligning analytics with business goals, and the necessity of fostering a data-driven culture within organizations. Timo shares insights on leveraging AI for analytics, the future of data implementation, and the role of books in knowledge sharing. The discussion also touches on innovative marketing techniques and the protection of intellectual property in the age of AI.
# Takeaways
- Data collection should focus on business insights, not just clicks.
- Creating a tracking plan is essential for effective analytics.
- Analytics setups must align with business strategy for success.
- A culture of data refinement is crucial for effective analytics.
- Data quality directly impacts business decisions and outcomes.
- AI can significantly enhance the process of creating tracking plans.
- The future of analytics may involve more automation and less human intervention.
- Books remain a valuable resource for knowledge sharing in the analytics field.
- Innovative marketing techniques can drive business growth.
- Protecting intellectual property is increasingly important in the digital age.
# Chapters
00:00 The Evolution of Data Tracking
03:34 Analytics Setup: A Strategic Approach
06:25 Integrating Business Strategy with Analytics
09:26 The Importance of Data Culture
12:37 Data Collection vs. Actionable Insights
15:33 Leveraging AI for Data Analysis
18:35 The Future of Data and Book Publishing
28:50 Navigating Data Engineering Literature
32:37 Innovative Marketing Techniques and Growth Hacking
37:22 The Future of AI in Analytics
44:36 Rethinking Analytics Implementation
48:34 Inspiration and Future Directions
### Hightouch's AI Decisioning, what will this mean for marketers? A chat with Tejas Manohar
URL: https://www.martechtherapy.com/hightouchs-ai-decisioning-what-will-877/
Last updated: 2025-10-09T19:47:41.000Z
Hightouch's AI Decisioning, what will this mean for marketers? A chat with Tejas Manohar
0:00
/200
1×
In this episode of Couch Confidentials, host Matthew Niederberger interviews Tejas Manohar, co-founder of Hightouch. They discuss the evolution of customer data platforms (CDPs) and the innovative AI Decisioning product. Tejas shares insights on the need for disruption in the CDP space, the dynamics of founding a tech company, and how AI is transforming marketing strategies. The conversation also touches on the potential of retail media networks and the future direction of Hightouch as a leader in the marketing technology landscape.
## Takeaways
- Tejas Manohar emphasizes the importance of disrupting traditional CDP models.
- Hightouch's growth is attributed to strong founder relationships and shared vision.
- AI Decisioning is designed to optimize marketing decisions using reinforcement learning.
- Marketers can set specific goals for AI Decisioning to enhance customer engagement.
- The platform allows for continuous learning and adaptation based on user interactions.
- Retail media networks present new revenue opportunities for companies.
- AI Decisioning simplifies campaign setup and execution for marketing teams.
- The integration of AI in marketing is seen as a productivity booster, not a job threat.
- Hightouch aims to educate the market on practical AI applications in marketing.
- The evolution of Hightouch reflects a commitment to composable solutions in the marketing tech space.
### A chat with Keanu Taylor, from The Martech weekly subscriber to Global Head of Research
URL: https://www.martechtherapy.com/a-chat-with-keanu-taylor-from-the-b78/
Last updated: 2025-10-09T19:47:41.000Z
A chat with Keanu Taylor, from The Martech weekly subscriber to Global Head of Research
0:00
/200
1×
In this engaging conversation, Keanu Taylor, the global head of research at The Martech Weekly, discusses his journey into the world of marketing technology, the evolving landscape of customer data platforms (CDPs), and the importance of establishing standards within the industry through the Marketing Technology Excellence Center (MTEC). He emphasizes the shift towards composable solutions, the role of AI in enhancing marketing strategies, and offers valuable advice for brands and professionals navigating the martech space.
# Takeaways
- Keanu Taylor's unique name is inspired by Keanu Reeves.
- The Martech Weekly started as a passion project and has grown significantly.
- The martech industry is filled with fluff and confusion, which The Martech Weekly aims to clarify.
- Choosing topics to cover involves looking for new, novel, or noteworthy developments.
- The CDP market is currently facing significant challenges and changes.
- Composable solutions are becoming more popular as companies seek tailored tech stacks.
- MTEC aims to create standards in various martech domains to improve industry practices.
- Engaging with the martech community is crucial for personal and professional growth.
- AI is being utilized in innovative ways to enhance marketing strategies.
- Understanding objectives is key to effectively leveraging martech solutions.
# Sound Bites
- "The CDP category has been ill-defined."
- "Always start with the objective."
- "Engage with the community."
# Chapters
00:00 Introduction to Keanu Taylor
02:41 The Journey to Martech Weekly
05:20 Navigating the Martech Landscape
08:24 The CDP Conundrum
11:26 The Shift Towards Composable Solutions
14:31 Broadening Perspectives in Martech
17:24 Introducing MTEC: A New Initiative
20:20 The Need for Standardization in Martech
24:37 Inspiration Behind M-Tech
26:27 Engaging Vendors and Consultants
29:12 The Knowledge Economy in MarTech
32:06 The Evolution of CDPs
38:04 AI Innovations in MarTech
45:22 Advice for Brands and Individuals in MarTech
### The fight for privacy: Big Tech, GDPR, and zero-party data | A conversation with Stéphane Hamel
URL: https://www.martechtherapy.com/the-fight-for-privacy-big-tech-gdpr-fe3/
Last updated: 2025-10-09T19:47:42.000Z
The fight for privacy: Big Tech, GDPR, and zero-party data | A conversation with Stéphane Hamel
0:00
/200
1×
It’s not every day you get to sit down with someone whose career has left a definitive mark on the Martech and analytics landscapes. In the latest episode of Couch Confidentials, brought to you by Martech Therapy, I had the privilege of reconnecting with Stéphane Hamel, an old friend and a thought leader whose influence spans decades, from crafting the renowned Digital Analytics Maturity Model to becoming an advocate for privacy and ethics.
Stéphane and I go way back, having first met at a Web Analytics Summit in Amsterdam during the days when Webtrends was a huge player (yes, that long ago!). Fast forward to today, and his work continues to challenge the norms of how businesses handle data and rethink their responsibilities in a world shaped by privacy regulations and Big Tech power plays.
Our conversation explored the stark differences in how North America and Europe approach data privacy. Stéphane noted that Europe’s GDPR has set the gold standard for protecting consumer rights, while the US faces a potential future of further deregulation, with Big Tech gaining even more freedom to operate unchecked. Stéphane said “There’s little difference between selling t-shirts and selling an election. Both rely on the same mechanisms of persuasion—one just carries far greater consequences.” The implications for users, Stéphane continues, could be dire. “If regulations continue to erode,” he remarked, “we might as well delete the word ‘privacy’ from the dictionary.”
One of the most intriguing moments was when Stéphane shared a personal experience of being asked for a voice confirmation during a furniture delivery, a vivid example of how biometric data, like voice, is increasingly being leveraged. “Your voice is a biometric, and cloning it is shockingly easy,” he pointed out, raising concerns about how such sensitive data is stored, used, and protected in everyday scenarios.
Yet, amidst the challenges, there were glimpses of hope. Stéphane spoke about the potential of zero-party data models, where individuals control their own information, choosing when and with whom to share it. This shift, he believes, could represent a more ethical and sustainable path forward for both businesses and consumers.
From the alarming realities of data leaks and consumer manipulation to hopeful visions of a more privacy-conscious future, this conversation explored the responsibilities of marketers, governments, and individuals alike. As Stéphane so powerfully stated, “Marketing should be about trust. Without it, it’s just manipulation.”
Stéphane’s insights are a wake-up call, reminding us that the future of privacy is not someone else’s responsibility—it’s ours.
### Are we still comparing composable CDPs to “packaged” CDPs ?
URL: https://www.martechtherapy.com/are-we-still-comparing-composable-cdps-to-packaged-cdps/
Last updated: 2025-10-09T19:47:42.000Z
🔗 [Originally posted on LinkedIn on December 19th, 2024](https://www.linkedin.com/pulse/we-still-comparing-composable-cdps-packaged-matthew-niederberger-wzwfc/?ref=martechtherapy.com)
The CDP market is saturated with debates over composable vs. traditional approaches. Some composable vendors claim their architecture is the only viable option, citing issues like unnecessary data duplication, high upfront costs, and inflexible schemas in traditional CDPs.
While composable CDPs have introduced valuable alternatives, framing this as a zero-sum game misses the complexity of business needs. What matters most is how any composable or traditional CDP delivers value to its customers.
Because, let’s face it, the constant comparisons in **marketing narratives are becoming stale**.
Recently, I’ve seen claims that implementing traditional CDPs creates “nightmares,” ironically from vendors promoting easy migration since they use the same, albeit forked, SDKs of the vendors they are shaming. I have witnessed first-hand as one of my past clients, who was using Segment, had moved to the composable solution with my original code still in place. Don’t misunderstand me; if this delivers more value to the customer, it is a win!
However, this type of messaging oversimplifies the reality. Both traditional and composable CDPs serve distinct purposes, depending on the organization. Traditional CDPs often excel at out-of-the-box capabilities like real-time orchestration and predictive analytics supporting marketing-resource heavy organizations, while composable solutions offer flexibility for organizations with strong data infrastructure for often data-engineering resource heavy organizations.
```
The thing about comparing yourself to others all the time is that you actually end up being totally blind to your own weaknesses.
```
Choosing a CDP is not about declaring one approach superior; it’s about finding the right fit for the business. A metaphor I often use is buying a car. Is an MPV better than a sedan? It depends on your needs. Car manufacturers rarely spend time disparaging their competitors; instead, they **focus on their own strengths**. CDP vendors could learn from this approach, showcasing unique selling points like scalability, support, or integration capabilities rather than recycling tired comparisons. Even a quick scan of G2 can deliver more than a handful of USPs for various solutions, which are user-generated no-less.
That said, the composable model is not without its challenges. Soon to be released research, unfortunately not independent but sponsored by a vendor, may highlight potential hidden costs, such as compute expenses for real-time data processing or AI-driven features. While composable CDPs often dismiss the importance of real-time capabilities to align with their narrative, the increasing demand for real-time customer experiences, driven by new expectations fueled by AI (*when is the last time you waited 5-15 minutes for a response to an AI prompt*) and dynamic audiences for multi-channel journey orchestration, suggests this remains a critical consideration.
Michael Katz recently introduced the concept of CDP 2.0, highlighting how **the future of CDPs lies in differentiation**. Vendors will need to define their niches, whether that means targeting specific industries, focusing on vertical integration, or delivering unique feature sets. The market is already commodified, as demonstrated by vendors only being able to market based on composable versus packaged arguments instead of features that benefit customers. **Success will depend on demonstrating tangible value**, not clinging to outdated comparisons.
By 2025, the debate over composable vs. traditional will likely fade. Instead, the focus will shift to how individual CDPs solve specific business problems. Those who fail to adapt, whether composable or traditional, risk obsolescence. Composable pioneers like Hightouch have already proven their ability to disrupt, and I applaud them for this, but if vendors remain stuck in these comparisons, they may fall behind.
My advice to CDP vendors: stop comparing, start leading!
Customers care about results, not architectures. **The CDP industry would do well to stop the petty arguments and instead focus on building trust, solving real problems, and delivering measurable outcomes.** It’s time to move beyond the “composable vs. traditional” debate. The future belongs to those who innovate, differentiate, and create lasting value.
The post [Are we still comparing composable CDPs to “packaged” CDPs ?](https://martechtherapy.com/are-we-still-comparing-composable-cdps-to-packaged-cdps/?ref=martechtherapy.com) appeared first on [Martech Therapy](https://martechtherapy.com/?ref=martechtherapy.com).
### OneTrust and Segment Integration: A Step-by-Step Guide
URL: https://www.martechtherapy.com/onetrust-and-segment-integration-a-step-by-step-guide/
Last updated: 2025-10-09T19:47:44.000Z
### Manage data distribution to Segment destinations with ease
##
## Introduction
You have come to the right place if you want a OneTrust and Segment integration. This article will introduce two methods to leverage OneTrust within your Segment landscape—one for Free and Team plan users and one for Business plan users. The OneTrust and Segment integration will allow you to determine to which destinations you may send data while respecting the user’s consent level.
##
## OneTrust and Segment integration flow explained
The solution, in general, makes use of [Segment’s Plugin architecture for their Analytics.js SDK](https://segment.com/docs/connections/sources/catalog/libraries/website/javascript/?ref=martechtherapy.com#plugin-architecture). It functions like middleware in that you can perform specific tasks to the analytics.js functionality and payload in-flight. There are currently five types of plugins that you can create:
1. before – Executes before event processing begins. These are plugins that run before any other plugins run.
2. enrichment – Executes as the first level of event processing. These plugins modify an event.
3. destination – Executes as events begin to pass off to destinations.
4. after – Executes after all event processing completes. You can use this to perform cleanup operations.
5. utility – Executes once during the bootstrap to allow you to modify how Analytics.js works internally.
For the OneTrust and Segment integration, we will use the enrichment-type plugin.
The enrichment plugin will allow us to modify the event’s payload before being sent. In our case, we want to add either an integrations object (Free & Team plan users) or the OneTrust OptanonConsent-cookie value to the event’s context (Business plan users).
Since Free and Team plan users cannot use Destination Filters, we will leverage the [default integrations object functionality](https://segment.com/docs/guides/filtering-data/?ref=martechtherapy.com#filtering-with-the-integrations-object). The integrations object will help you control how Segment routes collected data to specific destinations. The script calls a relatively unknown Projects API integrations endpoint. Together with your write key, you can retrieve a list of active destinations set up in your workspace.
The API returns an array of your active destinations, including a name and category, both of which will be used to build the integrations object.
If the OneTrust cookie contains consent for a specific category of tags, all destinations that match that category will be assigned a value of true. Otherwise they will be set to false, preventing Segment from forwarding that data.
Business plan users have it a bit easier. Their method will only require the injection of the OneTrust cookie value, particularly the groups variable, from which Destination Filters can be built within Segment. No API call needs to be made, so this method is quicker. The location where the OneTrust cookie values are injected is the context object. The reason that we do not use the integrations object is that that would require an API call. Although the properties object would also be a feasible location, it would not match with identify calls where the properties object is replaced with a traits object.
In the end, the location does not matter; you can easily set up destination filters clearly and concisely.
###
### OneTrust and Segment integration plugin Feature overview
1. failsafes for missing OneTrust cookies.
2. Listeners for click on OneTrust consent banners to reread the OneTrust cookie and rebuild the integrations object.
3. API call to retrieve a list of active integrations (Free & Team plan solution only)
4. Plugin that allows for the integration of consent data with every page, track, and identify calls (can be extended to more call types in the code)
##
## Setting up the OneTrust and Segment integration
The requirements for setting up the OneTrust and Segment integration are as follows:
1. your Segment Workspace Analytics.js Source write key
2. our OneTrust and Segment integration plug script
3. access to the source code
4. the proper rights in the Segment to setup Destination Filters (Business plan only)
###
### Finding your Segment Workspace analytics.js write key
To find this, go into **Segment** \> **Connections** \> **Sources** and click on the Javascript source you want to implement the integration for. The key is not a secret; it can be found on any website using Segment.
Copy the write key and save it for later.
###
### Copy the OneTrust and Segment integration script
This step is essential. Please select and copy the script from our GitHub repository that works best for you. There are two scripts to choose from:
1. [OneTrust and Segment integration script for Free & Team plan users](https://github.com/tagticians/segment-onetrust-integration-api?ref=martechtherapy.com)
2. [OneTrust and Segment integration script for Business plan users](https://github.com/tagticians/segment-onetrust-integration-cookie?ref=martechtherapy.com)
Business plan users can use either script, but their script is quicker, 54 versus 116 lines of code since it does not require an API call to retrieve destination information from Segment.
Update the write key value in either script in the WEBSITE\_WRITE\_KEY constant.
###
### Set default values
Several variables can be configured. For the Free/Team tier, there is one variable besides the write key variable, and for the Business tier, there are three.
- all\_default: \[*Free/Team tier*\] Since we need to do an API call to retrieve all the destinations in the Segment account, it is wise to have a value to fall back on, just in case of an error. The failsafe, in this case, is the **All** key in the integrations object with the default value of **false**. This will prevent data from reaching any destination in case of an error. Change this value to true to reverse the effect.
- OPT\_IN: \[*Free/Team tier*\] This value will be assigned to the **Segment.io** destination allowing you to still capture data within Segment and your data warehouse storage destination. I have set the default to **true**, but feel free to adjust this if needed.
- INDOMAIN\_INSTRUMENTATION\_URL: \[*All tiers*\] If you use Segment’s CNAME cloaking feature for first-party features, change the default url to whatever you need. If not, leave it as it is.
###
### Place (or replace) the Analytics.js on your website with the new script
If you have not already placed the Segment analytics.js SDK on your website, use our OneTrust and Segment integration script instead. If you already have the Segment analytics.js SDK script, replace it with our OneTrust and Segment integration script.
We would recommend that you place the script below the OneTrust script.
Publish and test your script.
##
## Update your Destination Filters for each destination **\[Business plan only\]**
If you are on a Business plan, you can use Destination Filters to filter data based on rules. These rules can be defined per destination. Please remember to set the right filter for the correct type of destination. You should do this using OneTrust’s group ids.
- C0002:1 – consent is given for Analytics destinations. [See list of Segment Analytics destinations](https://segment.com/docs/connections/destinations/catalog/?ref=martechtherapy.com#analytics).
- C0003:1 – consent is given for Functional destinations. [See list of Segment Functional a.k.a. Personalization destinations](https://segment.com/docs/connections/destinations/catalog/?ref=martechtherapy.com#personalization).
- C0004:1 – consent is given for Targeting destinations. [See list of Segment Functional a.k.a. Advertising destinations](https://segment.com/docs/connections/destinations/catalog/?ref=martechtherapy.com#advertising).
- C0005:1 – consent is given for Social Media destinations. Segment does not have Social Media destinations; these usually fall under Advertising C0004.
###
### Step 1 – Create a New Filter
###
### Step 2 – Add conditionals to the filter
1. Select ‘Only Send Event’ option from the first dropdown.
2. Select ‘Event Field’ in the second dropdown list.
3. Type ‘onetrust’ in the field behind the ‘Event Field’ dropdown list, and it should show you the value collected in the context object.
4. Select ‘contains’ in the following field.
5. Enter the OneTrust group id relevant to the destination for which you are creating a filter.
###
### Step 3 – Test the filter
Click on Test Event to test the filter.
Make sure to test with C0002:0, C0002:1, and without. You can manually add these values in the text editor.
With C0002:1, the filter will send the event.
###
### Step 4 – Save the filter
When satisfied with the test results, save the filter.
##
### Conclusion
Although this solution requires manual effort, the results will benefit your company in several ways. It will allow you to collect data while respecting the user’s consent and significantly prevent you from failing any regulatory board audit, such as GDPR, CCPA, VCDPA, etc.
If you have any questions or suggestions on improving these scripts, please feel free to contact me via LinkedIn or the contact form.
This solution was inspired by the [Segment TrustArc integration by Chris Sperandino](https://gist.github.com/sperand-io/4725e248a35d5005d68d810d8a8f7b29?ref=martechtherapy.com).
Cover Image: [Marija Zaric](https://unsplash.com/@simplicity?utm%5Fcontent=creditCopyText&utm%5Fmedium=referral&utm%5Fsource=unsplash) on [Unsplash](https://unsplash.com/photos/white-plastic-chairs-in-close-up-photography-3XML91loIOM?utm%5Fcontent=creditCopyText&utm%5Fmedium=referral&utm%5Fsource=unsplash)
The post [OneTrust and Segment Integration: A Step-by-Step Guide](https://martechtherapy.com/onetrust-and-segment-integration-a-step-by-step-guide/?ref=martechtherapy.com) appeared first on [Martech Therapy](https://martechtherapy.com/?ref=martechtherapy.com).
### Solving GA4’s Measurement Protocol Session issue in Segment
URL: https://www.martechtherapy.com/solving-ga4s-session-issue-in-segment/
Last updated: 2025-10-09T19:47:47.000Z
Better data quality in GA4 using Segment’s GA4 Destination
##
## Introduction
This article will work as a guide to making the [Google Analytics 4 Destination](https://segment.com/docs/connections/destinations/catalog/actions-google-analytics-4/?ref=martechtherapy.com), which relies on Google’s Measurement Protocol version 2, in Segment work. Segment has created the out-of-the-box GA4 solution for its customers to the best of its ability. This is referred to as a destination. However, due to its inherent nature, Google’s Measurement Protocol lacks certain functionalities to make it work as expected. The most significant challenge is identifying sessions since the server-side payload does not send the session\_id by default.
With Segment’s Analytics.js SDK we can get it to work for client-side and server-side GA4 tracking. If you are on a Segment Team Plan, this solution will work. You only need the Segment Connections module for this solution to work.
This article was inspired by Simo Ahava’s blog post [Session Attribution with GA4 Measurement Protocol](https://www.simoahava.com/analytics/session-attribution-with-ga4-measurement-protocol/?ref=martechtherapy.com).
**To get started, let’s set our goal**: To properly track GA4 sessions using Segment’s out-of-the-box Destination from both front-end and back-end, as shown below.
I have set up an Analytics.js SDK source and a Node.js source for this guide on a dummy website. Both sources point to two separate Google Analytics 4 Destinations with the same Measurement ID. This means that data sent to these destinations will be collected using the same data stream in the same Google Analytics 4 property.
##
### Step 1 – Setting up a client-side GA4 tag for generating the cookies
To obtain the GA4 tracking session id and client id, we need to install the Google Analytics 4 tracking script client-side. In my experience, I have found that enabling the Google Tag Manager Destination is the easiest way to achieve this. Let’s go through the steps.
###
### Step 1.1 – Enable the Google Tag Manager Destination in Segment
Enable Google Tag Manager Destination in Segment
First, if you haven’t already done it, go to Google Tag Manager and create a new container. Copy the container id (eg. GTM-XXXXXXX). Then, in Segment, add Google Tag Manager as a Destination and enter the Container ID in the appropiate field. We will need this container for implementing a client-side Google Analytics 4 Configuration tag that will generate the necessary cookies.
###
### Step 1.2 Add a Google Analytics 4 Configuration tag
The next step is imporatant since it will generate the \_ga and the \_ga\_ cookies for us, which contain the values we need to make Measurement Protocol work properly.
Go to your Google Analytics 4 property and copy the Measurement ID you want to collect the data with. You can find the Measurement ID under:
Admin > Data Streams > (Click on the relevant Data Stream) > Copy the Measurement ID
In Google Tag Manager, add a new tag of the type Google Analytics: GA4 Configuration.
Add the Measurement ID in the Measurement ID field. Since we will be tracking Page Views using the Action mappings in the GA4 Destination in Segment, we need to disable the option ‘Send a page view event when this configuration loads’.
Finally, add the All Pages trigger (or valid consent respecting trigger) to you Google Analytics 4 Configuration tag.
Save the tag and publish the Google Tag Manager Container.
##
### Step 2 – Adjust your source code to pass along the session id and client id to Segment
The following will be slightly different for everyone. A lot depends on the frontend framework that you are using. The goal is to collect the \_ga and the \_ga\_ values from their respective cookies. Personally, I have been using the Get Cookie function on W3 for years, old habits die hard.
Thes session id can be found in the \_ga\_ where the measurement ID matches that from your Google Analytics 4 property’s data stream. In the example below, the session id is 1675243172
The client id can be found in the \_ga cookie on your root domain. In the example below, the client id is 1172149353.1675243173
Although I collect the ga\_client\_id, it is not necessary since Segment will provide a similar value. The ajs\_anonymous\_id cookie contains an anonymous identification value that, due to Segment Identity Resolution feature, works similar to Google’s client id. For the purpose of this guide, I will add the Google Analytics client id.
Add the parameters to all your analytics function calls, including the identify call if you want to use [Segment Functions](https://tagticians.com/top-5-segment-features/?ref=martechtherapy.com) to build out your customer GA4 connector.
Since I am simulating backend transaction events from a Node.js server it is imporant to remember that we need to push the Segment user id (not be confused with the GA4 client id) and/or anonymous id from the originating POST call to the server endpoint and then on to to Segment.
If you have been very attentive, you will have noticed that I am also using the integrations object to pass along the GA4 client id to Segment. [Segment’s integration object](https://segment.com/docs/guides/filtering-data/?ref=martechtherapy.com#filtering-with-the-integrations-object) is mainly used to filter source data from reaching a specific destination. However, [Segment’s identity resolution](https://segment.com/docs/profiles/identity-resolution/identity-resolution-settings/?ref=martechtherapy.com) also leverages a certain aspect of the integrations object, mainly that you can pass along the GA4 client id through it. Segment will used the forwarded GA4 client id as a default when sending data to GA4 using its destination.
Segment’s instructions on [capturing GA4’s client id as an external id](https://segment.com/docs/profiles/identity-resolution/identity-resolution-settings/?ref=martechtherapy.com#externalids).
In order for this solution to work it is not immediately necessary to adopt this approach. Having worked with Segment for so long, I do this automatically in order to prevent any data loss.
##
### Step 3 – Verify that the data is being received by Segment
The next step, before we start mapping the data to Segment’s GA4 destination, is to verify that the data is being received by Segment. Using Segment’s Debugger tab on both the Analytics.js SDK and Node.js sources show that the parameters and integrations object are properly set.
##
## Step 4 – Update GA4 Destination mappings to include the client and session id
To make sure GA4 receives the necessary data we need to map the client id and session id to each individual Action.
For previously explained reasons, I prefer to use Segment’s anonymous id as a fallback for the Google Analytics 4 Client ID field. The main value should, however, always be the client id you have started collecting.
Finally, what we have been working towards, [adding the Google Analytics 4 sesion id as an event parameter](https://developers.google.com/analytics/devguides/collection/protocol/ga4/sending-events?client%5Ftype=firebase&ref=martechtherapy.com#recommended%5Fparameters%5Ffor%5Freports) in the destination action.
##
## Step 5 – Verifying that the Session data is properly processed in GA4
When we start looking at the data using GA4 User Explorer, it becomes evident that Google’s Measurement Protocol still lacks certain capabilities. Although we have fixed Google Analytics 4 session issue using Measurement Protocol, the user’s profile remains incomplete.
Measurement Protocol has no capabilities of passing an IP address to Google Analytics 4\. It is therefore unable to determine where a user comes from. The configuration tag does have this data, and you will see users pop up on the map every so often, but this is more a gimmick than a dependable datapoint.
Segment sets the Engagement Time in Milliseconds parameter to 1 by default. I am confident that you could find a workaround for this, but the question is, is it worth the effort. Let’s wait and see what Google will offer us moving forward.
##
### Conclusion
With thanks to Simo for shedding light on how to overcome the session attribution challenge using the Measurement Protocol, I hope that I have been able to show how to overcome this in combination with Segment. Measurement Protocol version 2 will continue to have several shortcomings, but it should not deter you from tracking sessions properly in Google Analytics 4.
This workaround will take quite some effort, mainly by developers, to get the data you need. Nevertheless, I feel that by doing so, you will seriously be able to improve the data quality in Google Analytics 4 using Segment’s Google Analytics 4 Destination option.
Cover Image: [Tania Melnyczuk](https://unsplash.com/@alphabetania?ref=martechtherapy.com) on [Unsplash](https://unsplash.com/photos/white-plastic-chairs-in-close-up-photography-3XML91loIOM?utm%5Fcontent=creditCopyText&utm%5Fmedium=referral&utm%5Fsource=unsplash)
The post [Solving GA4’s Measurement Protocol Session issue in Segment](https://martechtherapy.com/solving-ga4s-session-issue-in-segment/?ref=martechtherapy.com) appeared first on [Martech Therapy](https://martechtherapy.com/?ref=martechtherapy.com).
### Tiankai Feng on why humanity is the glue that holds federated data teams together
URL: https://www.martechtherapy.com/tiankai-feng-on-why-humanity-is-the-81a/
Last updated: 2025-10-09T19:47:48.000Z
Tiankai Feng on why humanity is the glue that holds federated data teams together
0:00
/200
1×
In Episode 4 of *Couch Confidentials Powered by Martech Therapy*, host Matthew Niederberger welcomes Tiankai Feng, the author of *Humanizing Data Strategy*. Together, they explore the intersection of data, humanity, and leadership. From responding to criticism as an author to building trust in data teams and balancing technical expertise with emotional intelligence, this episode dives into the philosophy behind humanizing data. Tiankai also shares insights on the future of AI, data convergence, and his unexpected connections between music and data strategy.
If you’re passionate about data, leadership, or just curious about the human side of analytics, this episode is for you!
# **Takeaways:**
1. **Criticism Builds Resilience**: Tiankai shared how dealing with a one-star review on his book taught him the importance of focusing on the bigger picture and using criticism as an opportunity for personal growth.
2. **TAG Framework**: His concept of *Talk, Act, Guide* emphasizes that talking about data’s importance isn’t enough—leaders need to act on it and guide others to align with data-driven goals.
3. **Music and Data Connection**: Tiankai revealed how his musical background influenced his data career by balancing analytical precision with emotional storytelling, much like composing music.
4. **Trust is the Foundation**: Whether working in data or leadership, building trust—through understanding, active listening, and collaboration—is central to success.
5. **Cross-Decking Insight**: Tiankai discussed the concept of immersing oneself in other teams or departments, akin to Matthew's military-inspired “cross-pollination,” as a way to build empathy and improve collaboration.
6. **Generative AI and Team Dynamics**: While AI insights can enhance decision-making, Tiankai argued that critical human oversight and teamwork are crucial to ensure AI outcomes are meaningful and accurate.
7. **Lonely Data Teams**: Tiankai acknowledged the challenges of one-man data teams and emphasized the importance of self-marketing, relationship-building, and connecting with communities to thrive.
8. **Leadership Evolution**: The discussion highlighted the shift towards humanized, empathetic leadership, driven by trends like agile transformations, federated team structures, and data decentralization.
9. **Future Vision for Data**: Tiankai hopes for a convergence of business, AI, and data strategies by 2025, breaking down silos and fostering a unified approach to organizational goals.
10. **Creative Processes**: Despite his achievements, Tiankai remains spontaneous with his creative energy, showing that inspiration can strike unpredictably, whether for books or music.
# **Funny Quotes:**
1. “Me being Dutch, you’ll probably get an invoice in the mail pretty soon.”
2. “Talk is not enough—you have to act like it and guide others too.”
3. “If your Spotify Wrapped is exciting, imagine what a company data wrap would look like!”
4. “Humanity is the glue that holds federated data teams together.”
5. “Music can be math, but it’s also magic—and the same goes for data.”
### Lytics CEO talk XCDP, real-time user profile data at your fingertips
URL: https://www.martechtherapy.com/lytics-ceo-talk-xcdp-real-time-user-1f7/
Last updated: 2025-10-09T19:47:48.000Z
Lytics CEO talk XCDP, real-time user profile data at your fingertips
0:00
/200
1×
In this episode, Matthew Niederberger sits down with James McDermott, CEO of Lytics, to dive into the game-changing potential of their new XCDP (Experience Customer Data Platform). From seamless integration with WordPress and Drupal to tackling the complexities of real-time personalization, discover how XCDP is poised to redefine the Martech landscape. Key topics covered:
1. What sets XCDP apart from traditional CDPs
2. The challenges of real-time data activation and how XCDP addresses them
3. The intersection of user data, content graphs, and scalable personalization
4. Thoughts on data privacy, consent, and evolving Martech strategies for 2025
Don’t miss this insightful discussion about the future of Martech and the role of XCDP in shaping it!
# **Soundbites**
- “The promise of personalization is real, and 2025 is the year we’ll finally start delivering on it.”
- “With XCDP, personalization is no longer a theory—it’s actionable at scale.”
- “95% of interactions happen with anonymous users. How do we activate data for them?”
- “Most companies spend too much time perfecting data and forget about the value it should bring to customers.”
- “If you have $20M, go with Adobe. If not, our free tier lets you start personalization now.”
# Takeaways
- **XCDP’s Unique Selling Point**: Real-time personalization directly within CMS platforms like WordPress and Drupal.
- **Content and User Data**: XCDP combines user graphs and content graphs for more effective personalization.
- **Accessibility**: Lytics offers a free developer tier to lower the barrier to entry for businesses experimenting with personalization.
- **Market Trends**: The gap between IT and marketing teams often hinders CDP success; XCDP aims to bridge this divide.
- **2025 Vision**: Martech is shifting towards orchestration and omni-channel experiences; XCDP is leading the charge.
### Brian Clifton and Gen-Z's awareness of privacy and tracking
URL: https://www.martechtherapy.com/brian-clifton-and-gen-zs-awareness-8b7/
Last updated: 2025-10-09T19:47:48.000Z
Brian Clifton and Gen-Z's awareness of privacy and tracking
0:00
/200
1×
In this conversation, Matthew Niederberger interviews Brian Clifton, a prominent figure in the data privacy and analytics field. They discuss Brian's journey from leading Google Analytics in Europe to becoming an advocate for data privacy. The conversation delves into the shift from traditional analytics to enhanced conversions, the importance of user consent, and the challenges posed by GDPR. Brian emphasizes the need for trust between businesses and users, the significance of data quality, and the potential impact of AI on data privacy. They also explore cultural differences in data privacy attitudes and make predictions for the future of data collection and privacy regulations.
**Takeaways**
- Data privacy is becoming increasingly important in analytics.
- Building trust with users is essential for businesses.
- Enhanced conversions can be more invasive than traditional cookies.
- User consent is often misunderstood by consumers.
- GDPR has changed the landscape of data collection.
- Data quality is crucial for effective analytics.
- AI has the potential to improve data analysis but poses risks.
- Cultural attitudes towards data privacy vary across regions.
- The future of analytics will focus on privacy and purpose.
- Education on data privacy is vital for the next generation.
### Michael Katz discusses his CDP 2.0 manifesto
URL: https://www.martechtherapy.com/michael-katz-discusses-his-cdp-20-fc5/
Last updated: 2025-10-09T19:47:49.000Z
Michael Katz discusses his CDP 2.0 manifesto
0:00
/200
1×
In this inaugural episode of Martech Therapy, Matthew Niederberger interviews Michael Katz, CEO of mParticle, discussing the evolution and future of Customer Data Platforms (CDPs). They explore the importance of first-party data, the commoditization of CDPs, and the challenges faced by businesses in selecting the right solutions. The conversation emphasizes the need for collaboration between marketing and data teams, the role of the CFO in decision-making, and the impact of pricing models on customer value. Katz shares insights on the future of CDPs, including predictions for 2025 and the ongoing trends in the marketing technology landscape.
**Key takeaways:**
- MarTech Therapy is focused on navigating the complexities of marketing technology.
- The rise of CDPs has transformed how businesses manage customer data.
- First-party data is now essential for digital success.
- Commoditization in the CDP space is leading to a race to the bottom.
- Batch solutions may not meet the needs of dynamic customer experiences.
- Collaboration between data and marketing teams is crucial for success.
- CFO involvement is necessary for balanced decision-making in CDP investments.
- Built-in CDPs can lower barriers for small and medium-sized businesses.
- Pricing models should align costs with the value delivered to customers.
- The future of CDPs will see increased consolidation and convergence in the market.
### Enhancing Customer Segmentation with CDPs: Key Benefits
URL: https://www.martechtherapy.com/enhancing-customer-segmentation-with-cdps-key-benefits/
Last updated: 2024-06-03T07:24:50.000Z
Using a CDP for Improving Customer Segmentation and Targeting
##
## Introduction
Customer Data Platforms (CDPs) have become indispensable tools for modern marketers. As businesses strive to [deliver personalized experiences](https://martechtherapy.com/services/personalization/?ref=martechtherapy.com) and improve customer engagement, the role of CDPs in customer segmentation and targeting has gained significant importance. This article explores the benefits of using a CDP to enhance customer segmentation and targeting, providing insights into how these platforms can transform marketing strategies.
##
## Understanding Customer Data Platforms
A Customer Data Platform (CDP) is a marketer-managed system that creates a persistent, unified customer database accessible to other systems. Unlike traditional data management systems such as Customer Relationship Management (CRM) or Data Management Platforms (DMP), CDPs integrate data from various sources to provide a comprehensive view of the customer. This unified view enables marketers to understand customer behavior better and create more targeted marketing campaigns.
CDPs are designed to centralize customer data from multiple channels, including websites, mobile apps, email, social media, and more. This data is then used to create a single, unified view of each customer, which can be used to inform and drive personalized experiences. [Segment emphasizes the importance of accurate and up-to-date data](https://segment.com/?ref=martechtherapy.com), stating, “Businesses can have complete confidence that the data in their customer profiles is accurate, up to date, and able to drive up engagement rates”
##
## The Importance of Customer Segmentation and Targeting
Customer segmentation involves dividing consumers into groups based on specific criteria such as interests, behavior, or demographics. Effective segmentation allows marketers to target these groups with relevant content, improving engagement and conversion rates. However, without a CDP, marketers often face challenges in accurately segmenting their audience due to fragmented data sources and limited insights.
Segmentation is crucial for delivering personalized marketing campaigns that resonate with customers. [Tealium highlights the growing expectations for personalized interactions](https://tealium.com/most-trusted-cdp/?ref=martechtherapy.com), noting that “71% of customers expect personalized interactions and 76% feel frustrated if a company doesn’t deliver a tailored experience”. This level of understanding is essential for creating meaningful connections with customers and driving long-term loyalty.
##
## How CDPs Enhance Customer Segmentation
CDPs centralize customer data from multiple sources, creating comprehensive and accurate customer profiles. Marketers can identify trends and patterns by analyzing behavioral data, enabling more precise segmentation. For example, a CDP can help segment users who have abandoned their shopping carts, live in specific regions, or have shown interest in particular products. This level of granularity allows for highly targeted marketing campaigns.
One of the key benefits of a CDP is its ability to anticipate customer needs and target the right audiences. [mParticle underscores the importance of a tailored data strategy](https://www.mparticle.com/resources/customer-data-integration-mp/?ref=martechtherapy.com), stating, “Creating a customer data strategy is critical for long-term success, and the path to creating your data strategy is bespoke to your business”. This capability enables businesses to forecast demand, understand customer preferences, and tailor their marketing efforts accordingly.
##
## Benefits of Improved Targeting with CDPs
Using a CDP for customer segmentation and targeting offers several benefits:
###
## Personalized Marketing Campaigns
CDPs enable marketers to create personalized campaigns tailored to specific audience segments. Personalized marketing campaigns can significantly improve customer engagement and conversion rates. [Segment’s platform allows businesses to leverage accurate data for better engagement](https://segment.com/?ref=martechtherapy.com), ensuring that marketing messages are relevant and resonate with the target audience.
###
## Increased Customer Engagement and Conversion Rates
Targeted campaigns are more likely to resonate with customers, leading to higher engagement and conversion rates. Personalized interactions can help close more sales and foster customer loyalty. [Amperity emphasizes the critical need for understanding customers](https://amperity.com/blog/most-cdps-are-not-actually-platforms-for-customer-data?ref=martechtherapy.com), stating, “Businesses fail without understanding their customers. This has always been true, but the urgency is greater now”. By delivering relevant content, businesses can build stronger customer relationships and drive repeat business.
###
## Enhanced Customer Satisfaction and Loyalty
By delivering personalized experiences, businesses can improve customer satisfaction and foster loyalty. Customers appreciate when brands understand their needs and preferences, leading to a more positive customer experience.[ Tealium’s insights on customer expectations highlight the importance of personalization](https://tealium.com/most-trusted-cdp/?ref=martechtherapy.com) in driving customer satisfaction and loyalty.
###
## Real-Time Data Analysis for Dynamic Targeting
CDPs provide real-time data analysis, allowing marketers to adjust their strategies based on customer behavior. This dynamic targeting ensures that marketing efforts remain relevant and effective. Amperity also points out that “[The key to unlocking the value of your customer data is making it accessible and actionable across your business tools](https://amperity.com/faq?ref=martechtherapy.com)“. This capability allows businesses to stay agile and responsive to changing customer needs.
##
## The Role of AI in the Future of CDP Operations
Artificial intelligence (AI) is set to revolutionize CDP operations by enhancing data management and segmentation capabilities. AI-driven CDPs can leverage predictive analytics and machine learning to identify patterns and predict customer behavior. This allows for more accurate segmentation and personalized recommendations. [Zendesk highlights the efficiency of AI](https://segment.com/customer-data-platform/?ref=martechtherapy.com), noting that “AI and machine learning can automate support tasks, providing faster resolutions and freeing up agents to focus on complex issues”.
AI can also help businesses automate customer insights and personalized recommendations. By analyzing vast amounts of data, AI can identify trends and provide actionable insights that can inform marketing strategies. This level of automation can significantly improve the efficiency and effectiveness of marketing efforts.
##
### Conclusion
In conclusion, Customer Data Platforms (CDPs) offer significant benefits for improving customer segmentation and targeting. By centralizing customer data, creating comprehensive profiles, and leveraging AI-driven insights, CDPs enable marketers to deliver personalized experiences that drive engagement and loyalty. As businesses prioritize personalization, the role of CDPs in modern marketing strategies will only grow in importance.
Explore the potential of Customer Data Platforms (CDPs) for your business. By leveraging their power, you can enhance your marketing strategies, improve customer engagement, and drive business growth. If you want more information on CDPs and how they can benefit your organization, please [contact us](https://martechtherapy.com/contact-us/?ref=martechtherapy.com) and learn how we can help. Martech Therapy offers [various services](https://martechtherapy.com/services/?ref=martechtherapy.com) and [interim solutions](https://martechtherapy.com/services/interim-solutions/?ref=martechtherapy.com) to help you leverage your Martech stack.
Cover Image: [Brett Jordan](https://unsplash.com/@brett%5Fjordan?ref=martechtherapy.com) on [Unsplash](https://unsplash.com/photos/white-plastic-chairs-in-close-up-photography-3XML91loIOM?utm%5Fcontent=creditCopyText&utm%5Fmedium=referral&utm%5Fsource=unsplash)
The post [Enhancing Customer Segmentation with CDPs: Key Benefits](https://martechtherapy.com/enhancing-customer-segmentation-with-cdps-key-benefits/?ref=martechtherapy.com) appeared first on [Martech Therapy](https://martechtherapy.com/?ref=martechtherapy.com).
### Why Freelance Martech Consultants Should Embrace Specialization
URL: https://www.martechtherapy.com/why-freelance-martech-consultants-should-embrace-specialization/
Last updated: 2025-10-09T19:47:49.000Z
Navigating Specialization in the Martech Ecosystem
##
## Introduction
In today’s world of Marketing Technology (Martech), specialization has become essential for [freelance Martech consultants](https://martechtherapy.com/the-growing-demand-for-freelance-data-talent/?ref=martechtherapy.com) aiming to stand out. As the Martech landscape continues to grow with new tools and solutions, focusing on niche expertise can provide significant advantages. This article explores the impact of specialization on Martech roles, the role of Martech vendors, and strategies for thriving in a crowded market as a freelance Martech consultant.
This article is inspired by [Brad Traversy’s video on specialization](https://www.youtube.com/watch?v=ImSjJwzqAss&ref=martechtherapy.com). While Traversy’s video focuses on the programming field, the benefits of specialization he discusses are also highly relevant to Martech consultants. By concentrating on a particular niche, whether in programming or Martech, professionals can achieve greater depth, enhance their marketability, and deliver superior client results.
“There’s nobody on the planet that can learn and master every technology. In the real world, specialization is what will benefit you most.”
\~ *Brad Traversy*
##
### **Specialization is all about Depth**
Specialization allows freelance Martech consultants to develop deep expertise in specific tools or platforms, leading to more effective implementations and problem-solving. For instance, mastering Customer Data Platforms (CDPs) or Ad Platforms can help consultants deliver superior results. Specialization provides a competitive edge, especially as composable solutions become more prevalent. By focusing on a particular technology stack, consultants can distinguish themselves from generalists who may lack the same level of depth. Aligning with market demand ensures that consultants possess skills that are in high demand, making them more attractive to potential clients.
Additionally, specialization offers adaptability. A strong foundation in one area makes it easier to learn and transition to related technologies. This flexibility is crucial in the ever-evolving Martech landscape, where new tools and trends continuously emerge.
As Brad Traversy aptly points out:
> “Quantity doesn’t equal quality in the tech learning sphere. It’s not about racking up certificates or boasting about how many languages you’ve dabbled in. Instead, it’s about depth and understanding.”
This insight is particularly relevant for freelance Martech consultants. In a field inundated with over 14,000 tools and technologies, true value comes from mastering a select few rather than having a superficial grasp of many.
Specialization allows consultants to offer deeper insights, solve complex problems more efficiently, and provide higher quality solutions to their clients. By focusing on depth over breadth, consultants can build a strong reputation and become trusted experts in their niche.
##
### **Balancing Depth and Breadth**
While deep expertise in a specific area is valuable, freelance Martech consultants must also maintain a broad understanding of the Martech ecosystem. This balance helps mitigate the risk of obsolescence if a particular technology falls out of favor. Staying informed about industry trends and adjacent technologies ensures that consultants can pivot when necessary.
Effective client communication is another critical aspect. Clients may not always understand the value of specialization. Therefore, it’s essential for consultants to clearly articulate how their specialized skills can address specific client needs and deliver high-quality results. This understanding fosters trust and sets the stage for successful collaborations.
##
### Pros and Cons of Specializing
**Pros** **Cons** Deep knowledge in specific tools/platforms leads to more effective solutions. Specializing too narrowly can be risky if the technology becomes outdated. Differentiates consultants from generalists, making them more attractive to clients. May limit opportunities early in your career as you focus on a specific niche. Specialists can command higher rates due to their expertise. Requires ongoing effort to stay updated with the latest trends and technologies. Specialization allows for efficient problem-solving and high-quality work. Demand for specific specializations can vary, potentially impacting job stability. Aligns skills with in-demand technologies, increasing job opportunities. Clients may not always understand the value of specialization, requiring effective communication. Strong foundation in one area makes it easier to learn and transition to related technologies. Risk of becoming too focused and not having a broad enough skill set for some projects. Builds a strong reputation and trust with clients and peers. Significant time and effort required to reach a high level of expertise. Partnerships with vendors and other specialists can enhance service offerings. Focusing too much on a niche can lead to missing out on broader industry developments.
By integrating these strategies and insights, freelance Martech consultants can effectively navigate the complexities of specialization and achieve greater success in their careers. At Martech Therapy, we are dedicated to helping you leverage your specialized skills to thrive in the Martech ecosystem.
##
### **The Role of Martech Vendors**
Martech vendors play a significant role in shaping the specialization landscape. They drive innovation and continuously develop new tools and features, which requires consultants to stay updated and specialized in the latest technologies. Vendors also offer training and certification programs that enhance a consultant’s credibility and expertise. Engaging with vendor communities and events provides valuable networking opportunities and insights into best practices.
Partnerships with Martech vendors can be particularly beneficial. Becoming a certified partner or consultant for a specific vendor can lead to new business opportunities and access to exclusive resources. These relationships can enhance a consultant’s marketability and expand their professional network.
##
### **Thriving in an Oversaturated Market**
In a crowded market, freelance Martech consultants need strategic approaches to differentiate themselves. One effective strategy is to focus on niche areas within Martech that are less saturated. For example, data privacy compliance or AI-driven personalization are fields with growing demand but fewer specialists.
Building strong relationships with Martech vendors is also crucial. Participating in certification programs, joining vendor communities, and seeking partnership opportunities can enhance a consultant’s reputation and provide access to valuable resources. Continuous learning and adaptability are essential for staying relevant. Engaging with industry newsletters, webinars, and training sessions helps consultants keep pace with technological advancements.
Developing a personal brand is another important strategy. Creating content such as blogs, videos, and case studies can showcase a consultant’s expertise and successes. A strong personal brand helps attract potential clients and establish credibility.
Offering comprehensive solutions rather than isolated services can also set consultants apart. Providing end-to-end services, including strategy development, implementation, integration, and ongoing optimization, demonstrates a deep understanding of client needs and adds significant value.
##
### Conclusion
Specialization is a key driver of success for freelance Martech consultants. By focusing on niche areas, leveraging vendor relationships, continuously learning, and building a strong personal brand, consultants can thrive in a crowded market. As Brad Traversy emphasizes:
> “Identify your interests because specialization begins with introspection. What aspects of web development are you passionate about?”
This introspective approach is equally valuable in the Martech field. Therefore, by identifying and pursuing your passions within Martech, you can develop deep expertise that not only aligns with market demand but also drives personal satisfaction and professional growth. Ultimately, at Martech Therapy, we are committed to guiding you on your journey to becoming a sought-after specialist in the Martech ecosystem.
Cover Image: [Danist Soh](https://unsplash.com/@danist07?utm%5Fcontent=creditCopyText&utm%5Fmedium=referral&utm%5Fsource=unsplash) on [Unsplash](https://unsplash.com/photos/white-plastic-chairs-in-close-up-photography-3XML91loIOM?utm%5Fcontent=creditCopyText&utm%5Fmedium=referral&utm%5Fsource=unsplash)
The post [Why Freelance Martech Consultants Should Embrace Specialization](https://martechtherapy.com/why-freelance-martech-consultants-should-embrace-specialization/?ref=martechtherapy.com) appeared first on [Martech Therapy](https://martechtherapy.com/?ref=martechtherapy.com).
### The Growing Demand for Freelance Data Talent
URL: https://www.martechtherapy.com/the-growing-demand-for-freelance-data-talent/
Last updated: 2025-10-09T19:47:50.000Z
What Businesses Need to Know
##
## Introduction
In today’s dynamic business landscape, the demand for data-driven decision-making is higher than ever. Companies across various industries are increasingly recognizing the value of data to gain competitive insights and drive innovation. However, building and maintaining a robust data team can be both challenging and costly. This is where freelance data talent comes into play. Leveraging freelance data professionals allows businesses to access specialized expertise without the burden of long-term commitments and overhead costs. As we explore this growing trend, we’ll uncover why businesses are turning to freelancers for their data needs and how they can effectively integrate these professionals into their operations.
This guide draws inspiration from [Alex Freiberg’s insightful YouTube video](https://www.youtube.com/watch?v=XbDRYzYUmMo&ref=martechtherapy.com), where he discusses the burgeoning trend of freelance data talent. While Alex, a seasoned Data Analyst, provides examples rooted in his extensive experience, his principles are broadly applicable across various data roles. Whether looking for data scientists, data engineers, or business intelligence specialists, the benefits of tapping into freelance expertise remain consistent. By leveraging freelancers, businesses can access specialized skills, achieve greater flexibility, and optimize costs, all while navigating the rapidly evolving landscape of data-driven decision-making.
##
### Section 1: The Rise of Freelance Data Talent
The trend towards hiring freelance data talent is not just a passing fad. According to recent studies, the gig economy is on the rise, with an increasing number of professionals opting for freelance work over traditional employment. This shift is particularly noticeable in the data sector, where the demand for specialized skills is growing rapidly.
Several factors are driving this trend. The flexibility of remote work has made it easier for professionals to offer their services on a freelance basis, while businesses are becoming more comfortable with the idea of remote collaboration. Additionally, the pace of technological advancement means that businesses often need specific skills for short-term projects, making freelancers an ideal solution.
“The number of freelance professionals in data analytics and related fields has surged, providing businesses with access to a vast pool of talent.”
\~ *Alex Freiberg*
This surge is not only a testament to the changing work culture but also highlights the need for businesses to adapt to new ways of acquiring talent.
##
### Section 2: Advantages of Hiring Freelance Data Experts
###
### Cost Efficiency
One of the most compelling reasons businesses turn to freelance data talent is cost efficiency. Unlike full-time employees, freelancers do not require benefits, office space, or long-term commitments, which significantly reduces overhead costs. This allows companies to allocate their budgets more effectively, investing in talent only when it is needed for specific projects.
Freelancers also bring a level of financial predictability. Companies can budget for projects on a per-task basis, avoiding the unpredictability of salaries and benefits associated with full-time hires. This model is particularly advantageous for startups and small businesses that need to manage their resources carefully.
###
### Flexible Expertise
Freelance data professionals offer a breadth of expertise that can be tailored to the specific needs of a project. This flexibility means that businesses can bring in specialized skills for short-term tasks or complex projects without the need for long-term commitments.
For example, a company might need a data analyst with expertise in machine learning for a new product launch, or a data engineer to optimize their data pipelines. Freelancers provide the ability to access these skills as needed, ensuring that projects are handled by experts in the field. “Consulting is more like high-level advising and bringing insights into a company,” says Freiberg, highlighting the strategic advantage of hiring seasoned professionals for specific challenges.
In conclusion, the rise of freelance data talent offers businesses a flexible, cost-effective way to access specialized skills and expertise. By leveraging freelancers, companies can stay agile, respond quickly to market demands, and drive innovation without the overhead costs associated with full-time hires. As we delve deeper into this trend, we’ll explore how businesses can overcome challenges and successfully integrate freelance data professionals into their teams.
##
### Section 3: Specialization in the Sea of Martech Solutions
The Martech landscape is a testament to rapid and exponential growth, underscoring the ever-expanding need for specialized data talent. According to the State of Martech 2024 report by Scott Brinker and Frans Riemersma,
> “It now includes 14,106 products — 27.8% more than the 11,038 on last year’s landscape. Since that first landscape in 2011, the overall count of Martech solutions has grown a mind-boggling 9,304%. Annualized, the industry has expanded at a 41.8% CAGR.”
This explosion of solutions offers many opportunities but also poses significant challenges for businesses striving to navigate this vast sea.
[](https://chiefmartec.com/2024/05/2024-marketing-technology-landscape-supergraphic-14106-martech-products-27-8-growth-yoy/?ref=martechtherapy.com)
Chiefmartec's Martech Map | Image Source: chiefmartec.com
With such an extensive array of tools and platforms, businesses need data professionals who are not just generally skilled but deeply specialized in particular niches. This specialization ensures that companies can effectively leverage the specific Martech solutions they use. Freelance data talent often brings this niche expertise to the table, allowing businesses to tap into precise skills without the burden of long-term commitments.
Specialization in data roles means more than just understanding how to operate a tool. It involves a deep comprehension of the data lifecycle, from collection to analysis, and the ability to draw actionable insights tailored to the specific needs of the business. Freelancers who focus on particular aspects of Martech can provide unparalleled expertise, ensuring businesses get the most out of their Martech investments.
##
### Section 4: The Benefits of Flexible Expertise
One of the most compelling reasons businesses are turning to freelance data talent is the flexibility it offers. Traditional hiring processes can be lengthy and expensive, often leading to a mismatch between the company’s immediate needs and the skills of the new hires. Freelancers, on the other hand, offer the agility to scale resources up or down as projects demand, providing a tailored fit for dynamic business environments.
Flexible expertise means businesses can quickly adapt to changing market conditions without the overhead costs associated with full-time employees. This is particularly crucial in the fast-paced world of data, where project scopes and technologies are constantly evolving. By leveraging freelance talent, companies can bring in specialists for short-term projects or specific tasks, ensuring they have the right skills at the right time.
Moreover, the ability to access a global pool of freelancers allows businesses to find the perfect match for their needs, regardless of geographic constraints. This not only broadens the talent pool but also introduces diverse perspectives and innovative approaches to problem-solving. As Alex Freiberg pointed out:
> “freelancing is like a Swiss Army knife for your business – versatile, efficient, and incredibly handy.”
This flexibility enables companies to stay competitive, innovate rapidly, and navigate the complexities of the modern data landscape with confidence.
##
### Section 5: Finding the Right Freelance Talent
As the demand for freelance data talent grows, so does the number of platforms and agencies offering these services. Businesses have a plethora of options, from general freelance marketplaces like UpWork to specialized agencies like Martech Therapy that focus on connecting businesses with top-tier data experts.
While platforms like UpWork provide access to a vast pool of freelancers, businesses should be cautious. The allure of low-cost services can be tempting, but as the saying goes, “you get what you pay for.” Cheap labor often comes with hidden costs such as lower quality work, missed deadlines, and the need for additional oversight and revisions. In contrast, investing in high-quality freelance talent can lead to better results, faster project completion, and ultimately, a higher return on investment.
Martech Therapy stands out as an agency of choice for businesses seeking specialized freelance data experts. Unlike generic platforms, Martech Therapy offers a curated selection of professionals who have been vetted for their skills and expertise. This ensures that businesses get access to top-notch talent who can deliver results without the usual headaches associated with managing freelancers. Whether you need a data analyst, a machine learning specialist, or a data visualization expert, Martech Therapy can connect you with the right person for the job.
##
### Conclusion: Embracing the Future of Freelance Data Talent
The growing demand for freelance data talent presents a unique opportunity for businesses to access specialized expertise, scale flexibly, and reduce overhead costs. By navigating the sea of Martech solutions with the right talent, companies can stay ahead of the competition and drive significant growth.
At Martech Therapy, we understand the complexities of [finding and managing interim data experts](https://martechtherapy.com/services/interim-solutions/?ref=martechtherapy.com). Our curated approach ensures you get the best talent tailored to your specific needs, helping you achieve your business goals efficiently and effectively. Whether you’re embarking on a new data project or need interim services to bridge a gap, Martech Therapy is here to support you every step of the way.
Embrace the future of work with freelance data talent and let [Martech Therapy](https://martechtherapy.com/about-us/?ref=martechtherapy.com) guide you through the journey. Contact us today to learn how we can help you find the perfect match for your data-related projects.
Cover Image: [Annie Spratt](https://unsplash.com/@anniespratt?utm%5Fcontent=creditCopyText&utm%5Fmedium=referral&utm%5Fsource=unsplash) on [Unsplash](https://unsplash.com/photos/black-flat-screen-computer-monitor-on-brown-wooden-table-wgivdx9dBdQ?utm%5Fcontent=creditCopyText&utm%5Fmedium=referral&utm%5Fsource=unsplash)
The post [The Growing Demand for Freelance Data Talent](https://martechtherapy.com/the-growing-demand-for-freelance-data-talent/?ref=martechtherapy.com) appeared first on [Martech Therapy](https://martechtherapy.com/?ref=martechtherapy.com).