Queue listener setup document
Overview
This document walks through the setup of two different uses of queue listeners within RPI.
Setting up a direct send queue listener
Using a queue listener for data ingestion and decision making using the database information
Direct send queue listener
A queue listener allows you to monitor a “listener queue” (message queue) for the arrival of data. Data arrives in the form of JSON packages – placed on the queue either by an external system, or at submission of a web form (outside Redpoint).
Downstream queue activities can then use this data to execute offers. You might typically use a queue listener for sending an email, for example after a customer makes a purchase, or when a web form is submitted in a landing page, etc.
Queue listeners are only able to use the data in the provided JSON payload for personalization or driving dynamic content. You are not able to enrich the payload with any data from any other source like the database. This is by design to ensure that the offers attached to the queue listener will execute as fast as possible, which is important for the types of messages that this functionality is intended to support.
Direct send notes
A queue activity can only use the data that is provided to it in the JSON payload to personalize or to drive dynamic content.
A queue listener is used to collect the JSON payloads as they are sent from the provider/vendor.
Once the payloads are collected by the queue listener, they are then sent directly out of RPI using an offer or data extract to be picked up and sent to proper vendor. All records are added to
OfferHistoryas well asQUEUE_LISTENERtables to allow for reporting on queue activity.For information about how to set up a queue listener and queue activity within RPI and also how to test the process, see RPI queue listener setup.
Using a queue listener for ingestion and decisioning
Using the above information and adding a few changes to configurations within the queue activity, RPI will allow a user to use a queue listener for data ingestion, which can then be used to compare data within the database tables and allow for further decision making. As a note, this process will add execution time to messages being sent.
Queue listener: Used to collect the JSON payloads as they are sent from the provider/vendor.
Queue Activity: Once the payloads get collected by the queue listener in this configuration, the data is sent to a control channel. This prevents the messages from being sent out directly, and you can now compare this data to the database tables/attributes exposed within RPI. All records are added to
OfferHistoryas well asQUEUE_LISTENERtables to allow for reporting on queue activity.
Once the records are entered into the OfferHistory table, the right side of the given interaction will then pick them up from the table and run them through criteria within the attached audience.
Going through the interaction, the first process box is the recurring schedule box, which is how the interaction is initially started. Within the recurring trigger, you control how often to execute this audience. In this example, it will trigger every 5 minutes.
The next process box is a batch activity, which is where the underlying audience is assigned and will be executed (Audience - Queue Listener - Ingestion/Decisioning w/PH). Next we'll walk through the audience set up and selection rules associated to it.
Within the first filter block, the audience is selecting the records that have been added to the OfferHistory table within the queue listener. The logic will only select records from the table that have an email address present and also the action_type = <user defined> within the last 1 day. These fields will be based on 3 placeholders that will allow the user to pick the correct action_type as well as the number of days they would like to look back in history.
Currently this selection rule is set to select records that have been added within the last 1 day. If you need to look further back, you'll need to update the placeholders for the offerhistory portion selection from 1 day to the number of days you need to look back.
The next box is a suppression block, which suppresses any RPIResolutionKey which has already been sent an offer through this interaction. The RPIResolutionKey is a unique key assigned to each record as it comes through the queue listener and is written to the OfferHistory table. The placeholders that are configured for this suppression will look for interaction name as well as offer activity name.
The next box is a split process box, which will put each of the given records into their associated bucket (Previously Received Offer and New Records). As the records are processed, they follow that specific hierarchy.
The first group (Previously Received Offer) is where each of the incoming records is checked to see if they already received the offer associated to new records or records that have gone through this flow for the first time. This is done by comparing the Queue Listener table to the Offer History table based on email address. The comparison is done within a custom SQL expression.
Following that there are two placeholders that will look for offer activity name as well as action type from the user's set up.
The bucket (New Records) is any record that is new to the program and has not qualified for any of the three previous groups. This is an all remaining bucket.
In the above screenshot, the input tab within the configuration of the export that only the “New Records” have been selected. This means that only these records will be sent through the previous step to the export portion of the interaction.
If you would like to also send to the records that previously received the offer, then you have the option to add a 2nd export/offer and assign that group to be sent there using these same steps.