Account feed layout overview

Overview

This document provides additional detail related to the account feed layout, including the use of the feed layout, how the data is reflected in the database, and how to use the data from RPI.

This section provides the following detailed information:

Feed layout intent

The intent of this feed is to allow for account information to be loaded to the Redpoint CDP. This can include various types of accounts: customer accounts (POS, e-commerce, mobile app, etc.), loyalty accounts, healthcare accounts, as well as others.

Like all other feeds, this feed supports the concept of business units, which means that a single corporation can store data for accounts for one or more business units. This allows for supporting aggregates and communications to accounts associated with a specific business unit versus just a customer of the corporation/enterprise. In addition to supporting accounts per business unit, you can have one or more members associated to an account. Associating members to an account is how you associate PII (Personally Identifiable Information) for members to an account. Loyalty accounts have additional detail about the loyalty program, points balance, and loyalty tiers, to name a few.

The accounts, loyalty information, and account membership are stored in the following high-level data structure. This data is used to create Customer and Loyalty Account Summaries (aggregates) that will be discussed in more detail later in this document.

Extension table

This feed has an associated extension table.

For general information about extension tables, refer to: extension tables.

Feed layout areas of consideration

This feed supports loading of account level information into the Redpoint CDP. The account feed supports loading accounts for one or more business units. Rounding out the account feed is the ability to associate one or more members to an account, which allows for multi-member account support. The multi-member feature gives you the ability to support accounts with a primary account holder as well additional members.

When loading multiple members though the account feed, you need to provide the same account information for both records, as the most recent account information will be what is stored in the customer account table. If you have a multi-membership account, and there are account-level updates to make, you only have to provide a record for one of the members to update the customer account data.

Account members are associated to the account via party profile records using source_party_profile_id and business_unit_code to look up the Individual_ID and Individual_Business_Unit_ID in the party profile table and load it to the Customer_Membership table.

• Party profile records need to be loaded before the account records will successfully load. If the party profile is not loaded yet, then the account record will be placed in the holding table until the associated party profile record is loaded.

• You must include Party Profile information to load any account record as it is a required field of the feed.

The account feed, like other feeds, provides the ability to supply business unit codes along with the account records. This allows for a corporation to load data related to the activity of an individual with a business unit and execute campaigns and communications for one business unit separate from another.

Account information is needed to link things like transactions to a customer in retail and appointments to a member in healthcare. The accounts need to be loaded before the transactions or appointments can be loaded to the CDP.

The account feed will support loading data for various use cases related to accounts. As illustrated above, the following three base tables make up the data structures that support storing account information.

• Customer Accounts

• Loyalty Accounts

• Account Membership

There may be multiple accounts for a single individual, and this may not be obvious to the source systems, but when the party profiles are loaded and Individual_IDs are assigned to them, two or more unique party profile records may be identified as the same individual when the data is run through matching.

In some cases, you may want to communicate to the individual once regardless of the number of accounts they have, like a newsletter for all individuals with a customer account. Other times, you may want to communicate to all of the accounts that are active, regardless of whether they are associated with the same individual. For example, when sending out a monthly points balance email to loyalty customers, if there are three accounts for the same individual, you may want to send a communication per account for marketing or compliance reasons. This would also apply to sending communications to the insurance policy holder as well as the additional members that may be on the policy.

Account natural key

The natural key of the customer account table and the account feed layout is source customer account ID + business unit code. This means that if there are two different account types with the same source customer account ID, the last one loaded will be what is represented.

If there is a concern that there may be an overlap of account IDs across different account types, this should be considered when creating the account feed layouts to determine a way to support your requirements based on what the feed layout supports. One approach could be to add a prefix of the source to the source customer account ID so that you can differentiate between the accounts and maintain a copy of each in the customer account table.

Loyalty data

If any of the loyalty fields are provided, then the data will get stored in the loyalty detail table, but in order for the LOYALTY_ACCOUNT_BU_SUMMARYtable to get populated, the account type needs to be loyalty.

Lookup tables

There are a couple of lookup tables that need to be loaded with the appropriate values to load the account data. Business unit is related to all feed layouts, but account type and loyalty account tier are only related to account feed layout.

• BUSINESS_UNIT_LOOKUP

• ACCOUNT_TYPE_LOOKUP

• LOYALTY_ACCOUNT_TIER_LOOKUP

Multiple account members for one account

You cannot associate account members (party profiles) from a business unit that is different than the business unit for the account you are trying to load. So if you need to associate PII from a party profile that has a different business unit than the account record you are loading, you will need to load a party profile record first that aligns with the business unit of the account you are trying to load.

Identity matching

Customer account feed does not go through the matching. Party profiles are used to associate PII to an account.

Use in RPI

Customer account and related summary data can be used in RPI to support campaign targeting based on account data. As mentioned above, this data can facilitate:

• Sending something like a newsletter to active accounts

• Sending monthly loyalty statements to each active loyalty account with their current points balance

• Notifying a patient that they are due for a physical

Use in aggregates

The following summary tables are created from the customer account data. There are two primary summary tables at the customer level and the loyalty level. These tables have customer-related information and link to the PII of the primary account holder.

Summary table names

• CUSTOMER_ACCOUNT_BU_SUMMARY

• LOYALTY_ACCOUNT_BU_SUMMARY

The only records that go to loyalty summary are those with an account type of loyalty. Otherwise, the records will get loaded to the customer summary.

Expanded ERD for account base tables

The detailed entity relationship diagram (ERD) below shows the fields in the various tables that make up the account data structure within the CDP and the links to each table as well as notes on the keys (primary - PK, natural - NK) and the various IDs.

Additional account use case examples

In addition to the documentation for usage of the account feed layout, there are also a set of use cases that we have provided sample records for to show how you would format the records depending on your use case. The use cases help illustrate how to provide data and how they will materialize within the data model. These are just a couple of common use cases, but the feed layout can be used to provide account data in ways that are not illustrated in these examples. These examples can be found here.

Use case examples

As a part of providing sample records for customer account and loyalty, additionally we will include data related to different use cases for the account feed layout, like one customer account with one member and another customer account with two members (primary and secondary). Below is a quick list of the use cases, but additional details and the data sets can be found here.

• Customer account only

• Loyalty account only

• Customer account with loyalty account data

• Loyalty account with customer account data

• Multiple members for one customer account

The supporting data for each of these use cases can be found in the sample page.