Evidence for recent and category-scoped recommendation strategies¶
Checked: 2026-09-23. Status: research guidance, not an approved product contract. This note covers the seven requested strategies and maps them to the service's existing data boundaries.
What the evidence supports¶
- Precomputed item-to-item relationships are a practical retrieval primitive: Amazon's original item-to-item approach moves relationship computation away from the online request, and the classic item-based study compares ways to form and rank item neighborhoods. These sources support reusing a bounded pair index for co-view and co-purchase candidates; neither shows that an unfiltered pair count is the best score for this particular catalog. Linden, Smith, and York, 2003; Sarwar et al., 2001.
- Recent actions can identify short-term intent without requiring a persistent shopper identity. A session-recommendation evaluation includes a simple association-rule baseline that looks up items co-occurring with the last session item, plus methods that weight position and sequence. Its cross-dataset comparison found simple neighborhood methods competitive with more complex neural methods, which justifies starting with a measurable item-neighborhood baseline here rather than asserting a neural model will improve outcomes. Ludewig et al., 2020, §§2 and 4.
- A recommendation system can keep candidate generation, scoring, and final constraints separate. This is useful here because category relation, product eligibility, duplicate suppression, and recency are different decisions. The categorical restriction should be enforced before filling a strategy's published result, with the resulting list evaluated for coverage. Google, Recommendation systems overview.
- Co-purchase evidence can nominate complements, but co-occurrence alone cannot certify compatibility or distinguish every complement from a substitute. Research on product relation graphs explicitly models substitute and complement relationships separately. Keep the requested different-category lane descriptive of observed cross-category purchase association unless the source supplies a verified compatibility rule. McAuley, Pandey, and Leskovec, 2015.
Recommended interpretation for this service¶
The following are implementation proposals, not results proved by the papers. They reuse the current co-occurrence scoring, daily popularity buckets, category index, and Shopper Profile boundary.
| Requested name | Candidate evidence | Scope and ranking rule |
|---|---|---|
| Recommendations using recently viewed | Eligible item neighbors of the latest acknowledged viewed Item(s) | Request-time profile/session seed; weight each bounded seed by its action recency, then aggregate published co-view scores. A snapshot-only variant would instead mean recent population views and should have a different name. |
| Recommendations using recently bought | Eligible item neighbors of the latest acknowledged purchased Item(s) | Request-time profile seed; weight bounded seeds by recency, aggregate published co-purchase scores, and define whether previously purchased Items remain eligible for replenishment. Do not infer order line sequence from line order. |
| Popular viewed same category | Most Viewed score | An anchor Item's category; restrict candidates to the same non-null category before ranking by the existing decayed view score. |
| Popular bought same category | Best Sellers score | An anchor Item's category; restrict candidates to the same non-null category before ranking by the existing decayed purchase score. |
| Frequent bought different category | Supported Frequently Bought Together pair score | Anchor Item; require a known candidate category different from its known category. Preserve minimum support and pair provenance. |
| Frequent viewed same category | Supported Also Viewed pair score | Anchor Item; require equal known categories. Preserve minimum support and pair provenance. |
frequent_viewed_different_category |
Supported Also Viewed pair score | Anchor Item; require two known, unequal categories. Preserve minimum support and pair provenance. |
In this table, popular means a per-Item aggregate over recent interactions; frequent means supported shared-context association with an anchor. That distinction follows the repository's approved definitions for Most Viewed, Best Sellers, Also Viewed, and Frequently Bought Together. Treat missing category as no evidence for either same- or different-category relations; do not place all uncategorized Items into an artificial common category. An empty primary set should stay distinguishable from a fallback-filled set through the existing provenance contract.
Scale and verification consequences¶
Use one bounded reducer for each interaction type and apply category predicates to its derived pair scores; use the existing daily popularity reduction for the two popular strategies. This avoids another read of raw interaction rows and maintains the requirement that serving reads published snapshots and profile projections only. A context of n distinct Items can produce n(n-1)/2 undirected pairs, so keep the repository's configured whole-context limits and bounded top-k output. Existing source and serving requirements; Amazon item-to-item architecture.
Tests should make these distinctions observable: equal versus unequal and missing categories; co-occurrence versus mere property-wide popularity; duplicate rows counting once for pair support; recent-seed order and tied-score determinism; no self recommendation; source/channel/property/catalog isolation; ineligible Items; insufficient evidence and explicit fallback provenance. For profile-seeded lanes, test authorization, withdrawal, history bounds, and no cross-property seed use according to the existing Shopper personalization contract. Compare category-restricted coverage and ranking against the unrestricted parent strategies with a temporal holdout before claiming a relevance improvement. Ludewig et al., 2020 evaluation method; repository evaluation contract.
City, region, and country variants¶
Evidence. SQL ROLLUP represents the nested levels of a hierarchy in one aggregation specification, and GROUPING SETS makes the selected levels explicit. Thus a training reducer can derive city, region, country, and property-level counts from the same bounded stream while preserving a level discriminator. This is a query pattern, not proof of a particular throughput target. PostgreSQL grouping-set documentation. ISO 3166 supplies codes for countries and their principal subdivisions, but not a universal city identity; therefore a city needs an explicit merchant-provided or versioned normalization contract, keyed together with region and country. ISO 3166 Maintenance Agency.
Proposed contract. Each geographic strategy variant should state whether location describes the interaction's transaction/delivery place, the browsing session's place, or the requesting Shopper's current place. Those are different meanings and should not be silently combined. One Order or Browsing Session must have one validated geography assignment before it contributes pair support. A derived key should include (data_source_id, tracking_id, catalog_id, geography_level, country_code, region_code?, city_code?); lower levels must be nested under their parents so homonymous cities cannot collide. Aggregate popularity by event and pair evidence by bounded context, using the same category predicate and score definition as the corresponding non-geographic strategy. Keep serving on published aggregate snapshots and approved Shopper Profile projections. These are architectural inferences from the service's isolation and source-read contract and SQL hierarchy semantics.
Proposed fallback, superseded by product clarification. The initial research proposal selected city, then region, country, or property-wide results when a level lacked support. The subsequent product requirement instead defines a configurable Swimlane: ordered strategy/geography variations accumulate nonduplicate Items to a quota, and authorized recent browsing history fills only after every configured variation is exhausted. Scores from distinct steps are not blended as though they shared a denominator. The reviewed implementation proposal is in the geographic-strategy design; this ordering and quota are product choices, not consequences of SQL ROLLUP. PostgreSQL grouping-set documentation.
Privacy and location quality. The W3C Geolocation specification warns that a device position can disclose a person's location, may come from GPS, network signals, or user input, and is not guaranteed to be the device's actual location. It recommends purpose limitation and prompt disposal for recipients. Do not turn raw coordinates, IP addresses, delivery addresses, or a history of precise locations into serving metadata or logs merely to produce city/region/country aggregates; obtain a purpose-authorized coarse location from the Commerce Property and retain only what the approved contract needs. This recommendation extends the repository's Shopper personalization boundary. W3C Geolocation, introduction and §3.
Verification. For each of the seven strategies, test city/region/country scoping and the chosen level, same-name cities in different regions, missing or conflicting geography, sparse-city fallback, distinct-context support, deterministic ties, and cross-property/catalog isolation. Test that a region result includes eligible evidence from its own cities exactly once, and a country result includes its regions exactly once. Profile-seeded recent lanes also need location-authorization and withdrawal tests. These tests follow from the proposed hierarchy and the repository's isolation, eligibility, and provenance obligations.