Feed layouts: processing sequence and dependencies

Below is a list of the Core and Retail feed layouts, the suggested sequence of processing when building the CDP, along with the dependencies that the feed layouts have.

Feed layouts and dependencies

Below are the list of the feed layouts and some details of any dependencies for that feed layout. There are two primary types of dependencies: extension dependencies and other feed dependencies.

Extension dependency

Many primary feed layouts have associated extension feed layouts to allow you to capture data that is not accounted for in the primary feed layout. These extensions are based off the primary key of the primary feed layout. In order for an extension record to load properly, it needs the primary record that it is extending to be loaded already.

Feed dependency

Feed dependencies are where one feed is dependent on another feed loading first because it has a reference to that other feed. Location itself is not dependent on any other feed before it can be ingested to the CDP, but other feed layouts are dependent on it. If there are any feed layouts that reference a location, they will require that the location has been loaded first before the records will load other feeds. The field source_main_location_id in the Party Profile feed layout is an example of a dependency on Location to load the Party Profile record. If the location in the party profile record is not found in the location table, then the party profile record will be placed in the holding table with a reason indicating that the location dependency was not found.

Core feed layouts

Here is the list of Core feed layouts. See the Core Feed Layouts and Dependencies section below for the recommended order to load the feeds layouts as well as any dependencies.

Party Profile
Party Profile Extension
Contact Authorization
Account (Includes Loyalty + Customer Account)
Account Extension
Campaign Event Non-RPI
Campaign Event RPI
Campaign Event Extension
Response Event
Response Event Extension
Location
Location Extension
Insight

Core feed layouts: processing sequence and dependencies

Below is the suggested sequence of processing Core feeds:

Location: There are no dependencies to load location data except for the lookup tables that are referenced by the location feed layout.
Location Extension: Records will be validated against Location using source_location_id, and un-matched records will be available in holding table with corresponding reason.
Party Profile: If source_main_location_id is populated, then values will be validated against Location, and no-match records will be available in holding table with corresponding reason.
Party Profile Extension: Records will be validated against Party Profile using source_party_profile_id, and un-matched records will be available in holding table with corresponding reason.
Contact Authorization:
1. contact_level_type_code = direct_mail -> these records will be validated against Address Table. Addresses and un-matched records will be available in holding table with corresponding reason.
2. contact_level_type_code = email -> these records will be validated against Emails, and un-matched records will be available in holding table with corresponding reason.
3. contact_level_type_code = fax OR phone OR sms -> these records will be validated against Phone numbers, and un-matched records will be available in holding table with corresponding reason.
4. contact_level_type_code = party_profile -> these records will be validated against Party Profile, and un-matched records will be available in holding table with corresponding reason.
5. contact_level_type_code = soc_media -> these records will be validated against Social Logins, and un-matched records will be available in holding table with corresponding reason.
Account:
1. If enrollment_location_id is populated, then values will be validated against Location, and no-match records will be available in holding table with corresponding reason.
2. If source_party_profile_id is populated, then values will be validated against Party Profile, and no-match records will be available in holding table with corresponding reason.
Account Extension: These records will be validated against Account using source_customer_account_id, and un-matched records will be available in holding table with corresponding reason.
Campaign Event Non-RPI:
1. If source_party_profile_id is populated, then values will be validated against Party Profile, and no-match records will be available in holding table with corresponding reason.
2. If email_address is populated, then values will be validated against Emails, and un-matched records will be available in holding table with corresponding reason.
3. If home_phone_num and/or mobile_phone_num and/or work_phone_num and/or other_phone_num is populated, then values will be validated against Phone numbers, and un-matched records will be available in holding table with corresponding reason.
4. If Address Attributes are populated, then values will be validated against Addresses, and un-matched records will be available in holding table with corresponding reason.
Campaign Event RPI: There are no dependencies to load Campaign Event RPI data except for the lookup tables that are referenced by the Campaign Event RPI feed layout.
Campaign Event Extension: These records will be validated against Campaign Event using client_campaign_event_id, and un-matched records will be available in holding table with corresponding reason.
Response Event: These records will be validated against Campaign Event using client_campaign_event_id, and un-matched records will be available in holding table with corresponding reason.
Response Event Extension: These records will be validated against Response Event using client_response_event_id, and un-matched records will be available in holding table with corresponding reason.
Insight:
1. identity_type_code = party_profile_id -> these records will be validated against Party Profile, and un-matched records will be available in holding table with corresponding reason.
2. contact_level_type_code = email_id -> these records will be validated against Emails, and un-matched records will be available in holding table with corresponding reason.
3. contact_level_type_code = household_id -> these records will be validated against Household, and un-matched records will be available in holding table with corresponding reason.
4. contact_level_type_code = individual_id -> these records will be validated against Individual Business Unit, and un-matched records will be available in holding table with corresponding reason.

Retail feed layouts

Here is the list of Retail feed layouts. See the and Retail Feed Layouts and Dependencies section below for the recommended order to load the feeds layouts as well as any dependencies.

Transaction
Transaction Header Extension
Transaction Detail Extension
Tender
Tender Extension
Purchase Discount
Purchase Discount Extension
Product
Product Extension
Fulfillment
Fulfillment Extension

Make sure all Lookup tables have been populated with default or custom values before proceeding with feed load; those lookup tables are not mentioned in this page.

Address is mentioned throughout this document. When Address is mentioned, it is a reference to the following attributes that make up Address:
Address = address 1 + address 2 + address 3 + address 4 + city + state_province + postal_code_1, postal_code_2

Retail feed layouts: processing sequence and dependencies

Below is the suggested sequence of processing Retail feeds:

CORE - Location: The location feed layout is referenced by the transaction feed, indicating where the transaction occurred. It is not required, but highly recommended that you include the location when providing transactions, even if they are only e-commerce transactions, as the location type is used to perform some of the aggregations related to transactions.
Product: There are no dependencies to load product data except for the lookup tables that are referenced by the product feed layout.
Product Extension: Records will be validated against Product using source_product_id, and un-matched records will be available in holding table with corresponding reason.
Transaction:
1. Records will be validated against Location using source_location_id, and un-matched records will be available in holding table with corresponding reason.
2. If original_source_location_id is populated, then values will be validated against Location, and no-match records will be available in holding table with corresponding reason.
3. If source_product_id is populated, then values will be validated against Product, and no-match records will be available in holding table with corresponding reason.
4. If source_party_profile_id is populated, then values will be validated against Party Profile, and no-match records will be available in holding table with corresponding reason.
5. If bill_to_home_phone_num and/or bill_to_mobile_phone_num and/or bill_to_work_phone_num and/or bill_to_other_phone_num is populated, then values will be validated against Phone numbers, and un-matched records will be available in holding table with corresponding reason.
6. If bill_to_email_address is populated, then values will be validated against Emails, and un-matched records will be available in holding table with corresponding reason.
7. If source_customer_account_id is populated, then values will be validated against Customer Account, and un-matched records will be available in holding table with corresponding reason.
8. If source_loyalty_account_id is populated, then values will be validated against Customer Account, and un-matched records will be available in holding table with corresponding reason.
Transaction Header Extension: Records will be validated against Transaction Header using source_transaction_id, and un-matched records will be available in holding table with corresponding reason.
Transaction Detail Extension: Records will be validated against Transaction Detail using source_transaction_id + line_item_num, and un-matched records will be available in holding table with corresponding reason.
Tender:
1. If source_location_id is populated, then values will be validated against Location, and un-matched records will be available in holding table with corresponding reason.
2. Records will be validated against Transaction Header using source_transaction_id, and un-matched records will be available in holding table with corresponding reason.
Tender Extension: Records will be validated against Transaction Payment using source_transaction_id + payment_seq_num, and un-matched records will be available in holding table with corresponding reason.
Purchase Discount:
1. If source_location_id is populated, then values will be validated against Location, and un-matched records will be available in holding table with corresponding reason.
2. Records will be validated against Transaction Header using source_transaction_id, and un-matched records will be available in holding table with corresponding reason.
Purchase Discount Extension: Records will be validated against Transaction Payment using source_transaction_id + discount_sequence + line_item_num, and un-matched records will be available in holding table with corresponding reason.
Fulfillment: Records will be validated against the Transaction Detail data to confirm that the source_transaction_id and line_item_num exist in the transaction data. Otherwise, the record will be placed in the holding table.
Fulfillment Extension: Records will be validated against Fulfillment records using source_fulfillment_id, and un-matched records will be available in holding table with corresponding reason.