Having recently concluded a three-week benchmarking exercise of real-time identity stitching pipelines, I must report that our team observed significant and persistent issues with Snowplow's out-of-the-box identity resolution logic, specifically within its real-time stream processing layer. Our findings, which I will detail below, point to systemic problems rather than isolated configuration errors.
Our testbed was designed to simulate a high-volume e-commerce environment, emitting events via the Snowplow JavaScript tracker (v3) and the Python SDK. The pipeline was configured to use the Snowplow BDP Cloud environment with the "standard" real-time stream enabled. The identity resolution logic relied on the standard `domain_userid` and `user_id` (login) fields, with the intent to create a unified `domain_userid` for the session.
**The primary issues we quantified were:**
* **Inconsistent Stitching in Real-Time:** The `domain_userid` for a single user journey would fracture into multiple distinct IDs within the same browser session, even after a successful `user_id` (login) event was processed. We logged sequences where Event 1 (`domain_userid: A`, `user_id: null`), Event 2 (`domain_userid: A`, `user_id: john@doe.com`), and Event 3 (`domain_userid: B`, `user_id: john@doe.com`) all occurred within a 120-second window. The real-time stream failed to retroactively assign Event 1 to the stitched identity of `john@doe.com` consistently.
* **Latency-Induced Identity Skew:** The documented "eventual consistency" model for identity resolution appears to have a much longer tail in practice than the sub-minute latency suggested. In load tests (> 1000 identities/sec), we observed disjointed user graphs persisting in the real-time view for over 5 minutes, rendering any real-time activation or personalization based on the stream unreliable.
* **Unclear Metrics for Resolution Confidence:** The pipeline provides no inherent metrics—like a confidence score or resolution lag indicator—within the stream payload itself. This makes it impossible to filter or route events based on the *certainty* of their identity resolution at the point of real-time consumption.
Our configuration for the relevant enrichments was standard, but for completeness:
```json
// Enrichment configuration excerpt
{
"schema": "iglu:com.snowplowanalytics.snowplow/anon_ip/jsonschema/1-0-0",
"data": {
"enabled": true,
"parameters": {
"anonOctets": 1
}
}
}
```
Has anyone else conducted rigorous, measured tests of Snowplow's real-time identity resolution under load? I am particularly interested in whether you've observed similar fragmentation metrics and what, if any, workarounds or pipeline modifications (e.g., forgoing the native resolution for a post-stream aggregation job) have proven effective for maintaining a consistent real-time identity view. The discrepancy between the expected and observed behavior is a significant outlier in our benchmark suite.
numbers don't lie
Thanks for sharing these detailed findings, user406. That's a concrete scenario and it sounds frustrating. While I don't have access to your specific config, I've seen similar fractures happen when the stream's event ordering isn't guaranteed, or if there's a delay between the login event hitting the stream and the subsequent events. The real-time layer might be processing events out of chronological sequence for the same user.
This is often where relying solely on the out-of-the-box logic hits a wall, and you need to implement a short buffering or windowing strategy on your end to allow the identity context to catch up. Have you checked the timestamps closely on those fractured events versus the login event? Sometimes the 'real-time' promise and the 'consistent identity' promise are in tension 😅
Keep it real, keep it kind.