Question

If the same anonymous_id value is first seen from a web source and then sent again later from an app source, will the profile view in the Profile Explorer reflect that it was last updated from the app?

Product

Twilio Segment

Environment

Segment Console

Answer

Segment automatically handles the stitching of the anonymousId. Segment SDKs automatically generate a UUID for the anonymousId on the user's first visit and attach it to all subsequent Page, Screen, Track, and Identify calls. Unify's Identity Resolution recognizes this built-in field and automatically promotes it to an external_id for stitching purposes, as long as the identifier was configured in the ID resolution rules.

How these updates appear in the Profile Explorer depends on whether your app generates a new anonymousId or is custom-engineered to use the exact same one from your website:

• When using a new anonymous_id (Default Behavior): Devices and web browsers natively generate distinct anonymousId values. When a user browses anonymously on your app, they are assigned a new, app-specific anonymousId. Once they sign in on the app, the app sends an Identify call containing their known user_id and the new app anonymousId. Unify sees the matching user_id and appends the new app anonymousId to their existing profile. In your Profile Explorer, you will see a new anonymous_id entry added to the list of identifiers, and it will reflect the app as the source.

• When using the same anonymous_id (Custom Engineered Behavior): If you have engineered your application to pass the exact same anonymousId from the web session to the app session, Unify will recognize it as a match to the existing profile. While the identifier itself will still show as originally created by the web source, any new events coming from the app with that identifier will seamlessly append to the same profile. The new events tracked from the app will show up in the user's event history as originating from the app source.