How Target Built AI into the Core of Retail Operations

In 2023, Target’s engineers admitted something most retailers never publish. Annual physical audits showed that half of the company’s out-of-stocks were invisible to its own systems. The shelf was empty. The database said otherwise. Nearly 2,000 stores were fulfilling online orders against phantom inventory.

Three years later, the same organization runs 360,000 inventory transactions per second. It scores 250 million availability predictions a day. It lets a learning algorithm rearrange product pages on the fly, and that system alone added an estimated $50 million in demand.

This is the story of how Target got from the first fact to the second. It comes down to a handful of decisions.

The Problem: A Retailer That Could Not Trust Its Own Numbers

Target’s strategy since 2017 has been stores-as-hubs. Most Americans live within ten miles of a store. So Target fulfills digital orders from the shelf, not from distant warehouses. The model is fast and cheap when it works. It depends entirely on knowing what is physically in each store at any moment.

That was the problem. Inventory records drifted from reality, and the drift was silent:

• Theft and misplacement: items left the shelf without a matching transaction.
• Damage and mis-scans: units existed on paper but not in sellable form.
• Phantom fulfillment: a store showed four units, a guest ordered two, the picker found none.
• Downstream cost: every miss meant a reallocation, a split shipment, and a later delivery.

The data platform underneath had its own issues. In a candid post on building certified datasets, Target’s data engineers described what they found:

• Large datasets copied off-platform because joins were too slow
• Metrics that disagreed depending on which copy you queried
• Ownership that “was not well defined”
• Users who could not find data or combine sources reliably

Personalization ran on overnight batch jobs. Search, transactions, and vector embeddings lived in separate systems stitched together with synchronization pipelines.

Target had plenty of models. What it lacked was a foundation those models could act on. The company’s answer was to fix the foundation first. Then it insisted, at every stage, that a model’s output had to change a real system, not just a dashboard.

What Target Delivered

Target’s engineering blog and Google Cloud’s case write-ups make the timeline reconstructible. Read in order, it shows a single dependency chain, not a portfolio of AI pilots.

Seven capabilities came out of that sequence. Each one sits on the layer below it.

How Target Built It

What follows is the build in six stages. At each stage the interesting part is not the technology. It is the decision Target made when it had a cheaper or safer option.

Stage 1: Build the platform for peak, then govern the data honestly

Retail is seasonal. Target’s holiday traffic runs three to four times normal levels for six weeks. Running that on a private cloud means buying capacity that sits idle most of the year. So Target adopted public cloud early and expanded to a hybrid multi-cloud footprint on Google Cloud and Azure.

The decision that mattered was not which cloud. It was refusing to let application teams depend on any one provider’s platform services. Target built its own cluster management layer, the Target Application Platform. The same workload can run in a store, a data center, or a public cloud without rewrite.

The data platform took a harder lesson. Target’s engineers designed a new architecture around certified datasets. Then they wrote down where the plan bent under reality:

• Some pipelines fell back to files instead of Kafka
• Source modernization lagged the platform migration
• Large datasets got copied off-platform because joins were too slow
• Off-platform copies produced inconsistent metrics

The response was governance with teeth. Every certified dataset now passes three gates before anyone builds a model on it:

1. Data contract: a template agreed between the source team, data engineering, and the business.
2. Engineering checklist: approved by the data engineering director.
3. Product certification: criteria approved by the data product director.

The pipeline behind this is Target’s in-house framework, Kelsa. It reads Kafka, SFTP, and HTTP sources and moves data through ephemeral storage into atomic history.

Stage 2: Let a model change the inventory record

This is the decision the rest of the story turns on.

After the audit exposed unknown out-of-stocks, ideas multiplied. Different teams proposed:

• Shelf-weight sensors
• Light sensors
• Shelf-edge cameras
• Several machine learning approaches

As Target’s leaders put it, “sometimes it felt like everybody at Target had a new idea.” Rather than pick a winner, they built an architecture that could test all of them. The data would decide.

The harder call came next. The models were good at inferring where an out-of-stock probably existed. The question was what to do with the inference. The safe option was an alert for a store team member to check. Target chose instead to pass inferences straight into inventory accounting. The system adjusts the position and triggers replenishment automatically.

The team acknowledged the risk in its own write-up. Inventory data is the lifeblood of a retailer. Interfacing with it “can be fraught with risk.” They accepted that risk for one reason: an alert nobody acts on changes nothing.

The system that makes this safe is the Inventory Ledger:

• Scope: every inventory change, for every item, in every store.
• Architecture: event-driven, stateless, and polyglot.
• State: computed in twenty RocksDB instances.
• Storage: custom sharding across MongoDB, because native sharding could not keep up.
• Models: an ensemble, each tuned to one product category’s patterns.

A second model followed. Inventory-Not-Found prediction estimates the chance that an item the system says is in stock will not be found when a picker looks for it. The modeling problem was ugly. More than 90% of cases are non-INF. The feature distributions of the two classes overlap almost completely.

The team did not reach for a more exotic algorithm. It changed the data:

1. Segment by business rules: split the data into three subsets where patterns stay consistent.
2. Engineer features per segment: handle missing values and outliers within each.
3. Combine recency and seasonality: learn from recent patterns and last year’s same period.
4. Retrain around events: refresh models for holidays and promotions to handle drift.

The model now runs about 250 million predictions a day. The allocation engine uses them to avoid stores likely to fail a pick.

Stage 3: Predict demand before it exists

Once inventory state could be trusted, the data science team moved upstream. Two decisions define this stage.

The first was to stop waiting for orders. The Demand Profiler generates synthetic digital orders: simulated transactions that replicate how guests in each region will order in a coming period, without any goods changing hands. Planners use them for:

• Labor forecasting at fulfillment centers
• Reserving inventory for items that appear in multi-item orders
• Consolidating orders into one box instead of three
• Testing fulfillment processes against realistic demand

The second was to shrink the problem rather than buy a bigger solver. Deciding which of roughly 200,000 items to hold at which warehouse, and in what quantity, produces trillions of variables and billions of constraints. A commercial solver would take weeks, if it fits in memory at all.

Target’s team made it tractable through three reductions:

• Regional aggregation: demand grouped by warehouse regions instead of individual guest locations.
• Item clustering: similar products grouped so the item set shrinks without losing accuracy.
• Parallel solves: daily, weekly, and monthly forecast horizons run simultaneously in PySpark.

The reduced model has a few million variables. Most runs finish in minutes. None exceed an hour. That speed lets operations teams try several configurations and pick one the same day.

Stage 4: Move personalization from overnight to right now

Target’s personalization platform, PRZ, launched in 2014 on batch predictions. By 2022 it was serving 169 billion recommendations and generating more than $4 billion in attributable demand. The team decided batch had reached its ceiling.

The move to real-time inference on microservices was engineered pragmatically:

• Model storage: artifacts deployed on Google Cloud.
• Features: a feature store serves real-time signals per request.
• Transport: services communicate over gRPC.
• Language by throughput: Python for services near 100 transactions per second, Java when traffic runs into the thousands.

The first real-time model, Target AutoComplete, treats a guest’s cart the way a search box treats typed letters. Each item added updates a session embedding. The service recommends what usually comes next. It went live for grocery, health, and beauty in late 2022, then for every other category in early 2023. The broader rollout lifted conversion 4.4% and attributable demand 5.8%.

Target Circle offers their own engine. In 2022 the offer personalization team was told to improve both engagement and incremental revenue. The obstacle was sparsity: most guests interact with very few offers. CORE, the Contextual Offer Recommendation Engine, answers with a contextual multi-armed bandit. It learns from each interaction rather than waiting for history to accumulate.

Stage 5: Let the page learn

By 2026 Target’s product pages were modular: carousels, banners, purchase modules, item details. Which module went where was decided by A/B tests. Each test took days or weeks. Across dozens of categories, the number of possible layouts made testing them one at a time impractical.

The decision was to treat layout as a continuous optimization problem. Target’s AI-driven layout system uses contextual bandits, with one arm per recommendation carousel. It chooses which carousels appear and in what order for a given guest, item, and page. It began on traffic-aware product detail pages, the ones reached from search engines and social media, where intent varies most.

The learning behavior is the interesting part:

• For the first couple of days the system explored a range of arrangements
• Within days it converged on carousels that drove deeper engagement
• In grocery it settled on substitutes at the top of the page
• In apparel it kept more variety
• It kept adjusting as context shifted, with no manual tuning

Nobody configured any of those outcomes.

GenAI reached the stores in the same period. Store Companion is a chatbot on team members’ handhelds:

• Built in-house in about six months
• Trained on real store FAQs and process documents
• Piloted in about 400 stores
• Rolled out to nearly 2,000 stores by August 2024

Stage 6: Rebuild the data layer before scaling GenAI

Guided search exposed the last weakness. About a quarter of Target’s searches use subjective words like “cute” or “sturdy.” Keyword matching cannot serve them. Adding a separate vector database would have meant one more system to keep in sync.

Target chose consolidation twice.

First, it rebuilt search on AlloyDB AI. A query like “eco-friendly water bottles under $20” now runs vector similarity and SQL filters in one statement.

Second, it went further. After evaluating standalone vector and graph databases, the discovery team moved its whole stack onto Spanner Graph:

• Retired: Elasticsearch clusters, separate NoSQL stores, standalone vector systems, sync pipelines.
• Built: an enterprise ontology where products, brands, categories, and guest preferences are nodes and relationships.
• Stored alongside: vector embeddings and full-text search in the same platform.
• Queried: SQL and GQL in a single statement.

That graph is what grounds Target’s conversational tools. Plain retrieval finds products that look similar. The graph also knows which accessory fits which toy and which age it suits. So the LLM behind Gift Finder answers from structured context instead of guessing.

The migration touched infrastructure that millions of guests depend on. It ran in four phases with no downtime:

• Ontology mapping: define the retail entities and relationships in the graph schema.
• Parallel replay: stream live updates and embeddings into Spanner Graph alongside the old systems.
• Canary deployment: shift traffic gradually while comparing results.
• Cutover and cleanup: retire the legacy clusters and the sync pipelines between them.

Business Outcomes in Numbers

Target reports outcomes as operating metrics, not model scores. That reflects the rule that ran through the whole build: a model counts when it changes a system.

Supply chain and inventory

The inventory loop and the planning layer produced the clearest cost effects. Every unknown out-of-stock avoided is a reallocation, a second box, and a late delivery that never happens.

A 0.4% reduction in shipping cost reads as marginal. Applied to national parcel volume, it is not. Target calls it an enormous improvement in an area that was already highly efficient. The 25 to 30% cut in warehouse stockouts is the number that changes guest experience. It determines whether the nearest facility can fill the order at all.

Personalization and digital demand

Real-time scoring turned recommendations into a measured revenue line. The adaptive layout result shows how much static pages were leaving on the table.

The last row comes from Target’s conversational AI fact sheet. By mid-2026 guests could browse and buy Target products inside three assistants:

• Google Search, including AI Mode and the Gemini app
• Microsoft Copilot
• OpenAI’s ChatGPT

That channel only works because the product graph underneath can answer an assistant’s questions consistently.

Search and data platform

The data-layer rebuild paid out on both sides of the interface.

Halving no-result searches means half as many sessions that end at an empty page. Halving database upkeep freed the engineering capacity to build Gift Finder and the conversational integrations in the first place.

Conclusion

• Target’s AI story is usually told as a list of features. Read as a sequence of decisions, it is more useful. Target chose to:
• Own its platform layer rather than rent one
• Certify data by contract and publish where the plan had bent
• Let a model write to the inventory ledger when an alert would have been safer
• Shrink hard optimization problems rather than wait for bigger machines
• Move personalization off the nightly batch
• Let pages learn
• Consolidate its data layer before scaling conversational commerce

Each decision cost something. Each one also produced the data or the system the next stage needed. That is why the outcomes show up as fewer stockouts, fewer boxes, and more demand instead of accuracy scores.

For enterprise leaders, the transferable lesson is the order of operations, not the model catalog. The same discipline underpins legacy modernization and production ML programs that hold up over years: platform, then data, then models wired into operations, then the interface. The question worth asking is which of those layers is missing today. And whether the next AI investment will land on something that can carry it.