You can send event transactional messages targeting an event. This type of transactional messages does not contain profile information: the delivery target is defined by the data contained in the event itself.
Once you have created and published an event (the cart abandonment as explained in this section), the corresponding transactional message is created automatically.
The configuration steps are presented in the Configuring an event to send an transactional message section.
Event transactional messages do not contain profile information, therefore they are not compatible with fatigue rules (even in the case of an enrichment with profiles). See Fatigue rules.
In order for the event to trigger sending a transactional message, you have to personalize the message, then test it and publish it.
To access the transactional message that you created:
Click the Adobe Campaign logo, in the top left corner.
Select Marketing plans > Transactional messages > Transactional messages.
Click the message of your choice to edit it.
To access transactional messages, you must be part of the Administrators (all units) security group.
In this example, you will learn how personalize a transactional message by adding three fields that you defined when you created your event: first name, last product consulted, total cart amount.
To do this, you will insert a personalization field in the message content.
Click the Content block to modify your message’s subject and content. For this example, select any template containing images and text. For more on email content templates, see Designing using templates.
Add a subject and edit your message content to suit your needs.
The link to the abandoned cart is a link to an external URL that will redirect the person to their cart. This parameter is not managed in Adobe Campaign.
Browse through Context > Real-time event > Event context to get the personalization fields: first name, last product consulted, total cart amount.
To enrich the content of your message, add fields by selecting them from the table with which you linked your event. In our example, select the Title (salutation) field in the Profile table through Context > Real-time event > Event context.
Insert all the fields needed.
Preview your message by selecting the profile that you defined for this event.
The steps for previewing a message are detailed in the Previewing messages section.
You can check that the personalization fields match the information entered in the test profile. For more on this, see Defining a test profile in a transactional message.
You can create product listings referencing one or more data collections in the content of a transactional email. For example, in a cart abandonment email you can include a list of all products that were in the users’ carts when they left your website, with an image, the price, and a link to each product.
Learn more in this video.
Product listings are only available when editing transactional email messages through the Email Designer interface.
Adobe Campaign does not support nested product listings, meaning that you cannot include a product listing inside another one.
In the example below, you will learn steps to add a list of abandoned products in a transactional message.
Before being able to use a product listing in a transactional message, you need to define at the event level the list of products and the fields for each product of the list you want to display. For more on this, see Defining data collections.
In the transactional message, click the Content block to modify the email content.
Drag and drop a structure component to the workspace. For more on this, see Editing the email structure.
For example, select a one-column structure component and add a text component, an image component and a button component. For more on this, see Adding fragments and components.
Select the structure component you just created and click the Enable product listing icon from the contextual toolbar.
The structure component is highlighted with an orange frame and the Product listing settings are displayed in the left palette.
Select how the elements of the collection will be displayed:
The Column option is only available when using a multicolumn structure component ( 2:2 column, 3:3 column and 4:4 column ). When editing the product listing, only fill in the first column: the other columns will not be taken into account. For more on selecting structure components, see Editing the email structure.
Select the data collection you created when configuring the event related to the transactional message. You can find it under the Context > Real-time event > Event context node.
For more on configuring the event, see Defining data collections.
Use the First item drop-down list to select which element will start the list displayed in the email.
For example, if you select 2, the first item of the collection will not be displayed in the email. The product listing will start on the second item.
Select the maximum number of items to display in the list.
If you want the elements of your list to be displayed vertically ( Column ), the maximum number of items is limited according to the selected structure component (2, 3 or 4 columns). For more on selecting structure components, see Editing the email structure.
To display a list of products coming from the event linked to the transactional email, follow the steps below.
For more on creating a collection and related fields when configuring the event, see Defining data collections.
Select the image component you inserted, select Enable personalization and click the pencil in the Settings pane.
Select Add personalization field in the Image source URL window that opens.
From the Context > Real-time event > Event context node, open the node corresponding to the collection that you created (here Product list ) and select the image field that you defined (here Product image ). Click Save.
The personalization field that you selected is now displayed in the Settings pane.
At the desired position, select Insert personalization field from the contextual toolbar.
From the Context > Real-time event > Event context node, open the node corresponding to the collection that you created (here Product list ) and select the field that you created (here Product name ). Click Confirm.
The personalization field that you selected is now displayed at the desired position in the email content.
Proceed similarly to insert the price.
Select some text and select Insert link from the contextual toolbar.
Select Add personalization field in the Insert link window that opens.
From the Context > Real-time event > Event context node, open the node corresponding to the collection that you created (here Product list ) and select the URL field that you created (here Product URL ). Click Save.
For security reasons, make sure you insert the personalization field inside a link starting with a proper static domain name.
The personalization field that you selected is now displayed in the Settings pane.
Select the structure component on which the product listing is applied and select Show fallback to define a default content.
Drag one or more content components and edit them as needed.
The fallback content will be displayed if the collection is empty when the event is triggered, for example if a customer has nothing in his cart.
From the Settings pane, edit the styles for the product listing. For more on this, see Editing email styles.
Preview the email using a test profile linked to the relevant transactional event and for which you defined collection data. For example, add the following information in the Event data section for the test profile you want to use:
For more on defining a test profile in a transactional message, see this section.
You first need to create a specific test profile that will allow you to properly check the transactional message.
Define a test profile that will be linked to your event, which will allow you to preview your message and send a relevant proof.
From the transactional message dashboard, click the Create test profile button.
Specify the information to send in JSON format in the Event data used for personalization section. This is the content that will be used when previewing the message and when the test profile receives the proof.
You can also enter the information relating to the profile table. See Enriching the transactional message content.
Once created, the test profile will be pre-specified in the transactional message. Click the Test profiles block of the message to check the target of your proof.
You can also create a new test profile or use one that already exists in the Test profiles menu. To do this:
Click the Adobe Campaign logo, in the top left corner, then select Profiles & audiences > Test profiles.
In the Event section, select the event that you have just created. In this example, select “Cart abandonment (EVTcartAbandonment)”.
Specify the information to send in JSON format in the Event data text box.
Save your changes.
Access the message that you created and select the updated test profile.
Once you have created one or more specific test profiles and saved your transactional message, you can send a proof to test it.
The steps for sending a proof are detailed in the Sending a proof section.
Once you have checked your transactional message, you can publish it.
Now, as soon as the “Cart abandonment” event is triggered, it automatically prompts a message containing the recipient’s title and last name, the cart URL, the last product consulted or a list of products if you defined a product listing, and the total cart amount to be sent.
To access reports concerning your transactional message, use the Reports button. See Reports.
You can suspend publishing your transactional message by using the Pause button, for example, to modify the data contained in the message. The events are therefore no longer processed, but instead kept in a queue in the Adobe Campaign database.
The queued events are kept during a period of time that is defined in the REST API (see the REST API documentation) or in the trigger event if you are using the Triggers core service (see Working with Campaign and Experience Cloud Triggers).
When clicking Resume, all of the queued events (provided that they are not expired) are processed. They now contain all of the modifications carried out while the template publication was suspended.
Clicking Unpublish allows you to cancel the transactional message publication, but also the publication of the corresponding event, which deletes from the REST API the resource corresponding to the event that you previously created.
Now, even if the event is triggered through your website, the corresponding messages are not sent anymore and they are not stored in the database.
To publish the message again, you need to go back to the corresponding event configuration, publish it, and then publish the message. For more on this, see Publishing a transactional message.
If you unpublish a paused transactional message, you may have to wait up to 24 hours before you can publish it again. This is to let the Database cleanup workflow clean all the events that were sent to the queue.
The steps for pausing a message are detailed in the Suspending a transactional message publication section.
The Database cleanup workflow, which runs every day at 4am, is accessible through Administration > Application settings > Workflows.
Once a transactional message has been unpublished, or if a transactional message has not been published yet, you can delete it from the transactional message list. To do this:
However, deleting a transactional message can only be done under certain conditions:
Make sure the transactional message has the Draft status, otherwise you will not be able to delete it. The Draft status applies to a message that has not been published yet, or that has been unpublished (and not paused).
Transactional messages: Unless another transactional message is linked to the corresponding event, if the transactional message is unpublished, the event configuration also needs to be unpublished to successfully delete your transactional message. For more on this, see Unpublishing an event.
Deleting a transactional message that has already sent notifications will also delete its sending and tracking logs.
Transactional messages from an out-of-the-box event template (internal transactional messages): If an internal transactional message is the only one associated with the corresponding internal event, it cannot be deleted. You must first create another transactional message by duplicating it or through the Resources > Templates > Transactional message templates menu.
A temporarily undelivered transactional message is subject to automatic retries that are performed until the delivery expires. For more on the delivery duration, see Validity period parameters.
When a transactional message fails to be sent, there are two retry systems:
If the event cannot be assigned to an execution delivery, the event processing is postponed. Retries are then performed until it is assigned to a new execution delivery.
A postponed event does not appear in the transactional message sending logs, because it is not assigned to an execution delivery yet.
For example, the event could not be assigned to an execution delivery because its content was not correct, there was an issue with access rights or branding, an error was detected on applying typology rules, etc. In this case, you can pause the message, edit it to fix the problem and publish it again. The retry system will then assign it to a new execution delivery.
Once the event has been assigned to an execution delivery, the transactional message can fail due to a temporary error, if the recipient’s mailbox is full for example. For more on this, see Retries after a delivery temporary failure.
When an event is assigned to an execution delivery, it appears in the sending logs of this execution delivery, and only at this time. The failed deliveries are displayed in the Execution list tab of the transactional message sending logs.
Sending logs update
In the retry process, the sending logs of the new execution delivery are not immediately updated (the update is performed through a scheduled workflow). It means that the message could be in Pending status even if the transactional event has been processed by the new execution delivery.
Failed execution delivery
You cannot stop an execution delivery. However, if the current execution delivery fails, a new one is created as soon as a new event is received, and all new events are processed by this new execution delivery. No new events are processed by the failed execution delivery.
If some events already assigned to an execution delivery have been postponed and if that execution delivery fails, the retry system does not assign the postponed events to the new execution delivery, which means that these events are lost.