Visitor profiles and IDs
Table of Contents
About Realtime visitor profiles and IDs
This section outlines what Realtime profiles consist of, how visitor IDs are assigned and used, and how master and alternate keys work.
Visitor profiles and IDs
Below are details related to Visitor IDs and associated profiles and their use.
Visitor IDs are unique identifiers assigned to individual visitors to a website or other online channel. In Redpoint Interaction (RPI), visitor IDs are used to track customer behavior and personalize interactions across multiple channels.
When a visitor first encounters a Realtime interaction, they may be assigned a new visitor ID, which is stored in the system along with other details about their behavior, such as the pages they visit, the offers they receive, and the goals they achieve. This information can then be used to personalize future interactions with the customer, for example by displaying targeted offers, recommending relevant products, or providing personalized content.
Visitor IDs can be generated in a number of ways, depending on the channel and the specific implementation. In some cases, they may be generated using a cookie or other tracking mechanism, while in others they may be generated based on user login credentials or other identifying information.
In addition to tracking individual visitors, RPI also allows you to segment visitors based on their behavior and other characteristics, such as demographics, purchase history, and preferences. This allows you to target specific segments with personalized messages and offers, improving the relevance and effectiveness of your campaigns.
Overall, visitor IDs are a critical component of RPI's Realtime personalization capabilities, allowing you to track customer behavior and personalize interactions across multiple channels to drive engagement, loyalty, and revenue.
Known and anonymous visitors
Every known and anonymous visitor to a web page tagged using RPI Realtime’s JavaScript web client, and/or a call made directly to an RPI Realtime API method, results in the building up of a unique Profile per discrete individual. Note that Profiles are built up on a per-device and per-browser basis, so if you view a web page in Chrome and also in Firefox on your laptop, and then again on your phone, you'll be treated as three Visitors by RPI.
Visitor profiles are stored in an in-memory Realtime cache. This means that latency is minimized when making decisions based on the information in the Visitor Profile.
A visitor’s profile can also be built up through the execution of Realtime cache offers, and through database lookups using cached attribute lists.
Populating the visitor profile
Visitor data in the form of name/value pairs can be added to the visitor profile through a variety of methods:
Querystring parameters: if a visitor navigates to a web page tagged by RPI Realtime using a URL to which
querystringparameters have been appended, the parameters' name/value pairs will be added to the Realtime cache. For example, navigating to'http://mylandingpage.com?CustomerKey=12345'will result in the addition of value'12345'for attributeCustomerKeyto the visitor profile.Web form submission: on submission of an RPI web form, the data entered by a visitor within the form will be added to his or her visitor profile if the RPI Realtime
web.configsettingCacheWebFormDatais set toTrue.A call to the RPI Realtime API:
api/Cache/Visitapi/Decisions/[endpoints]
The Realtime JavaScript web client: the web client provides methods for pushing data in the visitor profiles. In addition, the web client allows for the configuration of Realtime lenses, which are mechanisms for capturing and storing Realtime parameters based on the various sources from a web page.
Refer to the web client documentation for details on Realtime lenses:
DeploymentFiles\InteractionRealtimeAPI\RPIFormValidation\shared\js\rpiwebclient\do cumentation\index.htmlRefer to the Lens configuration definitions topic for information about using Realtime lenses, including descriptions and examples of the various lens options.
Supplementing visitor profiles with data from database
Data from one or multiple databases can also be added to the visitor profile through the following mechanisms:
Data can be retrieved from the data warehouse and stored in the visitor profile when a visitor self-identifies to RPI through the use of a Cached Attribute List (CAL). A CAL is a list of RPI attributes managed within a dedicated configuration interface in RPI. Identification of a visitor can occur:
At submission of a web form that is associated with a CAL.
On receipt of a name/value pair (e.g., through a
querystringparameter) when the name maps to an entry within the RPI RealtimeParameterToDataMappingssection ofappsettings.jsonfile, then the associated CAL will hydrate the visitor profile with the associated data. (See the ParameterToDataMappings setting section next for some additional details of RPI Realtimeappsettings.jsonconfiguration of this setting.)Via a call to the RPI Realtime API:
api/Cache/CachedAttributes
This endpoint could also be used to add an attribute to a visitor profile, as opposed to on thequerystring, which would trigger a lookup from a CAL and a hydration of data to the profile if a match was found.If the CAL is defined in the
appsettings.jsonfile and a lookup can be performed based on an attribute in the visitor profile, the hydration of data to the visitor profile will happen regardless of whether there is a Realtime decision that is using that data. Alternatively, if the CAL is not defined in theappsettings.json, but a Realtime decision is called that references the CAL and an attribute in the visitor profile can be used to perform the look in for the CAL, then the data will be hydrated in the profile for the CAL referenced in the Realtime decision.
A CAL can also be used to store “virtual lookup tables” in the Realtime cache. Calls to the data warehouse to retrieve visitor data can be avoided through the usage of this mechanism.
Visitor profile data can be populated in advance of site visits through the execution of a Realtime cache offer. This offer type is executed in the Interaction Designer workflow, within which an audience is used to define the list of potential site visitors for whom profile data is to be loaded. A Realtime cache offer is subsequently executed against the audience. Data, the structure of which is defined by the Realtime cache offer, is retrieved from the data warehouse and stored in visitors’ profiles in the Realtime cache. This data is then available when making decisions about content to be rendered to site visitors.
Visitor profile data can also be populated in batches via the RPI Realtime API:
api/Cache/Visitors/CachedAttributes
ParameterToDataMappings setting
ParameterToDataMappings are defined in the RPI Realtime website's appsettings.json file, as per the following example:
ParameterToDataMappings": [
{"ParameterName": "Email", "CALName": "CAL01"},
{"ParameterName": "Employee", "CALName": "CachedTable01"},
{"ParameterName": "CustomerKey", "CALName": "Cassandra"},
{"ParameterName": "Cassandra2", "CALName": "Cassandra2"}]Note: that RPI looks for changes to cached attributes every 10 minutes and updates the Realtime cache if any attribute values have changed in that period.
Visitor profile details and examples
A visitor profile is stored in two separate keys in the Realtime cache:
The primary visitor profile maintains all data except for Realtime events and is stored in the cache with
VisitorIDas the key.The second visitor profile stores data related to Realtime events and is stored in the cache with a key of
VisitorID_WE, whereWEstands for Web Events.
Primary visitor profile
This is identified in the cache by the VisitorID being the key. There is an example of the VisitorID as well as a list of the types of elements that can be found in the profile.
Example VisitorID
This is an example of a VisitorID, which is a GUID assigned by Realtime:
b5ab8de7-f342-43d5-94cd-ae6546960b4c
Types of elements stored in the primary visitor profile
Below is a list of elements that may exist in a visitor's profile.
Parameter/attributes (
Key/Value,Key/ValueList,Key/ValueJSON)Values: written to the profile directly; includes attributes created via lenses
Database values (
DBVals): values looked up in the database and stored in the profile
Geo location (
Location)Pages visited (
Pages)Realtime decisions and results (
Decs)
Example visitor profile in the cache
{
"v": 1,
"lastActivity": "2023-05-16T18:07:45.6333346-04:00",
"lastSavedDateUTC": "2023-05-16T22:07:46.6013915Z",
"isMasterProfile": "False",
"clientID": "d85fd304-91be-42ff-afd5-71876201ac4c",
"lTransfer": "2023-05-16T18:07:46.6013915-04:00",
"Values": {
"realtime_test": {
"u": "2023-05-16T18:00:15.7136716-04:00",
"iLE": "True",
"v": "False",
"vfmt": "str"
},
"PATHNAME": {
"u": "2023-05-16T18:07:45.6333346-04:00",
"iLE": "True",
"v": [
"/FTP/Landing_Pages/Realtime_Demo_Pages/Realtime_Examples.html",
"/FTP/Landing_Pages/Realtime_Demo_Pages/Realtime_Examples.html"
],
"vfmt": "cls"
},
"LATEST_PATHNAME": {
"u": "2023-05-16T18:00:15.7136716-04:00",
"iLE": "True",
"v": "/FTP/Landing_Pages/Realtime_Demo_Pages/Realtime_Examples.html",
"vfmt": "str"
},
"fe7e61b1-dfc8-492a-a452-ed727a3f0c22": {
"n": "Number of visits",
"u": "2023-05-16T18:00:15.7136716-04:00",
"iLE": "False",
"v": "1",
"vfmt": "int"
},
"6930beb7-ce98-4b8a-a00b-2bfd8fe0757d": {
"n": "Language",
"u": "2023-05-16T18:00:15.7136716-04:00",
"iLE": "False",
"v": "English (United States)",
"vfmt": "str"
},
"1945768d-7970-4e6c-aa4c-91c336f784df": {
"n": "Region",
"u": "2023-05-16T18:00:15.7136716-04:00",
"iLE": "False",
"v": "United States",
"vfmt": "str"
},
"individual_id": {
"u": "2023-05-16T18:07:45.6333346-04:00",
"iLE": "True",
"v": "100",
"vfmt": "str"
}
},
"Location": {
"lon": "string",
"lat": "string",
"sch": "string",
"upd": "2022-12-01T16:31:13.9920792-05:00"
},
"DBVals": {
"order_id": {
"d": "2023-05-16T18:07:46.6013915-04:00",
"v": [
"123",
"654",
"334",
"786"
]
},
"total_price": {
"d": "2023-05-16T18:07:46.6013915-04:00",
"v": [
"20.20",
"1000.07",
"475.35",
"85.92"
]
}
},
"isHistoryCached": "False",
"Pages": [
{
"n": "https://local.rphelios.net/ftp/landing_pages/realtime_demo_pages/realtime_examples.html",
"h": "local.rphelios.net",
"lV": "2023-05-16T18:07:45.6333346-04:00",
"lDec": "2023-05-16T18:07:46.5594887-04:00",
"pubid": 0,
"noV": 2,
"dyn": [
{
"id": "52586962-ff91-43e1-aab7-99c0e5b657a8",
"ix": "2"
},
{
"id": "96c306e8-ee3b-4163-a3ed-adffcc594e40",
"ix": "1"
},
{
"id": "5835daae-21c8-4b60-9d78-771c5c551f4f",
"ix": "5"
},
{
"id": "bfcec0e1-3d14-4676-ad8d-c6a213683898",
"ix": "2"
},
{
"id": "b7c9d812-9dd1-4b2e-ace7-3cdefb51e5a3",
"ix": "1"
},
{
"id": "2c91948b-bca1-4751-9a52-97354ee8b208",
"ix": "1"
}
]
}
],
"Decs": [
{
"id": "52586962-ff91-43e1-aab7-99c0e5b657a8",
"r": 2,
"i": 2,
"n": "RTD - RB - Query String Attribute realtime_test",
"d": "2023-05-16T18:07:45.635266-04:00"
},
{
"id": "96c306e8-ee3b-4163-a3ed-adffcc594e40",
"r": 1,
"i": 1,
"n": "Goal Smart Asset Test",
"d": "2023-05-16T18:07:45.6382575-04:00",
"h": [
{
"r": 2,
"i": 1,
"d": "2023-05-16T18:00:15.7272849-04:00"
}
]
},
{
"id": "5835daae-21c8-4b60-9d78-771c5c551f4f",
"r": 5,
"c": "Default",
"i": 2,
"n": "SA - RB - Favorite Color",
"d": "2023-05-16T18:07:45.6434602-04:00"
},
{
"id": "bfcec0e1-3d14-4676-ad8d-c6a213683898",
"r": 2,
"i": 2,
"n": "SA - RB - DB - Gender",
"d": "2023-05-16T18:07:46.5557119-04:00"
},
{
"id": "b7c9d812-9dd1-4b2e-ace7-3cdefb51e5a3",
"r": 1,
"i": 2,
"n": "SA - Number of Visits",
"d": "2023-05-16T18:07:46.55849-04:00"
},
{
"id": "2c91948b-bca1-4751-9a52-97354ee8b208",
"r": 1,
"i": 2,
"n": "SA - RTD - RB - Test Table Asset",
"d": "2023-05-16T18:07:46.5594887-04:00"
}
]
}Web events visitor profile
This is identified in the cache by the <VisitorID>_WE being the key. Below is an example of the VisitorID that is generated in the cache, as well as a list of the types of elements that can be found in the profile, including an example of a profile.
Example web event VisitorID
This is an example of a VisitorID, which is a GUID assigned by Realtime:
b5ab8de7-f342-43d5-94cd-ae6546960b4c_WE
Types of elements stored in the web event visitor profile
Below is a list of example events that may exist in a web event visitor's profile. These are just a few of the out-of-the-box event types that are generated when submitting RPI Web Forms or when the RPI web client generates events when page view and click tracking is enabled. Outside of these examples, any event and associated data will be stored in this profile, including custom events. Goals are also captured in the WE profile.
Events
Pages visited/viewed
Page link click
Form submission
Goals
Example visitor profile in the cache
{
"lTransfer": "2023-03-29T16:32:32.8905336-04:00",
"Goals": [
{
"name": "string",
"date": "2023-03-29T16:32:32.8915314-04:00",
"pub": 0,
"purl": "string"
}
],
"Events": [
{
"name": "Test Event",
"detail": "Test Event Detail",
"date": "2023-03-29T16:32:32.8915314-04:00",
"metric": 0.0
},
{
"name": "PageVisit",
"detail": "Realtime Decision Examples",
"date": "2023-05-17T01:07:54.5409295-04:00",
"metric": 0.0
},
{
"name": "PageLinkClick",
"detail": "https://local.rphelios.net/Realtime_Examples_LinkClick.html",
"date": "2023-05-17T01:07:51.1681543-04:00",
"metric": 0.0
},
{
"name": "PageVisit",
"detail": "Realtime Decision Examples Link Click",
"date": "2023-05-17T01:07:51.3321564-04:00",
"metric": 0.0
},
{
"name": "PageLinkClick",
"detail": "https://local.rphelios.net/Realtime_Examples.html",
"date": "2023-05-17T01:07:54.4573806-04:00",
"metric": 0.0
},
{
"name": "Sample_Event",
"detail": "Sample_Event_With_Meta",
"date": "2023-05-17T01:28:57.3261905-04:00",
"metric": 1.0,
"meta": [
{
"eDt": "2023-05-17T01:28:57.3261905-04:00",
"Meta": {
"svid": {
"v": "svid_123"
},
"fsid": {
"v": "fsid_23"
},
"rpcid": {
"v": "rpcid_357234"
},
"cxid": {
"v": "cxid_65843"
}
}
}
]
}
]
}