Orders in Zaius are created and updated via Events.
Top-level information about the order (e.g. billing address, coupon, tax) are stored in the Orders object and linked to order events on Order ID (
The unique identifier related to this order.
The unique identifier for the order line item.
Order Item: Price
The price for the order item.
Order Item: Quantity
The number of items purchased.
Order Item: Discount
The discount (if any) for the given line item.
Order Item: Subtotal
The calculated subtotal for the given product and quantity.
The unique identifier related to this order.Subtotal
The status of the order is taken from the event action
The billing address for the order, lines delimited by commas
The shipping address for the order, lines delimited by commas
The phone number for the order in E.164 format
The recommended method of sending historical Order data is to send the data via API or CSV. CSV files can be uploaded in the UI or via Amazon (AWS) S3. The fields utilized in either method adhere to the schema outlined above.
To process returns, refunds and cancellations, send an event with an event type of
order and one of the following event actions:
return - a customer has returned some or all of the items in an order and been refunded.
refund - a customer has been issued a refund for a given order. Semantically, refunds are treated the same as returns in Zaius (e.g., negative impact on revenue). You can use either. Use both if you want to distinguish between inventory being returned to you (a return) and just money being issued to the original purchaser (a refund). If inventory is returned and money is issued back to the purchaser, Zaius recommends using the 'return' order action.
cancel - a customer has canceled their order. The order purchase and cancel events remain in Zaius (e.g., on the customer profile page, and for segmentation), and revenue is negatively impacted, but the order no longer figures in to determining the customer's lifecycle. This is in contrast to returns and refunds, where the order still counts in determining the order count, and thus lifecycle, for a customer.
Note that order returns, refunds, and cancels can be partial. Zaius determines if they are partial by tracking whether the running tally of the order's subtotal field across all events is greater than zero (partial) or not.
cancel behave as above. However, the action on the order can be customized to your business. These custom statuses are treated as below:
If the order exists, the order details are not updated (i.e. the order total would not be incremented). The order information can sent as pass-through to an event triggered marketing campaign without concern about changing order details.
If the order does not exist, the order is created according to the details on the request.