[mattjstar]

This could in theory happen, but in my examples I'm adding the url right after someone converted -- paid for a subscription or completed an order. Those are unlikely to be shared with someone else (ideally). It's arguably more likely that the user will share it with themselves on another device, in which case the overall approach will work well.

I should also point out that the url tracker isn't meant to be persisted across page views. It's only done once at the moment that the user identifies themselves to your service.

[er4hn]

Then I'm a little lost. I had thought a big part of this (your "Stitch anonymous data to users once they convert" picture and around it) was to be able to backtrack anonymous users once they identify themselves.

Even if they identify themselves via ordering something, is it an unusual workflow to share a link after? For example "I got this new coffee, I'm excited, here's the link to what I ordered my friend!"

[ahmedelsama]

Well your tracking a user via the Anonymous id. Once you see a link (checkout url, order link, form submission, etc) you create a link. Now you have a list of cookies, their linked email at a moment in time. Then you create a table that has the cookie and who it maps to from a timestamp to a timestamp. This is then used to update the past and future identities. Think multi-user, multi-device in time.

So in the example you gave, the user who opens that links becomes tied to that cookie from the time they open the order to the next linked event. This is really critical because it will continue to stitch the users identity over time.

If link sharing is happening a lot, you can choose to not use that linkage foe identity resolution.

Does this help clarify the approach?