The Problem with Database Queries

Your product database (PostgreSQL, MySQL, or whatever you use) is optimized for transactional queries, not search. When a user types “blue running shoes,” your database searches through millions of product records, matching keywords in title and description. This takes 500ms–2 seconds. By then, your user has moved on or tried a competitor’s site.

Additionally, database search doesn’t understand relevance. It returns results based on exact matches or basic keyword scoring. A product titled “Running Shoes Blue Men’s Nike” might rank below “Blue Shoes” just because of word order. No intelligence about what customers actually want.

The Problem with Elasticsearch

Elasticsearch is powerful, but it’s a data warehouse. You have to manage it yourself: provision servers, configure clusters, handle sharding, optimize queries, upgrade versions, debug performance issues. Building production search on Elasticsearch requires:

• DevOps expertise to run it reliably
• Search engineers to tune relevance
• Monitoring and alerting infrastructure
• Scaling logic as your catalog grows
• Security hardening to prevent leaks

Most teams underestimate the operational overhead. A small team managing Elasticsearch often spends 30–40% of engineering time on search infrastructure instead of product features.

Our Approach: We’ve already solved the operational and relevance problems for you. We maintain the infrastructure, scale it globally, and provide intelligent ranking out-of-the-box.

If your inventory updates but search results are stale, customers see out-of-stock products or miss new arrivals. Manual reindexing (rebuild the entire search index nightly) causes hours of stale data. Real-time sync is essential but complex.

How We Solve It: Real-Time API Updates (Fastest) Every time a product changes in your commerce platform, push an update to us immediately.

Product is indexed within 500ms. New inventory levels, prices, and availability are reflected in search immediately.

Scheduled Batch Sync (Flexible) If you prefer, sync your entire catalog once daily or every hour. We pull from your API or database, diff against the current index, and update only what changed. Full catalog syncs take seconds, even for 1M+ products.

Webhook Integration (Automatic) If your commerce platform (Shopify, BigCommerce, SAP) sends webhooks when products change, we can listen directly:

• Product created → indexed immediately
• Product price changed → updated in index
• Inventory changed → search facets update
• Product deleted → removed from index

Inventory Management Out-of-stock handling is configurable:

• Option 1: Don’t show out-of-stock products in search
• Option 2: Show them at the bottom of results with a “notify me” button
• Option 3: Show them but with a “coming soon” badge

You decide based on your business strategy.

What About Historical Data? If you’re switching from another search system, we can backfill historical data: bulk import your entire catalog in one go. Then set up real-time sync for ongoing updates. First import takes 15–30 minutes for 500K products; after that, only changes are synced.

Slow search kills conversion. Studies show:

• Every 100ms of latency increase = 1% conversion loss
• Users who search convert 2–3x better than category browsers (if search is good)
• Poor search results → users try a different site

Our customers typically see these improvements:

You can track anything: wishlist adds, email signups, loyalty program joins, category sales mix. Tag them as custom conversion events; we’ll show you how search impacts them.

Yes, unlimited customization. No coding required for many use cases.

Here’s What You Can Do:

• Merchandising Rules (Boost/Bury Products)
  • Example 1: Seasonal Merchandising; During Q4 (holidays), you want to boost gift sets and bundles: IF season = “Q4” AND category = “gifts”THEN boost(weight = 1.5)
  • Example 2: Inventory-Based Merchandising; You have overstock of winter coats from last season. Boost them during clearance: IF inventory > 500 AND price < cost * 1.2 THEN boost(weight = 1.3)
  • Example 3: Margin-Based Ranking; Your electronics have 5–30% margins. Boost high-margin items: IF margin > 25% THEN boost(weight = 1.2)
  • Example 4: Bury Competitor Products; You sell electronics. You don’t want to show competitor brands prominently (you just stock them as filler). Bury them: IF brand IN [“Competitor_A”, “Competitor_B”]THEN bury(weight = 0.5)
• Ranking Customization (Adjust the Algorithm). Our default ranking considers:
  • Relevance (40%): How well does the product match the search query?
  • Popularity (30%): Sales volume, reviews, velocity
  • Inventory (15%): Prefer in-stock products
  • Business Rules (15%): Margins, promotions, merchandising
• You can adjust these weights via dashboard without touching code
• Different strategies for different customer segments:

• Personalized Ranking. Tailor search results per user based on behavior: IF customer_has_viewed_brand = “Nike”AND customer_purchase_history = “athletic” THEN boost(Nike_products, weight = 1.3). Results for a “running shoe” search:
  • User 1 (Nike fan): Nike shoes rank #1–3
  • User 2 (Adidas fan): Adidas shoes rank #1–3
  • Both still see relevant shoes overall, but their preferences are honored
• Typo Handling. Allow flexible typo tolerance. You decide how strict:
  • Strict (0 typos allowed): Exact matches only
  • Moderate (1–2 typos allowed): “Runnning shoe” finds “Running shoe”
  • Permissive (3+ typos allowed): “Bleu chees” finds “Blue Cheese”
• Price Range Boosts. For price-sensitive queries, boost mid-range products: IF query = “budget” OR query = “affordable”THEN boost(products WHERE price < $50, weight = 1.4)

If you sell globally, your product catalog probably has multiple languages, regional variations, and currency differences. A search query in French should return French-language results and handle French grammar/accents. A German customer searching for “Schuh” should get shoes. This is complex. We support 50+ languages natively.