Order Status Check

Event Serialization

always

Business Use Case

1️⃣ Customer Service: the contact-deflection lead reviews checks per order against WISMO ticket volume for the same order cohort each week, and where a status (typically processing beyond 48 hours) shows repeat checks converting into contacts, adds the missing detail — revised ETA, split-parcel notice, carrier hand-off — to the status page and re-measures deflection. 2️⃣ Fulfillment & Logistics: the operations planner monitors check volume by fulfillment_location and shipping_method; a rise in checks on orders at day three and beyond, ahead of any carrier exception, flags a node or lane running behind promise and triggers a capacity, cut-off or carrier-reroute decision. 3️⃣ Post-Purchase Experience / CRM: the lifecycle manager reads the days_since_order bucket at which checks peak for each status and moves that moment from pull to push — scheduling the proactive status email or SMS just before the peak — then tests the send against reduced check and contact volume for the treated cohort. 4️⃣ Product & Merchandising: the post-purchase product manager compares days_since_order at check time with the promised delivery window by shipping method to quantify promise accuracy, and tightens or widens the delivery dates shown on the product page and in checkout where customers are checking before the promise has even lapsed.

Business Criticality

High

Journey / Navigation Area

Engagement

Owning Function

Customer Service

Scope

Event

Calculation Notes

1️⃣ Fires once on successful render of the order status or order detail page for one resolved order, after the order management response has returned a status. It must not fire on the lookup form itself, on a failed or rejected lookup (wrong order ID, email or postcode), on the My Orders list page where no single order is in context, or on background status polling that refreshes an already-rendered page. 2️⃣ Serialization is always — every qualifying render counts, because repeat checks on the same order are the WISMO signal itself. Suppress technical duplicates only: drop a hit with the same transaction_id, order_status and page path fired within 30 minutes by the same client (back/forward cache restores, tab refreshes, SPA re-renders that do not re-query the order). Sessions follow the standard 30-minute inactivity timeout, so a check after that gap opens a new session and is counted again. 3️⃣ Boundary with Shipment Tracking View: this event is merchant-domain and order-scoped (one transaction_id, status supplied by order management). The moment the customer opens a parcel-level or carrier tracking view keyed by a tracking number — embedded carrier iframe, branded tracking page or carrier hand-off — that is Shipment Tracking View and page_view with page_type = order_status must not also fire. A split, multi-parcel order therefore yields one Order Status Check and several Shipment Tracking Views. 4️⃣ page_type, transaction_id and login_status are required on every hit; order_status and lookup_method are required whenever order management resolves them. transaction_id must be the merchant order ID sent on the originating purchase event, never the internal surrogate key, cart ID or fulfillment ID, or the join back to the order breaks. order_status must be the enumerated status rendered at page load, not a cached or predicted one. 5️⃣ Lookup paths: the authenticated path (account → My Orders → order detail) sets login_status = logged_in with lookup_method = account; the guest paths set login_status = guest with lookup_method = order_lookup_form (order ID plus email or postcode) or email_link (deep link from an order or shipping confirmation email or SMS). A signed deep link that renders the order without creating a session stays guest — inferring logged_in from a recognised device or a marketing cookie is incorrect and inflates the authenticated cohort. 6️⃣ days_since_order is whole calendar days between the order placement date and the check date in the store's reporting time zone, resolved server-side from the order record at render — not elapsed hours and not the visitor's local zone. Same-day checks are 0, negative values from back-dated or migrated orders are clamped to 0, and the parameter is omitted rather than defaulted when the placement date is unavailable. 7️⃣ Consent and PII: the hit is sent only under granted analytics consent; where consent is denied, no transaction_id is attached. The email address, postcode, phone number, tracking number and shipping address used in the lookup must never appear in a parameter, the page path or the query string — strip lookup tokens from the page location before the hit. Common instrumentation faults to avoid are naming the event after the KPI (wismo_check) instead of the unified page_view, sending free-text page copy ("your order is on its way") in place of the status enumeration, omitting login_status on guest lookups, and double-firing on SPA route changes.

Data Mappings

{
  "page": {
    "pageInfo": {
      "pageName": "order status",
      "pageType": "order_status"
    }
  },
  "transaction": {
    "transactionID": "ORD-100482",
    "attributes": {
      "orderStatus": "shipped",
      "lookupMethod": "email_link",
      "daysSinceOrder": 3
    }
  },
  "user": [
    {
      "profile": [
        {
          "attributes": {
            "loginStatus": "guest"
          }
        }
      ]
    }
  ],
  "event": [
    {
      "eventInfo": {
        "eventName": "page_view",
        "eventAction": "view",
        "type": "order_status"
      }
    }
  ]
}

{
  "event": "page_view",
  "page_type": "order_status",
  "transaction_id": "ORD-100482",
  "order_status": "shipped",
  "login_status": "guest",
  "lookup_method": "email_link",
  "days_since_order": 3
}

{
  "event": "page:view",
  "eventInfo": {
    "eventName": "pageView"
  },
  "page": {
    "pageName": "order status",
    "pageType": "order_status"
  },
  "order": {
    "transactionId": "ORD-100482",
    "orderStatus": "shipped",
    "lookupMethod": "email_link",
    "daysSinceOrder": 3
  },
  "user": {
    "loginStatus": "guest"
  }
}

{
  "eventType": "web.webpagedetails.pageViews",
  "timestamp": "2026-09-13T10:15:00Z",
  "web": {
    "webPageDetails": {
      "name": "order status",
      "siteSection": "order_status",
      "pageViews": {
        "value": 1
      }
    }
  },
  "commerce": {
    "order": {
      "purchaseID": "ORD-100482"
    }
  },
  "_experience": {
    "analytics": {
      "customDimensions": {
        "eVars": {
          "eVar40": "ORD-100482",
          "eVar41": "shipped",
          "eVar42": "guest",
          "eVar43": "email_link",
          "eVar44": "3",
          "eVar45": "order_status"
        }
      }
    }
  }
}

Source Data

Dependencies

Prerequisite: List the dependencies required for this Event

Report Attributes

Segment Eligibility

Governance

Dimensions

Derived Entities

GitHub

Community Discussion