Catalog-triggered vs event-triggered flow: product state change vs user action

What is the difference between catalog-triggered and event-triggered flows?

An event-triggered flow starts when a person does something (viewed product, started checkout, abandoned cart). A catalog-triggered flow starts when a product record changes (price drop, back in stock, new variant) and fans out to people who are watching that product.

One-line for eCRM teams: event trigger = user action; catalog trigger = product state change. Same inbox, different owners of the spark.

Iranian fashion and electronics shops often build strong abandoned-cart SMS, then wonder why “back in stock” feels broken. Cart is event-triggered. Back-in-stock and price-drop are catalog-triggered — they need a product feed, a watchlist (or browse affinity), and a fan-out rule, not another cart_updated listener.

This pairs with channel choice on cart recovery: Abandoned cart email vs SMS.

How does each one work?

Event-triggered flow

The person emits a behavior event: product_viewed, cart_updated, checkout_started. The flow enrolls that person, then waits, messages, and exits on goals like order_completed. Audience size grows with traffic. Payload on the event (SKU, cart value) usually drives personalization.

Catalog-triggered flow

The catalog (or product feed) changes: price from 4.2M to 3.5M IRR, stock from 0 to 12, new color added. The system finds people eligible for that SKU — browsed it, wishlisted it, or sat in a “interested in category” segment — and starts a flow for each person. The spark is the product row, not a fresh click.

Iran example: sneaker drop and size restock

A Tehran footwear shop runs a solid cart SMS after cart_updated. Size 42 of a popular model goes to zero for a week, then restocks on Tuesday. Staff manually SMS a spreadsheet of “people who asked.” Half already bought elsewhere; half never consented to SMS. Meanwhile the cart flow keeps firing on other SKUs.

Diagnosis

Practical fix

1. Keep cart/checkout as event-triggered journeys.
2. Add catalog hooks: product.stock > 0 after was 0; product.price decrease ≥ X%.
3. Eligibility: viewed SKU in 30 days, or wishlist, or started checkout on that SKU — not the whole category.
4. Suppress if order_completed for that SKU (or substitute) since the view.
5. Prefer email for price-drop detail; SMS only with consent and tight frequency.

For checkout vs cart abandon nuance, see Checkout abandonment vs cart abandonment. Browse vs cart is the cousin frame: Abandoned browse vs abandoned cart.

When event trigger, when catalog trigger?

1. Person just did something in-session? → Event-triggered.
2. Product became available or cheaper and watchers should hear? → Catalog-triggered.
3. Both: browse event builds affinity; catalog change later starts the notify flow.
4. Do you have a reliable product feed into Leadara (or mirrored events like product_back_in_stock)?
5. Can you suppress purchasers of that SKU before fan-out?

Leadara mapping: events, segments, journeys, email/SMS

Leadara runs on events, segments, journeys, email, and SMS. You can model catalog triggers as product-change events that start journeys, plus segments for watchers:

1. Events: keep cart_updated, product_viewed, checkout_started; add product_back_in_stock / product_price_dropped when the feed changes (emitted by your backend, not by the shopper).
2. Segments: “viewed SKU X in 30d,” “wishlist contains X,” suppress “purchased X.”
3. Journeys: event-triggered cart path; separate catalog-triggered notify path with short delays and tight exit.
4. Email: explain price/stock with product block; SMS: short restock ping only with SMS consent.
5. Goal + guard: purchase of that SKU (or cart clear) exits so restock fans do not get a stale ping.

Common mistakes

• Calling every product email “catalog-triggered” when it is just a weekly blast
• Fan-out to everyone who viewed the category in a year
• No purchase suppress on restock
• Using cart cart_updated as a fake stock signal
• SMS price-drop without consent or currency clarity

FAQ

What is the difference between catalog-triggered and event-triggered flows?

Event-triggered starts from a person’s action; catalog-triggered starts from a product record change and notifies eligible watchers.

Is back-in-stock an event or a catalog trigger?

The spark is catalog/stock state. You may emit a product_back_in_stock event from the backend — still catalog-origin, not a shopper click.

Can one journey do both cart and price-drop?

Better as two journeys sharing suppress rules. Different sparks, different copy, different frequency budgets.

Do we need a wishlist feature?

Wishlist helps. Browse affinity windows (e.g. viewed SKU in 14–30 days) work as a lighter eligibility filter.

What if the feed is delayed?

Late restock pings after sell-through again create distrust. Gate sends on live stock check before message.

Does Leadara store a full product catalog natively for triggers?

You drive triggers with events and segments Leadara already understands; sync product-change signals from your catalog service into those events.

What metric matters?

For catalog flows: notify → purchase of that SKU, unsubscribe/STOP, and waste rate (pinged but already bought). For event flows: time-to-convert after the behavior.

Bottom line and next step

Event trigger = user action; catalog trigger = product state change. This week, keep cart event-triggered, add one back-in-stock journey with 30-day view eligibility + purchase suppress, and judge by SKU conversion — not raw SMS volume.

14-day test pattern

Days 1–2: emit product_back_in_stock from inventory service; map SKU + stock.
Days 3–5: segment “viewed SKU in 30d,” journey with email first.
Days 6–10: optional SMS for consented high-intent (checkout started on SKU).
Days 11–14: compare purchase rate vs manual spreadsheet pings; watch STOP.

If B wins on SKU conversion with lower STOP, retire the spreadsheet.

Team language: who owns the spark?

In standup, ask: did a person do something, or did a product row change? “They abandoned cart” → event. “Size 42 returned” → catalog. Write both on the board so feeds and event pipelines get separate owners.

Go-live checklist for catalog triggers

1. Product-change event (or equivalent) reliable from inventory?
2. Eligibility window documented (views/wishlist), not “whole database”?
3. Purchase/suppress before send?
4. Live stock re-check at send time?
5. Separate frequency budget from cart SMS?
6. Dashboard: fan-out size, purchases of SKU, STOP, empty-stock sends?

Without item 6, “we automated restock” is ops folklore.

Boundary with weekly product campaigns

A Tuesday “new arrivals” blast to the whole list is still a campaign. Catalog-triggered means a specific SKU row changed and only eligible watchers enter. If merchandising wants a category story, use a campaign; if inventory wants “size 42 is back,” use catalog trigger + eligibility.

Mixing them creates fake urgency: people get a category blast and a restock ping for the same shoe in one afternoon.

Healthy catalog-flow signals

Related reading

• Abandoned cart email vs SMS
• Checkout abandonment vs cart abandonment
• Abandoned browse vs abandoned cart