Joins shipment timing to commerce-sibling orders by order_ref - which sales channel is suffering most from carrier delays. Key Metric.
At a glance
Cross-platform OTD split: takes every DPDLocal consignment, joins it back to the originating commerce order (Shopify / BigCommerce / Adobe / SFCC sibling) by order_ref, and groups by the originating sales channel. Surfaces “which channel’s customers are getting the worst delivery experience” so marketing can match acquisition spend to fulfilment reality.
Calculation
Calculated automatically from your DPDLocal data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A UK fashion DTC merchant on Shopify with active TikTok Shop and a small B2B trade portal. ~10,000 DPDLocal parcels per month total. Reading taken 12 Mar 26 for the trailing 30 days.
The card flags TikTok Shop at 87.2%, below the 90% channel threshold. Three things to notice:
- Aggregate OTD looks healthy at 95.2% but TikTok is in trouble. The xc card surfaces what the aggregate hides. TikTok-Shop customers are getting a materially worse delivery experience, which depresses repeat-purchase rates from a high-acquisition-cost channel.
- Why TikTok specifically? Three usual reasons. (a) Address-data quality is lower on TikTok orders (in-app checkout, no address validation); ADDRESS_INVALID exception rate is 3 times the DTC rate. (b) Same-day-promise marketing copy sets customers up to be disappointed by 1-day NextDay delivery. (c) TikTok’s order export sometimes truncates or mangles the
order_ref, causing some failures to fall out of the join (coverage gap, not real OTD drop). - Action. Add address-validation widget at TikTok Shop checkout (e.g. PostcodeAnywhere); align checkout copy with actual NextDay reality; cross-check
order_refintegrity in the TikTok-to-Shopify integration.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in DPDLocal’s dashboard: DPDLocal’s own portal does not split OTD by sales channel; the channel field exists only in the commerce-sibling order data. This card is a Vortex IQ-derived view, no native DPDLocal counterpart to reconcile against. The closest like-for-like is filtering the MyDPD tracking export byorder_ref prefix per channel and computing OTD manually.
Why our split may differ from a manual calculation:
Cross-connector reconciliation:
Known limitations / merchant FAQs
My TikTok / marketplace channel always shows worse OTD. Is the carrier punishing them? No, the carrier doesn’t know which channel an order came from. Three usual real reasons. (1) Lower address-data quality in marketplace-app checkouts that don’t run the storefront’s address-validation widget. (2) Customer expectation mismatch: marketplace-app checkout copy often promises faster delivery than the merchant’s actual SLA. (3)order_ref join coverage gap: some marketplace integrations truncate or mangle the reference, so a fraction of consignments fall into “Unknown channel” rather than the actual channel.
Why is the aggregate of channels different from the OTD Rate card?
Two reasons. (1) Coverage gap. Consignments that don’t join to a commerce-sibling order (missing order_ref) are excluded from the channel split but included in the aggregate OTD. (2) Window edge effects during sync, but these reconcile within 24 hours.
B2B trade portal shows perfect OTD. Believable?
Yes, usually. B2B accounts have clean address data (warehouse-to-warehouse delivery), generous delivery windows (expectedDeliveryDate set conservatively), and cooperative recipients (no recipient-not-available friction). B2B OTD typically runs 97 to 99% even when DTC is below.
Can I drill into the worst channel from this card?
Yes, click the channel bar to filter the OTD by Route and Exception Reasons cards to that channel only. The drill-through pre-filters by the same order_ref ∈ channel set.
My channel taxonomy doesn’t match what the card shows. Why?
The card uses the commerce-sibling’s native channel field (e.g. Shopify source_name, BigCommerce channel_id). Free-text or custom channel labels surface as-is. Set up channel-name normalisation in the connector field-mapper if you want tidier display labels.
Should I pause spend on the worst channel?
Not before fixing the root cause. The card surfaces the symptom, not the diagnosis. If the channel is structurally bad (e.g. address-data quality), pausing spend is treating the wound, not curing the disease. Fix the root cause first, then re-evaluate.