You’ve probably got eCommerce events firing somewhere in your Braze setup already. Maybe it’s the legacy purchase event. Maybe it’s a dozen custom events with names three different developers picked across three different sprints. Either way, cart abandonment isn’t waiting for your integration to catch up. 

The global average cart abandonment rate sits at 70.22% in 2026, according to Baymard Institute’s meta-analysis of 50 studies. Most retail teams trying to win that revenue back in Braze are working off whatever event names stuck over the years. Braze just standardized the entire purchase journey into six schema-validated events. Almost nobody’s written about how to actually set them up. That’s what this piece is for. 

Let’s cut to the chase. 

What are Braze eCommerce recommended events?

Braze eCommerce recommended events are standardized events with Braze-defined schemas. When an event is sent, Braze validates it against the expected schema. Successfully validated events can receive event-specific processing that supports eCommerce profile data, segmentation, messaging, reporting, and other Braze features.

The event names and schemas matter. The six canonical names are `ecommerce.product_viewed`, `ecommerce.cart_updated`, `ecommerce.checkout_started`, `ecommerce.order_placed`, `ecommerce.order_cancelled`, and `ecommerce.order_refunded`. An event that does not use the recommended-event schema should not be assumed to receive the same eCommerce-specific processing.

This matters because Braze has already flagged the legacy purchase event for retirement. It’s currently in maintenance mode: existing integrations keep working, but new functionality is being built on recommended events instead. Braze has promised roughly a year’s notice before any actual end-of-life date, and new customers are already being steered toward recommended events from day one.

Walking through the six standardized events

Each event represents a different point in the purchase journey. Implementation method can vary by event and platform; Braze provides SDK and REST API options, with some events using the SDK eCommerce APIs when available and cancellation/refund events using custom-event logging client-side.

1. ecommerce.product_viewed

Fires when a shopper views a product. It can be used for segmentation, triggering, and BrazeAI features such as item recommendations, and it can support browse-abandonment experiences.

2. ecommerce.cart_updated

Fires when cart contents are updated. Braze supports full cart payloads and incremental cart updates, including add, remove, and replace actions. A validated event updates the Active Cart data on the user profile and can be used for cart-abandonment journeys.

3. ecommerce.checkout_started

Fires when a shopper starts checkout. It can be used for segmentation and triggering checkout-abandonment experiences. Implementation can use the Braze REST API or supported SDK eCommerce APIs; it is not accurate to treat REST as the only implementation path.

4. ecommerce.order_placed

Fires when an order is placed. It is the core event for order and revenue calculations from recommended eCommerce events and can be used as the primary conversion event for Campaigns and Canvases.

5. ecommerce.order_cancelled

Fires when an order is canceled. For client-side logging, Braze documents `logCustomEvent` for `ecommerce.order_cancelled` and `ecommerce.order_refunded`, while the other recommended eCommerce events can use typed SDK eCommerce APIs where supported. Check the current SDK documentation for platform-specific implementation details.

6. ecommerce.order_refunded

Fires when you issue a full or partial refund. For a partial refund, `total_value` should represent the refunded amount so that Braze’s eCommerce revenue calculations reflect the refund correctly.

Use case examples

Braze provides eCommerce Canvas templates for key purchase-journey use cases, including abandoned browse, abandoned cart, abandoned checkout, and order confirmation. A shopper can therefore move through multiple measurable stages, with each event supporting a different journey or trigger.

What gets unlocked once events are validated

Validation is important because recommended events must conform to their defined schemas. If validation fails, Braze does not process the event as a valid recommended event. Check the current event-validation documentation for the exact handling of failed events and error reporting for the ingestion method you are using.

Debugging looks different depending on how you send the event. REST API calls return an errors array telling you exactly which event failed and why. SDK calls validate asynchronously, so the failure won’t show up in your response. You’ll find it in the workspace failure summary email instead.

Once an event validates, here’s what opens up:

• Calculated profile fields. Braze auto-populates Total Revenue, Total Orders, and Total Refunds on the user profile. No manual computation required.
• Canvas templates. Out-of-the-box flows for abandoned browse, abandoned cart, abandoned checkout, and order confirmation become available to build from.
• eCommerce reporting. Pre-built revenue, order, and refund reporting across the full funnel, with automatic currency conversion included.
• BrazeAI features. Richer input data for Predictive Events, Predictive Churn, and item recommendations.
• Segmentation and the Active Cart module. Purpose-built filters like Last Order Placed and Average Order Value sit alongside your standard custom event filters. The Active Cart module on the profile view shows the latest cart contents in real time, genuinely useful during QA.

So ask yourself: how much of this is your current setup already giving you? If the honest answer is “some of it, inconsistently,” that’s the gap these events are built to close.

Recommended events vs. custom events: Choosing the right tool

We’ve covered custom events in Braze before, so here’s the direct comparison. Short version: they’re not competing. They’re doing different jobs.

Custom events remain flexible and are appropriate for business actions that are not represented by a recommended event. Recommended eCommerce events trade some flexibility for standardized schemas and eCommerce-specific processing across the six purchase-journey events.

So when do you still reach for a custom event? Anything outside those six. Wishlist actions, promo code applications, loyalty tier changes- all of these stay custom events. added_to_wishlist and promo_code_applied, the examples from our earlier piece, are still exactly right here.

Both, recommended events and custom events, can be used in Braze messaging and personalization workflows, subject to the capabilities and data available for the specific event. In many retail implementations, the two can coexist: recommended events for standardized purchase-journey moments and custom events for additional business-specific behavior.

Implementation notes for retail teams

Implementation options include Braze SDKs, the REST API, and supported data-ingestion integrations. For client-side implementations, use the typed eCommerce SDK methods where available; `logCustomEvent` is documented for cancellation and refund events. Confirm the current SDK version and API documentation before implementation.

If you use Braze’s Shopify integration, check the current connector documentation for exactly which recommended events are provided by your connector version and configuration. Braze’s current Shopify documentation supports recommended eCommerce events, but implementation details can change as the connector evolves.

Where typed SDK helpers are available, prefer them for the recommended events they support. They can provide implementation-time structure and make the intended event schema clearer. Still validate end-to-end in a test workspace because successful client-side construction does not replace server-side ingestion checks.

If you are migrating from legacy purchase tracking, use a controlled transition: map the legacy data to `ecommerce.order_placed`, validate the new event and downstream reporting in a test or controlled environment, then coordinate the production cutover. Avoid changing live campaigns and segments until the new data path has been verified. 

Wrapping up

The six eCommerce recommended events give retail teams a standardized way to represent key stages of the purchase journey. Correct schema implementation is the foundation for Braze’s eCommerce-specific processing, segmentation, reporting, and journey capabilities.

For a phased rollout, `ecommerce.order_placed` is a logical starting point because it underpins order and revenue calculations, while the other events progressively add context across browse, cart, checkout, cancellation, and refund stages. Treat the six-event schema as a data foundation rather than assuming every future Braze feature will require every event.

If you’d like a second pair of eyes on how your Braze eCommerce setup is structured today, or want help mapping a migration off the legacy purchase event, our team at Mavlers is always happy to take a look. Let’s talk.