Assigning visitor IDs, including use of master and alternate keys

Table of Contents

Overview

Redpoint Realtime supports tracking of both anonymous and known visitors. You can still personalize a visitor's experience with an anonymous visitor profile tracking their behavior/data. That behavior can be merged with the information related to a known profile when a visitor provides information to link them to a known profile. This makes the platform very powerful, because you can personalize in both cases, but when someone is known or identifies themselves, you can merge the behavioral data when they were anonymous with the known profile for a more complete view of the customer's behavior.

Assigning visitor IDs

When assigning a visitor ID, you need to consider what ID to use for anonymous and known visitors.

Anonymous IDs can be set by the calling systems or Realtime can assign a visitor ID on behalf of the calling system, whereas Master and Alternate Keys need to be set in the configuration and then passed appropriately in Realtime calls to ensure proper alignment with keys as well as the expected profile merge behavior.

Below we will explore some of the considerations for both types of visitor IDs.

Anonymous or unknown visitor IDs

Anonymous Visitor IDs are used when a visitor has come to the website for the first time on a given device or if they have returned to the site on the same or a different device, but have not logged into their account and therefore are unknown. Using cookies or supporting website features to identify a previously identified or known user will be discussed further in the following sections.

Even though the idea that a visitor is anonymous doesn't mean that there isn't some thought that should go into picking these IDs. Using the Realtime visit endpoint (/api/Cache/Visit) allows for a visitor ID to be set, or Realtime can generate one for you based on setting the key IsNewVisitor in the body of the call to Realtime.

• If set to a value of true, it will generate a visitor ID (GUID) and provide that back to the calling system.

• If set to a value of false, it will use the ID that is passed in the value VisitorID key.

The considerations to be made when determining an anonymous visitor ID is if an anonymous or guest ID is already assigned to a visitor when they enter the website, mobile app, or other channels. If there is already one that is set by the calling system, then you may want to consider using it to keep things consistent. Also, if that ID is used by other systems that track Realtime behavior data, like Tealium, then you may want to consider using that ID instead of the Redpoint VisitorID. Otherwise, if there is no other compelling reason to use an existing ID for anonymous visitors, then you can use the Redpoint Realtime anonymous visitor ID to track anonymous behavior of a user.

Known visitor IDs: master and alternate keys

A known visitor is a visitor who has identified themselves by logging in or creating an account where they have provided data in order to identify themselves within the system they are interacting with. A website or mobile app are examples of these systems. This user account could be the same across applications, for example if a user ID on the website is the same as the user ID in the mobile app. Alternately, the systems may have different user IDs per application. In the latter case, additional identity resolution steps may need to be applied to determine if the user exists in another application so that a more consistent experience can be provided across applications. Additional identity resolution should be considered if you have a scenario like this.

If a visitor is known based on logging in or creating a account, we assume that they will now have a ID that is assigned uniquely to them by the user account system (Customer ID, AccountID, etc.). As mentioned before, these IDs or accounts may not be the same across applications, but ideally they will be used to make collecting data about a user and the associated experience consistent for the user.

In Realtime we have the option of defining a master key. Depending on the Realtime use cases, this may not be required, but it is needed in order to merge anonymous behavior with behavior and additional details related to a known user/account. One and only one master key can be assigned in a Realtime configuration. So, when assigning this key in the configuration, we need to determine what the best key is to use for this feature.

Considerations for setting the name of a master key

Is Realtime being deployed on more than one channel?

• If yes, then there is a follow up question: are the user or customer IDs the same across the channels that Realtime is being deployed on?

  • If yes, then the name of the Master Key should be set to the name of the ID that is used across the channels

  • If no, then you will need to consider what channel will be used more by Realtime, and set the name of the Master Key to be the name used by that channel. In addition, you may have to consider whether using the keys from the other channels as an Alternate Key makes sense.

• If no, and it is only being deployed on a single channel, what is the name of the user/account ID for that system? An example may be Customer_ID or Account_ID, and that would be what should be set as the name of the Master Key.

Consideration for alternate keys and their names

As mentioned, a Realtime environment can only have one Master Key, but you can have zero to many Alternate Keys. Alternate Keys are keys that can be used to link to a master key. An Alternate Key should only link to one Master Key.

We will use a retail business as an example of defining a Master and Alternate key. Let's say that in order to set up an account and get a customer ID, all you need to provide is your email address. In this case we would set the Master Key to be Customer_ID and then we would set Email_Address as the alternate key. This would allow you to provide the Master Key, and visitor data will be tracked to the profile associated with the Master Key. Alternately, if you have the email address but not the Master Key, then the Alternate key of Email_Address can be used to identify the Master Key and associate visitor data to the profile without providing the Master Key in the calls.

Master and alternate key functionality

To map an Alternate Key to a Master Key, a call needs to made to Realtime with both keys being provided. So using the previous example of a Master Key of Customer_ID and an Alternate Key of Email_Address, at least one call needs to be made to Realtime that has both the keys in it before calls can be made with just the Alternate Key. Once the link has been established between the Master and Alternate key, subsequent calls made with either the Master or Alternate key will map the data to the Visitor Profile associated with the Master Key.

Preserving visitor IDs across visitor sessions

In order to preserve a visitor ID across sessions, anonymous or known, the visitor ID needs to be stored somewhere. When the web client is used in on a website to integrate Realtime, client-to-server implementation, the visitor ID is persisted as a first-party cookie on the site. The name of the cookie is the ID of the client that Realtime is deployed and being called by. This same approach can be used for server-to-server implementations, but the server code will need to be adapted to maintain this ID.

A known ID like customer ID may be sourced from the website cookie and provided to Realtime in the event that it is populated, or known outside of Realtime, but it is the first time that Realtime is being initialized for a visitor. A good practice is to always provide the Master Key as a Visitor ID and provide it in the identity keys of a Realtime call to ensure that all the data is captured against the appropriate visitor profile.

Visitor profile merging: anonymous to known

There is a parameter in various Realtime payloads that allows setting the merge behavior of a profile from anonymous to known. This is covered in a separate topic that should be reviewed when determining what approach to take when merging profiles.

Tracking considerations when user logs out or deletes cookie

There are considerations to make when a user logs out or deletes a cookie as it relates to tracking visitor behavior. The considerations are around if you should continue to track that individual against the known visitor ID or generate a new anonymous visitor ID. This consideration has the biggest impact on shared devices where more than one user navigates the website or the app using the same device. There is no easy rule to apply when determining what the behavior should be, but it is something that should be considered when determining what the experience of the customers may be if tracking or merging of anonymous to known profiles is configured.

The user logs out

Using the logout as the example, if you continue to track behavior against that known visitor id after a user logs out, you may be serving content based on the logged in visitor's information, but the device may be a shared device, and the user may not actually be the same person as the previously logged in user. So you need to consider the implications of continuing to track and make decisions on the logged in account even after they log out. Some of this revolves around the types of decisions that are being made. If they are very personally related to the items that a logged in user was looking at, it may be inappropriate to show to users who are not related to the original user.

In a similar fashion, if you choose to configure the systems with Master Keys and allow for anonymous and known profiles to be merged, you have a similar consideration to make sure the active user was the same user that has been navigating the site up to the time that they logged in.

One option is to track anonymous and known behavior under separate IDs. So when a user logs in, you don’t merge the profiles, but you just begin to track things against the known visitor ID, which can be supplemented with additional data from a database or CDP that contains information related to the user beyond just their visitor profile behavior. When the user logs out, you can generate a new visitor ID to track the behavior against and provide a personalized experience based on the data tracked against that ID. This still provides a personalized experience for end users, but it doesn’t assume that the user who is on the site is the known user after they have actively logged out.

In addition to this approach of not merging or tracking the anonymous data against the known visitor doesn’t mean that you can’t capture the known user ID or previous logged in ID with the anonymous tracking in a way that you can use it to build a better profile at the data layer related to a visitor outside of Realtime.

Optionally you could consider these fringe cases and choose to merge anonymous to known profiles and to continue to track to the same visitor ID of the known user even after they log out.

The user deletes cookies

In the case of a cookie being deleted or if there was another cookie that was aware of the Master Key and the user was still logged in, it is reasonable to continue tracking to that ID. If they have deleted the cookies and logged out then it probably makes sense to generate a new visitor ID and track with that until the user logs back in.

Again, these are considerations that need to be made and discussed, but there is no one-size-fits-all approach; each client or Realtime user will need to consider the implications and options of the different types of behavior.

What should you use as anonymous and known IDs?

Below are a few questions to ask when considering what to use for these various IDs.

Anonymous visitor IDs

When considering what to use for an anonymous visitor ID, there are a few things you need to keep in mind.

What are the channels that Realtime will be deployed on?

• Website

  If there is already a notion of an anonymous visitor ID that is used on the website, that may be the best choice for an Anonymous Visitor ID for that channel to keep things consistent across the various systems.

  • Is there already a notion of a Visitor ID for anonymous visitors to the site?

    • Generated by the website?

    • Generated by an analytics tool?

      • Google Analytics

      • Adobe Analytics

      • etc.

• Mobile App

  If their anonymous users are allowed to use the app, however they or guests are tracked within the app may be the best option for an anonymous id for that channel. If only registered users are allowed to use the app, then this probably falls into the category of known visitors as opposed to tracking at the anonymous level.

  • Are guests or unknown visitors allowed in the app, or are they required to register or login to use the app?

  • If Unknown visitors are allowed, how is an anonymous visitor or guest tracked?

• Call Center

  If you were calling in for information related to the products or services provided by a company where Realtime is considered being hosted, you want to consider if there is value in knowing anonymous behavior and how it could be used in subsequent interactions via the call center or other channels. Given that it is a call center, you would expect to know the source phone number, which is a source of Personally Identifiable Information (PII) and may fall more into a known type of ID but maybe the number is blocked and tracking behavior to the number is not an option. This one is a little bit unique where it may be more important to know about active promotions or outreach programs and track inquiries about those initiatives to see what is driving more traffic than knowing the specific individual requesting information. Alternately, knowing that this is not the first time that a particular number has reached out may provide options for a more personalized dialog for future calls.

  • If you call in without an account is any information captured about the caller that could be used in subsequent calls?

What analytics or event tracking tools are being used across these channels?

If there is a consistent ID that is used across channels within the analytics applications that are deployed, that may be a good choice for an anonymous ID.

Known IDs

When it comes to known IDs, you want to consider what channels Realtime is being deployed on. If it is deployed on one channel, like the website, the account ID or whatever represents a unique customer or customer account may be a good ID to use. The entity like email that is required to set up an account may be a good choice as an alternate key.

If the system is deployed on multiple channels, you would want to consider if the same account ID is deployed across channels, or if each channel has its own notion of an account ID. If there is a single ID used across systems, then that is likely a good candidate for a master key. If they are unique per channel, then the channel with the greatest interaction may make the most sense for a master key, and the other channels' unique IDs may make sense as an alternate key.

In some cases, a master key may not make sense at all or using the Cached Attribute List feature of Realtime and bringing the various data points around a customer together in the backend and making it available to each channel's unique ID may be an approach that is most effective.

Again, in the case of known IDs, it is not a clear-cut answer to what the best solution is. The considerations listed above need to be reviewed, and a decision needs to be made as to what will be the best deployment approach for each individual customer using Realtime.