Transactions

 
Transactional mails, like order confirmation or shopping cart abandonnment mails, are an essential part of customer communication. Maileon guarantees, that those mails are submitted in an instant to the contact, using separate mailservers and the best IPs available to ensure good inbox placement.

Especially in the case of online shops, the transaction mails follow a certain structure. While CRMs like Pipedrive are specialized on one topic, deal management and analysis in this case, they have very specific transactional data. Online shops require the same information to be sent in basically all cases, e.g. the order date, the total sum or the items contained in an order.

In order to ease development and/or customer migration, this page describes proposals for the most common types of transactions in order to define a reusable data structure. The attributes are based on our experience with a vast amount of shop systems and the idea is: if all implementations use the same transaction type, a customer can switch e.g. from WooCommerce to Shopware, without changing the mailing templates. Also setting up the initial mails is much easier, if attributes are named the same for all systems. Thus, we started defining data models on the base of https://schema.org/, e.g. https://schema.org/Order.
 

Start Using Transactions

The developer documentation specifies the API resources for working with transaction types and describes their technical limits, e.g. see the overview.
 

For practical introductions, please check our interactive tutorial.

 

Configuration

Versioning: Changing a transaction type in Maileon can be a problem, once a transaction is used in live systems, as there is no possibility to update an existing type. Instead, it must be deleted and re created, which is not possible in live-systems. Instead, we propose using a versioning naming scheme.

• Prepend _{schema_version}.{specific_version}, e.g. “_1.0”
• The version of the schema is always the major verion, e.g. 1 or 2
• The (customer) specific version can differ as customers might override certain parts of the data model

This kind of versioning allows model updates. If e.g. a new attribute is added, version 2 will be released and when creating the “new) transaction type a version _1.0 and _2.0 will exist in parallel. Whis allows a soft change of transaction types in the life system without possible data losses and it allows keeping an overview shich attributes are available or maybe not.

Retention period: The retention period defines, how long transational data will be stored in Maileon. The optimal retention time of course depends on the usecase. If just sending mails with a download link, that is usable for 7 days anyways, having a retention time of one year, does not make sense. If planning to filter about bought product categories in the last year,, it surely does. The retention period should be configurable by the customer.

 

Transaction Type Proposals

This section provides proposals for transaction types. Remember, there is no need to fill all attributes.

• Order Confirmation
• Shopping Cart Abandonnment