> ## Documentation Index > Fetch the complete documentation index at: https://developers.perform.ai/llms.txt > Use this file to discover all available pages before exploring further. # EDD Prediction Model > The model built for your brand that turns your order and delivery history, warehouse rules and Perform.AI network data into a delivery date at checkout. **Available to all Checkout customers.** ## Summary Every brand gets its own EDD Prediction Model, built for it alone and trained on its own data, covering the journey from the warehouse to the shopper’s door. It blends your history with Perform.AI network data across more than 1,100 carriers, models the journey as a distribution rather than a single number, turns that distribution into a date at a confidence level you choose, and adjusts to live network conditions. ## Who it’s for E-commerce and logistics teams who need a delivery date they are willing to show on a product page, rather than a carrier estimate that starts at collection or a static transit table padded for the worst day. It is scoped first and never used alone: the [Checkout EDD Widget](https://developers.perform.ai/products/checkout/checkout-edd-widget.md) or the Checkout EDD API renders what it produces. ## Key benefits * **Your own date, not your carrier’s estimate.** The model is trained on how your warehouses, carriers and trade lanes perform, and covers every carrier you use with one definition. * **The warehouse is in the number.** Non-working days, processing times and cut-off windows, the stretch a carrier estimate never sees, are part of the prediction. * **Confident where your own data is thin.** Your signals are blended with network data from more than 1,100 carriers, down to postal-code level, so lanes you ship rarely still get a usable date. * **The ambition of the date is a choice.** A buffer and a confidence threshold decide how near or how safe the date is, and you can see the trade in conversion and in kept promises. * **It moves when the network moves.** Weather, strikes, hub backlogs and peak adjust the date without waiting for a retrain, and the model is retrained against what was delivered. ## How it works ### Scoping Before the model is built, Perform.AI assesses what your delivery date does today: whether shoppers see a date at all, how soon after ordering it reaches them, how often it was right and how much buffer sits between the predicted and the actual delivery. The scope is then agreed lane by lane in an EDD questionnaire with your account team. Coverage is per scope; outside it, the widget shows a text range rather than a date, and the scope widens as data accumulates. ### What the model uses | Category | What it covers | | - | - | | Your own history | Order confirmation timestamps for delivered shipments, plus either first delivery attempt timestamps or tracking numbers and carriers so the events can be retrieved. Roughly three months is the working ask, partly because that is as far back as many carriers retain events. Volume requirements vary by lane, and the dataset must be representative. | | Warehouse intelligence | Non-working days, processing times and cut-off windows between an order being placed and a parcel being handed over. | | Network data | Perform.AI’s harmonised events across more than 1,100 carriers, postal-code-level geography, a public holiday library and live network conditions. | Where the data supports it, the model can be segmented by product type, because different products travel differently. ### From a distribution to a date The journey is modelled as a distribution rather than a single estimate. You choose the confidence level at which that distribution becomes a date: a higher level produces a later, safer date; a lower one produces a nearer, riskier one. Buffers and confidence thresholds are set per scope. You decide what you want and Perform.AI configures it. ### Responding to change The model adjusts the date to live network conditions, such as weather, strikes, hub backlogs and peak season, without a full retrain. It is also retrained periodically against actual first delivery attempts, so it does not decay into the static rule it replaced. ### Marketplaces Marketplace onboarding also needs seller identifiers and the service agreements between sellers and the marketplace. A new seller with its own warehouse runs on fallback logic until there is enough data to retrain; a seller using marketplace fulfilment uses the existing model. ### Related model: Shipment EDD [Shipment EDD](https://developers.perform.ai/products/checkout/shipment-edd.md) is a separate model for parcels already moving, with its own inputs and its own buffer, tuned in the opposite direction. The two share a network and a method, not a configuration. ## Set up in the portal ## Use via API and MCP * Guide: [Predict checkout delivery dates](https://developers.perform.ai/guides/predict-checkout-edd.md) requests a prediction for a destination, origin, carrier and shipping service, and links the `checkout_id` to the shipment. * API reference: [Predict checkout EDD](https://developers.perform.ai/api-reference/checkout/predict-checkout-edd.md). ## FAQ ### We don’t have three months of clean data. Can we still get a model? Scope is agreed lane by lane against what exists. Lanes Perform.AI can cover get a date; lanes it cannot get the fallback range, and the scope widens as data accumulates. ### What data do you need from us? Timestamps and either delivery events or tracking numbers and carriers: enough to learn transit, not a customer database. Warehouse rules such as cut-off times and processing times add the part of the journey a carrier never sees. ### How is this different from our carrier’s estimate? A carrier’s estimate starts at collection and covers that carrier’s network only. This starts at the order, covers the warehouse and spans every carrier you use. ### What happens on a lane you don’t cover? The widget shows a configured text range rather than a date. No error, no blank space. ### Can we set the buffer ourselves? You decide what you want and Perform.AI configures it. Decide with accuracy and conversion both in view: a larger buffer or higher threshold pushes the date later and keeps more promises, a smaller one does the reverse. ## Troubleshooting | Symptom | Cause | Fix | | - | - | - | | The widget shows the fallback range on a major lane | The lane is outside the model scope, or inputs are not reaching the widget | Confirm the lanes in scope with your account team and check the location inputs on the page. | | The date looks more conservative than what you showed before | The buffer or confidence threshold is set to keep more promises | Review the trade with your account team; a tighter setting wins more orders and misses more promises. | | The date differs between your product page and checkout | The two pages use variants for different shipping methods | See [Checkout EDD Widget](https://developers.perform.ai/products/checkout/checkout-edd-widget.md). | | A new marketplace seller gets a generic date | The seller is not yet in the model and runs on fallback logic | Expected until enough of the seller’s data exists to retrain. | ## Related * [Checkout EDD Widget](https://developers.perform.ai/products/checkout/checkout-edd-widget.md) * [Shipment EDD](https://developers.perform.ai/products/checkout/shipment-edd.md) * [Checkout Analytics](https://developers.perform.ai/products/checkout/checkout-analytics.md) * [Checkout Widget A/B Testing](https://developers.perform.ai/products/checkout/checkout-widget-ab-testing.md) * [Checkout overview](https://developers.perform.ai/products/checkout/overview.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.