If you have ever stood up Sitecore CDP, Personalize, and Search as three separate products on the same project, you already know the part that never made it into the sales deck. Each product was good on its own. Getting the three of them to behave like one product was the actual work, and it was rarely small.

I sat in on the last Sitecore MVP webinar, which we were cleared to share publicly. Paul Trundle and Derek Fahey from the product team walked through the conversion optimization and unified data layer roadmap.

Derek runs the data and analytics side, including the UDL, CDP, and part of Sitecore Connect. He came in through the Boxever acquisition, so this is familiar ground. Paul is the lead PM for conversion optimization, which is the native rebuild of search and personalization features into SitecoreAI.

For anyone who has not kept up with the SitecoreAI direction, this is part of Sitecore’s broader move to bring content, data, personalization, search, and AI capabilities into one platform experience. SitecoreAI has multiple focus areas, and this session centered on the first one, conversion optimization, with the unified data layer sitting underneath it.

What the UDL actually is

Derek was clear about what the unified data layer is and is not. It is not CDP light. He described it as a new platform, built from scratch on Azure, meant to be the single place customer data lives so it can feed personalization, search, and experience orchestration across the rest of SitecoreAI.

Here is the line that stuck with me. Derek said, plainly, that while the individual products worked well by themselves, Sitecore had trouble making them work well together. That is not a marketing sentence. That is a product director saying out loud what everyone who has implemented these things already knew.

The example made it concrete. Search had a strong way to configure affinities for pages and users, but using those same affinities inside Personalize was difficult. Two products, overlapping ideas, no clean handoff between them. The affinity work you did in one place did not naturally carry into the other, so teams ended up rebuilding the same intent twice.

That is the integration tax. Not the license cost or the implementation estimate, but the invisible cost of making separate tools act like they were designed together from day one.

Why the data layer is the whole bet

That point is the real thesis of the session. Agents are only as useful as the data they can reach quickly. If customer data sits in one place, search behavior somewhere else, profile data somewhere else, and personalization logic in another tool, the agent story gets weaker before it even starts. You pay for that gap in architecture, in latency, in duplicated configuration, and every time a marketer has to ask why a signal captured in one product cannot be used cleanly in another.

Derek also talked about the infrastructure side. In the webinar, he said the older standalone products were built on AWS, while the new platform direction is on Azure. Pulling data across product and cloud boundaries introduces cost and delay, and moving these capabilities into one Azure-based platform should reduce that tax.

That is more than a hosting decision. In an AI-driven DXP, context latency becomes product latency. If the agent has to wait, the experience waits. Fragmented data means fragmented decisions, and incomplete context means incomplete output. Without the right context underneath it, an AI agent does not get very far.

That is why the UDL is probably more important than the interface people will see first. The visible feature may be personalization, testing, search, or insights. The thing that decides whether those features actually work is the data underneath.

Conversion optimization is where this becomes practical

Paul framed conversion optimization the same way. This is not the old Search and Personalize products wearing a new label. It is a native rebuild of search and personalization for SitecoreAI. The idea is one place to run A/B testing, personalization, and search, then read the analytics and react to what you see.

That is the part I care about, because in real projects these things are never truly separate. Search tells you what people want, personalization changes what they see, testing tells you whether the change helped, and analytics tells you what happened. When they live in separate tools, the marketer becomes the integration layer, and that is usually where things break. Not because marketers are not capable, but because nobody should need to stitch together five product concepts just to answer a simple question:

What should this visitor see next?

Composable versus composed

There was also a framing from Symposium worth repeating. The conversation has shifted from composable to composed. Sitecore still has composable products, and that does not go away. But the direction is clearly moving toward a more composed platform experience, where related capabilities live together instead of forcing every customer to assemble the same foundation themselves.

That is the right evolution. Composable is still valid, and I still believe in best-of-breed architecture when it fits the organization. But composable does not mean the customer should be the product team forever. At some point, the platform has to absorb the common wiring.

The buyer should still have choice and the architect should still have control. The marketer should not need a diagram to understand how to run a test. That balance is hard. Too much composition and the platform starts to feel closed. Too much composability and the customer spends all their time gluing things together. The UDL and conversion optimization work looks like Sitecore trying to find the middle.

What I am watching

I have two open questions.

First, what does the path look like for customers already live on the separate CDP, Personalize, and Search products? Rebuilding on a single cloud is the right call for the platform. It is also a migration path for everyone running the old pieces today, and migrations are where roadmaps meet reality.

Second, does the unified layer retire the overlapping features or carry them forward with the same gaps? Derek named the problem honestly, and that matters. The test is whether the new platform fixes it or repackages it.

For years, the hard part of a Sitecore data project was not any single product. It was the wiring between them. If the UDL does what Derek described, that wiring stops being the customer’s problem and becomes Sitecore’s. That is the right place for it to live.