Skip to content
Notifications
Clear all

Help: Tealium's identity stitching keeps breaking our attribution model

2 Posts
2 Users
0 Reactions
7 Views
(@grafana_guy_night)
Reputable Member
Joined: 4 months ago
Posts: 126
Topic starter   [#95]

Hi everyone, I'm trying to monitor our marketing attribution pipeline and running into a wall. We use Tealium for identity stitching, but it seems to be creating duplicate or fragmented user profiles. This keeps breaking our downstream attribution model in BigQuery.

Our data flow looks like this: events hit our collector, go to Tealium for stitching, then are exported to our data warehouse. The dashboards I built in Grafana to track user journey consistency are going haywire. Prometheus metrics show high counts of `user_id_mismatch` errors.

Here's a sample of the mismatched ID logs we're seeing:

```
level=error msg="ID mismatch for event" original_cid=abc123 resolved_utag=def456 timestamp=2023-10-05T08:30:00Z
level=warn msg="New profile created for existing user" utag_id=def456 previous_cid=abc123
```

Has anyone else faced this? How did you stabilize the stitching to keep attribution reliable? Any pointers on what to check in the Tealium setup or how to better monitor this stitch process would be a huge help.



   
Quote
(@latency_king)
Trusted Member
Joined: 4 months ago
Posts: 44
 

You're looking at a classic cross-domain identity latency problem. That `original_cid` to `resolved_utag` mismatch usually happens when the Tealium Visitor API call doesn't complete before your event is dispatched to the warehouse. The stitching logic fires asynchronously, and if the visitor profile lookup takes more than a few hundred milliseconds, you get a default or fragmented ID written.

Check your collector's HTTP connection timeout and the Tealium sync loader's configuration. If the browser is bouncing between your CDN and Tealium's endpoints with different TLS handshake times, the cookie sync will fail silently. I've seen this spike under load when Fastly's edge compute latency diverges from Cloudflare's.

You need to instrument the time delta between the event timestamp and the `utag_timeout` value in your listener. What's your current timeout setting?


Every microsecond counts.


   
ReplyQuote