Skip to content
CASATONA
All cases
E-commerceGCP#AI/ML#Data Engineering#Cloud

A recommendation engine on Google Cloud that lifted AOV and CTR

A regional e-commerce retailer

A recommendation engine on Google Cloud that lifted AOV and CTR

[A regional e-commerce retailer] · AI/ML · Data Engineering · Cloud · GCP

A recommendation engine on Google Cloud that lifted AOV and CTR

Context

A regional e-commerce retailer wanted product recommendations and search ranking that actually reflected what each shopper was likely to want. They had the raw material — browsing behavior, purchase history, catalog data — but it was scattered and stale by the time it could be used, so their recommendations were generic and their ranking didn't learn from recent behavior.

Challenge

Two problems compounded each other. First, the data pipeline was slow: signals about what customers were doing arrived in daily batches, so recommendations were always reacting to yesterday. In e-commerce, intent is fresh — a recommendation based on day-old behavior misses the customer who's shopping right now. Second, they had no real recommendation or ranking system to speak of, just basic rules. They wanted personalization that improved the metrics that matter — average order value and click-through on recommendations — and they were already on Google Cloud, so the solution needed to fit there.

Approach

We treated this as a data-engineering problem first and a modeling problem second, because no recommendation model can outrun a stale, fragmented pipeline. The fastest path to better recommendations was getting clean, fresh signals into the system.

So we rebuilt the data pipeline to consolidate the behavioral and catalog data and to move it from daily batches toward near-real-time freshness, so the system could react to what a shopper was doing in the current session rather than yesterday. On top of that clean data, we built recommendation and ranking models and served them in the shopping experience, and instrumented the whole thing so improvements could be measured against the metrics the business cared about rather than offline scores alone.

Building on Google Cloud was the right call here for a concrete reason: the client's data already lived there. Keeping the pipeline and the models close to the data avoided moving large datasets around and let us lean on managed services instead of standing up infrastructure.

Architecture

The system runs on Google Cloud, built around the data the client already had in their warehouse.

  • Data foundation: a rebuilt pipeline consolidating behavioral and catalog data in BigQuery, moving from daily batch toward near-real-time freshness so recent behavior actually informs recommendations.
  • Modeling and serving: recommendation and ranking models built and served on Vertex AI, returning personalized results in the shopping flow.
  • Data gravity, used deliberately: because the data already lived in BigQuery, running the models on Vertex kept compute next to the data — avoiding cross-system data movement that would have added cost, latency, and complexity.
  • Measurement: recommendations and ranking were instrumented so lift in AOV and click-through could be measured directly, closing the loop between model changes and business outcomes.

This case is the deliberate GCP counterpart to our AWS work: when the data already lives in BigQuery, building on Vertex AI is the architecture that respects data gravity instead of fighting it.

Results

  • Average order value up as recommendations got more relevant to each shopper.
  • Click-through on recommendations up double digits versus the prior rules-based approach.
  • Pipeline freshness from daily to near-real-time, so recommendations react to current-session behavior.
  • A measurable, instrumented loop tying model changes to AOV and CTR.

Stack

Google Cloud Vertex AI · BigQuery · rebuilt near-real-time data pipeline · recommendation and ranking models · GCP cloud infrastructure.


When the data already lives in BigQuery, building on Google Cloud respects data gravity instead of fighting it. See how we work across AWS and GCP →, or read our honest AWS-vs-GCP take.

Have a similar problem?

Talk to us