/
TUF Drip Campaign Configurations

TUF Drip Campaign Configurations

Slate Instance

TUF

Requestor

Leigh Pulford

Date

9/16/2024

Status

In progress

Summary Description

Is there a better way to configure the drip campaigns to ensure that students are not receiving multiple drip communications?

External Documentation

TechConnect Ticket

n/a

Box Folder

 

Desired Deliverable

Currently we are running a general drip, as well as specific Program and Field of Study drips. What I’m seeing is that some students are receiving multiple drips as they add to their profile, ie adding a Field of Study, and then also receive general communications if they start an application. Hence they are falling in multiple populations. I wonder if there is a better way to configure the drips to ensure that students are not receiving multiple drip communications? Some examples below.

Deliver Campaigns (tufts.edu)

Deliver Campaigns (tufts.edu)

Deliver Campaigns (tufts.edu)

Met w/Leigh on 9/13 and discussed setting up campaigns so they send on certain days of the week to a record that has been in a population for 10+ days (instead of “on day 10”) to avoid mailings sending all on the same day. Leigh requested instructions for changing his campaigns so they would run this way.

  1. Query to show which messages are hitting which days for records in the population

  2. Instructions for building a query for a mailing that would use the “10 days or more” kind of filter

  3. Instructions for setting a mailing to send on specific days/times.

Research

In the "traditional" drip campaign, each deliver mailing must be scheduled to send at least once per day. For every "scheduled" send date/time in a mailing, Slate runs the attached query and sends the mailing to any records that return in the query results. So the "traditional" drip campaign works because the attached query asks "what record has been in this population for 10 days?" and then sends at least once per day to whatever records are returned (and always catches the record on it's individual "day 10"). 

The limitation is that you have to have the mailings running every day and that you can't control what day/time the email sends, because for each record that timing depends mostly on when they took whatever action added them to the population in the first place.

The alternate is to send mailings on a specific day of the week/time and identify which records should get the mailing by if they have been in the population for a certain number of days or longer. This creates a process where weekly the mailing is going out to the records that qualified in between when it was last sent and now. That way we don't have to have Slate send them a mailing on the exact day they joined in order to make sure they are included.

Because we are changing how the query identifies records to include, we also have to account for all the records that exist in the population. Using Day 3, Day 10, etc. meant you were only mailing people on that day, but using a range (day 10 or older) means we want to make sure we're not including records on day 45, 300, 500, etc.

If you are starting a new population and a new campaign, this doesn't matter, and after the mailing is running it is also not a concern, because the mailing will not send more than once to a record. But if you are starting "in the middle" (either because you have an existing population that has been collecting records for a while or because you are switching to a new mailing and don't want records that got the previous mailing to get this new one) you also need a "date to start including records."

For Query Filters:

 

Outcome

 

 

 

 

 

 

 

 

 

 

Related content