[er4hn]

So the overall concept of "shove a tracker value into the URL and collate all interactions" makes sense - but how do you track if a user is sharing a URL?

Let's say that I'm on a desktop browsing a shopping site. I'm on shopping.site/product/coolthing.html?tracker=12345. I share this with my friend on a mobile device because it looks like something of interest to them.

Now how do you handle the other person having the same tracker as the initial person? You end up with a scenario where two different people, with different interests, are browsing the site. Even if they convert you have situations along the lines of: no conversions, person A converts, person B converts, both convert. How do you handle this?

With cookies the sharing of the URL would avoid this scenario since cookies would be separated between people.

[syrrim]

Use the referer, is my guess. Whereas browsers are starting to limit the sharing of referers, I don't think there are any plans to limit first party referers. So as long as the referer is your domain, you know the user navigated from within the site. Otherwise, the user followed a link offsite, likely shared by a friend. You can then assign a different tracking id to them.

[HWR_14]

> Whereas browsers are starting to limit the sharing of referrers

AFAIK, they are starting to standardize the sharing of referrer. For most people, this is limiting the sharing. However, they used to have an easy to find GUI option to just opt out of referrers in general. That is no longer the case.

[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?