Choose standard or custom
Select the Shopify integration approach based on storefront architecture, including standard online-store and headless/custom scenarios.
Braze + Shopify
Connect Shopify commerce data to Braze for personalized lifecycle journeys.
Design Shopify and Braze as one commerce engagement architecture across customer profiles, shopping behavior, product data, web tracking and post-purchase journeys.
Implementation considerations
Use the integration as a governed data and journey contract rather than a point-to-point connector with undocumented assumptions.
Web identity
Define when the Braze Web SDK initializes and how anonymous and identified shopper activity should map into the customer profile.
Commerce events
Agree on product, cart, checkout, purchase and customer-state events before building recovery or post-purchase journeys.
Product data
Use a stable product identifier and a reliable catalog sync so dynamic content reflects current product context.
Market and locale rules
Document regional storefront behavior, currency, language and destination URLs when the same Braze program serves multiple markets.
QA and reconciliation
Compare sample Shopify records with Braze profiles, events and catalog objects before production sends depend on the data.
Typical architecture
For a Shopify program, the engagement layer typically consumes customer, commerce and product signals while web behavior provides additional context. The architecture should define the storefront identity model, source-of-truth boundaries, catalog behavior and lifecycle states used for eligibility.
Production scenario
A retailer uses Shopify as the commerce source, captures web behavior through the Braze Web SDK, syncs product objects for dynamic content, and triggers browse, cart and post-purchase journeys from the resulting data model.
Common release gates
- Confirm identity and source-of-truth ownership.
- Validate sample records and event or audience counts.
- Test missing data, retries, timing and suppression behavior.
- Document the integration owner and rollback path.
- Validate current vendor behavior against first-party documentation before production changes.
See all Braze integration patterns → · Explore Braze capabilities →
Commerce data model and lifecycle QA
Shopify and Braze implementations become reliable when commerce objects and customer behavior are modeled separately. Define which customer, order, product and checkout facts become profile attributes, events or catalog objects, and keep the ownership of each field documented. For example, an order event can represent the transaction while product attributes or catalog records provide reusable merchandising context. In multi-market storefronts, also define currency, locale, inventory and destination URL behavior before campaigns rely on those fields.
QA should cover the full commerce lifecycle: product view, add to cart, checkout, purchase, refund and repeat purchase. Test a known customer, an anonymous browser, a customer who logs in after browsing, and an order that changes after the original event. Verify that dynamic content does not recommend unavailable products and that post-purchase journeys do not fire twice when retry logic replays an event. The goal is a consistent commerce identity and event model that supports both immediate lifecycle triggers and longer-term personalization.
Implementation runbook
Begin with a commerce data map: customer identity, product identity, order state, checkout state, web activity, refund state and market or locale. Decide which information should live as profile attributes, events or reusable catalog data. Then document the lifecycle journeys that depend on each signal, such as browse recovery, cart recovery, post-purchase education, replenishment and win-back.
Validate anonymous-to-known identity transitions on the storefront. Test a shopper who browses before login, a returning customer, a completed purchase and a refunded order. Reconcile event counts against the commerce source and check that currency, price, product URLs and inventory state remain consistent across markets. In headless implementations, separately test the web identity and event collection layer rather than assuming the storefront framework behaves like a standard integration.
Failure modes to test
- Duplicate purchase events cause repeated transactional or promotional journeys.
- A product is recommended after it becomes unavailable or changes destination.
- Anonymous browsing is attached to the wrong known profile after login.
- Regional pricing or locale fields are inconsistent with the customer experience.
Design the integration before the journey.
Bring the current stack, source systems and the customer-engagement use case.