When a catalogue holds thousands of products, choosing becomes harder than buying.

The Problem of Too Many Choices

A small shop can show everything on a few shelves. An online store may sell hundreds of thousands of items. A shopper who lands on the home page cannot possibly look at all of them, and a search box only helps people who already know what to type. Many visitors do not know exactly what they want. They are browsing, comparing, and waiting to be inspired.

A recommendation is a suggestion that a system makes to a person, based on what the system knows about the person, the product, and many other shoppers. Good suggestions save time for the shopper and increase sales for the seller. Poor suggestions annoy the shopper and push them away.

Where Businesses Feel the Benefit

Retailers use recommendations to raise the number of products viewed per visit, increase the value of each basket, bring customers back, and help new shoppers find something relevant on their very first visit. Media companies and travel companies use similar ideas for shows, articles, and trips, although the Google Cloud service discussed here is shaped especially for retail and commerce.

Before using the service, it helps to know the basic ways a computer decides what to suggest.

Three Classic Ideas

What the Model Actually Learns

Modern systems turn every product and every shopper into a list of numbers, often called an embedding. Products that behave similarly in the data end up with similar numbers. A shopper’s number list is shaped by what they viewed, added, and bought. To make a suggestion, the system looks for products whose numbers fit the situation. You never see these numbers, but they explain why the system can connect items that no human labelled as related.

Why Building It Yourself Is Hard

A managed service that learns from your catalogue and your shoppers’ behaviour, then serves personalised suggestions through an API.

What It Is and Why It Exists

Recommendations AI lets you build high-quality, personalised product recommendation systems without needing deep expertise in machine learning, system design, or operations. You provide two kinds of information, and the service does the heavy lifting of training and serving. It exists because every retailer wants the shopkeeper-who-remembers experience, but very few can afford a research team to build it.

The Two Ingredients

Real-Time, Not Just Yesterday

Each suggestion takes into account the shopper’s recent activity, such as what they just clicked or added to the cart. If someone starts browsing tents, the next page can already reflect that interest. This real-time quality is a major reason the experience feels alive rather than canned.

A Quick Word About Names

Behind the scenes, the programming interface for this family of services is known as the Retail API. The commerce product groups together recommendations and search and browse. When you read older tutorials, you may meet the name “Recommendations AI” or “Retail API”. Newer documents say “Vertex AI Search for commerce”. They all point to the same family, so do not be confused when you see different names on different pages.

The catalogue is the foundation. Weak catalogue data leads to weak recommendations.

What Goes Into a Product Record

Every product in the catalogue is described by a record. At minimum, you provide an identifier, a title, and categories. To get better results, add a clear description, price information, availability, images, and useful attributes such as brand, colour, and size. Products that come in several variants, such as one shirt in five sizes, can be grouped so that the system understands they belong together.

Ways to Bring the Catalogue In

Keeping the Catalogue Fresh

A catalogue is not a one-time upload. Prices change, new items arrive, and old items retire. If the catalogue falls behind, shoppers will be offered products that are unavailable or wrongly priced, which damages trust quickly. Plan a regular process, such as a nightly full refresh plus instant updates for stock and price changes.

Events are small notes about what people do. Together they form the memory of your shop.

Common Event Types

Ways to Record Events

Why Event Quality Matters So Much

The model learns from what you send. If events are missing, duplicated, or carry wrong product identifiers, the model learns the wrong lessons. A common good practice is to record the exact same set of events for each shopper journey, attach a visitor identifier that stays stable across a visit, and include the list of products that were displayed. Another important detail is the attribution token that comes back with each recommendation response. When a shopper clicks a recommended product, you pass that token along with the event so the system can tell which clicks and purchases came from recommendations. Without it, measurement becomes guesswork.

Different pages of a shop need different kinds of suggestions, so the service offers different model types.

Choosing the Right Suggestion for the Right Page

A shopper on the home page wants inspiration. A shopper on a product page wants alternatives or companions. A shopper at the cart wants to be reminded of things they might have forgotten. One model cannot serve all these moments well, so each model type is trained for a specific kind of suggestion.

A Page-by-Page Map

flowchart TD
    A["Where is the shopper?"] --> B["Home page"]
    A --> C["Product page"]
    A --> D["Cart page"]
    A --> E["Returning later"]
    B --> F["Recommended for You"]
    C --> G["Others You May Like or Similar Items"]
    D --> H["Frequently Bought Together"]
    E --> I["Buy It Again"]
        

A model needs a target. You must tell the system what success looks like for your business.

The Three Common Goals

Important Rules About Objectives

Each model type has a default objective, and some other objectives may be available for particular model types. Once a model is trained, its objective cannot be changed. If you decide to change your goal, you train a new model. This means you should think about the objective before training, and you should avoid creating many near-identical models, because each one can add cost without adding value.

You do not need advanced mathematics to understand the main stages of how the service learns.

From Raw Data to Useful Suggestions

How Much Data Is Enough?

Models need a reasonable amount of history to learn useful patterns. Google’s documentation describes minimum amounts and recommended time windows of user events for each model type, for example a certain number of purchase and view events spread over a certain period. A tiny shop with very little traffic will get less impressive results than a busy one. If you are starting out, importing historical events from your analytics system gives the model a head start.

The Cold-Start Problem

Two situations challenge any recommendation system. A new shopper has no history, so the system cannot know their taste. A new product has no clicks yet, so the system cannot know who will like it. The service handles both by leaning on what it does know. For new shoppers, it uses their first few clicks in the current visit and overall popularity. For new products, it uses descriptions, categories, and attributes to relate them to existing items.

A trained model is the brain. A serving config is the set of instructions for how the brain should behave on a specific page.

What a Serving Config Is

A serving config connects a trained model to a place in your shop. It carries the settings that decide how results are returned. You may have one serving config for the home page, another for product pages, and another for the cart, even if some of them use the same underlying model. This arrangement lets you adjust behaviour on each page without retraining.

Useful Adjustments

Preview Before You Publish

The console provides a way to preview what a serving config would return for a sample shopper and product, without changing your live site. This is the best place to catch odd results, such as baby products being suggested to a hardware buyer, before customers see them. Make it a habit to inspect previews with several example scenarios, including a new shopper, a loyal shopper, and an unusual product.

When a shopper loads a page, your application asks the service for suggestions and shows them.

One Request, One Answer

When your page loads, your application sends a request that names the serving config, describes the shopper with an identifier, and describes the current event, such as “viewing this product” or “viewing the cart with these items”. The service returns an ordered list of product identifiers, and optionally product details. Your page then displays them in a carousel or a grid. Because the request includes the latest shopper activity, the result reflects what the shopper is doing right now.

sequenceDiagram
    participant S as Shopper
    participant W as Web or App
    participant R as Recommendations Service
    participant C as Product Catalogue
    S->>W: Opens a product page
    W->>R: Requests suggestions with shopper and page context
    R->>C: Looks up candidate products
    C-->>R: Product details and availability
    R-->>W: Ranked product list and attribution token
    W-->>S: Shows recommendation panel
    S->>W: Clicks a recommended product
    W->>R: Records event with attribution token
        

Speed and Fallbacks

Recommendations appear while the page is loading, so they must be fast. Keep requests simple, ask for only as many items as you will display, and place the request close to your shoppers by using your regional setup wisely. Always decide in advance what the page should show if the service is slow or unavailable. A sensible fallback is a short list of best sellers kept in your own cache. An empty gap on a page looks broken, while a popular-items strip looks intentional.

Real products connect several components around the managed service.

The Building Blocks

flowchart LR
    P["Product system"] --> CAT["Catalogue import"]
    CAT --> RS["Recommendations service"]
    SF["Storefront"] --> EV["Event collection"]
    EV --> RS
    RS --> MOD["Trained models"]
    MOD --> SC["Serving configs"]
    SC --> API["Prediction API"]
    API --> SF
    EV --> BQ["Data warehouse"]
    API --> MON["Monitoring and A/B tests"]
        

Connecting With Other Google Cloud Services

Cloud Storage and BigQuery often serve as import sources. Pub/Sub and Dataflow can carry streams of product changes or events. Cloud Scheduler can trigger regular jobs. Cloud Logging and Cloud Monitoring help you watch the system. Identity and Access Management controls who may change what. Using these together lets you build a robust pipeline rather than a collection of manual steps.

Following one product and one shopper through the whole system shows where data is created, stored, and used.

flowchart TD
    A["New product added in your system"] --> B["Catalogue updated in the service"]
    B --> C["Model retrains with new catalogue"]
    D["Shopper views and buys products"] --> E["Events sent to the service"]
    E --> C
    C --> F["Updated model ready"]
    F --> G["Serving config returns suggestions"]
    G --> H["Shopper sees recommendations"]
    H --> D
        

A Loop, Not a Line

Recommendations form a loop. Suggestions shape what shoppers click, and clicks become events that shape future suggestions. This loop can be wonderful, because the system keeps getting better. It can also be risky, because the system may keep showing what already sells and never give new items a chance. This effect is sometimes called a popularity feedback loop, and teams manage it through diversity settings, careful objectives, and experiments that give fresh products some exposure.

The Life of Each Kind of Data

A recommendation that nobody measures is a recommendation that nobody can improve.

Metrics That Matter

The Console Dashboards

The Google Cloud console offers analytics for recommendations that use your ingested events. They typically depend on certain events being present, such as page views, add-to-cart actions, and purchases, and on attribution tokens being passed back correctly. Metrics refresh periodically rather than instantly, so a new launch may take some hours before numbers appear. Treat the dashboards as a daily health check, and use your own warehouse for deeper analysis.

A/B Testing: Proving It Works

Never rely only on before-and-after comparisons. Shopping behaviour changes with season, weather, promotions, and news. The reliable method is an A/B test, where some shoppers see the new recommendations and others see the old approach at the same time. Differences in sales then come from the change, not from the calendar.

Shopping behaviour is personal. It can reveal health, finances, family situations, and more.

Access Control

Access to Google Cloud services is governed by Identity and Access Management. Give each component only the permissions it needs. The system that imports the catalogue should not have rights to delete models. The web front end that records events should not have rights to read every customer record. This principle, called least privilege, limits damage if a credential leaks.

Consent and Transparency

Tell shoppers that you personalise their experience, explain what data you use, and offer choices where the law requires them. In many regions, rules about tracking and personalisation require consent notices and the ability to opt out. Involve your legal and privacy teams from the start rather than at the end of the project.

Fair and Respectful Recommendations

Also consider fairness. If a system only promotes what already sells, small sellers or niche products may never be seen. Use diversity controls, review coverage, and deliberately test whether your recommendations help a broad range of shoppers rather than only the most common ones.

A recommendation system is a living service. It needs regular attention.

What to Watch

Tools in Google Cloud

Cloud Logging collects log records, Cloud Monitoring turns numbers into charts and alerts, and audit logs show who did what. Build a simple dashboard that places event health, serving speed, business metrics, and cost side by side. When something goes wrong at three in the morning, a single page that tells you which part is unhealthy saves hours.

Quotas and Limits

Every service has limits on request rates, response sizes, and the number of items in a response. For example, the number of items per recommendation response has an upper limit, and the service can rerank only a bounded number of candidate items. Learn these limits before launch, ask for increases early for planned peaks such as festival sales, and design your application to retry politely with growing waits instead of flooding a busy service.

Good architecture is not only about what works. It is about what works at a price you can sustain.

How You Are Charged

Pricing for this family of services is described on Google’s commerce pricing page, and it generally involves charges linked to how models are trained and kept running, how many predictions are served, and how much data is stored. Details, free allowances, and contract options can differ and change over time, and some customers work out terms with Google’s sales team. Always read the current pricing page and build your estimate from it rather than from memory or from old blog posts.

Cost Levers

Advantages and Disadvantages

A good launch is a staircase, not a leap.

flowchart LR
    A["Goal"] --> B["Catalogue"]
    B --> C["Events"]
    C --> D["Model and objective"]
    D --> E["Preview"]
    E --> F["A/B test"]
    F --> G["Review"]
    G --> H["Expand to next page"]
    H --> D
        

Experienced retail teams keep reusing a small set of proven approaches.

Learning what not to do saves months of rework.

Recommendations quietly shape many everyday shopping experiences. Here is how common retail situations use the pieces described above.

A short checklist in plain language that you can reuse in every project.

Best Practices

Common Mistakes

Quick, beginner-friendly answers to the questions people ask most.

No. You supply a catalogue and user events, pick model types and objectives, and the service handles training and serving. Understanding the ideas in this guide is enough to design a strong solution.

Recommendations AI is the recommendation capability, and it is now offered together with search and browse under the Vertex AI Search for commerce name. Older pages and training material still use the earlier names, so expect to see both.

A product catalogue, describing what you sell, and user events, describing what shoppers do. The service uses both to train models and to serve real-time suggestions.

Start where intent and measurement are clear. Frequently Bought Together on the cart page, or Others You May Like on product pages, are common first choices. Home page personalisation can follow when your data is healthy.

Not after training. If your business goal changes, you train a new model with the new objective and compare it with the old one through an experiment.

Each model type has documented minimums and recommended event history windows. Busy shops with rich history do better. Importing historical events from your analytics system can speed up early learning.

For new products, it relies on descriptions, categories, and attributes. For new shoppers, it relies on their first clicks in the current visit and general popularity. Good catalogue data helps the new-product case a lot.

It is the set of settings that connects a trained model to a place in your shop, including filters, diversity, and other behaviour controls. You can use several serving configs with the same model.

It is a unique identifier returned with recommendations. When you include it in the follow-up events caused by those recommendations, the system can measure their effect correctly and learn from the outcomes.

Run an A/B test with a control group, check the console analytics, and compare goal metrics such as conversion or basket value with guardrail metrics such as returns and complaints.

Show a cached fallback shelf, such as best sellers or editor picks. It keeps the page complete and trustworthy while the service recovers.

Google Cloud provides encryption and access control, but you are responsible for good practice: use pseudonymous identifiers, limit permissions, follow consent rules, and set retention policies. Involve legal and privacy teams early.

Yes, they can infer things shoppers have not shared. Use filters, avoid sensitive suggestions in shared or visible places, and review previews with this risk in mind.

Train only models that serve distinct purposes, reuse models across serving configs, cache for anonymous traffic, keep only needed history, retire losing experiments, and watch usage with budgets and alerts.

Yes. Names, model options, limits, and prices evolve. Keep models, serving configs, and regions as configuration choices, and recheck the official documentation regularly.

Recommendations AI in Google Cloud gives a retailer the remembering, always-awake shopkeeper that no human team could provide at scale. You supply a clean product catalogue and an honest record of what shoppers do. The service trains models of different types for different moments, such as Recommended for You on the home page, Others You May Like on product pages, and Frequently Bought Together in the cart. You choose an objective that matches your goal, shape results with serving configs and filters, preview before you publish, and prove value with controlled experiments. Around the service sit the habits that decide success in real life: stable identifiers, fresh data, attribution tokens, fallback shelves, privacy-minded design, monitoring, and cost discipline. If you remember the picture of a shop with a stock register, a visitor diary, and a menu card for every table, you already hold the structure of every recommendation system in this guide.