Purchases Can Teach Your Store What to Recommend

A product page can recommend items from catalog rules, merchandising preferences, or shared attributes. A stronger signal often comes from what customers actually buy together. If shoppers regularly purchase a laptop sleeve with a specific laptop, or replacement filters with a particular appliance, those completed orders reveal relationships that product attributes alone may not capture.

For WooCommerce agencies, the opportunity is to turn order history into a controlled recommendation signal and make that signal available to the store’s search and discovery experience through WPSOLR.

Use completed orders as behavioral evidence

Start with paid and completed orders rather than every cart event. A cart can represent intent, but a completed order confirms that the relationship survived checkout. For each order, treat the purchased products as a set and record product pairs or product-to-category relationships.

For example, an order containing products 101, 205, and 310 produces these undirected pairs:

101 and 205
101 and 310
205 and 310

Across many orders, count how often each pair occurs. A simple score can be calculated as:

co_purchase_score = pair_orders / orders_containing_source_product

This normalizes the result. A pair purchased 40 times is not necessarily stronger than a pair purchased 20 times if the first product appears in thousands of orders and the second appears in only a few dozen.

Filter the order data before building relationships

Raw order data needs business rules. An agency implementation should decide:

Which statuses count as a completed purchase, such as processing and completed.
Whether refunded, cancelled, failed, or fully returned items are removed from the calculation.
Whether variations are treated as separate products or grouped under the parent product.
Whether subscriptions, bundles, gifts, and automatically added items should be excluded.
How many orders are required before a relationship becomes eligible for display.
How recent purchases should be, using a rolling period when product assortments change frequently.

These rules prevent recommendations from being dominated by one promotion, a bundle component, or an item that is no longer available.

Build a recommendation table instead of modifying product content

Do not overwrite the product description or permanently alter the catalog whenever a new relationship is found. Store the result separately so it can be recalculated, reviewed, and removed.

A useful custom table might contain:

source_product_id: the product receiving the recommendation.
recommended_product_id: the product to display.
order_count: the number of qualifying orders containing both products.
confidence: the proportion of source-product orders that also contain the recommended product.
last_calculated_at: the timestamp for operational monitoring.
expires_at: an optional date for seasonal or temporary relationships.

Keep this data separate from WooCommerce order tables. Orders remain the source of truth, while the recommendation table is a derived dataset that can be rebuilt by a scheduled job.

Make the signal useful to WPSOLR

WPSOLR can provide the search and faceting layer that helps shoppers discover products. The purchase relationship can support that layer in several ways, depending on the WPSOLR configuration and extensions used by the store:

Index a recommendation flag or score as product metadata.
Expose co-purchased products in a related-products component on product pages.
Use the relationship to prioritize eligible products in an associated-product query.
Combine purchase strength with stock, catalog visibility, category, and merchandising rules.
Use purchase-derived terms or categories to improve discovery when a shopper searches for a product family.

The important implementation detail is that recommendation data must be synchronized after it changes. If the derived score is stored as product metadata or a custom indexed field, trigger the appropriate WPSOLR indexing process after the calculation. A recommendation that exists in the database but not in the search index cannot affect the storefront.

Example: calculate relationships with WooCommerce order APIs

For a moderate catalog, a scheduled PHP process can retrieve qualifying orders through WooCommerce APIs, collect product IDs, and aggregate pairs. The exact implementation should use batching and persistent storage rather than loading the entire order history into memory.

<?php
$orders = wc_get_orders([
    'status' => ['processing', 'completed'],
    'limit'  => 200,
    'return' => 'objects',
]);

$pairCounts = [];

foreach ($orders as $order) {
    $productIds = [];

    foreach ($order->get_items('line_item') as $item) {
        $productId = (int) $item->get_product_id();

        if ($productId > 0) {
            $productIds[$productId] = true;
        }
    }

    $productIds = array_keys($productIds);
    sort($productIds);

    foreach ($productIds as $sourceIndex => $sourceId) {
        foreach (array_slice($productIds, $sourceIndex + 1) as $targetId) {
            $key = $sourceId . ':' . $targetId;
            $pairCounts[$key] = ($pairCounts[$key] ?? 0) + 1;
        }
    }
}

This example demonstrates the pair-generation step only. A production job should paginate through all relevant orders, persist intermediate results, account for refunds and returns, apply a minimum-count threshold, and write both directions of the relationship when recommendations are shown from either product.

Combine behavior with operational constraints

Purchase frequency should not be the only ranking factor. Before a recommendation reaches the customer, apply constraints such as:

The recommended product is published and catalog-visible.
The product is in stock, unless backorders are intentionally supported.
The product is not the same product as the source item.
The product is permitted for the customer’s region, channel, and price list.
The product is not excluded by brand, category, or campaign rules.
The recommendation does not duplicate a bundle or an item already selected in the current cart.

A practical ranking formula can combine normalized purchase confidence with recency and business controls:

final_score = (0.60 * purchase_confidence)
            + (0.20 * purchase_recency)
            + (0.20 * merchandising_priority)

Keep these weights configurable. A store with rapidly changing inventory may need a stronger recency factor, while a replacement-parts catalog may benefit from stable historical relationships.

Use different recommendation contexts

The same purchase relationship can be useful in more than one location, but the presentation should match the customer’s intent.

Product pages

Show products frequently purchased with the viewed product. Limit the block to a small number of in-stock items and label it clearly, such as “Frequently purchased together.”

Search results

If a shopper searches for a main product, use the relationship to surface compatible accessories or replenishment items without allowing the related products to displace exact matches.

Cart and checkout

Recommend a missing companion item only when it can be added without disrupting the checkout flow. Avoid showing products that the customer already owns in the current cart or that conflict with selected variations.

Post-purchase messages

For consumables and replacement parts, the order can start a future recommendation workflow. The timing should come from expected replenishment intervals, not simply from the date of the last order.

Protect customer privacy and recommendation quality

Purchase relationships should be aggregated before they are used for storefront recommendations. Do not expose individual customer identities, order numbers, or personal purchase histories in the recommendation payload. Review the store’s privacy policy, retention requirements, consent model, and applicable data-protection obligations before using order data for personalization.

Also monitor for misleading associations. A product pair can appear frequently because of a one-time clearance event, a staff purchasing pattern, or a mandatory bundle. Set minimum sample sizes, cap the number of recommendations per product, and give merchants an override for exclusions and preferred products.

Measure the automation

Track recommendation impressions, clicks, add-to-cart events, assisted revenue, and conversion rate separately from ordinary product-page performance. Compare the purchase-driven block with a control group or an existing rule-based block.

Useful agency-level checks include:

Percentage of visible recommendations that are in stock.
Percentage of products with enough order history to generate recommendations.
Average age of the data behind each recommendation.
Click-through and add-to-cart rates by placement.
Revenue per recommendation impression.
Products receiving recommendations that merchants have explicitly excluded.

Schedule the aggregation job during a low-traffic period, index the resulting fields through the store’s normal WPSOLR synchronization process, and alert the team when the job fails or the indexed recommendation count drops unexpectedly. This turns completed purchases into a repeatable discovery input without making the catalog dependent on manual cross-selling updates.

Table of contents :