Location feed layout overview

Overview

This document provides details about the location 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 layout is to allow for location details to be loaded to the Redpoint CDP platform. This data could be used in various contexts, like retail transactions, to reflect a purchase location, or in a healthcare context to reflect the location of a patient's service provider visit. There are various reasons for loading location data, but a few examples of how it can be used in campaigns are as follows:

• A retail campaign informing customers of a new store opening

• A health care campaign instructing a patient/customer to make an appointment at a particular service provider location and providing the number and address of the location

Additionally, the data can be used to calculate aggregates, such as the location of the most recent purchase or visit for a particular location. Location data can also be useful for reporting purposes, given all the data will be in one place for all internal and external analysis.

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 section includes some additional information to consider when providing data for this feed layout.

• The location feed layout allows for business unit to be provided, which allows you to maintain locations for a specific business unit.

• Additional detail can be provided with the location name and ID, like physical address details, manager’s name and email, location phone number etc. This data can be used in content for marketing purposes.

• This feed is a dependency for loading some of the other feeds, like party profiles or transactions. If another feed supports providing a location, then the location must exist on the location table before the record for the other feed can load. Records that are provided with a location that doesn’t exist in the location table will be put in the appropriate holding table and loaded when the location is provided that aligns with the record in the holding table.

• Both closed and open location information can be provided in this feed, and it is encouraged that you load both closed and open stores. Loading historical data that has a reference to a location that is closed will require for the location to be loaded in order for that other record to be loaded based on the referential integrity requirements. Historical transactions at a closed store is a good example.

• Distance to primary and closest store in the INDIVIDUAL_BU_LOCATION_SUMMARY uses the customer's address along with the address of the stores to determine these calculations.

• In cases where all information in a new record other than source_rec_create_date and source_rec_update_date matches an existing record in the database, the database record will not be updated, and the new record will be discarded as a duplicate. This is to ensure that location based portions of aggregations are only regenerated when the actual location data changes. This means that the data in the CDP database will match the oldest record if the files are processed sequentially and the newest record if they are processed as a batch.

Identity matching

Contact authorization data does not go through the matching process.

Use in RPI

The location table and data can be used in various ways in RPI. Selection rules can be defined for people with a specific primary store, or if a person has been made a purchase at a particular location they can be targeted for promotions at that location. In addition to that, there are aggregates that are calculated like first purchase location, last purchase location, and closest locations, among others, that can be used to personalize email content. An example would be to provide the address of the closest location or primary location in the content.

Use in aggregates

Summaries where the location is used:

• INDIVIDUAL_BU_LOCATION_SUMMARY

  • First purchase location

  • Last purchase location

  • Max purchase location

  • Closest location

  • Client primary location

• CUSTOMER_ACCOUNT_BU_SUMMARY

  • Enrollment location

• LOYALTY_ACCOUNT_BU_SUMMARY

  • Enrollment location

• TRANSACTION_DETAIL_SUMMARY

  • Transaction location