Optimizely Customized Commerce clients on page-view based billing should review documentation for Page view tracking for Optimizely Content Management System (CMS).
Optimizely defines a billing transaction as an order that has gone through the ‘convert-to-order’ flow within Customized Commerce or its APIs in a production environment. This includes all instances when a user clicks “order submit” on the checkout screen in production environment and orders that are submitted to and processed in the order table with a headless API or other custom implementation.
Every order that is captured in the Customized Commerce production order database and passes through the order status of 'InProgress' will be included in the total count of transactions.
Updates, cancellations, and returns to orders that have already moved through the order status of 'InProgress' will not impact the total count of transactions.
Optimizely reviews the client's order database on a daily basis and counts the number of lines in the order table. Before aggregating the count of transactions, duplicate orders are removed via a check for unique order IDs. Each month’s count of events will be reported to the Customer Success Manager for each client for aggregation and billing purposes.
No customer, PII, or product information is included in the logging.
Headless implementations of Customized Commerce that leverage the backend order table will be counted as a transaction. Completely custom order flows that bypass the order APIs may not be tracked.
All clients are required to self-report transaction volume that bypasses the order table and/or the order APIs of Customized Commerce.
The system conducts a unique Order ID check when aggregating transaction events. Specifically, the TrackingNumber column of the OrderGroup_PurchaseOrder table is referenced when completing the unique Order ID verification. In the case of a custom implementation in which the TrackingNumber field is not used as a unique identifier for each transaction, the total number of transactions may be calculated incorrectly.
In the case that a client has a custom implementation that does not leverage that field, the client will need to self-report their transaction volume for billing purposes.
The query references orders that move through the ‘InProgress’ status. In the case that a client uses a customer status to represent the ‘convert-to-order flow’, the client will need to self-report their transaction volume for billing purposes.
Updated 5 months ago