Customer Journey Investigation Patterns

This document describes how to trace a customer's order journey through the Commerce platform to determine if they successfully placed an order or abandoned.

Customers visit our brand websites (kfc.com, tacobell.com, pizzahut.com) or mobile apps and:

1. Login as registered user OR continue as guest
2. Select a store (localization)
3. Add items to cart
4. Checkout and pay
5. Order submitted to store

Happy path: Payment approved → Order confirmed to store Unhappy path: Payment declined → Order rejected → Customer may retry or abandon

Key insight: A @user.id can have multiple @order.ids - one per order attempt.

CRITICAL: Query on structured event attributes, NOT message content strings.

Full User Journey

env:production @user.id:<UUID>

Use storage_tier: flex for historical data (beyond hot storage).

Order Lifecycle Events (PREFERRED METHOD)

@user.id:<UUID> @event.action:* service:workflowservice

This returns all order status transitions with structured attributes you can filter on.

Did Payment Succeed?

env:production @user.id:<UUID> @event.action:* service:payment-dgs

Check @metadata.status: APPROVED vs DECLINED

Was Order Confirmed?

env:production @user.id:<UUID> @event.action:order_confirmed service:workflowservice

Was Order Rejected?

env:production @user.id:<UUID> @event.action:update_order_submission_rejected service:workflowservice

Specific Order Details

env:production @order.id:<UUID>

Combined User + Order Search

env:production (@user.id:<UUID> OR @order.id:<UUID>)

Query Tips

• *Use @event.action:** to find all events, then filter by specific actions
• Never search message strings like "confirm order successful" - use @event.action:order_confirmed
• Filter by @event.outcome:success to see only successful completions

From payment-dgs "authorization complete" logs:

From workflowservice logs:

Event Actions for Order Lifecycle

Reference: Confluence - Order Status and Timers

Happy Path

PENDING (order submitted, transmitted to brand)
   ↓
CONFIRMED (brand confirmed order)
   ↓
COMMITTED (pushed to kitchen, customer checked in)
   ↓
READY (order ready for pickup)
   ↓
FULFILLED (customer received order, sent for payment capture)
   ↓
CLOSED (payment captured - automatic transition)

Unhappy Paths

PENDING/CONFIRMED → REJECTED (store cannot prepare order)
PENDING/CONFIRMED → CANCELED (customer canceled, store closed, daypart)
PENDING/CONFIRMED/COMMITTED/READY → FAILED (payment failed, transmission timeout, delivery failed)

All Order Statuses

Order Timers

Autobump Behavior (TB example):

• If order is CONFIRMED → Autobump REJECTS (TB-specific)
• If order is COMMITTED or READY → Autobump FULFILLS

Example 1: Customer Reports Order Didn't Go Through

Scenario: Customer reports order didn't go through (unhappy → happy path recovery)

Step 1: Search all order lifecycle events

@user.id:9c3d487c-69fe-41b8-8b91-f24c887ec999 @event.action:* service:workflowservice

Step 2: Check payment authorizations

@user.id:9c3d487c-69fe-41b8-8b91-f24c887ec999 @event.action:* service:payment-dgs

Look for @metadata.status: APPROVED vs DECLINED

Step 3: Analyze results

Conclusion: First payment declined, customer retried with different @metadata.payment_method_id and succeeded.

Example 2: Trace Complete Happy Path

Scenario: Verify customer's order was fulfilled (TB DRIVE_THRU)

Step 1: Get all workflowservice events for user

@user.id:99aa11a1-f8d9-4033-bc52-cabb2e5c42df @event.action:* service:workflowservice

Step 2: Timeline of events

Key Attributes:

• @organization: tb_us
• @channel: WEB
• @order.occasion: DRIVE_THRU
• @store.number: 028718
• @order.total: 2906 (= $29.06)

Conclusion: Complete happy path - order confirmed, made, picked up, and closed.

Loyalty Events (from loyalty-dgs):

• points_earned - Customer earned loyalty points
• points_burned - Customer redeemed points for reward

1. *Query on @event.action:** - Never search message strings, use structured attributes
2. Use Flex storage for historical searches - storage_tier: flex
3. Always get extra_fields - use ["*"] to see all attributes
4. One user can have multiple orders - each attempt gets new order.id
5. Different payment_method_id = customer used different card
6. Check both user.id AND order.id - combined search gives full picture
7. Filter by @event.outcome:success - to see only successful completions
8. Use @order.currentStatus - to see status BEFORE the transition
9. @metadata.decline_reason - Only exists on DECLINED transactions (not on APPROVED)

DO - These queries work reliably:

# Order lifecycle events - one service at a time
@user.id:<UUID> @event.action:* service:workflowservice

# Payment events - one service at a time
@user.id:<UUID> @event.action:* service:payment-dgs

# Specific order's payment details
@order.id:<UUID> service:payment-dgs

# Check for closed orders
@user.id:<UUID> @event.action:close_order service:workflowservice

DON'T - These cause 500/timeout errors:

# Complex OR across different field types - BAD
@user.id:<UUID> (@event.action:close_order OR @metadata.status:APPROVED)

# Wildcard on metadata fields - BAD
@user.id:<UUID> @metadata.status:*

# Mixing multiple services in OR - BAD
@user.id:<UUID> (service:payment-dgs OR service:workflowservice)

Query Rules:

1. One service per query - don't mix services
2. Avoid complex OR clauses - run separate queries instead
3. Don't wildcard metadata fields - query specific values
4. Time window: Start now-2d, expand to now-3d → now-7d if needed
5. Always use storage_tier: flex for historical data