Audience and Trigger Condition Logic

This section provides a detailed explanation of how customers are qualified for events, based on audience and trigger conditions.

Representation of Customer Transaction Aggregates

In order to visualize the processes of selecting customers throughout an event, let us use the example following example. Using merchant category code in the audience, where we are aggregating transaction count based on category code in the last 1 month. Let us take A-05-005 (Paypal) & A-06-006 (Google) category codes for the below example.

Let us say a customer with customerId: 1 has transacted for both Paypal and Google in the past month. Let us also say a customer with customerId: 2 has done a Paypal transaction only in the last month. The way qbo decisions keeps record of this data can be represented using the table in image below.

../_images/fig-34.jpg

Representation of customers’ transactions

In the table, it is important to note that even though a customer only transacts for Paypal, a running tally or aggregate for Google transactions is still kept. However, the value will be 0. This is important for understanding the logic behind audience conditions and trigger conditions.

The expanded table in the image below contains information about the number of card transactions by customers for the last 1 month. CustomerID 1 and customerID 2 from the table above can be found also. CustomerID 3 with a Google transaction and CustomerID 4 with both Paypal and Google transactions are also included in the table.

../_images/fig-35.jpg

Expanded table

Audience Condition Logic

Now, let’s say the audience comprises of customers with a credit card who have made at most 1 transaction with Paypal in the last 1 month. The audience conditions will be set up as seen in the image below.

../_images/fig-36.jpg

Audience conditions set up

A representation of these audience conditions and the way customers are qualified is shown in the image below. The customers who initially satisfy these conditions are highlighted in yellow in the table and make up the audience size. It is important to note that the audience size changes constantly. This is because as time passes, customers are added to or removed from the event based on if they can meet the audience conditions. If customer 4, who currently meets audience conditions, transactions with Paypal once more in the same month, they will not meet the condition and will be removed from the audience. Similarly, customer 3 will continue to meet conditions for their next 2 Paypal transactions only.

../_images/fig-37.jpg

Audience conditions representation

At this point, customerID 2, customer ID 3 and customer ID 4 satisfy the audience conditions. The audience size is shown as 3.

Trigger Condition Logic

The trigger condition filters customers differently. Instead of looking at the state of individual customers, the trigger monitors specific events. In this case, the trigger event is when a specific type of transaction is made. This means it will monitor transaction logs.

The trigger condition will be set up as seen in the image below.

../_images/fig-38.jpg

Trigger conditions set up

A representation of this trigger condition and the way it selects customers is shown in the image below. The customers who satisfy the condition are highlighted in blue in the table. These are the customers who have done the trigger event.

../_images/fig-39.jpg

Trigger conditions representation

Satisfying both Audience and Trigger Conditions

The customers who qualify for the event are those who have satisfied both the audience condition and the trigger condition. That is, they are of the desired profile and they satisfy the trigger event.

However, before proceeding to identify these customers, it is important to recall that customers can be added to or removed from the audience based on updated, real-time data.

Taking into account the recent transactions in the trigger condition table, we can see that some customers who were initially included in the audience were no longer qualified after doing the trigger event. (The trigger event increased their transactionCount) In the image below, we see the updated transactionCount in the audience condition table. We will turn the previous transactionCount grey so we can easily distinguish them. The trigger condition table is also shown.

../_images/fig-40.jpg

Updated count

When the evaluation is done at this point, only customerID 4 satisfies both the audience condition and the trigger condition. Therefore, customerID 4 is the only customer who qualifies for the event. The venn diagram in the image below shows this in summary form.

../_images/fig-41.jpg

Audience and Trigger Condition intersection

Importance of Specifying Trigger Conditions

Although the conditions specified for audience and triggers may seem redundant, specifying each is important. The scenario in the image below shows the result of omitting the “eCommerceFlag” filter in the trigger condition for the same event discussed.

../_images/fig-42.jpg

Without eCommerceFlag filter in trigger condition

The customers who satisfy both audience and trigger conditions are customerID 3 and customerID 4. However, this is problematic because customerID 3 does not even have a past Paypal transaction. Since the categoryCode was not specified in the trigger condition, it was the Google transaction that mistakenly satisfied the trigger condition.

Importance of Specifying Audience Conditions

The next scenario in the image below shows the result of omitting the “categoryCode” filter in the audience condition for the same event.

../_images/fig-43.jpg

Without categoryCode filter in audience condition

The customers who satisfy both audience and trigger conditions are customerID 1, 2 and 4. However, this is problematic because customerID 1 and 2 have Google categoryCode transactions, which should not qualify them for the audience. Since the categoryCode was not specified in the audience condition, it was their Google transactions that mistakenly satisfied the audience condition.

Customer Added to Audience after Trigger Event

In the previous example, we saw that a customer who was initially part of the audience could be removed after qualifying for a trigger event (a specific transaction). This could happen when a customer goes over a desired transactionCount in the audience condition.

For this example, we will see that a customer who was not initially part of the audience can also be added after fulfilling the trigger event. This could happen when a customer meets a desired transactionCount in the audience condition.

../_images/fig-44.jpg

Without categoryCode filter in audience condition

When the evaluation is done at this point, customerID 1 and customerID 3 satisfy both the audience condition and the trigger condition. They qualify for an event.

Using ‘Both Category Code Count’ Condition

For this example, let us say the audience of the event are customers with at most 3 Paypal or Google transactions. The trigger for the event is when an ecommerce transaction is done.

The audience condition should include both Paypal and Google categories which is set up as seen in the images below.

../_images/fig-45.jpg

Audience condition set up

This condition looks at the combined transaction count of both Paypal and Google per customer. If a customer has done 3 transactions of Paypal, and 1 of Google, the combined transaction count will be 4. Hence, the ‘+’ in the condition description.

A representation of the audience conditions and the way it selects customers is shown in the image below.

../_images/fig-46.jpg

Audience conditions representation

It is important to note that this audience condition computes the combined transaction count of both Paypal and Google, even if the both the categories have not been fulfilled. For example, customerID 2 has a Paypal transaction count of 2 and the Google transaction count of 0. The combined transaction count will therefore be 2 + 0 or 2, and he will qualify for the audience.