Campaign event nonRPI feed layout overview
Overview
This document provides additional details about the campaign event nonRPI 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.
Feed layout intent
This feed layout allows you to load external campaign events to the Redpoint CDP. These types of events are related to campaign efforts that involve engagement through 3rd party applications or vendors to support channels such as direct mail, email, SMS, or phone.
There is also a complimentary feed layout called Response Event (documented separately) that captures the responses to a campaign event. Using email as an example, the send event would be represented as a campaign event, whereas the open, click, unsubscribe, and other disposition data would be represented as the response events related to the campaign (send) event.
The primary reasons for loading campaign history are for use in selection rules, to generate aggregates, and for reporting purposes. For example:
Use the data for a selection rule: to identify records that have previously been targeted for an email campaign that you want to suppress for a new email campaign.
Use the data to generate an aggregate: to support calculating the last date an email was sent to the individual or email address.
Use the data for reporting: to show various metrics related to a campaign, such as…
The number of emails sent for a given campaign
How many of the emails were opened or clicked
The number of unsubscribes generated from the campaign
Extension table
This feed has an associated extension table.
For general information about extension tables, refer to: extension tables.
Feed layout areas of consideration
The campaign event feed layout provides support for ingesting data related to records that are targeted for a given campaign. This data requires that a unique client campaign event ID and event data time is provided along with a campaign code. But, in addition to those fields, it is expected that you provide either source party profile ID or a PII (Personally Identifiable Information) element. This will be used to link the campaign event record to an indvidual_id and individual_business_unit_id or the ID associated to the PII element.
The campaign event nonRPI feed layout loads data to a few different tables that make up the campaign structure within the data model in the CDP.
Campaign
Campaign Event
Campaign Event Customer Map
Campaign Event PII Detail
Campaign
Offer
Cell
Identity matching
Campaign event records are not run through the matching process in order to assign individual IDs and individual business unit IDs.
Only provide either the party profile ID or ONE of the PII fields when generating these records. Passing both PII and party profile ID or more than one PII field will not result in an error, but could cause unexpected results in assigning an individual ID to the record.
If a campaign event has a party profile ID, the campaign event record will get assigned the individual ID and individual business unit ID from the party profile/business unit record found in the party profile table.
If PII is provided, the PII element (email, phone, etc.) will have hygiene applied on the PII field and then an exact match against the phone/email/address table to get the associated ID (i.e.,
email_id,phone_id,address_id, etc.).
An individual_id and an individual_business_unit_id are only assigned if source_party_profile_id is provided and will not get assigned if only PII is provided.
Use in RPI
The campaign event table can be referenced from the summary tables primarily by individual business unit ID or by party profile ID. This information can be used in various ways. For example…
To perform follow-up communications from a previous campaign
To support segmentation for new or different campaigns
For suppressions based on previously receiving a message
Given that this data is comprised of campaign data that is generated both within (internal) and outside (external) of the Redpoint CDP, it allows for a single place to access all campaign initiatives.
Use in aggregates
The data in the campaign tables is primarily referenced from the aggregate tables, but it is used to calculate values in the email summary table. In this case, the calculations are primarily based on the response event data.
The joins to the campaign event table from the base summary tables are all made through the table CAMPAIGN_EVENT_CUSTOMER_MAP, which is where all the IDs (individual_id, individual_bu_id, email_id, phone_id, etc.) are found.
The Individual_Golden_Record_Summary table is joined to the campaign event table through the customer map using Individual_Business_Unit_ID (IBUID). Whereas the customer account and loyalty account BU summary tables are joined through the customer map using Party_Profile_ID (PPID).
The campaign event data is stored with the PII that was used for the communication at the time of the event. Given the CDP data and summaries are updated at a regular basis, the data on the summary table may join on IBUID or PPID, but the PII in the event data may not match the summary record that has the latest data. An example would be if someone had an active email address that was receiving marketing communications, and they updated their customer account record with a new email address. The customer account record would still join to the campaign event data, but the email_ids would not be the same.
The other entity IDs (email_id, phone_id, etc.) in the summary tables may not match the campaign event customer map table, because the campaign event customer map is the values of the identity fields at the time of the event execution, which is what the data in campaign event represents, and the summary tables represent the latest identity fields for each of the resolutions they are associated to.
Other approaches outside of the standard joins may be required in order to determine something like if a given email_id has been contacted in the last month. This requires the use of custom selection rules using custom SQL expressions.
Use in reporting
The data structure that this data is stored in supports both external data as well as internal data that is generated via Redpoint Interaction and Redpoint CDP Data Activation. This is the one location that is comprised of both internal and external data. Because of this, it is ideal to perform reporting from this data structure because all of the campaign event data can be found in a single location.
This data is used by the PowerBI reports that are a part of the Redpoint CDP.