What happens when two visitor profiles are stitched and an attribute exists in each profile but with different values. For example:

  • Desktop "Opt-In Status" flag of "True"
  • Mobile "Opt-In Status" flag of "False"


First, it’s important to note a few important system functionalities.

  1. As events feed into AudienceStream, these events are used to create a visitor profile.
  2. When a visitor’s visit expires, both the visitor and all of the events of their visit are stored in two different DB collections (separate from EventStore logs).
    • Over the lifetime of a visitor there can be hundreds or even thousands of events, and a majority of the time these persisted events are never used and will expire when the visitor profile expires.

With that foundation set we can now discuss what occurs upon a stitching event. When matching profiles are found, AudienceStream will load up all past events for all of the visitors being stitched, sort each event chronologically, and replay all events to create a master stitched profile.

So back to the question, whether the "Opt-In Status" flag will be set to “True” or “False”, the answer is that it depends on the outcome of all of the enrichments that will be reprocessed when AudienceStream replays all of these visitors' past events.

More Notes and Possible Questions

You may be curious about more advanced attributes such as list and tally. Even though tally and list attributes look like they are merged, it's still just because they are setup using additive enrichments (i.e., add to list, increment tally, etc). These have typically been correctly stitched in the past.

Depending on how many events there are, stitching can take awhile to execute as it's an extremely complex and CPU heavy task to execute. However, over the past couple of years Engineering has made numerous optimizations to make this stitching process more efficient. Typically, it is a very quick process.

Does this mean stitching is backwards compatible? Imagine this scenario of events:

  • Customer registers on a website on their desktop
    • customer_type is passed to AS
    • customer_email is passed to AS
  • Within AudienceStream
    • Visitor ID is assigned using customer_email
    • customer_type is ignored
  • 1 week later a Trait is created that stores the customer_type
  • 2 weeks later the visitor authenticates on Mobile with the same customer_email value (but no customer_type is passed)
  • We stitch the desktop and mobile profiles together

The Trait capturing customer_type will not have existed in either device's visitor profile. However, when AS reprocesses all the events, AudienceStream will use the latest AudienceStream profile definition and re-evaluated the Trait's enrichment. This means the master visitor profile will now have the Trait storing the customer_type.

How does this affect Omnichannel data?

Since Omnichannel data is considered event data it will behave the same, meaning the event data will persist in the Event Database and chronologically be a part of the online event data.

How does this affect timeline timestamps and audiences joined/left dates in AudienceStore?

The timestamps represent when the singular event occurred, not when the stitching event occurred.