High‑Intent Abandonment Orchestration & Cross‑Canvas Control Using Wunderkind + Braze

Designing high-intent abandonment in Braze is ultimately a data and orchestration problem: you need clean, mutually exclusive entry conditions, clear priority rules, and a way to keep users from bouncing between overlapping canvases.

Wunderkind Signals for Braze is designed to give you that control out of the box. Wunderkind resolves identity, evaluates high-intent behavior (cart, product, category, and catalog events), and then calls Braze’s Canvas Trigger API with a structured payload that your canvases can key off of via entry properties and segmentation logic.

Below is a practitioner-level walkthrough of how we architect these flows inside Braze so they’re scalable, debuggable, and conflict-free.

Modeling abandonment and catalog Signals

For each use case, Wunderkind sends a Signal into Braze with:

• A target Canvas ID
• A user identifier (via user alias keyed to the email address)
• A canvas_entry_properties object containing metadata like purpose, user type, and items

Example entry properties (simplified):

"canvas_entry_properties": {   "Origin": "wunderkind",   "DataOnly": "Y",   "UserType": "prospect",   "WkChannel": "email",   "WkPurpose": "cart abandonment",   "Items": [     {       "WkCopy": "Product name",       "WkId": "012345",       "WkImageUrl": "https://.../image.jpg",       "WkUrl": "https://.../p/012345"     }   ] }json

We standardize campaign naming and tags across abandonment and catalog so you can filter and prioritize consistently:

• Cart abandonment: Wunderkind - Cart Abandonment (tag wknd-email-cartabandonment)
• Product abandonment: Wunderkind - Product Abandonment (tag wknd-email-prodabandonment)
• Category recap: Wunderkind - Category Abandonment (tag wknd-email-categoryabandonment)
• Back in stock, price drop, low stock: separate “Wunderkind - [Type]” canvases with wknd-email-backinstock, wknd-email-pricedrop, wknd-email-lowstock tags

All campaign types share the same Items array schema in entry properties, which your Braze templates access via Content Blocks (for example, }) and Liquid loops to render dynamic product grids.

active_signal_email: enforcing cross-canvas priority

To avoid users sitting in multiple Wunderkind-powered flows at once, we use a dedicated Braze custom attribute, active_signal_email.

Conceptually:

• On Canvas entry: set active_signal_email to the series key (for example, cart, product, category, back_in_stock, price_drop, low_stock) via a “Change User Attribute” step at the top of the Canvas.
• On Canvas exit (completion or timeout): clear or reset it (for example, set to none or remove the attribute) in a final step, or via a separate Status Reset Canvas (described below).

Each Canvas’ entry criteria then includes both:

• “Email Available is true” or your stricter subscriber segment, and
• active_signal_email either not set, or not set to a higher-priority program.

You get a simple, auditable priority table:

• Cart abandonment is treated as highest priority: cart canvases only require “not currently in cart abandonment,” because they should win over everything else.
• Product abandonment checks “not in cart abandonment” before entry (if the Signal fires while the user is in cart, we let cart win and block product).
• Category recap checks “not in cart” and “not in product.”
• Catalog alerts check for no active higher-intent abandonment program (or you can allow them to co-exist if business rules permit).

Because this is enforced on the Braze side as a single custom attribute, it plays well with other vendors and native triggers: your cross-vendor suppression is simply “exclude users where active_signal_email is not null / not none” on any competing flows you want to keep out of the path.

Entry/exit criteria and prospect vs. customer splits

We standardize entry logic via a base “Wunderkind Signal” Canvas template in Braze.

Key configuration:

• Entry schedule: API-triggered Canvas. Wunderkind calls /canvas/trigger/send by Canvas ID for each Signal.
• Entry audience filters:
  
  • Email Available is true (or a stricter mailability segment you maintain).
  • Optional: “Last Made Purchase > 1 day ago” to suppress post-purchase churn.
• Exit criteria:
  
  • “Make any purchase” as a global exit across all abandonment and catalog canvases.
  • Additional campaign-priority exits for lower-priority canvases. For example, category recap exits if the user has “Last received message from Canvas wknd-cartabandonment less than 1 day ago” or “Last received from wknd-prodabandonment less than 1 day ago.”

Prospect vs. customer handling happens via a Decision Split immediately after entry:

• Wunderkind’s upstream eligibility worker can flag the user as UserType="prospect" or UserType="customer" via entry properties and/or use Braze segments for “Customer” based on purchase history.
• In Canvas, you drop a Decision Split: if “in Customer segment” → Customer branch; else → Prospect branch.

This gives you mirrored but independent flows:

• Abandonment cadence (per branch):
  • Prospect: 4 emails (30 minutes, then +24h, +24h, +24h).
  • Customer: 3 emails (same spacing, but fewer touches).
• Catalog cadence (per branch):
  • 2 emails: immediate send, then +24h reminder.

You clone this template per campaign (cart, product, category, back-in-stock, price-drop, low-stock) and only adjust the messaging and, for catalog, the number of steps to match the shorter series.

Canvas configuration and filter logic

A typical cart abandonment Canvas, built from the shared template, looks like this:

1. Entry: API-triggered on cart abandonment Signal.
2. Entry audience:
   • Email Available is true.
   • Last Made Purchase > 1 day ago.
   • Optional: active_signal_email is null or not equal to cart.
3. User attribute update:
   • Set active_signal_email = "cart".
4. Decision Split: Customer vs. prospect branch.
5. Delay + Message steps:
   • Delay 30 minutes → Email 1 (Wunderkind product grid Content Block).
   • Delay 24 hours → Email 2.
   • Delay 24 hours → Email 3 (customer) or Email 3 + 4 (prospect).
   Each Message uses:
   • HTML or Drag-and-Drop editor with Wunderkind Content Blocks (Wunderkind_Product_Grid, Wunderkind_Hero_Product, etc.).
   • The shared “Wunderkind Signals” Link Template (adding bxid=} and UTM parameters) so clicks carry the Braze ID for downstream identification and reporting.
6. Exit criteria (global):
   • Make any purchase.
7. Final step:
   • Clear or reset active_signal_email (for example, set to none).

Product and category flows are identical structurally; only the purpose and exit rules differ:

• Product abandonment:
  • Same cadence and structure as cart.
  • Exit if “Last received from cart abandonment Canvas < 1 day ago,” to give cart priority when both triggers fire.
• Category recap:
  • Same structure, but messaging uses the category landing URL and top products from that category.
  • Exit if last received from cart or product abandonment < 1 day ago (two exit conditions layered on top of purchase).

Catalog flows (back-in-stock, price drop, low stock) reuse the template but with only 2 messages per branch and with content pulled from catalog-driven Signals rather than abandonment behavior.

“Status Reset” cleanup Canvas

Over time you’ll have edge cases: users who drop out mid-flow, profiles left with stale active_signal_email values, or data backfills that need a clean slate. To handle this, we recommend a lightweight “Status Reset” Canvas that runs on a schedule or listens for a generic Wunderkind maintenance Signal.

Typical logic:

• Entry audience: users where active_signal_email is not null AND they are not currently in any Wunderkind-tagged Canvas (for example, no “last received from wknd-… canvas” in the past N hours).
• Actions:
  
  • Set active_signal_email to none (or remove the attribute).
  • Optionally, write a timestamp to a separate custom attribute for debugging (“last_signal_reset_at”).

This keeps your priority system honest and prevents one bad attribute from blocking a user from re-entering legitimate flows later.

Preventing conflicts with other vendors and native Braze programs

The architecture above isolates Wunderkind-powered flows without forcing you to replatform or retire existing programs:

• Shared identity and link tracking: The bxid=} Link Template is applied to both Wunderkind and non-Wunderkind emails, so your onsite identity resolution benefits all traffic and Braze gets consistent identifiers in URLs.
• Clear tagging: All Wunderkind canvases are tagged (wknd, wknd-email-cartabandonment, etc.), making it trivial to build filters and reports like “exclude users currently active in any wknd-* Canvas” from another vendor’s journey.
• Mailability & unsubscribe in Braze: Wunderkind checks and sets subscription state via Braze APIs (/users/export/ids, /email/status, subscription groups), so mailability logic stays native to Braze and applies evenly across Wunderkind and non-Wunderkind sends.
• Priority enforced at the Canvas layer: Because active_signal_email is a Braze attribute, any vendor or native program can respect it. For example, you can add a simple entry filter “where active_signal_email is null or equals none” on batch promos or third-party cart flows to avoid collisions.

The result is an architecture where Wunderkind handles identity and high-intent decisioning, while Braze remains the single source of truth for cadence, eligibility, and cross-channel orchestration. You get more send volume and revenue from abandonment and catalog programs—without duplicating flows across tools or fighting hidden conflicts.