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_id
s that are created by the identity resolution process along with individual_business_unit_id
s. 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_id
s and individual_business_unit_id
s 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_id
s. 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 aNULL
field. Below are some examples of source party profile ids. ANULL
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 thesource_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 ofsocial_login
+social_platform
fields together.If
custom_match_attribute
field(s) are populated, thencustom_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 differentbusiness_unit_code
s and…The same PII, we’ll generate one
individual_id
and separateindividual_business_unit_id
s.Different PII, we’ll generate two separate
individual_id
s andindividual_business_unit_id
s.
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_id
s assigned to a party profile can change due to more or different information coming in on records. This causes theindividual_id
s 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 defaultFirst name has alias matching is on by default
For example,Arthur
andArt
andArthar
will match together as the same Individual if other PII attributes are the sameFirst name abbreviation matching is
ON
For example,Betty
andB
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.