A Discussion On Marketing Cloud Triggered Sends
A triggered email is a message automatically sent to a contact in response to a specific user action or event, delivered to the inbox promptly to align with user behaviours. The goal of triggered emails is to deliver timely and relevant content, increasing the chances of engagement and conversion. Instead of being sent on a predetermined schedule, triggered emails are initiated by user actions or certain conditions being met. These emails are highly targeted and relevant to the recipient’s behaviour, preferences, or interactions with a website, app or platform. For instance, a triggered email may be generated as a confirmation message following a customer’s purchase, sign-ups to newsletters, abandoned carts, or other user activities such as reaching a new loyalty tier.
You as the developer are responsible for identifying the events that trigger the email and proceeding to create code to fire the triggered email interaction which sends the email.
The API call executes the interaction; and the interaction sends the email.
The API call to initiate the SMFC triggered send interaction determines the specifics of when and to whom an interaction sends the email. The triggered send firing API event can be achieved by using Marketing Cloud’s internal scripting languages WSProxy, AMPscript, or Core Library functions. Additionally, third party applications can use the REST API after a connection is established through an installed package in Marketing Cloud. Your code captures any subscriber information necessary to send the message but at a minimum, the subscriber email address is required.
A triggered email has two components that you create in SFMC:
- Content, and
- Triggered Send Definition (aka interaction).
The Triggered Send Definition defines the email content and delivery settings and the overall behaviour each time it gets triggered. The system uses this information each and every time an email is triggered. It will have a unique External Key value that is used by the API calls to initiate the interaction. Remember, the definition of what actually triggers the interaction to send the email is maintained using API calls.
Before you can use the Marketing Cloud API to trigger emails, you need the following information:
- You need a user on your account that is enabled to use the API.
- Your organisation must identify the events that trigger the email message.
- You need to capture the subscriber attributes that are needed in the content of the email message for personalisation and dynamic content.
- You need the External Key of the interaction to trigger.
Journey Builder Emails are Triggered Sends
Did you know that when you create a Journey Builder email, a triggered send is automatically created? Activating the journey creates the Triggered Send Definition that the journey’s email activity uses. Activating a new journey version defines a brand new Triggered Send.
You can see this all for yourself by going to Email Studio > Interactions > Messages > Email > Journey Builder Sends.
You can modify the email’s content, then restart the triggered send to re-enable sending within the journey.
Triggered Sends differ from Scheduled Ad-hoc Sends because they are active over a period of time. This is a crucial point of distinction. Triggered Sends do not use the same Send Definitions as User Initiated sends, they use Triggered Send Definitions. This is reflected in numerous areas within the platform:
- SFMC platform has two different SOAP API objects for each: “EmailSendDefinition” and “TriggeredSendDefinition”
- Marketing Cloud Connect package has “et4ae5__SendDefinition__c” and “et4ae5__Automated_Send__c” objects.
Because of this key point of differentiation, the way we report on Journey Emails and Triggered Sends needs to be modified compared to standard “once and done” user initiated sends.
To begin with, the Primary Keys for identifying Triggered Sends in SFMC reporting are the TriggeredSendCustomerKey and/or the TriggeredSendDefinitionObjectID [note that in the Job DataView this field is referred to as TriggererSendDefinitionObjectID]. These keys are used to uniquely identify a triggered send.
SFMC reports on Triggered Sends using these keys rather than JobID and this enables you to track the performance and metrics associated with a specific Triggered Send over its lifetime. In other words, the TriggeredSendCustomerKey and TriggeredSendDefinitionObjectID persist over the lifetime of the Triggered Send to identify that Triggered Send.
During the lifetime of a Triggered Send, the associated email content can undergo updates or refreshes. This means you can change the email creative, subject line, or other aspect of the email message, or even choosing an entirely different email asset while keeping the same Triggered Send active. Thus, it is possible that a single Triggered Send can be linked to many different Content Builder assets / emails (EmailID) throughout its lifetime.
Each time a Triggered Send is published or republished (regardless if any actual updates took place), a new job is generated with a unique JobID.
If you have edited an email in a running journey, after clicking ‘Done’, a saving window will initiate. This counts as republishing the Triggered Send and the email activity will have a new JobID.
When a republish occurs, the TriggeredSendCustomerKey persists, while the JobID linked to that TriggeredSendCustomerKey gets updated. This behaviour is what allows a single Triggered Send (that exists over time) to be associated with various emails (and various jobIDs). When we want to update email content within an active Triggered Send, we need republish the TS in order to apply the changes.
When significant changes are made during the re-publishing of a Triggered Send, you should communicate to stakeholders and document the why, when, where and what. This will empower you when it comes to reporting time and you’re trying to interpret the results, you’ll be armed with the business context.
In the Email Studio Tracking screenshot above, notice the External Key in place of the Job ID? This means the metrics in the Tracking section dashboard are for the Triggered Send overall. It is not going into the breakdown of send metrics for the individual jobs linked to this Triggered Send. The same goes for the Triggered Sends Tracking Report in Analytics Builder. It will produce your metrics for the Triggered Send as a whole, essentially grouping results by the TriggeredSendCustomerKey.
If an existing email in a Triggered Send is updated and we republish the Triggered Send, then:
- the
TriggeredSendCustomerKeywill be the same - the
JobIDwill change - the
EmailIDwill be the same (since we didn't change the email, just applied content edits to the existing email in Content Builder)
To report on the specific email sent within a Triggered Send, it becomes necessary to focus on the associated JobID’s which serve as a reference point for understanding which email content was delivered. You’ll be able to extract the EmailID once you have got the JobID.
As mentioned earlier, a single Triggered Send can be linked to many EmailID’s. Because the Triggered Sends exist over time, we can update it during its life, which will generate a new JobID. The JobID is where our selected email and some other send settings are defined. So when we see different EmailID in our data corresponding to the same TriggeredSendCustomerKey, there will also be a new JobID.
You may encounter this when we want to refresh content in an ongoing journey. For example, you may decide to update your Welcome Series eDMs with new Content Builder emails that have creative reflecting the particular time of year, such as Halloween or Black Friday.
Also important to remember is that DataViews have a 6 month retention policy and this goes for the _JOB DataView as well. As compared to the engagement DV’s such as Sent, Open, Click, Unsubscribe which are based on EventDate, the Job DV’s retention calculation is based on the ModifiedDate field. Hence, if any Triggered Send has a ModifiedDate greater than 6 months ago, it will NOT be present in the _JOB DataView results.
To paint a picture, say you have a long running journey that you have not modified in a long while, the journey is still running and sending emails daily, and you have email engagement reporting queries that involve joins to _JOB, then you may be getting incorrect results! Since the job is no longer found in the DataView, the Sent, Open, Click events are unable to be joined and these rows may be dropped from your results.
Another consideration for writing reporting SQL queries for Salesforce Marketing Cloud journey builder email sends and/or triggered sends, is that you should NOT be using any INNER JOIN to bring together the various engagement DataViews. Why? Consider the scenario where an email is sent in February and clicked in September. The click will create a new click event, but the sent event has already “expired” and is no longer available in the Sent DataView due to the retention policy. An inner join would fail to match click event to the sent event, and consequently the click will be omitted from your reporting.
Another example might be that you are trying to optimise your SQL by defining an explicit date range in your query to reduce the volume of data that the platform needs to work with. You might limit all engagement event DVs to the last 3 months of data. This is a good idea and the right mind-set, however, what if an email was sent outside the cut-off date date, and an open event occurred within the date range? The same outcome as before; SFMC will find the open event but fail to INNER JOIN it to the corresponding sent record, which means the event will be omitted from the final result set.
Since there is no limit on how many times you can republish a Triggered Send, be aware that while a certain JobID may no longer be currently active in terms of sending out new emails to subscribers, the emails that it has already historically sent out will continue to appear in your tracking results data as subscribers open, click and otherwise engage with your email. These sends were from the JobID that was active at that point in time.
This all comes back to the fact that Triggered Sends exist over time. So the mindset in which you are writing the query and analysing the data needs to reflect this.
To throw some other complexities into the mix, _Unsubscribe and _Complaint DataViews do not have our Triggered Send fields (TriggererSendDefinitionObjectID and TriggeredSendCustomerKey ) that are common among Job, Sent, Open, Click and Bounce system tables.
This is a challenge to capture in your aggregate report in the scenario that the unsubscribe took place originating from a journey builder email send which took place over 6 months ago and the triggered send has not been modified for 1 year. All the usual avenues to trace back this event to a job and then to a particular Triggered Send (and thus a certain journey email) yield no value: unsub cannot be joined to _job and it cannot be joined to _sent because both values are no longer in the DataViews due to Retention Policy. It may look like a mistake, but we just don’t have the complete picture.
In order to try fill this gap, you can set up a dataview logging automation that will log all jobs to a data extension. To the same end, I have found the messaging/v1/sends/instance REST API endpoint which you can retrieve email sends and you can get all JobIDs associated to a particular Triggered Send (as well as Test sends and regular Scheduled sends). I have set up a logging automation for this API object, and am using it as a lookup to fill in the missing TriggeredSendCustomerKey value for the Unsubscribe and Complaint DataViews. The logging query would be the preferred way to go as it is far simpler than querying the REST API (which goes into another level of effort as you need to manage Auth tokens).
Final Recap
- The Primary Keys for Triggered Sends are
TriggeredSendCustomerKeyand/orTriggeredSendDefinitionObjectID - Triggered Sends are different to regular user initiated sends
- Journey Builder will create Triggered Sends behind the scenes
- Triggered Sends exist over time
- Expect a new JobID to be created when you republish a Triggered Send
- Document and communicate when Triggered Sends are re-published to help your future self with interpreting report data
- Older JobIDs continue to produce engagement data alongside the currently active JobID as subscribers can interact with prior emails sent out under a different job
- Watch out for SQL that uses
INNER JOINin relation to Triggered Sends — data may accidentally be omitted if certain conditions are met - Be mindful how your DataView SQL is rolling up aggregate data and double check you’re not accidentally excluding data
The broader SMFC community has already contributed enormously to document how to get Triggered Sends set up and functional. I think it is well discussed with plenty of detailed guides meticulously written freely available. To learn more see:
- https://help.salesforce.com/s/articleView?id=sf.mc_es_triggered_emails.htm&type=5
- https://medium.com/cervello-an-a-t-kearney-company/marketing-cloud-end-to-end-triggered-email-overview-a32ead33a374
- https://sfmarketing.cloud/2019/11/25/introduction-to-triggered-sends/
- https://sfmarketing.cloud/2019/08/29/send-a-triggered-email-using-ampscript/
