We will describe the Replaces table by first describing an example journey of visitor stitching. Our visitor stitching works as follows:
Replaced VisitorID UDH.png
  • A user gets sent to CDH with the default visitor ID (ID1).
  • A visitor profile is created using ID1.
  • The user then authenticates with an email address (ID2).
  • A visitor profile is created using ID2.
  • The visitor profile for ID1 is updated with a "secondary_id" of ID2.
  • The system checks for a "master" visitor profile.
  • If a "master" visitor profile does not exist, it is created with ID2 being set as the "_id" parameter and "replaces" parameter reflects ID1.
  • The original visitor profile for ID1 is updated with a reference to the new "master" visitor profile.
AudienceStore works off the most current data available, so the "master" visitor profile will be used for that user instead of the "original" visitor profile for ID1 or ID2.
 
The "replaces" array is only available on "master" visitor profiles. When using "replaces" in a query, the query is only pulling profiles for users that have been stitched (or authenticated with a secondary ID). 

Obtaining visitor stitching data from values of the 'replaces' property in an AudienceStore JSON payload

You can rely on the value of the "replaces" property to show that a visitor was stitched. The Replaces and "secondary_ids" properties are ONLY available in a Master profile, which occurs when a visitor is stitched. If a visitor has not stitched, those values will not be available. Below are excerpts from the JSON Object of two AudienceStore files: "master" and "nomaster":
 
// Master
"current_visit.events[0].visitor_id" --> Initial Visitor ID the user starts with (016ccea2ab9700037286abffdc0603073001e06b00bd0)

// Replaces
"replaces" --> The ID being replaced (016ccea2ab9700037286abffdc0603073001e06b00bd0)
"secondary_ids" --> The secondary ID ("12896": "user@email.com")*
* The number before the secondary ID (12896) corresponds to the AudienceStream attribute ID number being used as a visitor ID

The "New" ID (for the "master" visitor profile) will be in the same "event" as the "replaces" value. So it would show like this:

Original ID --> "replaces"
New ID --> "_id" in same event as "replaces"
visitorstitching-audiencestore.png

Tracking Visitor Stitching over three devices

Here is an example of how the stitching would work for a user (Jane) authenticating on three devices:
  • Jane uses her desktop computer at home to visit "xyz.com". She is assigned a visitor_id of "x".
  • Then she logs in with her email and her email is assigned to "secondary_id".
  • Now she's out to lunch and opens"xyz.com" on her phone. She will have a visitor_id of "y".
  • When she logs in with her same email, she will have a "secondary_id" that matches the email on her desktop.
  • Then she's at work and opens"xyz.com" on her work desktop computer. She will have a visitor_id of "z". When she logs in with her same email, she will have a "secondary_id" that matches the email on her desktop AND phone.

To track each individual stitch, check against the "current_visit.events[0].visitor_id", since the "_id" will be the same for each one. The data would show as follows for our example:

Stitch #1:

current_visit.events[0].visitor_id = "x"
replaces = "x"
_id = "__xyz_main__12896_user@email.com__"
secondary_ids = {12896:"user@email.com"}


Stitch #2:

current_visit.events[0].visitor_id = "y"
replaces = "y"
_id = "__xyz_main__12896_user@email.com__"
secondary_ids = {12896:"user@email.com"}


Stitch #3:

current_visit.events[0].visitor_id = "z"
replaces = "z"
_id = "__xyz_main__12896_user@email.com__"
secondary_ids = {12896:"user@email.com"}
To track each stitch for the user, pull everything that has "replaces" or "secondary_ids" populated, then check against the "replaces" OR the "current_visit.events[0].visitor_id" to see if it's "unique".

To track a user's stitch once, you can pull everything that has "replaces" or "secondary_ids" populated, then check against the "secondary_ids" to see if it is "unique".
 
Version history
Revision #:
9 of 9
Last update:
‎10-29-2020 06:57 AM
Updated by: