Restaurant Delivery Retention: Measure Who Comes Back

Summary Highlights
A practical way to separate returning-order mix from customer retention, check data limits and compare mature delivery cohorts.
A useful delivery-retention report follows the same group of customers for the same amount of time. Define who enters the group, what counts as a return, which stores and platforms are included, and whether every customer has completed the observation window. Keep a platform's new-versus-returning summary separate from a cohort return rate. If the available data cannot follow a customer over time, report that limit instead of manufacturing a retention percentage.
For a multi-unit restaurant team, this turns “Are guests coming back?” into a question that can be checked before the next marketing decision.
Start with the question your data can answer
Two useful measures answer different questions:
• Returning-customer order share: Of the completed orders in a period, how many were placed by customers the source classified as returning?
• Cohort return rate: Of the distinct customers who entered a defined group, how many placed at least one qualifying later order within a fixed window?
The first describes the current order mix. The second follows an earlier customer group. One loyal customer can generate several orders, so an order count cannot stand in for a count of customers who returned.
Uber Eats documents new and returning customer information in its Analytics area. DoorDash describes new, occasional and frequent customer segments in its Merchant Portal. Those native labels are useful, but the public descriptions alone do not establish an identical lookback window, store scope or customer definition across platforms. Keep the original labels and record the definition shown in the report you actually use. Uber Eats analytics guide · DoorDash customer analytics
Write a retention definition before calculating
Use a short specification that another analyst can reproduce:
1. Entry event: A customer's first qualifying completed order in the available history. If earlier history is missing, call this “first observed order,” not “first-ever customer.”
2. Entry dates: One defined week or month, using a named reporting timezone.
3. Customer scope: A single store, a defined group of stores, or the brand. Returning to another location counts only if your definition includes it and the available identity can support that match.
4. Return event: At least one later qualifying completed order within the chosen follow-up window.
5. Window: For example, the 30 days after the entry order. This is a chosen operating lens, not an industry benchmark.
6. Exclusions: A consistent treatment of canceled, test and duplicate orders, plus a stated refund policy.
7. Data cutoff: The latest date through which the source is complete, including any known reporting delay.
Define returns as later completed orders, not a second line item, modifier or duplicate export row from the original order.
Check whether the data supports a cohort
A custom cohort calculation needs a stable, permitted customer identifier within the relevant source, completed-order timestamps, and the store and order status fields needed for your definition. Confirm that the identifier stays consistent across the periods you are comparing.
Do not attempt to join people across delivery apps using names, addresses or guesses. Separate marketplace reports may describe overlapping guests without providing a reliable cross-platform identity. Adding their customer counts does not produce a verified count of unique people across the brand.
DoorDash explicitly distinguishes the information available for Marketplace customers from the more detailed information it describes for Online Ordering customers. A field available in one product should not be assumed available in another. DoorDash analytics and customer-data scope
If you have only aggregate new/returning order counts, use them as an order-mix report. If the platform supplies a native retention view, retain its own definition and observation window. If neither supports the desired cohort, mark the cohort rate unavailable and identify the missing field or report. A useful decision can start with an honest limit.
Give every customer the full window
A customer who first ordered two days ago has not had 30 days to return. Mixing that customer into a completed 30-day cohort biases the comparison toward groups with less observation time.
Publish a final cohort result only after its last entrant has had the full follow-up window and the reporting lag has passed. A more recent cohort can be shown separately as “still maturing,” with no direct winner/loser comparison against a fully observed group.
Keep the data cutoff fixed in the report. A result calculated today and another calculated last week may differ because of newly observed returns rather than a change in guest behavior.
A worked example: customers, orders and maturity
The following numbers are hypothetical and illustrate the calculation. They are not Voosh customer results or industry benchmarks.
A restaurant follows 200 distinct, first-observed customers whose initial completed order occurred September 1–7. Complete data through October 8 gives every entrant a full 30-day follow-up window.
During each customer's own window:
• 40 customers place at least one later completed order.
• Those 40 customers place 76 later orders in total.
• The 30-day cohort return rate is 40 ÷ 200 = 20%.
• Later orders per cohort customer are 76 ÷ 200 = 0.38 orders.
Dividing 76 by 200 and calling the result “38% customer retention” would count some returning customers more than once.
Now consider a first-observed October 1–7 cohort viewed on October 15. Its 30-day result is still maturing. Even if its observed return rate is currently lower, that is not yet a fair full-window comparison.
Use one small cohort review sheet
Keep these fields together for each store or defined store group:
• Source and scope: Platform, report, stores, fulfillment type and timezone
• Cohort entry: Entry event, dates and available historical lookback
• Follow-up: Return event, number of days and completeness cutoff
• Eligible customers: Distinct entrants with the full observation window
• Returning customers: Distinct eligible customers with at least one qualifying return
• Return rate: Returning customers divided by eligible customers
• Additional context: Return orders, order value, discounts and operational issues, where available
• Decision: One next step, an owner and the evidence needed to revisit it
Show the numerator and denominator alongside the percentage. Two returns out of ten and 200 out of 1,000 both equal 20%, but the smaller group gives much less information about a repeatable pattern.
Turn the result into a bounded next step
When a mature cohort changes, check the context before increasing discounts:
• Did acquisition channels, promotion eligibility or the mix of stores change?
• Were the initial orders concentrated in a seasonal event or a different daypart?
• Did menu availability, cancellations, order accuracy or delivery feedback deteriorate?
• Did the source change its definition or arrive with incomplete data?
Use one consistent comparison first. Then investigate a specific explanation. A lower observed return rate does not, by itself, prove which operational issue caused it. A higher rate among customers who received an offer also does not prove that the offer created those returns. Use a properly designed restaurant promotion test when the decision requires a causal answer.
Put retention beside marketing cost
Retention becomes more useful when the team can review the spending associated with the customer groups it is trying to reach.
Voosh's published True ROI release describes comparing locations and campaigns and examining spending on new, repeat and lapsed customer segments across DoorDash and Uber Eats. That provides context for a campaign review. It does not establish that every connected account exposes the customer-level history required for this custom cohort calculation. Voosh True ROI release
Bring your cohort definition, source report and current data limits to the conversation. Request a Voosh demo to review the available marketing analytics for your restaurant group.



