Cross-Channel Cart Abandonment With Messy App Events
UrbanStep is a footwear retailer with 300,000 mobile app users and a website running Web Extend. It wants one cart-abandonment program across email, push, and SMS. The app team sends a "cart_updated" event on every screen load, not just cart changes, and sometimes sends events before login. The website fires a cart event after a 30-second delay; the app fires immediately. About 18% of app events lack a contact ID. The retailer has email opt-in for 210,000, push opt-in for 120,000, and SMS opt-in for 40,000. Marketing wants the first message within 30 minutes and up to three reminders in 24 hours. The existing Automation Center has a welcome series and a birthday program. The team is unsure whether to use Web Extend recommendations or a relational data table for cart contents.
1. Diagnose the event-data problems and recommend an identity and de-duplication approach.
Read the worked answer
The core problem is that the event stream describes screen activity, not cart state. "cart_updated" on every screen load will trigger false abandonment and inflate volume; events before login cannot be tied to a known contact. First rewrite the taxonomy: emit a cart event only when cart contents change, include a cart version or event ID, timestamp, contact ID when known, and an anonymous ID when not. On login, stitch the anonymous ID to the contact ID and reconcile the latest cart state. De-duplicate by event ID or cart version, keeping the latest state per contact and cart. Drop or quarantine events without any identifier rather than guessing. Align website and app semantics so a 30-second website delay and an immediate app event mean the same thing. The reasoning is that automation entry and frequency caps are only as reliable as the event definition; cleaning the event contract prevents duplicate reminders and wrong segmentation.
2. Design the cart-abandonment program across email, push, and SMS with consent and frequency controls.
Read the worked answer
Use one Automation Center program with a single entry event, then a wait and a purchase-check condition. On entry, check channel consent separately: email, push, and SMS each require their own opt-in. Choose a channel priority rather than sending all three-for example push first for app users with push consent, email second, SMS only for high-value carts or customers who have explicitly opted in. Enforce a maximum of three messages in 24 hours across the program and a global contact frequency cap so the welcome and birthday programs cannot stack on top. Exit immediately on purchase or cart clear. For the 30-minute goal, use a short first wait and ensure the event pipeline is near-real-time; do not promise 30 minutes if the queue is batch. Include a fallback for contacts with no channel consent: no message. The reasoning is that cross-channel orchestration is consent orchestration; the program must not turn three channel opt-ins into three simultaneous messages.
3. Should cart contents be stored in Web Extend or a relational data table? Explain the division of labor.
Read the worked answer
Use both, for different jobs. Web Extend captures on-site and app behavior and can power recommendations and affinity, but it is not the durable system of record for cart lines and prices. Store cart contents-product ID, quantity, value, timestamps-in a relational data table keyed by contact or cart ID, refreshed from the commerce platform. Use that table to render the reminder with accurate items and to suppress reminders when the cart is empty or purchased. Use Web Extend recommendations to suggest complementary products, not to reconstruct the cart. Define which system is authoritative for cart value and ensure the event and the table agree. This division avoids overloading behavioral tracking with transactional accuracy and gives the automation a reliable exit condition.