Party profile feed layout overview

Overview

This document provides additional details about the party profile 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 party profile (PP) data to be loaded to the Redpoint CDP. The party profile is used to ingest personal information of any individual party (such as prospect, customer, patient, or digital information of a party) generated by your source systems (i.e., Point of Sale, CRM, web platform, private label credit card, etc.). This feed layout is composed of source system IDs and Personally Identifiable Information (PII). This data is used to capture identity resolution record(s) that are then matched and merged into a single individual in the match process.

There are unique individual_ids that are created by the identity resolution process along with individual_business_unit_ids. The CDP supports multiple business units by default, and if the source systems only contain data for a single business unit, then although the value of the indvidual_ids and individual_business_unit_ids will be different, they will effectively represent a unique individual per ID. Whereas when source systems contain data for more than one business unit, both the business unit code along with the PII will be provided in the feed, which can result in a single individual_id that is associated to one or more individual_business_unit_ids. The golden record summary is unique on individual_business_unit_id to support summary and aggregation data per business unit.

Extension table

This feed has an associated extension table.

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

Feed layout areas of consideration

Given that the party profile feed is the primary source of PII and therefore is a crucial feed in relation to the identity resolution within the CDP, there are a lot of things within in this feed that impact the way the feed is processed along with the matching.

This section highlights the unique components of this feed that affect the ingestion of PII data as well as the impact on matching. Matching itself will be addressed in a separate page, but there may be some overlap between the information below and that page.

• source_party_profile_id is a natural key, and it's not a NULL field. Below are some examples of source party profile ids. A NULL source_party_profile_id record will get rejected and stored in a quarantine file during validation process.

• If only source_party_profile_id is provided in a record, then it will pass through validation, but it won't get loaded into the CDP. On the CDP dashboard, you will see the record in the ignore bucket. This is because, along with the source_party_profile_id, there is some level of PII that is required to run the data through matching and load to the CDP with any value. Below is a list of the minimum PII fields for matching.

• Household ID is assigned based on the combination of one of the following:

  • last_name + address_1 + address_2 + address_3 + address_4 + address_5 + city + state + postal

  • last_name + email

  • last_name + phone

• If social_login fields are populated and they are same across the platform, then they will match to the same individual and household (assuming no other PII fields are populated). In general, social_login fields are used for matching criteria and not the combination of social_login + social_platform fields together.

• If custom_match_attribute field(s) are populated, then custom_match_attribute (across 1 to 5) will be used for matching. custom_match_attribute_name fields are not part of the matching criteria.

• If an email is invalid, as determined by email processing rules or phone provided, then this information will be NULL in the party profile, and it will not be used in matching-related processes.

• When the same source_party_profile_id is provided with different business_unit_codes and…

  • The same PII, we’ll generate one individual_id and separate individual_business_unit_ids.

  • Different PII, we’ll generate two separate individual_ids and individual_business_unit_ids.

• When a party profile record is provided with source_main_location_id, then this information is validated against the location data. If it’s not matched, then the record will be inserted into a feed layout holding table and will not be available in the CDP/DBO/client facing table. Holding table records are processed each time the feed gets processed, and if the corresponding information is available in the respective table in the CDP, then the holding record will get processed and will be available in the CDP, otherwise it will go back into the holding table.

• When two party profile records are provided with the same address attributes, then only one record is inserted or updated in the address table, and the associated address ID is assigned to both records.

• Over time, individual_ids assigned to a party profile can change due to more or different information coming in on records. This causes the individual_ids to merge or break apart due to the additional or changed information on the records. These ID changes are logged in a reference table.

• When new/updated PII information comes through party profile, then those attributes will be available when calculating the golden record summary table.

• Multiple PII attributes for the same entity can be provided to the CDP, e.g., personal_email_address, work_email_address, other_email_address_1. This adds additional values and context for matching, and each of the values will be available in the CDP.

• The most recent information provided for a party profile record…

  • Is available for aggregations

  • Is in the party profile table

  • Overwrites the existing data; partial updates to records are not performed

Example for source_party_profile_id

• Customer ID: generated/created on online profile account

• Loyalty ID: generated/created by loyalty system

• User ID (name): generated/created on online profile account

• Patient ID: Patient Identifier
  A Patient ID is a broader term that can refer to a unique identifier used at a system-wide level, which may encompass multiple facilities or entities within a health network.

• MRN: Patient's Medical Record Number
  An MRN is a unique number assigned to a patient's medical record in a specific healthcare facility or health system.

Identity matching

Party profile goes through matching, and in order for the record to be valid, PII data need to be included, such as one of the following:

• Email address

• A combination of either full name or first name and last name + address 1 + state province + postal code1 fields

PII fields required for identity resolution (matching)

A party profile record is processed through the matching process if one of the following PII conditions are met. Although some information related to matching is listed below, more use cases can be found in the Matching use cases page.

• Name + email

• Name + phone

• Name + address

• Name + custom match attribute

• Name + social login

• Email (if configured for email-only match)

• Phone (if configured for phone-only match)

• Name = first and last name fields in the field layout

• Email-only match and phone-only match featured are set to Y by default

• First name has alias matching is on by default
  For example, Arthur and Art and Arthar will match together as the same Individual if other PII attributes are the same

• First name abbreviation matching is ON
  For example, Betty and B will match together as the same individual if other PII attributes are the same

Use in RPI

Party profile data can be used in RPI for various selection rules and segmentation as well as for personalization when using each of the various aggregates that reference or are built upon the party profile data.

Use in aggregates

Party profile is the primary source of PII data for the CDP. This is a primary source of data for the INDIVIDUAL_BU_GOLDEN_RECORD_SUMMARY table via the party profile table and the identity resolution tables.

In addition to that, the CUSTOMER_ACCOUNT_BU_SUMMARY and LOYALTY_ACCOUNT_BU_SUMMARY directly link back to the party profile and party profile PII in order to tie the main party profiles associated with the creation of the customer or loyalty accounts.

See industry specific data model summaries for additional links to the party profile data.