One-to-many relationships and transactional audience definitions

Introduction

This document provides a detailed guide on how to configure and use the transactional audience definitions feature in Redpoint Interaction (RPI). It covers the configuration steps, usage patterns, and the results of various configuration and usage options.

The key sections include:

• Configuring a transactional audience definition

• Creating an audience using a transactional audience definition

• Example configuration of a transactional interaction

• Considerations and restrictions

This feature is one of multiple ways that you can export or personalize messages with data that has One-to-Many (1:M) relationships in the data model that RPI is configured to use. The audience definitions feature supports identifying one record from the many side of the relationship to use to extract or personalize with. The configuration of this feature, along with providing selection criteria to identify specific records on the many side of the relationship, will be used in combination to determine what record to use for extraction or personalization.

A use case that this feature would support is if you want to send an email message to people who made their last transaction 6-9 months ago and include data from the last transaction in the content of the email.

About transactional audience definitions

Transactional audience definitions in RPI allow you to export or personalize data from tables on the many side of a 1:M relationship. This feature helps you select specific records for extraction or personalization based on defined criteria. In addition to configuring the audience definition, there is a certain pattern for usage to get the expected results. As with any feature, there are some use cases that may not be suitable with the behavior of the feature, which we will call out in this document.

Without this feature, you can use attributes from the many side of the relationship in the database, but RPI will pick a single value from all available values, leaving you unsure of which value will be selected. With this feature, you can control which records and values are selected more granularly from the many side of the data relationship.

There is an export feature that allows you to export all records from the many side of the relationship, if needed.

Configure transactional audience definition

To configure a transactional audience definition, at a high-level, you need to do the following:

1. Configure two resolutions:

   • The primary resolution (e.g., golden record summary). The primary resolution is what is tied to the audience definition that will be used when creating the audiences/segments. This relates to the 1 side of the 1:M relationships.

   • The transactional resolution (e.g., transaction header table). The transaction header resolution relates to the M side of the equation.

2. Create and configure the audience definition.

Step 1: Configure resolutions

If you already have resolutions defined, you can skip to Step 2: Create and configure the audience definition.

1. Define the primary resolution (Golden Record Summary).

2. Define the transactional resolution (Transaction Header).

Step 2: Create and configure the audience definition

Now that you have the two resolutions defined, you can create a new audience definition that will be configured to support transactional relationships. At a high-level, you need to do the following:

1. Create a new audience definition.

2. Set the resolution level to the Primary Resolution.

3. Select the option to "Support Transactional Configuration" and configure the transactional resolution level, attributes, and deduplication behavior.

Step 2a: Create a new audience definition

Create your new audience definition, configuring it according to the next steps. Refer to Configuring audience definitions in the RPI docs for more information.

Pro Tip: Clone an existing audience definition if the metadata is going to be the same or similar for the new audience. This will save the time required to create each of the metadata fields in the new audience manually.

Step 2b: Set primary resolution level

When configuring an audience, you start by setting the resolution level, which will be Golden Record Summary in this case. There are various other settings that can be configured based on your needs, but we are only going to focus on the transactional configuration of audience definitions; for additional information, refer to Configuring audience definitions.

Step 2c: Support transactional configuration

1. First you select the option to Support transactional configuration.

2. Select the Transactional resolution level. This is the resolution that represents the many side of the 1:M relationship.

   • Transaction resolution

3. Transactional attributes: select the transactional attributes that you want to capture in Offer History (OH) in addition to the attributes being captured in the OH configuration for the audience definition.

   • Transaction ID (TRANSACTION_ID)

   • Transaction Date Time (TRANSACTION_DATETIME)

4. Transactional deduplication:

   • Transaction Date Time - Descending

Create an audience using the transactional audience definition

Now that you have configured a transactional audience definition, you can create a new audience using that definition. Follow these high-level steps to create and use a transactional audience:

1. Create selection rules:

   1. Create a selection rule using the primary resolution.

   2. Create a selection rule using the transaction resolution.

2. Create a new audience and use the selection rules, including the transactional selection rule as a filter block or split block.

Step 1: Create selection rules

Assuming you will not be targeting all of the primary resolution records, you will have a selection rule to identify the primary targets of the interaction (the one side of the relationship). Then you will need a selection rule at the transactional resolution level to identify the eligible records from the many side of the relationship.

Step 1a: Create primary (Golden Record) selection rule

We are identifying a set of records with multiple transactions and creating a selection rule with the records to get a sample set.

Step 1b: Create transaction selection rule

The goal of the selection rule that will execute at the transactional resolution level is to help RPI determine what records to consider on the many side of the relationship. This rule may result in zero or many records, and from there the deduplication logic that was configured in the audience definition will get applied. This is a single attribute to sort on, and the order to sort them in for selection. If the sort attribute is date, and the order is descending, and there are three out of six records that qualify for the selection rule, then one of the three records will be selected based on the transaction date in this example, which is configured to select the most recent transaction date (order descending).

If you have more than one transaction record that meets the selection criteria and the sort order, then the record will be selected at random. An example would be if two purchases were made on the same day and the sort attribute was transaction date (without time), then one of the two transactions would be selected at random.

We are identifying a set of transaction records to see if the Golden Records have any qualifying transactions. In this case, we are just looking at a six-week timeframe for the transaction.

Step 2: Create an audience

Now we can set up an audience using these selection rules. We will create two outputs: one with all records, and one with records that meet the transaction criteria. A split was used with a single segment for all records, and then a filter is used in the second example to filter down to transactions in the timeframe 10/1/24-11/15/24.

In order to have all the input records from the first filter be eligible for the purchase filter and the split, we had to disable the Single output contact setting in the “Purchases 10/1/24-11/15/24” filter block. That will allow both segments, the “all records” segment and this segment, to have the same records.

This feature allows for the two blocks in the example, filter and split, to not be mutually exclusive, which is the default behavior in RPI. So, each segment in this example can and will have the same records in both segments.

Example of an interaction using transactional audience

We are going to use two interaction workflows to illustrate the behavior of a transactional audience definition to dedupe and select specific transactions vs. a standard audience definition with a 1:M relationship in the data. For illustrative purposes, we have identified a set of Golden Records with one or more purchases.

The workflow on the left side is a standard audience definition based off the Golden Record Summary table, and the one on the right is the transactional audience based on Golden Record Summary.

Each of the extracts provides a different representation of the output of the data. Each one is used to help illustrate how the different configurations result in different outputs. Below, you will see a description of each export, a screenshot of the records that were extracted and formatted in Excel, as well as a table of the raw data.

Details and results of each export

Here you will find the details and the results of each of the exports based on the segment that was used as well as the way that the exports are configured.

The following sections delineate the set of exports and the associated records to validate that the standard and transactional audience are executing as intended.

Golden Record and all transaction records

Audience Definition: Standard

This is all of the transaction records for the identified Individual_Business_Unit_IDs. Each set of Individual_Business_Unit_IDs is shown in the same color to help show the transactions associated to each Individual_Business_Unit_ID more easily.

The Allow duplicates feature of an extract allows you to extract duplicate records in the cases of a 1:M relationship in the data. You will get a record for each record on the many side of the relationship in the extract.

Sample records

Golden Record and one transaction record

Audience Definition: Standard

One Individual_Business_Unit_ID transaction record will be associated randomly; you will not have control over what record is selected. As you can see for Individual_Business_Unit_ID 10000000000200001, the transaction that was selected is one of the random records selected out of all of the seven associated transactions.

This export is configured to NOT allow duplicates (the default behavior).

Sample records

Transactional: unique records all

Audience Definition: Transactional

In this case, the transactional audience configuration is referenced, and the most recent transaction record for each of the Individual_Business_Unit_IDs is what will be extracted.

Sample records

Transactional: specific records

Audience Definition: Transactional

In this case, there were two records that were dropped because they didn’t meet the criteria of the transaction-based selection rule. Of the five records with a qualifying transaction, the most recent transaction was identified to be extracted.

Sample records

Considerations and restrictions

This section outlines the limitations and important considerations when using the Transactional Audience definitions feature in RPI. Here are the key points:

• Specific Record Selection: You cannot dial-in to a specific record in a set of records for deduplication. For example, if your transaction-based selection rule identifies three records to associate with an Individual_Business_Unit_ID, and it has one attribute to sort by (e.g., transaction date time) and a sort order (i.e., descending or ascending), you will get the most recent transaction. Alternatively, you could have picked the oldest transaction. However, if there are different criteria or additional needs beyond a column to sort by and an order, this feature may not be suitable for your use case.

• Configuration and Testing: Make sure you fully configure your audience definition before testing. If you make a change to the deduplication setting, you may want to create a new audience and interaction from scratch for testing to ensure the latest changes are reflected.

Conclusion

The document provides a comprehensive guide on configuring and using Transactional Audience definitions in RPI. It covers the configuration steps, usage patterns, and the results of various configuration and usage options. Here are the key takeaways and limitations:

• Purpose and Benefits: The Transactional Audience definitions feature allows you to export or personalize data from tables on the many side of a 1:M relationship. This feature helps you select specific records for extraction or personalization based on defined criteria.

• Configuration Steps: The document details the steps to configure a transactional audience definition, including defining the primary and transactional resolutions, configuring the audience definition, and using the selection rules.

• Use Cases and Examples: The document provides examples of configuring and using Transactional Audience definitions, illustrating how different configurations result in different outputs.

• Limitations: The feature has some limitations, such as the inability to dial-in to a specific record in some instances where alternative approaches need to be considered.

By understanding these considerations and limitations, you can effectively use the Transactional Audience definitions feature in RPI to achieve your data extraction and personalization goals.