We've been running Segment's Personas for about eighteen months, primarily for B2C audience activation to Facebook and Google Ads. Last week, we executed a planned schema evolution in our core `users` table, migrating from a legacy, denormalized `address` JSON blob to a structured set of fields (`street`, `city`, `postal_code`, `country`) within a nested object. The change was backward-compatible at the application layer, but it has completely broken our identity resolution in Personas. Our computed traits and audiences have stagnated, with no new users being resolved for the past seven days.
Our pipeline is standard: Snowflake -> Stitch (for extraction) -> Segment Warehouses -> Personas. The schema change was applied in Snowflake, and we verified Stitch is replicating the new fields correctly. The Segment Warehouses sync shows the new columns present. However, the identity graph appears to have stopped merging user profiles based on the `email` trait. The `identifies` calls are still flowing via our Segment SDKs, but the warehouse-backed source seems disconnected.
Key details of our setup:
- **Identity Resolution Settings**: We use a primarily warehouse-first strategy, with the key `email` trait for merging. The `users` table is our primary source, with `id` as the external ID.
- **Schema Change**: We altered the `users` table, adding new columns and deprecating the old `address` column. A view with the old schema exists for fallback, but Personas is configured to use the table directly.
- **Observed Behavior in Personas Dashboard**:
- The "Warehouse Sources" status shows "Synced."
- The "Identity Graph" size has flatlined.
- New users from streaming events (`identifies`, `tracks`) are created as standalone profiles, not merged with existing warehouse profiles.
We've already performed the basic troubleshooting:
1. Verified no changes to the Personas workspace configuration or access keys.
2. Confirmed that the `EMAIL` field in the warehouse source still populates correctly with the new schema (it does).
3. Checked for any sync errors in the Segment UI (none reported).
My hypothesis is that the schema change, even though additive, may have triggered a full re-scan of the warehouse source, which in turn has caused Personas to treat the newly synced records as a fundamentally different source, breaking the linkage to the historical identity graph. Alternatively, there might be an implicit hash used for profile deduplication that's changed.
Has anyone encountered a similar breakdown after a schema evolution in a primary warehouse source? Specifically:
- Did you need to manually force a re-computation of the identity graph?
- Are there undocumented dependencies on column order or the presence of certain legacy fields?
- Is there a way to audit, via Segment's APIs, whether the warehouse-derived profiles are being considered for merges?
I can provide anonymized Terraform for our Personas configuration if it's helpful, but I'm first seeking anecdotal experience on recovery steps before we engage Segment support. The operational impact is significant, as our activation pipelines are now stale.
That schema evolution, especially moving from a JSON blob to a nested object, is a classic trigger for identity resolution failures in warehouse-first setups. You mentioned verifying the fields are present in Segment Warehouses, but the key is whether Personas can *access* them for its merge logic.
The issue likely isn't the schema itself, but how the identity graph's merge keys are configured to read from the warehouse source. When you changed the column structure, any computed trait or audience rule that referenced `address.city` is now looking at a path that no longer exists in the old format. Personas might be failing silently on those rules, which can stall the broader identity stitching process.
Have you checked the Trait and Audience configuration in Personas to see if any are now showing errors due to the missing field path? Also, confirm in the Personas settings that the primary `email` trait is still correctly mapped to the new column location in your warehouse source. The sync might show columns, but the mapping could be broken.
Measure twice, spend once
Yeah, the mapping part is so easy to miss. We had a similar break when we switched our primary key column name, and everything looked fine until we checked the actual source mappings in the Personas settings. The sync status was all green, but the field was just... unattached.
What would you recommend checking first in the settings, the trait definitions or the identity graph configuration?
You're right about the silent failures, but I think blaming the trait configuration misses the bigger picture. The real issue is that these platforms treat a schema migration like a simple column rename.
It's never that clean. Personas' identity graph has its own internal mapping layer *separate* from the warehouse sync status. Even if your primary email field is "mapped," the historical graph might still be trying to reconcile old JSON path data with the new nested object, and the merge logic chokes. The green checkmark in the settings UI is almost meaningless.
You'll likely need to force a full recompute of the identity graph, which they don't advertise because it's a resource hog and might require a support ticket. This is a classic vendor move: their abstraction leaks, and you pay the compute cost to fix it.
Trust but verify.
You're focusing on the warehouse sync and the `email` trait, but you've missed the first and most critical failure point: the identity graph's source priority list. In a warehouse-first strategy, Personas still needs to know which source property to pull the email *from* after a schema change.
Go to Settings -> Identity Resolution -> Source Priority. Look at your warehouse source. Click into it. There should be a mapping for the identity trait, likely `email`. I'll bet you a dollar it's still pointed at the old JSON path, like `address.email` or something nested inside that defunct blob, not at the new top-level column. The graph isn't merging because its primary merge key is now resolving to null for all new records.
Even if you fix that, your computed traits referencing the old address structure are dead. You'll need to audit every single one and rebuild them, which is why the whole system feels stalled.
Oh, that's a fantastic point about the Source Priority mapping. I've been burned by that exact screen before, but for a different reason. We added a new `work_email` column and the graph defaulted to pulling that for the `email` trait because it was alphabetically last in the list, which was a mess.
> The graph isn't merging because its primary merge key is now resolving to null
This is spot on and explains the total stall. But I'd add a caveat: even after you correct the mapping in Source Priority, Personas often needs a manual nudge to re-evaluate historical records against the new path. We had to run a backfill for the identity graph, which is a hidden option under the source's settings, not just a recompute of traits. Did you find the same?
Pipeline is king.