How does Visitor Stitching work if a Visitor ID changes?

[loldenburg]

We have a large account migration where some data appeared where we have two different values for a Visitor ID of one and the same user.

The most common case is when a user changes his email address (which we track via hashes of it). He may be logged in with his Login ID and then change his email address for example. 

I have read this article several times but I just can't understand it: https://community.tealiumiq.com/t5/Universal-Data-Hub/What-happens-when-there-are-different-Visitor-...

So see this example where the user changes his email address in session 2: Session 2 and 3 also have less Visitor Attribute data in the data layer, so we are hoping to get that via stitching from Audience Stream:

Session Number	Email (Visitor ID)	Login ID (Visitor ID)	Gender (Visitor Attribute)
1	oldemail@x.com	123456789	male
2	newemail@x.com	123456789	(not tracked)
3	newemail@x.com	(not tracked)	(not tracked)

1. Will Gender be stitched to "male" in Session 2?

2. Will Login ID and Gender be stitched in Session 3?

Thanks.

[mark_reddin]

Hi @loldenburg,
Could you give more information about the type of migration you are doing?  How is the data getting in to the UDH and where is it coming from?

The answer here is - it depends.

It depends on a couple of things;

1. Are these regular web sessions from a single browser running TiQ with a collect tag, or is the user clearing cookies or using Incognito or anything like that, or are these "sessions" actually coming from the Collect API or elsewhere?

2. Do the sessions actually end / time out before the next session happens?

3. Are the two visitor IDs being set on different events, or on the same event?

Thanks
Mark

[loldenburg]

Hello @mark_reddin. Type of migration: Old site -> new site. The old site's user ID is not going to be used anymore on the new site => users will have a completely different ID on the new site. But by doing an omnichannel import into Audience Stream of a mapping table between old and new id, we want to rescue users history over to the new site.

The problem where users have changed their email or will change it in the future has just come up while doing that migration, but the problem is something that probably any AudienceStream Customer may experience. Otherwise using email hashes as Visitor IDs should not be recommended. But the Tealium Doc has some examples with emails as Visitor IDs.

1. They come from the browser, regular web sessions. User may have totally new cookies or still the ones from the old site. Both is just as likely

2. Most likely is that the last session happened on the old system, and the next one on the new system. But during the last weeks we had users going back and forth between the two systems (they had the option to go back through a link because not all functionality was on the new site yet).

3. It is not possible to send email A AND email B in the same Event, so: different events.

[mark_reddin]

Hi @loldenburg

On question 3, I meant can the login and visitor ID arrive into UDH on the same event?

[loldenburg]

Yes, @mark_reddin, the examples in the tables represent individual Hits in Sessions.

If there are so many "depends", I think it would be great if Tealium could add those to the documentation.

[mark_reddin]

Hi @loldenburg
Assuming all of this is coming from a single device, with no cookie clearing or anything, in your case, after session 3, here will be the state of the visitor profile;
Email (Visitor ID) = oldemail@x.com
Login ID (Visitor ID) = 123456789
Gender (Visitor Attribute) = male

This is what happens step by step;

1. Before even event 1, there is an anonymous visitor profile with no Visitor ID key set, let's call it A, and then Email, Login and Gender are enriched to A on your event 1.
Since two stiching keys are enriched on the same event, two visitor stitches happen immediately one after the other, and you'd see that in trace. The order in which they happen is not important in this case, and in any case I don't know if it's a deterministic order or not. But let's say first anonymous profile A gets replaced by oldemail@x.com and then in turn oldemail@x.com gets replaced by 123456789.

At this stage, the profile is 123456789. It still has the anonymous visitor ID of A, but also has visitor IDs of oldemail@x.com and 123456789 set as separate Visitor ID attributes, as well as Gender set to male.

Also, the original visitor profiles are still in the system, but point to and are replaced by the "master" profile, so

A -> oldemail@x.com -> 123456789.

2. On your event 2, nothing changes. Even though the email address has changed, as documented in the link below, once a Visitor ID attribute has been set for an existing Visitor Profile, it never changes value.

https://community.tealiumiq.com/t5/Universal-Data-Hub/Understanding-Visitor-Stitching/ta-p/91

3. On your event 3, nothing changes either. The new email address is still in the data layer. It hasn't been set in AS, but as long as the user's anonymous visitor ID cookie is still A, AS will still see this as a single master profile and so there is no change in profile.

You mention omnichannel - you can join the omnichannel data on either email or login, but if email, you will need to use the old email address. You can include both the old and new email in the omnichannel feed to be sure.

You also mention a link in your Original Post. This link is describing behaviour that is different than what I outline above, and the reason is because in that case, there were two separate devices in play, with two different anonymous visitor IDs. I have updated that article to make this clearer.

[loldenburg]

Sorry, I think I don't get it, but if I understand you correctly, if a user moves from Email 1 to Email 2, we cannot stitch his old data (like his gender) to his new Email2 even if we have this "Helper ID" of VisitorID which logically provides the link between the 2 Emails.

This is bad as it means that migrating users to a new ID will not be possible even if we import a matching table with new ID and Helper ID into Audience Stream.

The whole thing I describes btw is most likely to happen with different browsers and cookies, so maybe you can verify that the behaviour you describe is the same in that case.

[loldenburg]

would still be very helpful to understand the logic better, so thanks.

[loldenburg]

@mark_reddin Still would be glad for an answer here. There must be a sensible way for Audience Stream to handle such typical cases of users changing their email addresses.

[mark_reddin]

Hi Lukas

I am sorry for taking so long to reply.

If we suppose that the three events came from two different devices, then it would play out differently, as follows

1. There is anonymous visitor A1, which is replaced by oldemail@x.com and then in turn oldemail@x.com gets replaced by 123456789

2. Anonymous visitor A2 is replaced by newemail@x.com, and then in turn newemail@x.com is replaced by 123456789. But since 123456789 already exists from 1 above, we end up with

A1 -> oldemail@x.com -> 123456789

and

A2 -> newemail@x.com -> 123456789

at the same time.

So although the master profile has oldemail@x.com and 123456789 set as the Visitor IDs, either oldemail@x.com or newemail@x.com or 123456789 itself will point to the master profile 123456789, because the other "replaced by" Visitor Profiles are left behind as well. This differs from the case where all the traffic was coming from a single device.

3. Nothing effectively changes on event 3. Even if it came from a new device A3, then

A3 -> newemail@x.com, which already -> 123456789

In this case, omnichannel using EITHER the old or new email address will attach correctly to the master profile.

Finally, there is another possibility, that the visitor stitches run the other way around, with login running before email.

In that case, from two devices the behaviour is similar to that from a single device

A1 -> 123456789 -> oldemail@x.com
and
A2 -> 123456789, and since this already points to oldemail@x.com, newemail@x.com is not set.

I would suggest that you raise a Product Idea to ask for AudienceStream to deal with different email addresses from the same device in the way you need it to.

Mark

[loldenburg]

Ok thanks, @mark_reddin, so just so I understand it right:
It seems like if a user changes his email address and then visits the site in another device where we only have his login ID, Audience Stream will point to his old email address => Data Layer Enrichment will push his old email address into the data layer
This is hugely important for us as it would mean that users get always "pushed back" into their old Visitor Profile Data.

[mark_reddin]

Hi Lukas

There are a couple of points here;

1. Visitor IDs do not come back via Data Layer Enrichment - the above discussion relates to the actual Visitor ID stitching key used inside AudienceStream.

2. If you had a separate String recording the user's email address, that would come back via DLE (unless you set it to restricted).  The value that would come back would depend on whether you'd set up this String to be first value, or last value (i.e. whether you set up the String to be overwritten if it already has a value).  If first value, then old email, if last value, then new email.  First value as a String would equate to the value of the Visitor ID attribute, since as mentioned above, once a Visitor ID attribute has been set on a visitor profile, it is never changed.

3. You could also record the email addresses seen in a Set of Strings, in which case you would be able to get all the values back into the Data Layer, if you wished, but again those are separate from the Visitor ID.

[loldenburg]

1. Visitor IDs do not come back via Data Layer Enrichment - the above discussion relates to the actual Visitor ID stitching key used inside AudienceStream.

=> Ok, then let's say Visitor ID as a Visitor STring Attribute which is enriched with the Visitor ID (or by the same rule that enriches the Visitor ID). But 2. answers the question already. So it is indeed strange: Visitor ID as a String will be different from the very Visitor ID even though both are filled by the same rule... That's going to create confusion.

[josh_wolf]

If you create a new variable for the new ID you would keep the old ID associated historically with the profile but begin stitching off of the new ID going forward, @loldenburg.

[TimWaijers]

Bump to this use case, we're currently running into the same issue. I've added a product idea for these types of use cases. I Would very much appreciate your upvote/like. See the product idea here: https://community.tealiumiq.com/t5/Product-Ideas/Stitching-with-changing-visitor-IDs/idi-p/24077

[tamedbeast]

@loldenburg @josh_wolf @mark_reddin #hinthint #winkwink