Contact authorization feed layout overview
Overview
This topic provides additional details related to the contact authorization 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 is to capture customer preferences in the CDP (Customer Data Platform). Preferences are captured for a contactable entity value (address, email address, phone number, etc.) along with the business unit and associated preference information. The data is captured transactionally as events, and the most recent event is surfaced through summary tables for use in campaigns. The latest event for a combination of an entity and business unit is surfaced in the summary table along with the preference information that is provided with that specific event. There are unique summary tables for each of the entities.
The preferences can be as simple as opt-in/opt-out data for a given entity or more sophisticated like opt in for an entity with a specific topic of interest along with a limit on the frequency of the communications. For example, an email could be “opt-in for communications about 90’s rock content with limited circulation rules of no more than one email communication per week”. Capturing this data at a business unit level allows for preferences for a specific entity, like email to be opt-in for one business unit while opt-out for others. These preferences can be used for selections that can be used for both inclusion and exclusion (suppression) purposes.
Extension table
This feed does NOT currently have an associated extension table.
Feed layout areas of consideration
Below are a few considerations to make when providing contact authorization data. These features are all dependent on the way that preferences are captured and offers flexibility in how the data can be provided to the CDP for managing communications based on an individual's preferences for a channel.
Authorization Code: This field contains the values
Opt_InorOpt_Outand either one (Opt_Out) or both can be provided to the platform. We recommend that you provide both if available in your source system. AlthoughOpt_outonly could be provided, the assumption you are making in this case is that any of the entities that are not opted out are opted in. This may make sense for something like direct mail or outbound phone calls but may be too permissive when it comes to email or SMS. So, when possible, it is recommended that you capture and provide both codes.Authorization Value: This attribute stores different types of categories for the authorization record, for example, Newsletter or Catalog subscription for the retail industry, or topics of interest such as Diabetes or Heart Health information for the healthcare industry. Using different authorization values and contact level type codes such as channel combination allows for more granular content preferences and tailored communications.
Authorization Frequency: This attribute is used to support limited circulation strategies where you want to provide the contact and associated entity with the ability to limit the number of communications as a general communication strategy or as an option to limit the number of opt outs by giving them an option to reduce the communications. This can be used in conjunction with the authorization value to manage frequency for one authorization value vs another. For instance, allow newsletters at any cadence, but limit general marketing content to once a week.
Double Verification Indicator: This double opt-in indicator, which is typically used for SMS or Email communications, is a way to both confirm that the correct contact value, email, or phone number was provided as well giving the individual a second opportunity to confirm their consent to receiving marketing communications.
Identity matching
Contact authorization data does not go through the matching process.
Use in RPI
Contact authorization summary data can be used in RPI at a minimum to either select opted-in records based on contact level type or suppress records if they are opted-out. The additional preference information can also be used for tailoring communications and content for contacts.
Use in aggregates
The following summary tables are created from the source contact authorization event data. They are referenced by all of the other summaries and base tables that have an <entity>_id (e.g., email_id) and business unit code to join the base table to the Contact_Auth_<entity>_Summary tables.
CONTACT_AUTH_ADDRESS_SUMMARYCONTACT_AUTH_EMAIL_SUMMARYCONTACT_AUTH_PHONE_SUMMARYCONTACT_AUTH_SMS_SUMMARY