In the second part of our series, we review how companies in the future can capture user behavior and use it to personalize the user experience. In the first part of our blog, we have shown and evaluated alternatives to user identification without cookies.
Part 2: Which solutions are reliable for real-time personalization and what experiences exist?
User identification and consistent user communication is a highly relevant subject for real-time personalization. Digital channels like web and mobile apps especially pose new challenges for most of our customers. Due to increasing restrictions in the browser environment and stricter legislation User identification becomes more and more difficult. We want to describe our experiences and solutions under these circumstances.
1. Website Personalization
To identify users on websites, we recommend various methods:
First-Party Cookies
FFirst-party cookies are used to identify users within a custom domain and its associated sub-domains. So, if a first-party cookie is set under the domain “yourdomain.com”, we will recognize users on websites associated with that domain and its sub-domains e.g. subdomain.yourdomain.com.
However, the scope of applying a first-party cookie is limited to the respective domain on which it is set, this makes it unsuitable for cross-domain user identification. For example, the value of a first-party cookie, in this case, the user ID, can only be read in the context of the domain in which the cookie was set. The lifetime of first-party cookies is usually one to two years unless the user actively deletes the cookie.
Using first-party cookies presents its own technical and legal challenges. On the one hand, the consent of the user is required (this subject has already been discussed in detail in part 1 of this blog series).On the other hand, browsers and platforms sometimes act against user identification via first-party cookies. For example, Apple’s iOS platform partially limits first-party cookies on all browsers by shortening the lifetime of first-party cookies set on the client-side via document.cookie to 7 days. Additionally, the lifetime is reduced to only one day if the referrer domain is a known tracker domain and contains encrypted parameters in the URL. The term tracker domain refers to the domain with which the browser communicates for user identification and data collection. To identify the trackers, iOS uses a tracking radar list provided by the DuckDuckGo search engine. This list includes domains from Facebook (facebook.com) or Google (doublecklick.net), for example. However, not every domain is automatically treated as a tracker domain; an algorithm makes the decision based on user behavior and the number of hits on the domain in the tracking context.
There are several alternatives to these restrictions, which we use successfully for our customers. I will explain one of them in more detail:
- All network communication, including setting and reading the first-party cookie, runs through the server domain where the user resides. The cookies must be set in the HTTP headers on the server-side, which is only possible if the HTTP endpoint has the same domain as the source of the HTTP call.
- In practice, this means that either a CName or an “A” record must be entered in the Domain Name System (DNS) for the respective domain of the tracking system. This can only be done in collaboration with the domain owner and is, therefore, more complex than conventional cookie integrations but creates significantly more transparency and traceability in tracking.
Expert Tip:
Since the dynamics of browser-based restrictions in the cookie environment are high and often releases are rolled out, we recommend that you frequently update via https://www.cookiestatus.com/. (Tip: bookmarking is essential)
2. Cross-Domain Personalization
For customers operating across different domains, in whose boundaries users should be identified, we use a combination of different approaches:
Third-Party-Cookies
Opposite to first-party cookies, third-party cookies are not set under the respective customer domain but the tracker’s server domain. For example, the cookie of a user on yourdomain.com is set under trackerdomain.com. Such allows the tracker to theoretically read the cookie’s value across different domains and recognize the user.
In practice, however, several browser restrictions are leading to the end of third-party cookies’ life cycle. Although third-party cookies can still be used as cross-domain identifiers, Firefox and all iOS browsers block the reading of third-party cookies by default. Chrome still supports this method until 2022 if the third-party cookies are set on the server-side with appropriate attributes. In 2022, Chrome will discontinue support for third-party cookies.
Hence, we increasingly rely on solutions based on user logins or URL parameters for cross-domain user identification.
URL Parameters
URL parameters are a method to transfer information, such as the user ID, from one domain to another. For instance, it is possible to add the User-Id as a URL parameter to the target URL when the user clicks on a link. The user can then be recognized when visiting the other domain. An example could be yourdomain.com?info=374859403, where 374859403 stands for the unique ID of the user.
Expert Tip:
The practice has shown that this approach works particularly well for personalization, e.g., through a personalized message that brings users from Domain A to Domain B to convert to domain B. In this case, the UserId can be attached as a parameter to the redirect URL referring to domain B.
User-Login
In Web portals where users log in, the user can be identified through the user’s account (e.g., customer ID). If a user is able to use his login information within different domains, he is recognized across domains at the time of login, and the user data can be retrospectively linked.
3. Mobile App Personalization
User recognition on mobile devices is divided into mobile web and mobile apps. While the user identification processes for mobile web, i.e., for websites accessed via mobile devices, operate very similarly to non-mobile devices (see the previous paragraph “Website”), the user identification methods for mobile apps work differently. User identification on the Web is primarily based on cookies set and read via JavaScript; contrary, the basis for identifying users on mobile apps is provided by so-called tracking software development kits (tracking SDKs). These SDKs are for various platforms such as iOS, Android, or Windows and contain a set of predefined code that developers can embed in their mobile apps to enable the identifying users – given that the user consents to the collection of his data. SDKs make life easier for developers because they do not have to provide their own code to track users. Instead, the mobile apps send the user’s data directly to the tracking server with a reference to the particular user:
There are two alternatives for user identification:
- User ID without authentication or user login
- User ID with authentication or user login
These User-Ids are also known as User-Pseudo-Id. These IDs are linked to the respective mobile app installation and will not change as long as the user does not reinstall the app. You can only identify users within the respective mobile app, but not across apps or devices.
When the user logs in to the mobile app, it is possible to identify them uniquely throughout the account in the app. If the user logs in to different mobile apps with the same account, he can be identified across apps and the user data can be retrospectively associated.
Fair and clean identification of users on the Web and mobile app channels is the primary and important step towards better recognition of the user; this establishes the basis for a uniform, cross-channel view of the user and thus for real-time personalization and optimization of the user experience.
Our following blogpost (Part 3) will address the possibilities of linking individual, channel-specific identities and merging them in an identity graph.
Photo: Antonio Gravante| Unsplash