ITP2 Blog Series: Part 1 | Part 2
In my previous blog post, I covered how businesses use third-party cookies to identify users as they move across web sites. This practice is now being challenged by ITP2 in Safari and by similar approaches in other browsers. I discussed two different workarounds that some vendors are using to combat the problem. But each workaround still has limitations, and this post is an overview of some other solutions we have seen our customers implement to maintain visitor identification for their website users.
The first is authentication. If you have an authenticated user, you can use their username or email address to create a hashed ID. Hashed IDs are anonymous to the human eye and can be consistent across domains. A simple example would be: "email@example.com" MD5 hash: "23463b99b62a72f26ed677cc556c44e8"
When done right, hashed IDs can provide a consistent identifier that is difficult to decode without information on your users. And if you have a visitor authenticating on multiple sites, you will have a 100% match, which gives you the ability to see the full customer journey. In fact, vendors like SAP’s Gigya specialize in helping clients login and authenticate with Google or Facebook IDs. As a result, many web sites now prompt users for a Facebook or Google login before they allow viewing content.
As authentication becomes more common, it will be more accepted and less likely to be ignored, and visitor behavior tracking may become more accurate (if less private).
Another potentially effective solution is creating iframes in first-party domains. Evidence of achieving success with this approach is largely anecdotal and may run into legal and technology issues.
Link decoration is a great way to carry visitor IDs from one site to the next as a user clicks from one site to another.
Here's how it works: both the origin site and the destination site agree on a query string parameter to use to pass a shared identifier. This parameter is appended to all links from the origin site to the destination site. For example, instead of "http://example.com/page/link.html", the decorated link would be, "http://example.com/page/link.html?shared_param=VALUE_TIMESTAMP".
As the origin site displays pages, this parameter is dynamically added to the links. The parameter value usually contains two values: the user's identifier and a timestamp. The identifier can be any unique value to the user, but it's best if it doesn't contain any personally identifiable information (PII), such as an email address. The timestamp ensures that the parameter values don't get shared between users. When the user lands on the next page, the destination site reads the shared query parameter from the URL, decodes the identifier and timestamp to validate the value, and stores the shared identifier for use.
Sometimes, it's important to understand visitor behavior from a week or a month ago (across multiple sessions). To do this, you can stitch multiple IDs together. The most common use case for this is if your visitor is unknown and appears to be there for the first time. If this visitor later authenticates, you can connect one session to a previously-authenticated session. Ideally, the consumer would then be rewarded for logging in, with the reward being based on their previous behavior (i.e. a 15% off offer on items viewed before).
Check back with us soon for the next post in this series. You can also submit your own blog post about ITP2 or other trending industry topics by sending a line to firstname.lastname@example.org.
ITP2 Blog Series: Part 1 | Part 2