Articles in this section

Real-Time Data Feed and Event Triggers

The Real-Time Data Feed refers to specific activity taking place in relation to a message sent through MessageGears. In the Admin > Real-Time Data Feed section of Accelerator, users can customize actions to occur when a specific Activity occurs.  Information on the location and credentials for accessing your Real-Time Data Feed can be found in Admin > System Info in the Real-Time Queue table.

What this allows you to do is have a series of custom SQL actions which respond immediately to specific campaign events. Individual Activities can be Enabled or Disabled independently of the others, so you can choose to implement any combination of Activities triggering SQL actions.

Activity Types

Activity

Description

Bounce

Message bounced

Spam Complaint

Feedback loop

Unsubscribe

Unsubscribe processing

Click

Click tracking

Open

Open tracking

Delivery

Delivery confirmations

Job Error

Job error

Render Error

Occurs when there is a problem with the template merge process

Managing Event Triggers

Clicking the name of an Activity will open the Event Trigger page where multiple unique SQL actions can be added. Like a Campaign Trigger, the order of the Actions on the page dictates the order in which they are performed.

Pausing and Resuming Event Triggers

When the Real-Time Data Feed triggers are paused, the events continue to queue for up to 14 days. Events start to expire after 14 days. If event processing is Resumed, events queued will initiate the Actions for the resumed Triggers.

Example Use Case: Unsubscribe Event Triggers Opt-Out in Database

A common way to use Real-Time Data Feed event triggers is to maintain a clean database of recipients, and avoid sending further Marketing Emails to anyone who has unsubscribed, bounced, or complained. Here’s an example of an Action on the Unsubscribe event where UnsubActivity changes opt_in to “false” in the connected database:

For another example, here’s a sample of how we have set up an Event Trigger to insert a record of a bounce event into a database:

In both of these examples, the schema and tables referenced are defined by your own team, and not proscribed by the MessageGears platform. In the above update example for UnsubActivity, the behavior is intended to allow existing rows within your database to be updated when an unsubscribe event occurs, allowing for easy integration into your existing system.
Was this article helpful?
0 out of 0 found this helpful

Comments

0 comments

Article is closed for comments.