How to Personalize Food Delivery in 2026: Beyond Reorder History

TL;DR.

• Food delivery is the most context-saturated surface in consumer tech: time, weather, location, basket, hunger-state, and social context all shift preference in measurable ways.
• Most platforms throw 90% of that signal away and surface the last three orders, which maximizes short-run convenience but kills discovery and long-run retention.
• The right frame is not "collaborative filtering on orders" but a context-aware knowledge graph over cuisine, ingredient, and occasion nodes — with session signals as the primary ranking input.
• In 2026 the constraint has shifted: cheap LLM embeddings make semantic food graphs trivial to build; the hard problem is latency-safe real-time context injection at p99.
• If you only remember one thing: the reorder button is a retention killer dressed as a convenience feature — discovery rate at session 5 predicts 90-day LTV better than any engagement metric you're already tracking.

Food delivery platforms collect behavioral signal that most ML teams would kill for: exact timestamp, GPS precision, weather at order time, basket composition, browsing dwell time per restaurant card, delivery address inference (home vs. office vs. third location), and explicit re-order vs. search-driven session intent. The signal density per transaction is an order of magnitude richer than a music play or a content watch. Yet the median personalization implementation on a food delivery surface in 2026 is: collaborative filtering on order history, a cuisine-preference checkbox during onboarding, and a "reorder" carousel at the top of the home feed. That is not a personalization layer — it is a query shortcut with extra steps.

The reason this persists is not laziness. It is a measurement trap. Reorder-heavy surfaces show strong short-run conversion. Reorder UX is genuinely what users say they want. But the platforms that have published data — Uber Eats, DoorDash, Grab — consistently find that users who discover and order from a new restaurant in sessions 3–8 show materially better 90-day retention than users who reorder exclusively. The reorder surface optimizes the metric it can see while eroding the one that matters.

What Makes Food Delivery Signal Uniquely Rich

Food delivery is context-saturated in a way that most recommendation surfaces are not. A user's preference state is not stable across a day — it is a function of at least six independent context dimensions that each carry predictive signal.

Time-of-day context. Breakfast, lunch, dinner, and late-night are not just temporal buckets — they are distinct preference regimes. A user who orders Thai curry at 8 PM does not want Thai curry at 8 AM. Platforms that model cuisine preference as a static distribution over order history conflate these regimes and get noisy signals in both directions.

Weather context. This is underused relative to how predictive it is. A 2021 study on food ordering behavior found statistically significant shifts toward comfort-food categories (soups, burgers, pizza) during precipitation and cold, and toward lighter/salad categories during warm weather (Eating behavior and weather, Appetite 2021). The effect size is large enough to warrant a weather feature in any ranking model.

Location context. Home address vs. work address vs. a third location (hotel, friend's place) signal completely different availability constraints and likely different social context (solo vs. group). Address clustering from delivery history gives you this for returning users at zero incremental cost.

Session-entry context. Did the user open the app and immediately tap a restaurant, or did they browse for four minutes? Did they come in via a push notification about a specific promotion? Session-entry behavior is a strong hunger-state proxy — deliberate browsing correlates with lower urgency and higher discovery intent; direct navigation correlates with high urgency and reorder intent.

Basket composition context. A user ordering a large basket with drinks and sides is likely feeding multiple people. Their restaurant-level preference signal is dominated by breadth of menu rather than personal taste for a specific cuisine.

Recency of preference shift. Someone who ordered Vietnamese three times in the last two weeks has revealed an active preference that should outrank a Thai preference from six months ago. Static collaborative filtering weights history uniformly; a temporal decay model on the preference graph does not.

Why Collaborative Filtering Is the Wrong Base Model

Standard collaborative filtering (item-item or user-user) is the wrong starting point for food delivery, not because it is inherently bad but because its assumptions break against the structural properties of this domain.

CF assumes that co-occurrence in behavior space reflects latent preference similarity. In music or video, that assumption roughly holds. In food delivery, it does not — because order behavior is dominated by convenience constraints (delivery radius, availability window, minimum order threshold) that have nothing to do with taste preference. Two users in the same apartment building will have high behavioral overlap purely because they share the same set of reachable restaurants. CF will conclude they have similar taste; in reality they may have completely different cuisines in their graph.

The second problem is the reorder amplification loop. CF on sparse food order history will surface whatever the user ordered last, because recency creates a false popularity signal within the user's personal history. The model looks correct — it is recommending things the user has ordered — while systematically suppressing everything the user might order next.

The right base model is a context-aware knowledge graph over three node types: User nodes (with temporal preference vectors, household size inference, price sensitivity), Restaurant nodes (with cuisine tags, ingredient graph, delivery-time distribution), and Occasion nodes (weeknight dinner, weekend brunch, office lunch, late night) derived from time and location context. Edges encode preference signals with decay weights. A session-level context vector — assembled in real time from current timestamp, weather API, location type, and entry behavior — gates the graph traversal to surface restaurants relevant to the current occasion, not the user's cumulative history.

DoorDash's ML engineering team published work on exactly this kind of multi-context ranking in their 2020 recommendation post (DoorDash Engineering, 2020), noting that adding contextual features for time-of-day and location type produced larger ranking gains than adding six months of additional order history. The signal was already there; the architecture just wasn't consuming it.

Building the Food Knowledge Graph

The cuisine taxonomy problem is harder than it looks. Most platforms use a flat tag system: Italian, Chinese, Mexican, Indian, and so on. That representation cannot answer questions like "what does this user like about Italian?" — is it the carbs, the olive oil, the heavy sauces, the light antipasti? Without that resolution, you cannot generalize from Italian preference to Spanish tapas, or from Thai preference to Vietnamese, even though flavor-profile overlap is substantial.

The right structure is a three-level ontology:

Level 1 — Cuisine / region. Standard categorical tags. Low resolution but necessary for cold start.

Level 2 — Flavor profile. Spice level, umami intensity, sweetness, acidity, richness. These can be inferred from menu item embeddings or sourced from food ontology databases. FoodKG (Haussmann et al., 2019) is an open knowledge graph linking recipes, ingredients, and nutritional properties at scale — a useful backbone for this layer.

Level 3 — Ingredient graph. Specific recurring ingredients (fish sauce, cumin, fermented black bean) that appear across cuisine categories. A user who repeatedly orders dishes with fish sauce across Thai, Vietnamese, and Filipino restaurants has revealed a preference that is deeper than "Southeast Asian food" — and that preference can be used to recommend a new Korean banchan restaurant that happens to feature fermented seafood prominently.

FOODON, an OWL-based food ontology maintained under the OBO Foundry (FOODON, Nature npj Science of Food 2019), provides a reasonable starting vocabulary for Level 2–3 node types. In practice you will enrich it with menu-text embeddings from your own restaurant catalog — embedding menu descriptions with a sentence transformer and clustering gives you flavor-profile clusters that are specific to your market.

The graph construction pipeline does not need to be expensive. Menu text is already available for every restaurant on your platform. A batch embedding job over menu item descriptions, clustered into 50–100 flavor dimensions, gives you edge weights for the Restaurant → Flavor subgraph. Order history populates User → Flavor edges with temporal decay. The whole graph can live in a property graph database (Neo4j, Amazon Neptune, or even PostgreSQL with the pgvector extension for the embedding layer) and serve sub-30ms traversals at session start.

Cold Start: Day-Zero Personalization Without Order History

Food delivery has a particularly harsh cold-start constraint. Unlike a music app where the user listens to 20 tracks before you have enough signal, food delivery users place one or two orders before they either churn or habituate. If the first-session experience is "here are the 20 most popular restaurants in your delivery zone," you have wasted your best acquisition window.

The day-zero personalization frame applies directly here. You have four signal sources before the first order:

1. Onboarding dietary signals. Explicit preference capture — cuisine checkboxes, dietary restrictions — is widely used but poorly executed. The mistake is treating these as filter rules rather than graph priors. "I like spicy food" should update a spice-intensity prior that influences ranking across all cuisines, not just filter the Thai category.

2. Address context. The delivery address alone gives you neighborhood-level demographic signal. Median household income, density of specific restaurant types in the area, typical delivery windows — these are publicly available and useful for ranking calibration before any behavioral signal exists.

3. Time of first session. A user who installs and opens at 7 PM on a Friday is probably not looking for a meal-prep service. The occasion prior is strong.

4. Synthetic clone initialization. This is where a knowledge graph architecture earns its keep. A cold user can be initialized as a weighted mixture of existing user embeddings matched on: address cluster, device type (price proxy), session time, and onboarding selections. The synthetic clone is not a prediction of who the user is — it is a starting point that is meaningfully better than global popularity, which immediately starts receiving correction signal as the user browses and orders. By session three, the clone contribution should be near zero and the user's own graph should be dominant.

Context Injection at Ranking Time

Graph construction handles the long-term preference structure. The session-level problem is different: you need to inject real-time context into the ranking model in under 30ms at the p99 tail, which means the context feature assembly cannot be a blocking network call in the critical path.

The architecture that works: pre-compute the user's preference vector from the knowledge graph on a rolling basis (every 15 minutes is sufficient — food preferences do not change faster than that). Cache this vector in a low-latency store (Redis, Momento). At session start, assemble a context vector from: current timestamp bucket, weather API result (cacheable at 30-minute granularity per zip code), resolved location type (home/work/other from address clustering), and session-entry signal (push notification vs. organic open). Concatenate the preference vector and context vector, pass through a lightweight two-tower ranking model, and score the candidate restaurant set.

The two-tower architecture is important here. A cross-encoder over all (user, restaurant, context) triples would be too slow at inference. Two towers — one encoding (preference vector + context vector), one encoding restaurant features — allow the restaurant tower embeddings to be pre-computed and cached, reducing session-time computation to a single dot product over a pre-ranked candidate set. Uber Eats described this pattern in their query understanding work (Uber Engineering, 2022), noting that it allowed them to score thousands of restaurants per session within latency budget.

The Discovery Problem: Exploitation vs. Exploration in Food

The reorder surface is not inherently wrong — it is wrong when it occupies too much real estate relative to its contribution to long-run retention. The correct framing is a multi-armed bandit over the home feed layout: exploration slots have expected value that is harder to measure in single-session conversion but significantly positive in LTV prediction.

The practical implementation is straightforward. Reserve 15–20% of feed positions for exploration candidates — restaurants the user has not ordered from but that the knowledge graph predicts are high-affinity based on flavor-profile overlap with their history. Track the exploration click rate and order conversion as a separate metric. Set a floor: if a user's exploration slot conversion is above threshold, keep the allocation. If a user is a confirmed repeater (low exploration CTR across 10+ sessions), respect the signal and reduce exploration slots.

The measurement problem is that exploration converts more slowly — a user might click a new restaurant on session 4, browse the menu, close it, and order on session 6. Attribution models that do not look ahead by at least two sessions will undercount exploration's contribution. Use a 14-day attribution window for discovery credit on new restaurant first orders.

Session-based recommender architectures, particularly transformer-based models like BERT4Rec (Sun et al., 2019), are well-suited to capturing within-session browse sequences that indicate exploration intent. A user who opens three menus of restaurants they've never ordered from before landing on a fourth is not bouncing — they are deliberating. That deliberation sequence, modeled as a session embedding, is a strong signal that the current session has high discovery intent and should receive more exploration slots, not fewer.

Multi-Sided Constraints: Why Preference Alone Is Not Enough

Food delivery is a three-sided marketplace — user preferences, restaurant availability, and delivery logistics all constrain the feasible recommendation set. A personalization layer that ignores the supply side will recommend restaurants that cannot fulfill the order within acceptable delivery windows, which destroys trust faster than a bad recommendation.

The constraint hierarchy at ranking time:

Hard constraints: delivery radius, restaurant open/closed status, dietary restriction filters (allergens must be treated as hard constraints, not soft preferences).

Soft constraints with scoring weight: estimated delivery time (users in the session have a tolerance model — late-night sessions are more patient than weekday lunch), minimum order threshold vs. basket size signal, promotion eligibility.

Preference signal: the knowledge graph output.

The mistake is to apply personalization purely at the preference layer and trust that the hard/soft constraints will filter down to a reasonable candidate set. In a dense market with 500+ restaurants in a delivery zone, this works fine. In a sparse market with 40 restaurants, hard constraints can eliminate 60% of the catalog before preference scoring begins, leaving you personalizing over a set where the top result is determined by delivery time, not taste. In sparse markets, delivery-time prediction accuracy matters more than ranking model sophistication — you cannot personalize around a 60-minute ETA.

What to Build First

Start with the signal you already have before touching the model.

Week 1–2: Time-of-day segmentation. Split your order history into four sessions (breakfast, lunch, dinner, late night) and compute per-user cuisine distributions within each segment. Serve session-specific rankings instead of global history rankings. This is a heuristic, not a model, and it will outperform your current global ranker because it eliminates cross-session noise. Measure: session-specific CTR vs. baseline.

Week 3–4: Weather feature injection. Add a weather API integration and a simple weather × cuisine affinity lookup table. During precipitation, boost comfort-food categories. During warm weather, boost lighter categories. This is a population-level heuristic that does not require per-user training. Measure: order conversion rate on weather-matched restaurants vs. control.

Month 2: Build the cuisine ontology and flavor-profile graph. Embed your menu item descriptions, cluster into 40–80 flavor dimensions, and attach these as edge weights on the restaurant nodes. Use order history to build User → Flavor edges with a 30-day decay window. You now have a knowledge graph that can serve personalized rankings via graph traversal.

Month 3: Cold-start synthetic clone initialization. Implement the address cluster + onboarding signal → user embedding initialization for new users. A/B test first-session discovery rate (first order from a non-top-10 restaurant) against the current cold-start baseline.

Month 4+: Session-level context injection. Build the context vector assembly pipeline, implement the two-tower ranking model, and start running the exploration slot experiment with a 14-day attribution window.

The dependency order matters. The signal infrastructure (time segmentation, weather, flavor graph) should be live before you build the model — otherwise you are training on data that does not contain the features you need at inference time.

The platforms that are getting this right in 2026 are not the ones with the most sophisticated models. They are the ones that resolved the measurement trap — stopped optimizing reorder conversion in isolation and started tracking discovery rate, cuisine breadth expansion, and 90-day LTV as the primary success metrics. The model follows the metric. Get the metric right first.