Event transactional messages
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.
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 transactional messages, you must be part of the
Administrators (all units)security group.
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 .
Defining a test profile in a transactional message
Define an adapted test profile, which will allow you to preview your message and send a proof to check it.
Creating a test profile within the transactional message
- To access the message that you created, click theAdobe Campaignlogo, in the top left corner, then selectMarketing plans>Transactional messages>Transactional messages.
- Create a test profile that will be linked to your event.
- Specify the information to send in JSON format in theEvent data used for personalizationsection. This is the content that will be used when previewing the message and when the test profile receives the proof.
- After having been created, the test profile will be pre-specified in the transactional message. Click theTest profilesblock of the message to check the target of your proof.
Creating a test profile outside the transactional message
You can also create a new test profile or use one that already exists in the
- Click theAdobe Campaignlogo, in the top left corner, then selectProfiles & audiences>Test profiles.
- In theEventsection of the page of the test profile that you have chosen, select the event that you have just created. In this example, select "Cart abandonment (EVTcartAbandonment)".
- Specify the information to send in JSON format in theEvent datatext box.
- Save your changes.
You can now access the message that you created and select the updated test profile.
Personalizing a transactional message
To set up personalization in a transactional message, follow the steps below:
- Click theContentblock 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.
- Browse to those fields throughContext>Real-time event>Event context.
- 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 theTitle (salutation)field in theProfiletable throughContext>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 .
Using product listings 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.
To add a list of abandoned products in a transactional message, follow the steps below.
You can also watch a set of videos explaining the steps that are required to configure product listings in a transactional email. For more on this, see this page .
Adobe Campaign does not support nested product listings, meaning that you cannot include a product listing inside another one.
Defining a product listing
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 theContentblock to modify the email content.
- Select the structure component you just created and click theEnable product listingicon from the contextual toolbar.The structure component is highlighted with an orange frame and theProduct listingsettings are displayed in the left palette.
- Select how the elements of the collection will be displayed:
TheColumnoption is only available when using a multicolumn structure component (2:2 column,3:3 columnand4: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 .
- Row: horizontally, meaning each element on one row under the other.
- Column: vertically, meaning each element next to the other on the same row.
- Select the data collection you created when configuring the event related to the transactional message. You can find it under theContext>Real-time event>Event contextnode.For more on configuring the event, see Defining data collections .
- Use theFirst itemdrop-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 .
Populating the product listing
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, selectEnable personalizationand click the pencil in the Settings pane.
- SelectAdd personalization fieldin theImage source URLwindow that opens.From theContext>Real-time event>Event contextnode, open the node corresponding to the collection that you created (hereProduct list) and select the image field that you defined (hereProduct image). ClickSave.The personalization field that you selected is now displayed in the Settings pane.
- At the desired position, selectInsert personalization fieldfrom the contextual toolbar.
- From theContext>Real-time event>Event contextnode, open the node corresponding to the collection that you created (hereProduct list) and select the field that you created (hereProduct name). ClickConfirm.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 selectInsert linkfrom the contextual toolbar.
- SelectAdd personalization fieldin theInsert linkwindow that opens.From theContext>Real-time event>Event contextnode, open the node corresponding to the collection that you created (hereProduct list) and select the URL field that you created (hereProduct URL). ClickSave.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 selectShow fallbackto 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.
- 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 theEvent datasection for the test profile you want to use:For more on defining a test profile in a transactional message, see this section .
Testing a transactional message
Once you have saved your transactional message, you can now send a proof to test it.
The steps for sending a proof are detailed in the Sending a proof section.
Publishing a transactional message
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
Reportsbutton. See Reports .
Suspending a transactional message publication
You can suspend publishing your transactional message by using the
Pausebutton, 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 REST API documentation ) or in the trigger event if you are using the Triggers core service (see Working with Campaign and Experience Cloud Triggers ).
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.
Unpublishing a transactional message
Unpublishallows 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.
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 cleanupworkflow 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.
Database cleanupworkflow, which runs every day at 4am, is accessible through
Deleting a transactional message
By selecting a transactional message, you can delete it with the
Delete elementbutton even if it has already been published. However, deleting a transactional message can only be done under certain conditions:
- Transactional messages: To delete a transactional message, the message should be unpublished and not paused.If the transactional message is unpublished, the event configuration also needs to be unpublished to successfully delete your transactional message, unless another transactional message is linked to the corresponding event. For more information on how to unpublish a transactional message, refer to this section .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): To delete an internal transactional message, the message should be unpublished and not paused.It also shouldn't be the only transactional message in the event, other messages have to be linked to the corresponding event.
Transactional message retry process
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:
- At the transactional messaging level, a transactional message can fail before the event is assigned to an execution delivery, meaning between the event reception and the delivery preparation. See Event processing retry process .
Event processing retry process
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.
Message sending retry process
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 listtab of the transactional message.
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
Pendingstatus 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.