Can I remove user stitched instances?

Gold Contributor
Gold Contributor

occasions occur where a user gets some devices attached to them that should be.  I need  amethod to remove those associations permanently.  How can i do that?

 

ie: Person A clicks an email , and that devices gets their email ID as a visitor ID in audience stream.

Person A shares their email with person B, who then also clicks on a link, and then gets that email ID associated with their device. 

Now within AudienceStream the master user profile now has both devices attached to it.

Person B browses a bunch of stuff, and now Person A and Person B are getting emails about that stuff they browsed.  

 

This causes problems (privacy, accuracy, etc).  So I'm hoping for a way to be able to trigger stitched devices to unstitch.  Since Audiencestream maintains some kidn of master 'user' profile, i'm worried that even if i cleared the cookies of the devices, that then the next time Person A clicks on a email, all the activity of Person A AND Person B (prior to clearing cookies) will still get attached to Person A's new device/cookie ID.

 

any ideas?

 

1 REPLY 1

Can I remove user stitched instances?

Tealium Employee

@Michael_Kim_shc

 

At this time there is not a straight-forward way to handle this. Once a visitor ID attribute is set it will never change, and once a stitch event occurs it's not possible to "tear" that visitor. Tearing is something we've talked about, but there are many caveats assocatied to it on the backend that would make this difficult to successfully accomplish - such as re-applying events to the correct visitor profile or re-linking visitor profiles to site visitors.

 

We have had a few clients in the past that will first store the email ID as a String, and then at the end of the visit update the Visitor ID with the String. This will ensure that if someone mis-types their email that we get the last one used.

 

Another thing we've doing in the past with a client is when a user logs in, their user id can be flagged as a "group" ID (think Library or School where multiple users use the same id) to prevent that ID from being stitchable.

 

I know the above 2 points don't directly answer your question, but just throwing other ideas out their for future readers and hoping it sparks some creativity.

 

Cheers,

-Dan

Public