System Transactions

Overview

System Transactions store transactional data, such as order and product details, directly in a contact’s profile. This data can be used for segmentation, automations, and transactional messaging based on purchase history.

Unlike features such as Wishlists or Abandoned Carts, System Transactions do not require a product catalog. This makes them suitable for a wide range of eCommerce and custom transactional use cases.

Navigation Path

Administration > E-commerce > System Transactions

Common Use Cases

Storing completed order and product data directly on contact profiles for long-term use
Segmenting contacts based on purchase history, such as products bought, order value, or purchase frequency
Triggering automations or transactional messages based on completed purchase data
Personalizing transactional or follow-up messages using order and product details
Supporting e-commerce and custom transactional scenarios where no product catalog is available
Reusing persistent transactional data across segmentation, automations, and message personalization

Transaction Behavior

Transactional data storage: order-related data is stored in the Transactional Related Data table of a contact profile and can be used in segments, automations, and transactional messages.
No product catalog dependency: System Transactions work independently of a product catalog, unlike Wishlists or Abandoned Carts.
Contact-based persistence: transactions are stored for existing contacts in the Mapp Engage instance, except when data is injected via Mapp Connect, which can automatically create contacts.
Multiple ingestion sources: transactional data can be injected via integrations, imports, or API-based processes.

Data Structure and Behavior

Key Column and Key-Value Structure

System Transactions use a key-value structure to uniquely identify each transaction record.

The key is a combination of:

orderId
contactId (internal contact identifier)

This combination forms the key-value pair orderId-userId.

The resulting value is displayed as the Key Column in the transaction table. The userId or internal contactId is not shown separately in the table and cannot be edited or configured.

The Key Column is not part of the System Transactions data structure and does not appear in the structure table. It is used internally to identify transaction records and to enable searching transactions using a key prefix.

System Transactions Table Structure

Each row in the System Transactions table represents a product within an order.

Required Fields

Field	Description	Type
Key Column	Combination of `orderId` and internal `contactId`	String
orderId	Unique identifier of the order	String
timestamp	Timestamp of the order	DateTime
productSKU	Product identifier (SKU)	String
productName	Name of the product	String
productPrice	Product price, raw number without currency	Number
productQuantity	Quantity of the product in the order	Number

Optional Fields

Field	Description	Type
storeId	Used for multi-shop scenarios	String
currency	Defaults to the currency set in the Transactional RD if not provided	String
returnedQuantity	Defaults to 0, used for return transactions	Number
imageURL	Link to the product image	String
productURL	Link to the product page	String
category	Product category	String
brand	Product brand	String
variant	Product variant, such as color or material	String
discountValue	Discount value per order	Number
discountPercentage	Discount percentage per order, value between 0 and 1	Number
purchaseSource	Source of the purchase, such as campaign name or channel	String
customDetail1–customDetail5	Custom fields added by extending the table structure	–

Differences from Other E-commerce Features

Compared to Wishlists and Abandoned Carts: System Transactions do not rely on a product catalog and focus on completed transactions rather than browsing or intent data.
Compared to event-based data: transactional records are stored persistently and can be reused across segmentation, automations, and message personalization.