Session-Aware E-Commerce Recommendation Architecture

An anonymized Ampity account of offline embeddings, session signals, candidate retrieval and ranking. Performance and business outcomes remain unverified.

[Overview] Session-aware recommendations for an e-commerce catalog

This anonymized Ampity engagement concerned an e-commerce recommendation system that relied on batch-computed suggestions. The original account records building a hybrid recommendation platform with offline embeddings, an online feature layer, approximate nearest-neighbor retrieval and a contextual ranking model.

The intended change was to let current browsing, cart and search activity influence recommendations alongside historical behavior. The account describes the work and design choices, but does not establish measured serving performance, recommendation quality, conversion uplift or revenue impact.

[Context] Historical preferences and current intent

The original account describes recommendations based on purchase history, with limited use of activity within the current session. Its examples concern shoppers moving between product categories and newly added products waiting for the recommendation data to refresh.

Those are separate freshness problems. A shopper's current activity can change while the product catalog stays unchanged. A new product can enter the catalog before its representation is available for retrieval. Updating a session feature would not, by itself, make an unindexed product retrievable.

The recorded requirements included retaining existing recommendation endpoints, integrating with an existing experiment framework and keeping the catalog system. Privacy limits, explainability and restrictions on eligible products were also constraints. They are requirements in this account, not verified compliance or filtering results.

[Decisions] Hybrid retrieval rather than only faster batches

The account records three alternatives: more frequent precomputed recommendations, simpler online models, and a hybrid approach combining precomputed embeddings with session signals and approximate nearest-neighbor retrieval.

The hybrid approach was selected to combine historical information with request-time context while limiting the work done for each request. The source does not provide a reproducible comparison of model quality, serving cost or capacity for those alternatives.

Faster batch refresh remains an option when the information needed for a recommendation changes slowly enough. Google's retrieval guidance describes both offline precomputation for a static query embedding and approximate nearest-neighbor search. That supports comparing approaches against the actual freshness requirement, rather than treating batch processing as inherently incapable of useful recommendations.

For this engagement, the recorded reason to add online work was the interest in session behavior. No particular model complexity or serving architecture is proven necessary for every e-commerce catalog.

[Design] Candidate retrieval and ranking had different jobs

The described platform learned user and product embeddings offline. At request time, recent activity modified the user representation used for retrieval. Product representations combined catalog attributes and behavioral signals. A feature layer supplied information used across training and online inference.

Approximate nearest-neighbor search produced candidate products. A ranking model then scored and ordered those candidates using context. These are the functional responsibilities described by the account; no cloud provider, storage engine, deployment topology or feature-freshness guarantee is established here.

Google's scoring guidance explains the separation between generating candidates and scoring the resulting pool with additional features. In a comparable design, inspect both outputs. A ranker cannot select an eligible product that never entered its candidate pool.

Eligibility also needs an explicit contract. Define where product restrictions are applied and what happens when filtering leaves too few candidates. An empty set, a retrieval error and an unavailable ranking model may require different responses. The original requirement to return a relevant recommendation under all conditions is not evidence that such fallback behavior was delivered.

[Approach] Work described in the original account

The account describes establishing the feature layer alongside existing batch recommendations, introducing online serving and an ANN index, then adding session signals and contextual ranking. Compatibility with the existing endpoints and experimentation framework formed part of the migration scope.

This sequence separates data preparation, serving and model changes for discussion. It does not establish an elapsed timetable, completed test gates or a reversible cutover mechanism.

For a similar change, identify which artifacts must remain compatible: user and product representations, index contents, feature definitions, ranker inputs and the endpoint response. Keeping an earlier application version does not establish recovery if its required data or index version is no longer available. Confirm the actual dependency before describing an earlier version as a fallback.

[Evaluation] Serving behavior and business results need separate records

A historical-data comparison can examine how a model ranks held-out interactions under a stated evaluation method. It cannot directly establish incremental purchases or revenue from exposing shoppers to that model.

AWS's Amazon Personalize evaluation documentation distinguishes offline model metrics from online interaction metrics and cautions against comparing models evaluated with different data. This is a general evaluation reference. Amazon Personalize is not identified as part of this engagement.

Serving evidence answers another question: whether requests complete within an agreed budget under a defined workload, including feature lookup, retrieval, ranking and fallback. A quick model call alone would not establish the time until a recommendation appears on the page.

Before interpreting a business experiment, define who is assigned to each variant, which surface can show the recommendations, what counts as an exposure and which outcome is being compared. Preserve the difference between assignment, a returned list and an actual display. AWS's A/B-testing guidance calls for a defined hypothesis, user groups, recorded interactions and evaluation of statistical significance. It also identifies user-experience changes and external factors that can mislead a comparison.

Actual-display logs describe delivery and exposure. They do not authorize dropping assigned users who saw no display or encountered errors, or restricting analysis to purchasers. Keep the estimand, population and analysis predefined; a justified exposure-specific analysis needs its own definition rather than an ad hoc filter on the randomized comparison.

For purchases observed after the session, predefine the observation window and the handling of late events, cancellations and refunds. These are proposed measurement choices, not mechanisms claimed as delivered. A purchase following a recommendation is an association; an incremental-revenue claim needs a defensible comparison and attribution method.

[Operating checks] Review the evidence before changing traffic

The following is a proposed review artifact, not an executed engagement test. Start with authorized read-only inspection of existing records. Collect no additional personal data merely to fill a worksheet.

If a replay is needed, use only an explicitly authorized, isolated environment with synthetic or approved sanitized data and test identities. Disconnect live recommendation surfaces, experiment assignment, analytics ingestion, messaging, purchases and other downstream effects. Keep receivers non-delivering and stay inside the approved scope. These checks authorize no production fault injection or live traffic change.

For example, a synthetic fixture can contain a recommendation request, a returned list, a separate display event and a purchase event that arrives later. First inspect which records the proposed analysis would count. A returned list without a display should not silently become an observed exposure. A purchase outside the declared window needs its predefined disposition rather than a convenient reassignment after results are known. This example tests the interpretation of records, not customer behavior or model quality.

Retain expected and observed fixture behavior separately. If there is no existing trace for a proposed check, record the gap without treating the expected response as a passed test.

[Results and applicability] What this account can support

The account supports an explanation of the recorded move from batch suggestions toward session-aware retrieval and ranking, including the alternatives considered and the described implementation sequence. No measured improvement in relevance, latency, conversion, order value, cold-start behavior or revenue is asserted.

This decision is relevant when current-session information could affect product selection and the team can identify where that information would enter retrieval or ranking. It may be unnecessary when a simpler precomputed list meets the actual freshness and selection requirements.

Begin with one recommendation surface and an authorized request record. Identify the available inputs, candidate set, ranking decision, display evidence and outcome window. Use the unresolved boundary to choose the next investigation before changing a model or promising a commercial result.

Technical reference

Google's retrieval and scoring documentation and AWS Amazon Personalize evaluation and A/B-testing documentation were read on 17 October 2026. Links accompany general explanations and proposed checks. They do not establish use of Google software, Amazon Personalize, any AWS deployment, this engagement's configuration, completed tests or results.