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.
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_SUMMARYuses the customer's address along with the address of the stores to determine these calculations.
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_SUMMARYFirst purchase location
Last purchase location
Max purchase location
Closest location
Client primary location
CUSTOMER_ACCOUNT_BU_SUMMARYEnrollment location
LOYALTY_ACCOUNT_BU_SUMMARYEnrollment location
TRANSACTION_DETAIL_SUMMARYTransaction location