The Silent Salesperson: How to Optimize Your Magento 2 Product Filters for Conversion

Place a minimal module.xml under etc/module.xml to enable the module. I won’t paste the boilerplate here — most Magento devs already have a module template. The important parts are the PHP classes we’ll add next.

2) Add a small observer to inject the filter into the category product collection

We hook into the catalog layer to alter the collection when the request contains our filter param (for example: stock_status=1).

// etc/frontend/events.xml
<event name="catalog_block_product_list_collection">
  <observer name="vendor_stockfilter_apply" instance="Vendor\StockFilter\Observer\ApplyStockFilter" />
</event>

// Observer: Vendor/StockFilter/Observer/ApplyStockFilter.php
namespace Vendor\StockFilter\Observer;

use Magento\Framework\Event\ObserverInterface;
use Magento\Framework\Event\Observer;

class ApplyStockFilter implements ObserverInterface
{
    protected $request;
    public function __construct(\Magento\Framework\App\RequestInterface $request)
    {
        $this->request = $request;
    }

    public function execute(Observer $observer)
    {
        $collection = $observer->getEvent()->getCollection();
        $stockParam = $this->request->getParam('stock_status');
        if ($stockParam == '1') {
            // Join cataloginventory_stock_status table and filter by stock_status = 1
            $connection = $collection->getConnection();
            $select = $collection->getSelect();
            $stockTable = $collection->getTable('cataloginventory_stock_status');

            // be careful with table aliases to avoid duplicate joins
            $select->joinLeft(
                ['stock_status' => $stockTable],
                'e.entity_id = stock_status.product_id',
                []
            )->where('stock_status.stock_status = ?', 1);
        }
    }
}

Notes:

• This works for stores without MSI (Multi-Source Inventory) or where you rely on cataloginventory_stock_status. If you use MSI, the join/table set is different (see the MSI section below).
• We’re changing the SQL layer early so the layer navigation pagination and counts stay consistent.

3) Add the front-end toggle

A simple checkbox on the category toolbar can add the query param and reload the listing. Ideally, use AJAX, but start simple:

<!-- in catalog/product/list.phtml or a block template you inject -->
<form id="stock-filter-form" action="" method="get">
  <label>
    <input type="checkbox" name="stock_status" value="1" <?php if ($block->getRequest()->getParam('stock_status')=='1') echo 'checked' ;?>>
    In stock only
  </label>
  <button type="submit">Apply</button>
</form>

For better UX, add JavaScript to rewrite and preserve existing query parameters so applying the stock filter doesn’t remove category, attributes, or sort params.

4) Maintain filter state and SEO concerns

Make sure filtered pages are not indexed in a way that creates huge spider traps. Use canonical tags or robots directives if you produce many parameter combinations. For "In stock only" it's usually safe to allow indexation if it meaningfully changes user experience, but exercise caution on large catalogs. Consider:

• Use rel="canonical" on parameterized pages pointing to the category base (if filtered pages add little SEO value).
• Or add the filter value into the canonical if the filtered result is a persistent, useful landing page (e.g., "clearance" + "in stock").

Handling MSI (Multi-Source Inventory) in Magento 2.3+

MSI changes how inventory is stored. Instead of a single cataloginventory_stock_status, you may need to check the inventory_stock_* views or use Magento Inventory APIs. A robust approach is to use the StockRegistry or search criteria against the Inventory source and join the stock index table used for storefront queries (like inventory_stock_1 view).

Example (simplified):

// For MSI shops you can use the stock index table alias such as inventory_stock_1
$stockIndex = $collection->getTable('inventory_stock_1');
$select->joinLeft(
    ['stock_idx' => $stockIndex],
    'e.entity_id = stock_idx.product_id',
    []
)->where('stock_idx.is_salable = ?', 1);

To be safe, detect the presence of MSI and the correct index table at runtime rather than hard-coding names.

Advanced filtering techniques: combining stock status, categories and custom attributes

The real magic happens when filters act together. Here are patterns that convert well:

• Default “in stock” during promotions: Temporarily set the category page to only show in-stock items so users don’t bookmark out-of-stock offers.
• Priority stacking: When users select multiple filters, give precedence to stock status + shipping availability first, then attribute filters. This prevents showing a product that matches attributes but is unavailable.
• Attribute weighting: Use analytics to see which attributes lead to purchases and highlight them (position them higher in the UI) when stock for those SKUs is high.
• Bundled filters: Create combined pre-defined filters like “Under $100 — In stock — Fast ship” to help shoppers land on high-converting sets quickly.

Code example: programmatically apply combined filters

// Compose filters in an observer or block before collection load
$collection->addAttributeToFilter('color', ['in' => ['red','blue']]);
$collection->addAttributeToFilter('price', ['lteq' => 100]);
// stock join as earlier
$select = $collection->getSelect();
$select->joinLeft(
    ['stock_status' => $collection->getTable('cataloginventory_stock_status')],
    'e.entity_id = stock_status.product_id',
    []
)->where('stock_status.stock_status = ?', 1);

Keep conditions indexed-friendly (avoid non-SARGable constructs) and reuse Magento product attribute indexes to maintain performance.

Case study: Force Product Stock Status to create smart “In stock only” filters

Extensions that let you force a product's stock status (for example to mark certain SKUs as always in stock for marketing or bundling reasons) are a practical tool in your toolkit. Here's how to use such a capability responsibly:

1. Identify SKUs that should be artificially set to “in stock” (e.g., drop-shipped items you can source quickly or virtual products bundled with services).
2. Use the extension settings to mark those SKUs as "forced in stock" instead of changing the real inventory quantity — this prevents inventory tracking issues while enabling storefront availability.
3. Expose these flagged SKUs in a separate filter or a combined filter: e.g., "In stock or Force-available" so customers can understand the difference if necessary.
4. On the product page, surface the fulfillment note: “Usually ships in 2 days (forced in stock)” to keep expectations clear.

Important caveat: forcing products as in stock must match the operational reality — using it on a large scale without proper supply processes will create customer service problems.

Performance considerations

Filters touch collections and SQL. Badly implemented filters slow down category pages. Keep an eye on:

• Query complexity: avoid joining many large tables on every request.
• Indexes: make sure the stock index table is used and you don’t force full table scans.
• Cache: use full-page cache and Varnish; cache results for popular filter combinations (e.g., category + in-stock + price bucket) and serve cached HTML whenever possible.
• AJAX approach: for mobile and interactive experiences, fetch filtered blocks via AJAX and let the FPC cache the unfiltered shell.

UX tips that actually increase conversion

• Show counts next to filter options (e.g., In stock (112)). That immediate feedback sets expectations.
• Offer an “In stock only” quick toggle in the toolbar and keep it sticky across categories.
• When combining filters produces zero results, offer “Notify me” or show close matches instead of a dead end.
• Label forced-in-stock SKUs clearly on product cards so shoppers understand any special fulfillment conditions.

Measuring the impact: how to prove filters move revenue

Measurements are crucial. Here are concrete steps and event ideas you can implement quickly to quantify the effect of optimized filters on conversions.

1) Track filter application events

Use Google Tag Manager (GTM) and the dataLayer to push an event whenever a customer applies a filter. Example dataLayer push:

dataLayer.push({
  'event': 'magefine_filter_applied',
  'filterName': 'stock_status',
  'filterValue': 'in_stock'
});

Create GA4 custom events or Universal Analytics events to capture: filterName, filterValue, categoryId, and the number of products returned. In GA4, define custom dimensions for filterName/filterValue so you can segment funnels by users who used the stock filter.

2) Measure downstream KPIs

• Rate of Add-to-Cart after filter application: count add-to-cart events within the same session and pageview after a filter event.
• Conversion rate differences: compare sessions with filter applied vs. sessions without.
• Average order value for filter users: segment revenue by the filter custom dimension.
• Cart abandonment after applying the filter: do users who apply stock filters stick around?

3) A/B testing filters

Use an A/B testing tool (e.g., Google Optimize, VWO) or server-side experimentation to compare default views (all products visible) vs. stock-limited defaults (in-stock-only). Run the test for several thousand sessions or until statistical significance. Track revenue-per-user and add-to-cart rates as primary metrics.

4) Build a simple SQL report

If you have a data warehouse or can query Magento DB & analytics data, create a report that joins sessions where the filter param exists with orders to compute conversion:

-- pseudo SQL
SELECT
  f.filter_value,
  COUNT(DISTINCT s.session_id) AS sessions,
  SUM(o.grand_total) AS revenue,
  SUM(CASE WHEN o.entity_id IS NOT NULL THEN 1 ELSE 0 END) as orders
FROM
  analytics_sessions s
LEFT JOIN analytics_events e ON e.session_id = s.session_id AND e.event_name = 'magefine_filter_applied'
LEFT JOIN sales_order o ON o.session_id = s.session_id
GROUP BY f.filter_value;

Start small: even simple GA custom reports can show you if “In stock only” improves conversion.

SEO and indexation best practices for filtered pages

Filters can create huge parameter spaces. For SEO and crawl budget:

• Disallow benign but infinite combos in robots.txt or use parameter handling in Google Search Console.
• Decide which combinations are worth indexing. For example, category + brand + in-stock might be useful; random attribute permutations usually are not.
• Use rel=canonical wisely: either canonicalize parameter pages to the base category or to a canonical that reflects the most relevant view.
• Consider server-side rendering for critical filtered landing pages for SEO, and use structured data when appropriate.

Operational tips for merchandising with filters

• Run weekly reports of best-selling filters and stock levels. If high-converting filters drive sales, prioritize stocking those SKUs.
• Communicate with merchandising: highlight which attribute-filter combos produce high AOV and push campaigns around those.
• Use forced-in-stock sparingly and only when supply chain fulfills reliably — ticket spikes from broken promises destroy trust.

Common pitfalls and how to avoid them

• Too many filters: overwhelms users. Focus on conversion-driving attributes.
• Poor performance: always test filters under realistic load and use DB explain plans to identify slow queries.
• Broken counts: if counts shown next to filters are expensive to calculate, they may be stale. Consider precomputing counts during low-traffic windows for large catalogs.
• User confusion about forced availability: be transparent about which SKUs are forced-in-stock and what that means.

Putting it all together: an optimization checklist

1. Audit current filters: list attributes, counts, and their conversion performance.
2. Make stock status filter visible and usable: add toggle + counts.
3. Implement backend filter safely (use joins on stock index for performance, detect MSI).
4. Track filter usage with GTM/dataLayer and tie to revenue.
5. Run A/B tests for default behaviors (in-stock-first vs. all products).
6. Optimize caching and precompute heavy counts where possible.
7. Document forced-in-stock policies and use them only when supported by operations.

Sample checklist for a release

Before you push a filter change to production:

• Unit test the product collection modifications.
• Smoke test on a staging mirror with realistic inventory and MSI config.
• Check SQL explain on category + stock query; ensure indexes are used.
• Verify FPC/varnish behavior and that the filter toggle does not unintentionally bust caches unnecessarily.
• Deploy GTM dataLayer changes and verify events in GA real-time.

Final thoughts — make filters part of your conversion strategy

Filters are not a “nice-to-have” UI flourish; they’re a conversion lever. When you treat stock status as a strategic filter and combine it sensibly with categories and high-impact attributes, you make it far easier for customers to find and buy what’s actually available. Use data to decide which filters matter, instrument them for analytics, and don’t be afraid to experiment with defaults like "In stock only" during promotions. If you have an extension like Force Product Stock Status available, use it to help present accurate availability while maintaining operational sanity.

Quick reference: code snippets and resources

Here are the key snippets from above that you can copy into your module as a starting point:

// Observer join example (core idea)
$select = $collection->getSelect();
$stockTable = $collection->getTable('cataloginventory_stock_status');
$select->joinLeft(['stock_status' => $stockTable], 'e.entity_id = stock_status.product_id', [])
       ->where('stock_status.stock_status = ?', 1);

// Front-end quick form
<form id="stock-filter-form" action="" method="get">
  <label>
    <input type="checkbox" name="stock_status" value="1">In stock only
  </label>
  <button type="submit">Apply</button>
</form>

// dataLayer push
dataLayer.push({
  'event': 'magefine_filter_applied',
  'filterName': 'stock_status',
  'filterValue': 'in_stock'
});

If you want help

If you’d like, I can:

• Draft a ready-to-install module with MSI support detection and a toggle for in-stock filtering.
• Create a GTM container snippet to capture filter events and wire them into GA4.
• Sketch an A/B experiment plan and a SQL report for measuring impact.

Tell me which one you want first and I’ll prepare the next steps with code and deployment notes.

— a colleague who’s done too many filter PRs