Frequently Bought Together for WooCommerce

A “Frequently Bought Together” module is a different problem from a “you may also like” carousel. The goal is to identify products that customers commonly purchase in the same order as the product currently being viewed or added to the cart. For a WooCommerce agency, that distinction affects the event model, Amazon Personalize recipe, API placement, merchandising rules, and the way results are measured.

Model the recommendation around completed orders

Use WooCommerce order data as the primary signal for this use case. A completed order should produce one purchase event for each product in the order. If an order contains product A, product B, and product C, the training data should contain the customer’s interaction with all three items at the order timestamp.

Cart additions and product views can be useful for broader personalization, but they should not be treated as equivalent to a purchase when the label shown to shoppers is “Frequently Bought Together.” Including every product view can turn the module into a related-products widget rather than a co-purchase widget.

Recommended event fields

USER_ID: The WooCommerce customer ID, a consented account identifier, or a stable anonymous visitor identifier.
ITEM_ID: The product or variation identifier used consistently in the catalog and recommendation requests.
TIMESTAMP: The event time in Unix epoch seconds or the format required by the ingestion method.
EVENT_TYPE: A value such as purchase.
EVENT_VALUE: Optional order-line quantity, revenue, or another numeric value if the implementation needs it.
EVENT_ID: A unique order-line or event identifier that allows the integration to avoid duplicate submissions.

For variable products, decide whether recommendations operate at the parent-product level or the variation level. Parent-level IDs usually provide more training volume and a cleaner storefront experience. Variation-level IDs can be appropriate when size, compatibility, or configuration materially changes the product relationship.

Choose an Amazon Personalize item-to-item approach

Amazon Personalize can provide item-to-item recommendations through a solution version trained on interaction data and exposed through a campaign. For a frequently-bought-together experience, an item-to-item similarity approach such as the aws-sims recipe is a practical starting point because it learns relationships between items from historical interactions.

The recipe does not automatically understand WooCommerce concepts such as parent products, out-of-stock status, bundles, or product substitutions. Those rules remain the responsibility of the integration and catalog layer. The recommendation response is a ranked set of item IDs; your application must resolve those IDs to current WooCommerce products before rendering them.

Keep the catalog and event identifiers aligned

The most common implementation failure is an identifier mismatch. If the training interaction uses a WooCommerce post ID, the catalog import uses a SKU, and the runtime request uses a variation ID, Amazon Personalize cannot establish the intended relationship.

Choose one canonical identifier and use it in all three places:

The interactions dataset.
The items dataset and any catalog import.
The item ID sent to the recommendation campaign.

Maintain a separate mapping table if the storefront needs to display a parent product while the model uses a variation. Do not silently change identifiers when products are migrated between environments.

Build the WooCommerce request flow

A reliable architecture keeps AWS credentials and recommendation calls on the server. When a product page or cart is rendered, WooCommerce can request recommendations from a custom endpoint or from a server-side integration layer. That layer calls Amazon Personalize, filters the response, and returns product data suitable for the storefront.

A typical product-page flow is:

Read the current product’s canonical recommendation ID.
Check a short-lived cache keyed by site, product ID, model version, locale, and currency.
Call the Amazon Personalize campaign only on a cache miss.
Remove the current product, unavailable products, restricted products, and products already in the cart.
Resolve the remaining IDs through WooCommerce product queries.
Return a fixed number of renderable products, preserving the recommendation order.

For a cart-based module, send one recommendation request for each meaningful cart item and merge the responses, or use a separately designed cart recommendation service. A single request based only on the last-added item can produce unstable results when the cart contains several products.

Example server-side request

&lt;?php
$response = $personalizeRuntime-&gt;getRecommendations([
    'campaignArn' =&gt; $campaign_arn,
    'itemId' =&gt; (string) $canonical_item_id,
    'numResults' =&gt; 12,
    'context' =&gt; [
        'site' =&gt; get_current_blog_id(),
        'currency' =&gt; get_woocommerce_currency(),
        'locale' =&gt; determine_locale(),
    ],
]);

$recommended_ids = array_map(
    static fn ($item) =&gt; (string) $item['itemId'],
    $response['itemList'] ?? []
);

The exact SDK method and supported request fields depend on the AWS SDK version and campaign configuration. Treat contextual fields as optional only when the deployed solution supports them; do not add arbitrary fields and assume they influence ranking.

Apply WooCommerce merchandising rules after ranking

Personalization should rank eligible candidates, not override basic commerce rules. Before displaying a recommendation, verify that the product:

Still exists and is published.
Is purchasable in the current channel, country, and customer segment.
Is in stock or backorderable according to the store policy.
Is not the source product or an item already present in the cart.
Has a valid price, permalink, image, and required product data.
Is not excluded by brand, category, subscription, age, or regulatory rules.

Use a fallback when fewer than the requested number of candidates survive filtering. A deterministic category-based or manually curated set is preferable to leaving a large blank area in the product template. Log the reason for every filtered item so merchandising teams can distinguish model quality from catalog problems.

Handle cold start and sparse purchase data

Frequently bought together recommendations need enough co-purchase history to form useful relationships. New products, low-volume catalogs, and products sold mostly as one-off purchases will produce sparse or empty results.

Use layered fallbacks:

Frequently bought together recommendations for products with sufficient purchase history.
Curated cross-sells configured in WooCommerce for strategic products.
Category, brand, or compatibility-based recommendations when no trained relationship is available.
A site-wide bestseller or merchandising set only as a final fallback.

Make the fallback explicit in application telemetry. A recommendation response with no items, a response filtered because products are unavailable, and a model response with low confidence are operationally different situations.

Prevent duplicate and misleading purchase events

WooCommerce order status transitions can fire more than once. A payment retry, webhook replay, administrative status change, or subscription renewal may cause duplicate ingestion unless the integration is idempotent.

Persist an event key based on the order ID, line-item ID, event type, and relevant version of the integration. Mark the key as submitted only after the ingestion request succeeds, and make retries safe. For refunds and cancellations, decide whether the training pipeline excludes those lines during export or sends a separate business event. Do not count a failed or cancelled order as a completed purchase merely because an order record was created.

Cache carefully

Item-to-item recommendations are usually suitable for short-lived caching because the same product page receives repeated requests. Cache the ranked item IDs rather than rendered HTML when price, stock, tax, or customer-specific eligibility can change frequently. Resolve current WooCommerce product data at render time or use a cache invalidation strategy tied to catalog updates.

Include the following in the cache key when they affect the result:

Canonical item ID.
Amazon Personalize campaign or model version.
Site, language, and currency.
Customer segment or channel, if supported by the implementation.
Relevant catalog or merchandising rule version.

Set timeouts and a graceful fallback for Amazon Personalize failures. The product page should remain usable if the recommendation service is slow or unavailable.

Measure the module as a commerce feature

Track impressions, rendered recommendations, clicks, add-to-cart actions, purchases, revenue, and position. Record the recommendation source, such as personalize_fbt, curated_cross_sell, or category_fallback.

Measure more than click-through rate. Useful metrics include attach rate, average order value, revenue per eligible session, conversion rate for shoppers exposed to the module, and the percentage of requests that return at least one eligible product. Compare against a control group or an existing cross-sell implementation when possible.

When a shopper clicks a recommended product, capture the recommendation context so the resulting purchase can be attributed to the module. Keep the model-training event stream separate from analytics attribution: the former describes customer behavior, while the latter describes how the storefront influenced that behavior.

Operational checklist for agencies

Confirm that completed-order events, not only page views, reach the training pipeline.
Verify that product IDs match across WooCommerce, the items dataset, and runtime requests.
Test parent and variation products with real catalog fixtures.
Validate stock, visibility, price, tax, customer-role, and geographic filtering.
Test duplicate webhooks, payment retries, refunds, and cancelled orders.
Monitor Amazon Personalize latency, throttling, empty responses, and campaign errors.
Provide a deterministic fallback for cold-start and unavailable-product cases.
Run an experiment before replacing existing WooCommerce cross-sells across the entire store.

Table of contents :