I am trying to use Marketing Cloud to solve for the specific need of sending an email quickly after an open occurs. This is part of an overall, wait-based campaign that sends certain messaging days after an open/non-open, and some in near-real time.

Part of it seems like a journey, but it doesn't quite fit a journey paradigm - or at least not as far as I can tell.

What I've done so far is build out an automation that queries the _sent, _open, and _click data views, filtering to only those sends/activities that are relevant to the campaign.

Using this information, I get send/open/click times and created filtered data extensions for those who meet the timing requirements. All of the recipients of send 1 who have opened it 48 hours ago and have not already received send 2 will receive send 2; all of those who received send 2 and clicked a specific link in it at any time (so the point being near real time) and have not received send 3 will receive send 3. And so on.

There are challenges with this approach, and it seems like it might be over engineered. For example, this automation basically has to be running all of the time to look for those near real time clicks in order to send out the next message. Automation Studio can only be scheduled to run once an hour. To get around this, I utilized some of Adam Spriggs creative SSJS (found https://sprignaturemoves.com/retrieving-and-starting-an-automation-with-ssjs/) to start another automation. That automation's sole purpose is to restart the first automation with another similar SSJS activity. It'd be a clever solution if it wasn't so dumb.

Another challenge is that the data views do not always update in time for the next send. Part of the logic for most of my filtered data extensions looks to the data produced by the _send data view to make sure to exclude recipients who have already received the next email. If that data hasn't been captured yet from the _sent data view, the email will keep going out to the same individuals until the data view acknowledges that they've been sent the email.

Lastly, and probably the most over engineered piece of this is the fact that the email dashboard gets junked up because even if there's nobody in the filtered data extensions, the user-initiated email is still going to register as being sent, and the email dashboard is going to become littered very quickly with hundreds of sends delivered to 0 recipients. My "solution" was to abuse the heck out of those SSJS activities by creating individual automations for each send. Each automation does the filter activity and uses the new "verification" activity. If the filtered data extension has 0 recipients, the automation stops, the email doesn't send, and the dashboard remains clean.

The TL;DR question is - how do I create a campaign that is able to react to both real-time and wait-based activity?

  • Thanks for the shout-out. How many people are in the sends, on average? Commented Oct 20, 2017 at 15:03
  • Right now it's an internal proof of concept with less than 100 recipients. We wanted to get enough sends to show the different "paths". In real life it'll be a total population of 50k - 75k with individual sends probably ranging in the low thousands.
    – Rob
    Commented Oct 20, 2017 at 15:10
  • For the dashboard part - the DE's are filtered DEs, correct? If so, you can likely build all the email sends into a single SSJS script activity, rather than multiple automations. Commented Oct 20, 2017 at 15:42

1 Answer 1


TL;DR answer: use two separate journeys. I would create a new data extension and run a sql query to populate on whatever interval (15 minutes?) by joining the first table with the _Opens data view. You can do something like:

, maxopen.ContactID 
from (
    min(opens.[EVENTDATE]) as [OpenDate]
    , opens.[JOBID] as [JobID]
    , opens.[SUBSCRIBERKEY] as [ContactID]
    from _Open opens WITH (NOLOCK)
    group by opens.[JOBID], opens.[SUBSCRIBERKEY]
) maxopen
join ent.[COMMERCIAL - Contacts] MDE on maxopen.[ContactID] = MDE.[CONTACTID]

You can save this query with data action of update. And then run the activity in an automation with a schedule of your choosing. The second journey would use this data extension as the entry source with the setting of no re-entry to prevent if a contact opens multiple times.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .