CDP baseline configuration

Overview

This document provides information about the baseline configuration of RPI (Redpoint Interaction) in Redpoint CDP, based on best practices.

This is how we’ve configured RPI for Redpoint CDP, but it may also be a useful reference for you if you’re configuring RPI.

The baseline configuration aligns with the core data model that is consistent across all verticals (retail, healthcare, financial services, etc.). This document outlines what is configured and to some extent why but is not intended as “how to” document.

User groups and permissions

RPI provides six user groups to assign roles and permissions to each of the RPI users. The groups that are set up, along with a high-level explanation of their permissions, are as follows:

Redpoint Administrator: These users have complete and total control of the RPI environment, mainly comprised of the RPI support and operations team.
Super User: These users can create and design all the various aspects of a campaign/interaction from start to finish, which may include Real-Time, forms, offers, and segmentation. They will also have access to some of the RPI configuration options.
Campaign Designer: These users are the campaign designers and will have access to everything necessary to do that work. They can build interactions and do everything associated with that process.
Content Designer: These users are responsible for setting up the content for offers such as assets (html, text, etc.) and smart assets to support dynamic content.
Selection/Segmentation Designer: These users can set up selection rules that will be used by the campaign designers. They have a good understanding of the data available to build rules and segmentation.
Realtime Designer: These users have access to creating the pieces needed for Real-Time (Real-Time rules, smart assets, and Real-Time layouts).

For detailed information about these user permissions, see User group permissions.

Database keys

Database keys define the primary keys' various resolutions and support deduplication. For example, the primary key of the Golden Record Summary Resolution is set as individual_business_unit_id. This field is comprised of the records Individual_ID and Business_Unit, making each record unique. In the case where an individual has multiple brands associated to them, then they would have two or more different Individual_Business_Unit_ID records.

Database key reference:

Name	Column Name
Address Id	`address_id`
Customer Account ID	`customer_account_id`
Email Id	`email_id`
Employee ID	`employee_id`
Home Phone ID	`home_phone_id`
Household ID	`household_id`
Individual Business Unit ID	`individual_business_unit_id`
Individual ID	`individual_id`
Loyalty Account ID	`loyalty_account_id`
Mobile Phone ID	`mobile_phone_id`
Party Profile ID	`party_profile_id`
RPIResolutionKey	`RPIResolutionKey`

In the previous table, you can see that there are additional database keys configured. This allows a campaign designer to dedupe their audience on any of these keys.

For example: The campaign designer wants to select all of the opted in records based on a resolution that uses individual_business_unit_id as its database key. From there, they want to ensure that only one email is sent to an email address. So, they would need to dedupe on email_id, and having email_id as a database key would support that.

Folder structure

The baseline configuration for the RPI folder structure will consist of multiple root (parent) folders that users will see when navigating through the file system. The two main parent folders that users will be focused on are “Client” and “RPI”. The following sections explain the usage of the two and how a user’s permissions will play a part in that usage.

Client folder structure

The “Client” folder will be where users save their work as they are building out new pieces of RPI, such as selection rules, audiences, and offers.

The “Client” folder can be renamed to match actual clients' name. Users have full read/write access to this location, and it is the best place to save all of their work.

The previous image shows the base configuration, but you can expand each of these folders to a more granular level. For example, you could break the selection rule folder into distinct brands.

Refer toRPI client folder structure and examples for more information.

RPI folder structure

The “RPI” folder is where users can use predefined artifacts that are provided at the time of RPI deployment and are updated as new features and enhancements are deployed within the system. These predefined items consist of selection rules, attributes, placeholders, and so on. These folders have permissions applied to them based on the RPI user groups that users have been assigned to. For example, a Redpoint Admin will have read/write access to all of the folders, where a Campaign Designer will have read-only access to these folders.

Users will also see that the attributes are organized into groupings, with the attributes sourced from its related tables within the database.

Resolution levels

The resolution levels that have been set up within RPI have been set up at the Individual Business Unit record level. The resolutions that are configured are:

Customer Account Summary: This resolution level will pull all records that have a Customer Account ID. If you are looking to send to all customers and all of the accounts associated to them, this would be the resolution that you would use.
Email Summary: This resolution level will pull all records that have an Email ID. If you are looking to send to all email addresses within the database, this would be the resolution that you would use.
Golden Record Summary: This will pull unique records based on the Individual Business Unit ID. If there are multiple brands associated with a customer, then RPI will see each of those brands as unique records due to this combination. You don’t have the ability to dedupe based on additional database keys.
Golden Record Summary PII: This resolution will allow you to segment or select records based on certain PII (Personally Identifiable Information) data such as gender, birth date, or location information. You cannot see the data from the PII tables, but they are able to use the given table for queries.
Loyalty Account Summary: This resolution level will pull all records that have an Loyalty Account ID. If you are looking to send to all Loyalty Records within the database, this would be the resolution that you would use.
Party Profile PII: This resolution level will pull all records that have a Party Profile ID. If you are looking to send to all Party Profile Records within the database, this would be the resolution that you would use.

Multiple business units

The RPI database structure will support multiple business units based on the database key of Individual_Business_Unit_ID. The database key is created from the combination of Individual_ID as well as Business_Unit_ID, which is provided by the client if they support multiple business units. Since RPI will use the Individual_Business_Unit_ID as the key for selecting records, a user is able to then use the Individual_ID to perform a dedupe where needed in the audience.

The following table delineates the resolution levels.

Target Audience	Resolution Name	Database Table	Unique ID	Notes
Individual	Individual	`ir.INDIVIDUAL`	`individual_id`	Data is coming off of the PII table for Individual
Individual Golden Record	Individual Golden Record	`dbo.INDIVIDUAL_GOLDEN_RECORD_SUMMARY`	`Individual_business_unit_id`
Individual Golden Record PII	Individual Golden Record PII	`ir.INDIVIDUAL_GOLDEN_RECORD_PII`	`Individual_business_unit_id`	Data is coming off of the PII table for Individual Golden Record

Audience definitions

The default audience definitions that have been set up within RPI are based around the Golden Record Summary table. Running campaigns using the Golden Record Summary audience definition selects unique records based on Individual Business Unit ID from the underlying resolution level of Golden Record Summary.

The following table delineates the audience definitions:

Name	Resolution Level	Default Audience
Individual Golden Record	Individual Golden Record	Yes

Offer history attributes

The Offer History Attributes that have been assigned to the default audience definitions consist of the different ID fields that are available on the Golden Record Summary table. By writing these attributes to the Offer History table, it allows users to use the given data in future campaigns where needed, such as for suppressions or segmentation purposes. This data can also be used for reporting purposes.

The following table delineates the offer history attributes:

Field Name	Database Table
`address_id`	`INDIVIDUAL_GOLDEN_RECORD_SUMMARY`
`email_id`	`INDIVIDUAL_GOLDEN_RECORD_SUMMARY`
`employee_id`	`INDIVIDUAL_GOLDEN_RECORD_SUMMARY`
`home_phone_id`	`INDIVIDUAL_GOLDEN_RECORD_SUMMARY`
`household_id`	`INDIVIDUAL_GOLDEN_RECORD_SUMMARY`
`individual_business_unit_id`	`INDIVIDUAL_GOLDEN_RECORD_SUMMARY`
`individual_id`	`INDIVIDUAL_GOLDEN_RECORD_SUMMARY`
`mobile_phone_id`	`INDIVIDUAL_GOLDEN_RECORD_SUMMARY`

Metadata fields

The metadata fields that have been created within RPI can be used at either the audience level or at the segmentation level. The data assigned can be used for future decisions and also used within reporting, personalization and smart assets. The linked list provides the attributes that have been created and the data types associated to them.

For a delineation of the metadata attributes, refer to Metadata attributes.

Channels

The initial channel that is configured within RPI can be seen in the link below.

Control Channel: This can be used to write records that have been selected into offerhistory. The control channel allows users to hold out records from a campaign selection and allow reporting to be created to compare control vs. non-control records.

The following table delineates the available channels:

Channel Type	Channel Name	Available
General	Control Channel

Table joins

Within RPI there will be a predefined set of joins that will allow users to select data from the database tables based on the defined audience definitions and resolution levels. Note that Offer History joins are created at the time of audience definition validation. Although the joins are noted here, they are based on the standard data model and the tables that are exposed in RPI.

For a delineation of the table joins, refer to Table joins.

Placeholders

Within RPI, placeholders have been created to help users with campaign selection and segmentation. Multiple sets of placeholders have been created which users can use for either targeting data for selection or for suppression. This will help with cutting down the amount of configuration needed within a given audience or interaction. The link provided shows the current list that has been created in RPI.

In the link provided is the list of current placeholders that have been created in RPI along with their location within the folder structure. As audience definitions evolve there may be more placeholders added to the list as well.

For a delineation of the placeholders, refer to Placeholders.

PII vault

Within RPI there are two different databases that are set up with in the catalog. The first one is the data warehouse. The second one is the PII Vault, which is set up as an auxiliary database in RPI. The purpose of the PII Vault is to house all of a record's PII information in one place and allow RPI to remove the ability to see the data within the PII fields. Users will be able to use attributes from the PII Vault that have been exposed, but they will not be allowed to view the data they are pulling from those attributes.