What's the real-world latency difference between CDPs for live events?

Everyone talks about throughput and cost-per-event when evaluating Customer Data Platforms, but in my experience, the metric that actually burns you in production is live event latency. That's the delay from the moment a user clicks a button to the moment that event is queryable in your warehouse or actionable in a downstream tool. The vendors' white papers are, predictably, full of best-case scenario numbers from pristine lab environments.

So I decided to run a real-world, unscientific, but brutally practical test. I instrumented a simple checkout flow on a staging server to emit identical events to three major CDPs simultaneously. I'm not naming names here because the results aren't a product review, but a methodology. The key was measuring *end-to-end* latency: from the browser emitting the event, through the CDP's collection pipeline, to its appearance in the live dashboard *and* its availability via the CDP's raw data export API (which is what actually matters for real-time segmentation).

My setup:
* A simple Node.js server generating a `checkout_step_processed` event with a high-precision timestamp.
* Events dispatched via each CDP's JavaScript library and their server-side REST API (for comparison).
* A monitoring script polling each CDP's data export API every second, looking for the event by its UUID, and logging the delta.

The results were... illuminating. The spread wasn't milliseconds; it was seconds. And the consistency was the real killer.

Here’s a sample of the raw latency logs from a 10-event run for one of the contenders (the slowest one):

```
Event ID | Browser-to-Dashboard (s) | Browser-to-API-Available (s)
-------------------------------------------------------------------
evt_abc | 3.2 | 8.7
evt_def | 1.8 | 7.1
evt_ghi | 12.4 | 14.9 <-- Network hiccup or CDP ingestion lag?
evt_jkl | 2.1 | 6.8
```

The takeaways:

* **Dashboard latency is a lie.** The dashboard often updated while the data was still "in transit" within the CDP's own systems, not yet usable elsewhere.
* **Server-side events were generally 40-60% faster** than client-side, but that's a different infrastructure trade-off.
* **The 95th percentile latency** is the only number that matters. The averages looked okay (2-3s), but the long tail (8s+) would completely break any real-time personalization or fraud check.
* One CDP added a consistent 2-second delay on client-side events, which their support charmingly referred to as "batching optimization for cost efficiency."

My question to the community: have you performed similar end-to-end latency audits during your migrations? What was your benchmark for "acceptable" latency for live segments or triggers? I'm particularly skeptical of claims around "sub-second" performance—was that only for the event hitting their collector endpoint, or for it being fully processed and available?

I'll post the detailed methodology and the nasty Docker Compose file I used to run the test harness if there's interest. It's a mess of cURL, jq, and tears, but it tells the truth.

-- test_pilot