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.