Giving Each Streaming Recommendation Surface Its Own Acceptance Contract

An anonymous streaming engagement combining candidate retrieval, contextual ranking and feature pipelines across viewing and messaging surfaces.

One recommendation service served different product decisions

A video-streaming platform needed recommendations across its home page, search, end-of-video suggestions, email and push notifications. Its existing collaborative-filtering process relied on batch updates and had limited support for recent viewing context, new viewers and new content.

Ampity's work on this anonymous engagement used two stages: embedding-based approximate-nearest-neighbor retrieval produced candidates, and a contextual model ranked them. The account also describes real-time feature processing using Kafka and Redis, batch features using Spark, a feature-serving layer and an experimentation workstream.

The product decision was not whether every surface could call the same ranker. It was what each surface could legitimately show, using which context, and how the team would distinguish a ranking result from permission to expose it. This case preserves that engineering scope without claiming improved engagement, retention, model quality, response time or audience scale.

Retrieval reduced the scoring problem, not the product's responsibilities

The team considered scoring the entire catalog directly, a retrieval-then-ranking design, and heavier reliance on cached recommendations. It selected retrieval and ranking to narrow the scoring population while retaining contextual ordering. That added an embedding/index lifecycle and a dependency on the features used by the ranker.

Direct catalog scoring remains a possible choice for a smaller catalog or a different latency and cost budget. Caching can reduce repeated work when its key and refresh policy capture the relevant context. Neither alternative is universally unsuitable. The engagement's choice does not establish a current benchmark against those alternatives.

Google's retrieval guidance describes finding candidate embeddings through nearest-neighbor search. Its scoring guidance separates that candidate stage from subsequent ordering. These mechanisms explain the design choice; they do not establish the particular index settings or deployed model versions in this engagement.

Surface eligibility must survive the ranking decision

The account identifies editorial control, content licensing and parental controls as constraints. It does not establish their effective rule configuration or the exact position of an eligibility filter. A high score therefore cannot be treated as evidence that a title was allowed to appear on a particular surface.

Use the following proposed surface-admission card for a comparable product. It asks product, content and identity owners to supply existing rules and sanitized decision records. It does not authorize a campaign send, playback request or change to an entitlement rule.

Search has an additional query-relevance contract and should not inherit a home-page success criterion unchanged. The same distinction applies when a ranking model is reused: shared code does not make all surfaces share the same permission or product objective.

A filled example can expose an unresolved fallback

Suppose a synthetic end-of-video review supplies the ranked order A, B, C. A is excluded by the supplied parental-control rule. B has UNKNOWN licensing evidence for the proposed destination. C is eligible under the supplied rules. These are fictional item labels and review facts, not customer observations.

Only C is eligible on that evidence. That is still insufficient to accept the proposed display if the product's required item count or fallback behavior is UNKNOWN. Do not infer permission for B, or assume that an empty or shorter list is acceptable. Assign licensing evidence to the content owner and fallback behavior to the surface owner, then hold the affected proposal.

This example deliberately separates ranking order, eligibility and display acceptance. A trace should preserve all three, including the rule revision and decision time. It should not replace missing evidence with an extra recommendation request against a live viewer account.

Feature freshness needs more than a component name

The recorded system combined streaming and batch feature paths. That combination creates a timing question: which viewer events and catalog state were actually available when a recommendation was made? Redis identifies a serving technology, not an accepted age limit for every feature.

For a supplied decision record, distinguish event time, arrival time, feature materialization and request time. Ask the feature owner to identify the revision and freshness requirement relevant to that surface. If the event arrived after the decision, it cannot explain the features used by that earlier decision. A later successful lookup cannot repair the missing historical record.

Give feature transport, computation and serving separate owners in that review. Ask where an event was accepted, which computation produced the value and which value the ranker actually used. A component inventory alone cannot answer those questions or establish that a particular recommendation used fresh context.

An experiment needs exposure evidence, not just assignment

The engagement included experimentation work, but that does not demonstrate that every proposed model change improved the product. Distinguish assignment to a variant, an eligible recommendation actually displayed or sent, and an outcome observed under the agreed attribution rule. Missing exposure records make the interpretation uncertain.

Choose the hypothesis, population, comparison and decision window before interpreting results. AWS's recommendation experiment guidance also emphasizes predefined metrics and factors such as user experience. This is general guidance for reviewing an experiment, not a claim that the customer used Amazon Personalize.

Viewing time is not automatically the right objective for every surface. It may favor longer content or conflict with editorial and viewer needs. The product owner must define the acceptable objective and guardrails before an outcome can justify expansion.

Start with one surface and its first missing record

Choose one surface, one rule revision and one sanitized supplied decision trace. Fill its admission card, separate ranking from eligibility, and identify the earliest unresolved feature or display decision. Keep viewer identifiers, histories, tokens and message destinations out of the shared worksheet.

Stop at UNKNOWN licensing, messaging permission, historical feature state or fallback behavior. A later isolated replay requires separate approval for permitted data, scoped identity, bounded cost and inert analytics, email and push receivers. Do not use a live campaign or viewer interaction to fill an evidence gap.

The useful next step is an owner-assigned missing record, not a larger recommendation batch. Once that surface's contract is explicit, the team can decide whether it needs a feature-path repair, eligibility clarification or a separately approved model experiment.

Technical reference

Google's retrieval and scoring documentation and AWS's recommendation experiment guidance were checked on 18 October 2026. They support the general distinctions linked above, not this engagement's effective permissions, freshness settings, experiment results or use of Amazon Personalize. The A/B/C example is synthetic.