If you’re evaluating customer data platforms for an Adobe Commerce or Shopware deployment, you’re looking at two fundamentally different architectural categories, even if vendor marketing doesn’t say so.
The distinction isn’t about features. It’s about where in the request path the CDP operates and what data it can access in real time. Getting this wrong in a real-time CDP comparison means evaluating capabilities that work differently by design, which makes the comparison meaningless.
Here’s the technical breakdown of both architectures. It’s a framework for knowing what you’re buying.
How application-layer CDPs work
An application-layer CDP is a system that collects customer data outside the request path and makes it available to downstream personalization logic. It receives data from your commerce application through one of three mechanisms: a JavaScript tag on the storefront, an event stream from the application backend, or a batch export from the commerce platform’s data layer.
JavaScript tag collection is the most common for mid-market deployments. The tag fires on defined events and sends data to the CDP’s collection endpoint. The CDP processes the event asynchronously. For implementations without dedicated event stream infrastructure, the profile update typically becomes available to your segmentation model on the next query cycle. This is anywhere from 30 seconds to a few minutes under normal conditions, longer under peak load.
Event stream collection (Kafka, managed equivalents) tightens the latency curve but adds infrastructure complexity. You’re now owning the stream as well as the CDP. The stream has its own operational overhead and failure modes. For organizations already operating mature streaming infrastructure, this can still be an effective architecture. The tradeoff is operational ownership: lower latency usually comes with additional systems to maintain and monitor.
Batch export is the worst case for latency: hourly or daily. It’s also the most common for merchants who built their data strategy before dedicated CDPs existed.
How data-path CDPs work
A data-path CDP is a system that operates inline on the request path between the edge and the origin server. It reads session signals as they travel through the delivery layer, without waiting for an export or event stream.
The profile update happens synchronously with the request. When a shopper adds a product to their cart, the CDP processes that event inline, in the same millisecond window as the request, making the updated profile available to downstream AI layers before the response is returned.
In internal benchmarking, Webscale observed sub-10ms P95 profile update latency under production-scale load conditions. Actual performance varies by deployment architecture and traffic profile. This is a function of where the CDP sits in the stack: there’s no asynchronous processing step between the event and the profile.
For a deeper look at how this fits alongside the AI inference and personalization layers, see Inside the Stack: Where the AI Lives.
Four technical differences that matter in a CDP evaluation
Data freshness. Application-layer CDPs work on data that arrived at their collection endpoint at some point in the recent past. Data-path CDPs work on data from the current request. For session-level personalization decisions, this is the most material technical difference. The shopper never sees an outage page when this breaks. That’s what makes it difficult to detect operationally. Personalization quality degrades: recommendations become less relevant, segmentation lags behind session behavior, and discovery experiences drift away from current shopper intent during the highest-conversion window of the session.
Integration footprint. Application-layer CDPs require a collection mechanism and a retrieval mechanism. Each is a maintenance surface, validated on every major platform update. Data-path CDPs require no collection mechanism beyond the request path that already exists.
Peak load behavior. Application-layer CDPs receive more event volume under peak traffic, which pressures their processing pipeline. How CDP latency changes under peak load depends entirely on whether that pipeline has headroom. Data-path CDPs scale with the request path infrastructure; the same infrastructure handling peak traffic by design.
Failure modes. Without proper observability tooling, application-layer CDP failures can be silent: the commerce application falls back to serving unpersonalized content without an alert firing. Data-path CDP failures show up in request latency, which is monitored aggressively. Loud failures get fixed faster than silent ones.
Four questions to ask any CDP vendor
Before signing anything, get specific answers to these four questions.
- What is your P95 query latency at 2x my peak traffic load? If they can’t answer with a number, the answer isn’t good.
- What happens to personalization quality when your ingestion pipeline is degraded? Is the fallback a stale profile, a generic profile, or an error? How would I know it’s happening?
- How many integration components do I own and maintain between my storefront and your CDP? Count the collection mechanism, the processing pipeline, and the retrieval call separately.
- Where exactly in my request path does your CDP run? If the answer isn’t on the same layer as your CDN and WAF, ask for the latency cost of bridging those layers.
The answers tell you more about how a CDP performs in your stack than any feature comparison sheet. A vendor who answers question 1 with a specific P95 number at peak load has tested their system under real conditions.
That’s also the architecture that lets you activate high-intent shoppers in real time, not on the next ingestion cycle.
FAQ
What is a data-path CDP?
A data-path CDP operates inline on the request path and processes session signals synchronously as requests move through the delivery layer.
What is an application-layer CDP?
An application-layer CDP collects customer data asynchronously through tags, event streams, or batch exports and makes it available to downstream systems after processing.
Why does request-path placement matter?
Request-path placement determines data freshness, personalization latency, operational complexity, and how quickly failures become visible.
See how Webscale’s Customer Data Platform operates inline on the request path → webscale.com/customer-data-platform/
