Delivery Confirmation

Event Serialization

always

Business Use Case

1️⃣ Logistics and Carrier Management team: when weekly On-Time Delivery Rate for a carrier and service_level falls below the contracted SLA, they file service-failure refund claims with the carrier and shift volume in the rate-shopping rules toward better-performing carriers for the affected lanes. 2️⃣ Customer Service operations lead: when Days to Delivery for a region exceeds the promised window for two consecutive days, they trigger proactive delay notifications and pre-authorise shipping-fee credits to reduce "where is my order" contact volume. 3️⃣ E-commerce Merchandising and Site Experience team: each month they recalibrate the delivery-date promise shown on product and checkout pages using actual delivered_timestamp distributions by service_level and destination, tightening estimates where carriers consistently beat them. 4️⃣ CRM and Lifecycle Marketing team: on receipt of delivery_confirmation they schedule the post-delivery review request and replenishment or cross-sell journey a fixed number of days after delivery rather than after purchase, suppressing sends for flagged reversals.

Business Criticality

High

Journey / Navigation Area

Generic

Owning Function

Operations

Calculation Notes

1️⃣ Deduplication: one event per shipment_id. Carriers frequently emit repeated "delivered" scans or re-send webhooks; keep the earliest delivered_timestamp per shipment_id and discard subsequent duplicates, including replays after OMS resyncs. 2️⃣ Split shipments: each shipment_id fires its own event. An order (transaction_id) counts toward Orders Delivered only when every non-cancelled shipment on that order has a delivery_confirmation; On-Time Delivery Rate is evaluated at shipment level against that shipment's promised_delivery_date. 3️⃣ Exclusions: digital or non-shippable items, buy-online-pickup-in-store and curbside orders (fulfilled by pickup, not carrier delivery), return-to-sender and reverse-logistics shipments, cancelled or fully refunded-before-ship orders, internal replacement shipments flagged as such, and test or employee orders. 4️⃣ Timing and time zones: delivered_timestamp is the carrier scan time normalised to UTC; on-time comparison uses the destination local calendar date against promised_delivery_date inclusive (a delivery at 21:00 local on the promised date is on time). Report on delivered date, never on webhook ingestion date. 5️⃣ Late-arriving data: carrier webhooks and OMS polling can lag 24–72 hours, so daily aggregates are restated on a rolling 7-day lookback; shipments in transit with no delivered status after 30 days past promised_delivery_date are routed to delivery-exception-occurrence rather than left open. 6️⃣ Status reversals: a delivered scan later followed by a carrier exception (misdelivery, lost-package claim) keeps the original event for audit but is flagged and excluded from On-Time Delivery Rate numerators until resolved; the corrected delivery, if any, supersedes it. 7️⃣ Days to Delivery is measured from the purchase event timestamp (joined on transaction_id) to delivered_timestamp in fractional calendar days; transit time (ship_timestamp to delivered_timestamp) is reported separately so warehouse handling time and carrier performance are not conflated.

Source Data

Dependencies

Prerequisite: List the dependencies required for this Event

Report Attributes

Segment Eligibility

Governance

Dimensions

Derived Entities

GitHub

Community Discussion