HomeGuidesAPI Reference
Submit Documentation FeedbackJoin Developer CommunityOptimizely GitHubOptimizely NuGetLog In

Tracking transactions for transaction-based billing in Commerce Cloud

This topic describes the product-specific transaction tracking for Optimizely B2C Commerce, which is required for Commerce Cloud clients on transaction-based billing.

Optimizely B2C Commerce Cloud clients on page-view based billing should review documentation for Page view tracking for Optimizely CMS.

Billing transaction definition

For billing purposes, Optimizely defines a 'transaction' as an order that has gone through the ‘convert-to-order’ flow within the B2C Commerce Cloud product, or its APIs, in a production environment. This includes: (a) all instances when a user clicks “order submit” on the checkout screen within B2C Commerce Cloud in production environment; and (b) orders that are submitted to and processed in the order table via a headless API, or other custom implementation.

📘

Note

Every order that is captured in the B2C Commerce Cloud 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.

Installation

To initiate tracking of transactions on your site, you must install the EPiServer.CloudPlatform.Commerce 1.1.1 NuGet package or any later release.

Transaction tracking was included in the April 2022 B2C Commerce Cloud release package and updated in the September 2022 release and every subsequent release.

This NuGet package with transaction tracking is available for both Commerce 13 and Commerce 14, including .NETFramework 4.6.1, .NET5.0 and .NET6.0.

Frequently asked questions

How are transactions captured?

When a new order line is added to the order table and its status is updated to 'InProgress', an event will be sent to Optimizely’s backend servers for tracking. 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.

What information is logged for each transaction?

For each transaction saved in the Order table, the following information is logged:

    public class OrderModel 
    { 
        public string OrderId { get; set; } 
        public string Currency { get; set; } 
        public string Status { get; set; }   
        public decimal OrderTotal { get; set; } 
        public decimal MerchandiseTotal { get; set; } 
        public int NumberOfShipments { get; set; } 
        public decimal ShipmentTotal { get; set; } 
        public decimal TaxTotal { get; set; } 
        public decimal NumberOfUnits { get; set; } 
        public decimal CustomerId { get; set; }
        public decimal SiteId { get; set; }
    } 

No customer, PII or product information is included in the logging.

Is historical transaction data captured?

No. Tracking of transaction events will only begin once the client has installed the above NuGet package to their site. Once tracking has begun, transaction data will be retained by Optimizely for up to 24 months.

How are headless orders and other custom implementations handled?

Headless implementations of B2C Commerce Cloud that leverage the backend order table of B2C will be counted as a transaction. Completely custom order flows that bypass the order APIs of Commerce Cloud may not be tracked.

All clients are required to self-report transaction volume that bypasses the order table and/or the order APIs of Commerce Cloud.

How are custom order IDs handled?

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.

How are custom statuses handled?

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.