How to deal with transactional data in Salesforce Marketing Cloud
Thousands of orders every day, the online store is booming and the store system is running at full speed: the eCommerce and marketing teams are busy driving marketing forward and improving communication with customers.
A big part of customer communication day after day are the numerous transactional mailings. Mailings that, for legal reasons, must contain all relevant components of the order as well as for example information on returns or cancellations. This means that it is precisely these mailings, which are not highly recognized either by the customer or the company, that require the highest degree of personalization. Store systems, however, often offer only very rudimentary options for customizing these mailings in terms of content and design, and therefore more and more companies are linking the store to marketing clouds to prevent these restrictions.
And this is very often where the problem begins. While eCommerce and marketing staff are good at selling products and communicating in a personalized way in stores or marketing emails, they often find it difficult to map individual order content cleanly. This is because, unlike product data or marketing data, transaction data is usually not available in tabular form, but can be received via interfaces as XML or JSON.
The Salesforce Marketing Cloud is used in a large part of myprojects, and we now want to refer to it more.
An XML code as mentioned above is then very quickly transferred into a table field of the Marketing Cloud in the following form and just not one table field per parameter.
Now it is necessary to identify the required information that must be legally mapped in the transactional mail and integrate it into the HTML construct of the mail. The first step is to define the XML and read out the required fields: To do this, the values per attribute must be read out. The XML in the example is reused as a variable, as defined at the beginning.
This is the first step for reading out the values for a product. In the next step, a loop is built around the readout, since especially in order data there are often several products including all values.
The identified and read values must now be integrated into the content blocks of the mail. For this purpose, If-Then queries are often integrated if certain blocks are to be mapped only under certain assumptions. For example, the content block with the credit card icons is only mapped here if the credit card payment method was selected when the order was placed and this information could be read from the XML.
If attributes are missing in the XML data, such as the net amount, these can also be calculated using AMPscript. “Beauty adjustments” such as country-specific spellings and display formats for prices can also still be made in the mail without any problems.
If custom attributes are used in a store system and these can have a different name depending on the value, this is a special case. This is mapped in the XML as follows, for example, and thus cannot be read out with:
The query can now be extended by an option in the query and thus this problem is also easily solved.
Conclusion: Transactional mails, if they are not sent as a pure standard mail from the store system, usually require a know-how of data processing via script in HTML. Because especially in these mailings a hundred percent correct reproduction of all values is indispensable and the planning is therefore linked to a high testing effort.
