Shipping DoorDash’s First Production Transformer for Homepage Store Ranking

TL;DR — DoorDash’s store ranker is a core model behind our personalized homepage. It works across a marketplace to connect customers, merchants, and Dashers by combining customer preferences with store availability and delivery context. We explain here how the ranker works, its features, and the iterations over the past year that led to DoorDash’s first production transformer. Adding the transformer has improved recommendation quality and customer engagement, showing the strongest gains among customers who use DoorDash less frequently.

When a consumer opens the DoorDash homepage, the system has only milliseconds to turn thousands of nearby options into a small set of useful recommendations. Understanding a user's baseline preferences is only part of the problem. The same person may want a familiar weekday lunch, groceries on a weekend afternoon, or something new for dinner. The homepage must recognize these shifts in intent while operating within a strict latency budget.

For years, DoorDash’s store ranker relied on a mature, multi-tasking deep neural network (DNN). It combined consumer behavior, consumer/store affinity, store attributes, and real-time context to predict outcomes such as engagement and conversion. While reliable and efficient, the model used consumer histories that entered it as aggregate features: counts, recency buckets, and pooled embeddings. These summaries captured general preferences but often lost the order and timing of individual interactions. A model might know that someone likes coffee and tacos, for example, without learning that coffee is exclusively a weekend morning habit and tacos are a recurring weekday dinner choice.

In Mid 2025, we launched DoorDash’s first production Transformer for Homepage Store Ranking. Rather than replace the established architecture, we added a transformer module that encodes ordered consumer interactions and their temporal contexts. We then combined this sequence representation with candidate-store and request features inside the existing multi-task system.

This post describes that journey, including the starting foundation, the data and architecture built for sequence modeling, the production constraints that shaped the design, the lessons learned while launching at homepage scale, and follow-up iterations and future opportunities.

DoorDash’s multi-stage homepage recommendation system 

Although consumers see a single homepage, no one model determines everything that appears on it. The experience is assembled through multiple stages that retrieve candidates, score stores, and construct carousels that are then arranged across the page.

The full system includes specialized paths for restaurants, grocery and retail, ads, merchandising, and new content. Figure 1 follows the store-centric path, showing how five stages work together to select and rank on the homepage:

1. Store retriever narrows the nearby catalog to a manageable set of eligible candidates for each carousel.
2. Store ranker evaluates each candidate for the current consumer within a temporal and carousel context. Using behavioral, affinity, store, and contextual signals, it predicts outcomes such as engagement and conversion. It answers the question: How relevant is this store to this consumer right now?
3. Horizontal blender combines calibrated ranking predictions with business objectives.
4. Vertical ranker evaluates completed carousels within related content or objective groups. 
5. Vertical blender combines carousel groups into the final homepage list. It balances signals such as session intent, engagement, diversity, exploration, long-term value, and page-level constraints. 

Store ranker sits between retrieval and page composition, estimating the relevance of each candidate for the consumer’s current request. Its predictions provide the primary personalized signals used to order stores within store-based carousels.

The starting point: A multi-task DNN

Earlier versions of LightGBM and basic DNN rankers performed well on static features, but typically required separate models for different objectives and could not fully share learning across related outcomes. Multi-task DNNs address this by learning a common representation while preserving task-specific behavior, improving data efficiency, consistency, and the ability to balance multiple business goals in one model.

We organized the Store Ranker’s inputs into five broad groups:

• Customer behavior: Such as historical views, clicks, orders, and conversion rates. 
• Context: Including time and day of the week.
• Customer/store cross features: Previous interactions, purchase patterns, store preference, and embedding similarities.
• Store quality and operations: Delivery time, distance, ratings, uptime, menu quality, market share, and pricing signals.
• Behavioral sequences: These are drawn from a consumer’s interaction history.

These features provide a strong foundation for the transformer iteration; aggregated signals preserve stable customer and store context, while behavioral sequences expose the order and temporal interactions, allowing the model to learn how customer intent evolves.

Model architecture

Our baseline ranker used a multi-task multi-label (MTML) architecture built around two well-established components:

• MMoE (multi-gate mixture-of-experts): A set of shared expert networks with per-task gates that allow related tasks like click and conversion to share capacity while still routing signals differently.
• DCN (deep and cross network): An architecture that explicitly models feature crosses — interactions among customer, store, context, and promotion features — alongside standard dense layers.

The baseline architecture combines customer, store, and contextual features to support multiple prediction tasks. However, its aggregated behavioral inputs make it difficult to distinguish histories with similar overall activity but different sequences of events. Addressing this limitation required both richer sequence data and a model that could learn from it.

From foundation to production

Getting a transformer into production took two stages over several quarters. First, we strengthened the foundation with full-journey attribution, richer behavioral sequences, and robust feature representations. Then, we integrated the transformer into the existing ranker and adapted its architecture to meet production serving constraints.

Building the foundation

Before a transformer could add value, the data and the ranker around it had to be ready. Among the required steps were:

• Full-journey data: We rebuilt attribution so the model could learn from a customer's entire journey — impression, click, add-to-cart, checkout, and delivery. This data was collected across the app rather than just from the homepage. This enriched the labels available to the ranker, spanning positive milestones and allowing it to learn the underlying behavior patterns of a full customer journey.
• Sequence features: We restructured click and conversion histories into sequence features enriched with temporal context — signals describing when each interaction occurred. We capped click histories at 500 interactions to limit feature-fetching latency. Conversion histories were substantially shorter and remained uncapped. 
• Robust feature representation: Continuous features are noisier and less predictable online than in training, so a model that fits raw offline values can degrade in production. We instead map each one to a percentile bucket — about a hundred buckets, each a small learned embedding — to create a stable representation that still captures nonlinear differences, as shown in Figure 3. Two practical lessons stood out:
  • Skip the zero-fill: Many engagement features are zero for most customers; computing percentiles over the non-default values keeps the buckets from collapsing onto that zero mass.
  • Convert selectively: Each converted feature enlarges the model's input, so we apply it only to the highest-importance features, gaining the accuracy benefit without the full latency cost.

Transformers

Transformers can learn relationships among interactions separated by many steps in a behavioral sequence. This allows a ranker to preserve the order, timing, and context of customer actions instead of compressing them into fixed summaries. Industry work such as Meta’s HSTU and Pinterest’s PinnerFormer and TransAct demonstrate the value of learning from long, context-rich interaction histories.

For store ranking, this offered three key advantages:

• Richer behavioral sequences: Each interaction can combine the store, customer action, and temporal context. Modeling these events in order helps the ranker recognize recency, repetition, routines, and shifts in intent that aggregate features may obscure.
• Context-dependent interpretation of history: Fixed pooling treats a customer’s past interactions as a static summary. A sequence model can instead emphasize different parts of that history depending on the surrounding behavior
• End-to-end, task-aligned representations: Store, action, and temporal embeddings are learned jointly with the sequence encoder and ranking objectives.

As shown in Figure 2, we introduced the transformer as a sequence-encoding branch within the existing multi-task architecture. Its customer-history representation was combined with candidate-store and contextual features before the established task heads, preserving the homepage objectives

Applying self-attention in store ranker

Customer histories mix recurring habits with one-off decisions. We wanted our store ranker to tell the two apart and to understand how they vary with context, such as time of day and location. Applying self-attention to click and conversion histories lets the model read each interaction in light of the others. Every action is enriched with context from the rest of the history, so what it means reflects the broader pattern it belongs to rather than the single event. Together, these contextualized actions form a holistic representation of the customer's interests, and recurring preferences emerge from otherwise noisy behavior.

Imagine a customer has three past interactions:

1. Ordered from Sushi A
2. Ordered from Sushi B
3. Clicked on Pizza C

In this example, the attention layer gives the two sushi orders more influence than the pizza click when updating the Sushi A representation:

This shows how related interactions can reinforce a recurring preference in the customer’s history. This richer history representation became an input for store ranker’s click and conversion predictions alongside the candidate store and current request context. Figure 4 expands on this idea.

Adapting the architecture to serving constraints

The most difficult constraint was the requirement that our first transformer run on the existing serving infrastructure. On the upside, that pushed us toward higher quality and more efficient architecture choices, including:

• A modernized Transformer block: We adopted SwiGLU (Swish gate linear unit) activations, RMSNorm (root mean square normalization), and pre-normalization in place of GELU (Gaussian error linear unit), LayerNorm, and post-normalization. Together, these updates improved offline ranking quality, raising the model’s relative AUC lift by 0.08%.
• Taming the vocabulary: Store IDs span millions of values. Frequency-based hashing and shared embedding tables reduced the model from around 160 million parameters to 10 million — a whopping 94% reduction — while improving relative offline area under the curve (AUC) over the previous ranker from 0.88% to 1.15%.

Impact

The transformer produced a 1.15% relative offline AUC lift over the previous store ranker baseline, a substantially larger result than what was seen in recent architectural iterations. More importantly, it translated into online wins in a roughly three-week global A/B test of:

• Order rate overall, driven especially by lower-frequency customers
• Merchant trial rate — customers ordering from a new-to-them merchant — with trial rates up specifically in newer categories.

Together these drove a material annualized order value impact; (because of proprietary interests, we are omitting the absolute figure from this public discussion). The biggest gains came for data-sparse customers, low-frequency customers and those new to a category who are precisely the people for whom aggregate features carry the least signal and for whom sequence modeling helps the most.

Beyond the initial launch

Scaling toward generative recommendation: Our current ranker is a pointwise multi-task model that uses a transformer to encode and pool a customer’s interaction history, then predicts click and conversion probabilities for each customer/candidate pair. That objective imposes three structural limits:

• First, because candidates are scored independently, the objective gives the model little reason to represent the order of interactions. 
• Second, the pointwise objective draws a single training label from each example, whereas a customer's history is a sequence of many ordered decisions — a signal the current setup leaves largely unused as a prediction target. 
• Third, the model can only score candidates supplied by an upstream stage; it cannot propose them.

A generative formulation addresses these limits while preserving what already works. Rather than discarding the dense cross-features the current ranker depends on, it tokenizes them and combines them with the behavior sequence in a single representation, which adds sequential signals without giving up the set-level features that drive much of today's accuracy. Reframing the objective as an autoregressive next-action prediction then turns each customer trajectory into a target at every step rather than a single label.

We adapted a similar variation to the hierarchical sequential transduction unit (HSTU) and the Meituan generative recommendation as described in this paper: MTGR: Industrial-Scale Generative Recommendation Framework. This applies HSTU-based generative modeling to industrial ranking while retaining the cross-features on which  conventional recommenders rely. We are actively developing this direction and have seen encouraging offline gains.

Improving store identity understanding: Raw store IDs carry no inherent semantic information, so each ranker must learn representations from interactions, with limited signal for new or rarely visited stores and little transfer across rankers. We therefore explored hierarchical semantic IDs derived from store content as a common identity vocabulary across rankers. As a second, lighter-weight approach, we enriched existing hashed store embeddings with a content-cluster embedding.

Hierarchical semantic IDs

This work is inspired by Better Generalization with Semantic IDs: A Case Study in Ranking for Recommendations, which uses a residual-quantized variational autoencoder (RQ-VAE) to learn hierarchical semantic IDs for recommendation.

We trained an RQ-VAE over content embeddings of stores on Doordash. Each store received four hierarchical codes, with 512 choices per level. We compared a single shared codebook with separate codebooks and built hierarchical category-alignment, coverage, and cardinality evaluations. Our results:

• The first code captured a broad category structure; some codes grouped 10,000+ stores within a relatively narrow set of categories.
• Our approximately 100 primary category labels could validate broad semantics but not the finer distinctions learned at deeper levels.

Our lesson: Separate codebooks produce a stronger hierarchy, but downstream ranking tests and richer labels are still needed to measure the value of fine-grained semantics.

Cluster-enriched store embeddings

For a lighter-weight approach, we added a learnable content-cluster embedding to the existing hashed store embedding and tested K-means configurations with 100, 500, and 1,000 clusters.

Our lesson: Coarse semantic grouping adds more ranking value than finer clustering. Cluster embeddings offer a low-cost incremental path, while hierarchical semantic IDs remain the richer long-term representation.

Conclusion and future work

Shipping DoorDash’s first transformer ranker at homepage scale was as much a systems achievement as a modeling one. Richer behavioral signals, context-sensitive matching, and robust feature representations delivered meaningful gains, especially for customers whose preferences were harder to capture with aggregate features. These results showed how transformers could learn connections across the marketplace to improve personalization for those customers with less data. Every gain had to fit within strict latency and cost budgets, shaping the architecture, features, and serving path.

This launch is a critical step toward generative recommendation on the homepage. The full-journey data and sequence features lay the foundation for a unified, near-real-time record of what each customer searched for, browsed, added to cart, and was shown. Building on this success, we are working toward a generative recommender that combines customer interaction sequences with the cross-features that drive today’s ranking quality. With the next-action objective and semantic IDs explored above, models can learn from every step of a customer’s history and generate candidates, supporting cold-start recommendations and discovery of new content across the app. Our goal is a state-of-the-art homepage that delivers a personalized, responsive, and diverse experience by understanding the customer’s full journey and generating the homepage slate as a whole.

Acknowledgments

We are indebted to the contributions of Da Long, Di Li,Shan Zhong, Yilin Li, Medhanie Irgau, Daniel Fonyo, Rui Hu, Parul Khurana, Colin Salter, Mauricio Barrera, Chunlei Li, Chun-Wei Lee, and Eric Gu.