Most Viewed Products with Amazon Personalize and WooCommerce

A “most viewed” product block is often requested as a simple popularity widget, but the implementation details matter. WooCommerce agencies need to decide whether the ranking should represent raw product page views, meaningful shopping activity, a time window, or a personalized interpretation of popularity. Amazon Personalize can provide the ranking when view events are sent as interactions, while WooCommerce can remain the source of product catalog and merchandising rules.

Define what a view means

A product page request is not automatically a useful view. Bots, crawlers, repeated refreshes, prefetching, and authenticated administrative traffic can distort the ranking. Before creating the dataset, define the event that should count.

• Product view: a shopper has loaded a product detail page and the product is available for purchase.
• Qualified view: the page has remained visible for a minimum period or the shopper has interacted with it.
• Engagement event: the shopper has selected an option, expanded product information, or added the item to a cart.

For a general “most viewed” widget, use a consistent View interaction event. If the business wants products with the strongest buying intent, use a separate event type such as AddToCart or Purchase. Do not combine these event types without deciding how each should influence the result.

Choose the ranking architecture

WooCommerce-only ranking

A WooCommerce implementation can record view counts in a custom table, object cache, analytics platform, or warehouse. This is appropriate when the requirement is a transparent global list such as “the 10 products with the most views in the last seven days.” It also makes time-window filtering and editorial exclusions straightforward.

Avoid incrementing post metadata on every request. That approach creates write contention, makes cache invalidation difficult, and can produce inaccurate counts on high-traffic stores. Queue events or aggregate them asynchronously instead.

Amazon Personalize popularity ranking

Amazon Personalize includes the Popularity-Count recipe for recommending items that are popular across users. It is useful when the store wants an Amazon Personalize-managed popularity signal rather than a query against WooCommerce analytics. The ranking is still non-personalized: two shoppers can receive the same results when the same campaign and request parameters are used.

The recipe uses interaction volume to identify popular items. The interaction dataset should include the product identifier, user identifier, timestamp, and event type. If the store sends product views as View events, the resulting list is closer to “most viewed.” If it sends purchases, the list represents “most purchased” instead.

Hybrid ranking

A common agency implementation combines Amazon Personalize with WooCommerce rules. Amazon Personalize supplies candidate product IDs, and the application then removes products that are out of stock, unpublished, restricted by customer role, or excluded by a campaign. The application can also apply a category constraint or fill missing positions with a WooCommerce popularity list.

Send product view events

For real-time collection, use an Amazon Personalize event tracker and the PutEvents API. The browser should not contain long-lived AWS credentials. Send the event through a server-side endpoint or a tightly scoped authenticated integration.

{"trackingId":"YOUR_EVENT_TRACKER_ID","userId":"session-8f31c2","sessionId":"session-8f31c2","eventList":[{"eventType":"View","itemId":"wc-product-1842","sentAt":1710000000,"properties":"{}"}]}

Use a stable product identifier that matches the ITEM_ID value in the Amazon Personalize Items dataset. Many WooCommerce stores use the product ID rather than the variation ID, but that choice must match the display and inventory model. If shoppers choose variations with materially different inventory or pricing, send variation IDs and map the returned IDs back to the correct WooCommerce entities.

For logged-in customers, use a stable application-level user ID. For anonymous shoppers, generate a random session identifier and do not use an email address, name, or other directly identifying value. Preserve the same anonymous identifier during the browsing session so repeated events can be associated correctly.

Prepare the interaction dataset

The interaction schema should contain at least these fields:

• USER_ID: a stable, pseudonymous customer or session identifier.
• ITEM_ID: the WooCommerce product or variation identifier.
• TIMESTAMP: the event time in Unix seconds for event ingestion or the required dataset format.
• EVENT_TYPE: for example, View, AddToCart, or Purchase.

Keep the event vocabulary consistent. A common error is to train with view and stream View, or to send a WooCommerce SKU in one path and a numeric product ID in another. Validate identifiers against the Items dataset before deployment.

Historical imports can provide an initial signal, but they should be cleaned first. Remove bot traffic, invalid product IDs, internal users, and events generated by preview URLs. If a product was unavailable during a large traffic spike, consider whether those views should influence its future ranking.

Retrieve and render recommendations

After training and deploying a solution version using the popularity recipe, call the campaign endpoint from the server. Request only the number of products needed by the widget, then hydrate the returned IDs with WooCommerce data.

{"campaignArn":"arn:aws:personalize:REGION:ACCOUNT:campaign/most-viewed","numResults":8}

The response contains item IDs and recommendation metadata. Do not trust the recommendation response as a substitute for catalog validation. Fetch the corresponding WooCommerce products and verify that each product is published, visible in the current catalog, purchasable where required, and permitted for the current shopper.

Preserve the order returned by Amazon Personalize after filtering. If filtering removes too many items, fill the remaining slots from a deterministic WooCommerce fallback list. A fallback prevents an empty component when the campaign has limited data or when recently unpublished products are removed.

Handle freshness, caching, and placement

Popularity changes over time, especially during promotions. Decide whether the component should represent the last hour, day, week, or a longer period. Amazon Personalize popularity results are governed by the data and retraining or campaign update process; they are not automatically equivalent to a rolling SQL window. If the business requires an exact seven-day ranking, maintain that calculation separately or design a data pipeline that regularly rebuilds the relevant dataset.

Cache recommendations at the page or API layer, but do not cache a response indefinitely. A short cache period is usually suitable for a category page or home page widget. For stores with multiple currencies, languages, catalogs, or customer groups, include all relevant context in the cache key and apply visibility rules before returning the result.

Measure whether the widget helps

Track impressions for the component separately from product views. At minimum, record:

• the recommendation request or widget impression;
• the position of each displayed product;
• click-through rate by position;
• add-to-cart and purchase rate after a click;
• revenue per widget impression;
• the percentage of results removed by inventory or merchandising rules.

Use a control group or an A/B test against the existing WooCommerce popularity block. A higher click-through rate is not sufficient if the widget lowers conversion rate, increases returns, or repeatedly promotes products with weak stock availability.

Operational safeguards for agencies

• Keep AWS credentials on the server and grant the integration only the permissions it needs.
• Log rejected events and unknown product IDs without logging personal data.
• Deduplicate client retries where possible; a retrying browser request should not create misleading view volume.
• Use a queue when traffic spikes could overwhelm the event endpoint.
• Build an administrative fallback so merchandising teams can disable the component or pin selected products.
• Document whether the displayed list is global, category-specific, customer-specific, or restricted to a time period.

For a WooCommerce agency, the key design decision is whether “most viewed” is an analytics report or a storefront recommendation. A WooCommerce aggregation is usually best for an exact, explainable time-window report. Amazon Personalize with the Popularity-Count recipe is useful when the store wants a managed popularity recommendation service and may later extend the same event pipeline to personalized recipes.