Relewise integration for ecommerce search and discovery

Facet decisions are owned jointly by category merchandisers, PIM teams and search operations. PIM defines which attributes are available, but search merchandisers choose which are indexed as facets based on shopper intent and conversion performance. This decision is reviewed as part of your facet governance cycle, not delegated to Relewise configuration alone.

iWeb instruments index freshness monitoring that compares the timestamp of the last successful catalogue feed to the current time. Alerts fire when the index is older than your defined SLA (e.g. more than 2 hours stale). Staleness is also visible in your BI platform so merchandisers can check before a promotion launches.

We build a fallback search mode into your storefront that routes to native platform search, alphabetic sort, or cached results. The fallback is transparent to shoppers but visible to operations via a fallback trigger log. This prevents checkout from breaking and gives you time to restore Relewise.

Synonyms and ranking rules are maintained independently from the catalogue in Relewise. Changes take effect immediately without requiring a reindex or catalogue feed. However, your teams must have a change governance process so that rule updates are tested and approved before going live.

Yes. Relewise allows you to create multiple rule versions and route a percentage of traffic to each, measuring conversion, click-through and engagement separately. Rule A/B tests are independent of catalogue releases and can be run continuously to optimize merchandising.

A zero-results query is a search that returns no matching products. These are intent signals that your catalogue or facets do not address. We set up logging and redirection rules so merchandisers can route zero-results to a category or apply a synonym before shoppers abandon. Without visibility, zero-results opportunities are lost.

Channel-specific attributes (e.g. marketplace readiness, channel pricing flags) are included in the catalogue feed with channel identifiers. Relewise creates channel-specific indices or facets based on these flags, so each channel sees only attributes it is ready to merchandise. This requires that your PIM tracks channel readiness for each attribute.

iWeb designs the feed schedule (e.g. full feed nightly, delta feed every 2 hours) based on your merchandising cycle and product change velocity. The schedule is owned by operations and monitored continuously. Manual refreshes can be triggered by PIM or ecommerce teams if urgent changes are needed.

Key metrics include: search query volume, click-through rate by query, zero-results rate, facet usage, result abandonment, average time to purchase after search, and conversion rate by top queries. iWeb helps you define performance budgets and set up dashboards in your BI platform so merchandisers can optimize continuously.

Facet cardinality (the number of unique values) directly impacts search latency. iWeb works with your search team to prune low-traffic facets and set cardinality limits per attribute. Performance budgets are defined and monitored; if facet load times exceed your SLA, we alert and trigger a review with merchandisers.

Relewise can filter by stock flags that are included in the catalogue feed (e.g. in-stock, low-stock, out-of-stock). However, real-time stock movements from your WMS must be fed back into the search index via scheduled catalogue refreshes or a dedicated stock API. Without continuous stock sync, stock filters will lag live inventory by the feed interval.

The attribute-to-facet mapping is a shared governance decision. PIM owns attribute definitions and channel readiness; search merchandisers own facet definitions and ordering. iWeb documents this mapping in your integration runbook and tracks changes as part of your product data governance.

We establish a change governance process where synonyms and rules are reviewed by a named merchandiser or operations team before publication. Changes are versioned and can be rolled back if they cause unexpected regressions. We log all rule changes and monitor search performance metrics to detect conflicts automatically.

iWeb implements validation rules that check for required attributes, facet cardinality limits, image availability and channel readiness flags. Validation errors are logged separately from the index feed, so bad records can be rejected without blocking the entire index refresh.