Parallel journey trips by event context: one user, many product instances

What are parallel journey trips by event context?

User-level enrollment usually allows one active trip of a journey per person. Context-keyed enrollment (product ID, loan ID, policy ID) lets the same user run parallel trips of the same journey, each bound to its own event attribute through waits and exits.

One-liner: one person ≠ one cart. If they have four open SKUs, four reminders should not cancel each other.

In Digikala-style Iranian shops, a user adds a phone in the morning and headphones in the afternoon. If enrollment is only user_id, the second trip kills or never creates the first. One cart gets no reminder.

Event model frame: Event-centric vs contact-centric automation.

How does each work?

User-level trip

Entry is per person. While that trip is live, the same journey does not open again for them (or re-entry has separate rules). Waits and goals sit on the person profile, not a product instance.

Context-keyed trip

Enrollment key = person + event attribute (e.g. product_id). Cart SKU-A opens trip one; cart SKU-B opens a parallel trip. Wait-until / purchase goal must filter that same product_id; buying headphones must not close the phone reminder.

Iran example: two open carts

At 11:00 the user fires cart_updated for a phone; at 15:00 for earbuds. The cart journey waits 2h then email+SMS but enrollment is user-level only. Phone trip starts; earbuds trip is rejected. At 13:00 the phone email sends; earbuds get nothing. The team says “accessories automation is broken” — it lacks a context key.

Diagnosis

Practical fix

1. Enrich cart_updated with stable product_id (and sku if needed).
2. Open the cart journey on user_id + product_id.
3. Filter wait-until / purchase goal by the same product_id.
4. Cap: max 3 parallel cart trips per person; expire older than 7 days.
5. Keep onboarding user-level — product context does not belong there.

Realtime complement: Journey vs realtime event campaign. Path frame: Marketing journey vs campaign.

When context, when user-level?

1. One life-path per person (welcome, broad quiet)? → User-level.
2. Independent instances (SKU, loan, ticket)? → Context key.
3. Should exit close only that instance? If yes, filter goal by context.
4. Does the event catalog carry a stable property? Without stable product_id, parallel trips become fiction.

Leadara mapping

1. Events with stable properties: product_id, category_id, cart_id.
2. Cart journey with context enrollment and bound goals.
3. Welcome journey separate at user-level.
4. Segments for parallel-trip caps / blast suppress.
5. Email/SMS tokens from that trip’s product context — not a generic “your cart.”

Common mistakes

• Assuming one cart per user always
• Global purchase goal on a product trip
• Keying on unstable Persian product titles
• Leaving trips open with no TTL
• Copy that omits the specific SKU name/link

Programmer language

Like code: one class (journey), many instances (trips) with separate state.

Go-live checklist

1. Same product_id on cart and purchase events?
2. Purchase goal filtered by context?
3. TTL and parallel-trip cap?
4. Onboarding still user-level?
5. Templates read product fields from context?
6. Per-product abandonment report separate from per-user?
7. Holdout on % of users, not only trips?

FAQ

Can one user run multiple instances of the same journey at once?

Yes with a context enrollment key; usually no in user-only models.

Should buying one SKU close every cart path?

No — only the trip for that product_id unless you explicitly run a single-cart policy.

Which key should we pick?

Stable and repeated on purchase: product_id or cart_line_id — not the Persian title string.

What causes trip explosion?

Keying on every pageview or unstable sessions; set TTL and caps.

Does Leadara ship a named “contextual journey” feature?

You compose it with rich events plus enrollment and goals bound to properties.

Right metric?

Per-product recovery rate and that trip’s RPR — not merely “user got a message.”

Does broad winback need context?

Usually no; it is relationship-level unless you are per-subscription.

Bottom line and next step

One user can hold parallel trips when the context key is right. This week, move the cart journey from user-only to user_id + product_id, filter the goal, and set TTL.

14-day pattern

Days 1–2: align cart/purchase events on the same product_id.
Days 3–5: build the context journey with a 3-trip cap.
Days 6–10: keep 10% holdout.
Days 11–14: compare per-SKU recovery to the prior version.

Antimatter: what not to contextualize

Do not shatter relationship paths with product_id: welcome, channel preference, sunset, broad winback. Context is for repeatable instances, not the whole relationship.

Data contract with backend

1. Same ID on cart_updated and order_completed.
2. ID must not change after catalog merges.
3. Product removal: expire the trip — do not leave eternal timeouts.
4. In the message, read name/link for that ID from context — generic fallback fails acceptance tests.

Related reading

• Event-centric vs contact-centric automation
• Journey vs realtime event campaign
• Marketing journey vs campaign