Alright, let’s add another chapter to my ever-expanding saga of platform migration misery. This year’s protagonist: identity resolution. It worked. Then we moved. Now it doesn't. I feel like I’m paying six figures annually to be a QA tester for foundational features that were sold as "enterprise-grade."
The premise was simple, as it always is during the sales demo: we’d move from our old CDP (which shall remain nameless, but rhymes with "Segment") to the new shiny one (which boasts a three-letter acronym). The migration plan covered the usual suspects: schema translation via Fivetran, historical event backfill using cloud storage, and re-wiring all the downstream connectors to our marketing automation and warehouse. The data *arrived*. Records count matched. Celebratory slack emoji were deployed.
Then the reports started lying.
The core issue manifests in two beautifully frustrating ways:
* **Customer journeys now look like schizophrenic vignettes.** A known user, with a userId in our system, performs an action on the web. This gets logged as an entirely new, anonymous profile. Hours later, that same user logs in and their activity starts a fresh timeline. The two profiles refuse to merge, despite having the same email address passed in both streams. It’s as if the logic that says "email == stitch" got lost in transit.
* **Our deterministic overrides are being ignored.** We have business rules—if a `userId` is present, it should take precedence. If not, fall back to `email`, then `anonymousId`. The new system seems to be applying its own probabilistic logic on top, or perhaps just picking the first identifier it sees and clinging to it for dear life. The result is a fragmented view where we can’t reliably attribute a sales opportunity to the marketing touchpoints that actually created it.
I’ve been down the rabbit hole with support, which mostly consists of them asking for "samples" and then suggesting we adjust the "identity graph rules" in the UI. We’ve tried:
* Adjusting merge precedence in the identity graph console (putting `userId` at the top, increasing its weight).
* Explicitly setting `identify` calls with both `userId` and `email` in every possible permutation.
* Reviewing the raw event stream entering the CDP to confirm the data is structured correctly (it is).
The working theory, which I’m developing through sheer exasperation, is that the migration itself borked the chronological order of events. The historical backfill of past `identify` and `page` events might have landed *after* the new live events started streaming, causing the system to build its graph on a flawed timeline. The new CDP’s resolution logic seems far more sensitive to event sequence than the old one.
So, my question for the trenches: has anyone else performed a CDP migration and watched identity resolution crumble in the aftermath? Specifically:
* Did you find a reliable way to "re-hydrate" or "re-sequence" the identity graph after a bulk historical backfill?
* Are there specific settings around "merge windows," "historical vs. real-time resolution," or "event timestamps" that proved critical?
* Is the solution just to accept a 30-day "burn-in" period where resolution is a mess until the new system’s timeline corrects itself?
I’ll document whatever we find, as always. Currently weighing whether to attempt a total reset of the identity graph (terrifying) or to build a parallel resolution layer in the warehouse and bypass the CDP’s logic entirely (expensive, but predictable).