5 Operational Policies to Establish Before Developing an AI-Powered E-Commerce Search Engine

AI can quickly create product listing APIs, search bars, and sorting buttons. However, which products to display, which to hide, and what to label as “recommendations” are determined by operational policies, not code. E-commerce search is not merely a lookup function; it is a decision-making system that integrates shelf placement, ad space allocation, inventory management, customer experience, and data collection all in one place.

If you simply instruct the AI to “build a product search feature” without providing specific policies, it may arbitrarily fill in familiar examples such as sorting by most recently added, partial product name matches, or simple pagination. Even if the code runs, it may not align with store operations. Typical issues include the latest products appearing at the top even when they’re out of stock, discontinued items being added to shopping carts, and customers failing to find “Cheongsong Busa” apples even when they search for “apples.”

Search Ranking Is an Operational Policy, Not a Technical Feature

Merchants can design the order in which products are displayed. However, if the meaning conveyed to consumers on the screen does not align with the actual ranking calculation method, or if sponsored listings with economic interests are made to appear like general recommendations, the legal and trust-related risks increase significantly.

In June 2024, the Korea Fair Trade Commission (KFTC) announced a provisional fine of 140 billion won against Coupang and CPLB for issues related to search ranking operations and the posting of purchase reviews by executives and employees; based on the resolution issued in August of the same year, the fine was set at 162.8 billion won. The companies contested the decision, and as of April 2026, the related lawsuit seeking to overturn the ruling was still pending. The practical lesson from this case is not simply the proposition that “favoring one’s own products is always illegal.” It is essential to review at the design stage what the “recommendation” label actually means, whether advertising and the company’s vested interests are clearly disclosed, and whether changes in rankings can be explained with data and documentation.

Since the application of the law can vary depending on the service structure and display methods, it is safest to separately verify relevant laws and the latest enforcement precedents before the actual launch.

The Pitfalls of a “Quick-and-Dirty Version” Created by a One-Line Prompt

AI can fill in the gaps in requirements, but it cannot determine whether those choices align with the store’s strategy and legal responsibilities. Therefore, at least the following five policies must be documented and finalized before implementation.

1. Default Sorting: What Will Be Considered “Recommended Order”?

The default sorting order is the display customers see first. Since most users do not change the sorting options, the default setting directly impacts sales, inventory depletion, new product promotion, and customer satisfaction.

First, Separate the Ranking Calculation Steps

It is safer to divide search results into the following steps rather than calculating them all at once.

1. Eligibility Check: Include only products that are available for sale, publicly viewable, and not subject to legal or operational restrictions.
2. Calculate Search Relevance: Calculate how well the product name, brand, category, attributes, and synonyms match the search query.
3. Calculate Organic Ranking: Combine signals such as sales velocity, conversion rate, rating reliability, and delivery quality.
4. Application of Business Rules: Apply penalties for out-of-stock items, prioritize new product discovery opportunities, and enforce diversity limits.
5. Ad Slot Integration: Insert ad products separately from organic rankings and clearly label them.
6. Stable Tie-Breaking: When scores are tied, order is determined using a fixed key such as product_id.

The recommendation score must be a documented formula

The following is merely an example to illustrate the structure; it is not a one-size-fits-all solution for every online store.

organic_score =
  0.45 × query_relevance
+ 0.20 × conversion_rate_28d
+ 0.15 × sales_velocity_14d
+ 0.10 × rating_confidence
+ 0.10 × fulfillment_quality

Each signal must be normalized to the same range, and the time period and aggregation scope must be specified. Since a simple average rating could make a product with a single 5-star review appear higher-rated than a product with 1,000 reviews averaging 4.8 stars, it is better to use a weighted score that accounts for the number of reviews. Using only sales volume could give products that have been on the market for a long time a permanent advantage, so we also consider recent sales velocity and conversion rates.

Essential Details to Define

• Which of the following is the goal of the recommendation ranking: search relevance, purchase likelihood, customer satisfaction, or inventory efficiency
• The aggregation period and update frequency for each signal
• Negative signals such as cancellation rates, return rates, shipping delays, and the likelihood of being out of stock
• The exploration opportunities and maximum bonus points to be granted to new products with few reviews
• Diversity rules to prevent a single brand or seller from excessively dominating the top of the rankings
• A fixed sorting key to use in case of tied scores
• An audit log documenting the version of the ranking formula, reasons for changes, implementation dates, and approvers
• Success metrics and termination conditions for A/B testing

Do not mix paid ads with organic recommendations

While it is acceptable to reflect economic interests—such as advertising spend, whether a product is the company’s own, or high profit margins—it is risky to allow users to mistake this for a general “popularity” or “recommended” ranking. In the 2025 case involving a high-end product sales platform, the Fair Trade Commission took issue with a system where products from sellers who purchased paid options were given priority in the default sorting, as well as the related labeling. As a general rule, advertised products should be managed in separate pools and slots, and clearly identifiable “Ad” or “Sponsored” labels should be provided at the card level. The admin dashboard must display advertising exposure rules and organic ranking algorithms separately.

2. Products in Abnormal States: Out of Stock and Sales Suspension Are Different States

If you handle all exceptions with just is_sold_out, discrepancies will arise between search results, product details, the shopping cart, and order verification. At a minimum, you must separate sales status, inventory status, visibility status, and regulatory status.

Recommended Status Model

Out-of-stock products are valuable for restock notifications and gauging search demand, so they do not need to be deleted unconditionally. On the other hand, discontinued products should be excluded from general listings; however, customers arriving via existing bookmarks or external links can be provided with a “Sales have ended” message and similar products. Whether to retain the product detail URL or return a 410 Gone status should be determined based on search traffic, the need for legal notices, and the value of alternative content.

The search index does not have the final authority on order availability

Search indexes may experience synchronization delays. Therefore, even if search results show that an item is in stock, it must be verified again at the next stage.

• Re-verify sales status and inventory when adding to the cart
• Re-verify price, discounts, and inventory when proceeding to the order form
• Reserve inventory or perform atomic deduction immediately before checkout
• Immediately remove items from the search index when a “Sale Stopped” event occurs
• Monitor indexing latency and failure rates

Without these rules, customer service incidents will recur where the search results appear normal but the order fails only at the checkout stage.

3. List Display Methods: Paginated, “See More,” or Infinite Scroll—Which Should You Use?

If there are thousands or tens of thousands of products, they should not all be loaded at once. However, it is also inaccurate to assume that “numeric pagination is always the right answer for online stores.” In comparison-based searches, restoring position and state is important, while “Load More” may be more convenient for category browsing.

In practice, you can prioritize pagination or “See More + restorable page URLs” for search results, and infinite scroll for discovery-based recommendation feeds. Even when using pure infinite scroll, the following conditions must be met:

• Save the search term, sort order, filters, page number, or cursor position in the URL or in a restorable state
• Restore the previous product and scroll position when navigating back from a detail page
• Support keyboard navigation, screen readers, and focus movement
• Provide accessible alternatives for the footer and primary navigation links
• Provide a UI for loading failures and retries
• Provide an accessible, unique URL or link structure for each result batch

Offset and Cursor Pagination

Deep offsets like OFFSET 5000 LIMIT 40 tend to slow down as the data volume increases and updates become more frequent, and they are prone to duplication andomissions. While offsets are simple for shallow pages and admin screens, the cursor method—which passes the sort key of the last result—is more stable for large-scale searches.

ORDER BY score DESC, product_id DESC
cursor = last_score + last_product_id

Using only the score as the cursor may omit products with tied scores, so a unique key is used in conjunction with it. If recommendation scores change frequently in real time, a policy is also needed to fix a snapshot version or a specific time for the ranking criteria during the search session.

4. Search Scope and “No Results” Page: Linking Customer Queries to Product Data

Customers do not know the exact product names registered by the operator. To show “Cheongsong Busa,” “Hongro,” and “household apples” to a customer searching for “apples,” the product data and search dictionary must be designed together.

Search Field Priorities

For Korean searches, differences in spacing, separation of letters and consonants, brand names in English and Korean, numbers and units, and compound nouns must also be considered. For example, “AirPods Pro 2,” “AirPods Pro 2,” and “AirPods Pro 2” are all mapped to the same product category through normalization rules.

Recommended Search Pipeline

1. Validate input length and allowed characters.
2. Normalize case, spaces, special characters, and units.
3. First, check for an exact match with the product code.
4. Apply tokenization and morphological and spelling variations.
5. Expand the synonym and category dictionaries managed by the operator.
6. Find candidates using text search.
7. If necessary, use semantic search to generate additional candidates.
8. Filter by sales, public availability, and regulatory status.
9. Calculate organic scores and combine them separately with ads.
10. Return results and diagnostic information.

Even when introducing generative AI or vector search, exact matches such as SKUs, brands, and model names must not be compromised. In shopping search, a hybrid approach combining exact search + text relevance + optional semantic search is generally the safest approach. All responses must be linked to actual product IDs and current data to prevent AI from inventing products, prices, or inventory that do not exist in the catalog.

The “No Results” Screen Is Your Second Shelf

When there are no search results, do not simply display a blank screen. However, you should also avoid mixing in unrelated popular products as if they were search results.

The recommended structure is as follows:

• Display the user’s search query exactly as entered and clearly indicate that there are no matching products
• Offer typo correction suggestions and synonym recommendations
• If the count is 0 due to filters, provide guidance on which filters can be removed
• Present results with broader search criteria under a separate label
• Display related categories, alternative products, and all popular products separately
• Include options to request restocking or new listings, or link to customer support
• Log searches with no results in the administrator’s analytics

“No results” and “No results after applying filters” are different issues. If there were originally matching products but the count dropped to zero due to price or color filters, relaxing the filters is the most useful solution; if the product is not in the catalog at all, the data should be used for sourcing purposes.

5. Search History: Manage Market Research Data and Personal Information Together

Search terms that yield no results reveal demand—customers who searched for a product but did not purchase it. Popular search terms help with product display and inventory planning, and the flow from search to clicks, cart additions, and purchases serves as a key metric for evaluating search quality.

However, it cannot be assumed that “simply storing search terms and their frequency never constitutes personal information.” Search terms themselves may contain phone numbers, order numbers, names, or sensitive information such as health, religion, or sexual activity; when combined with account, IP, or device information, the likelihood of identifying or tracking an individual increases significantly.

Recommended Data Collection Items

Even hashed member IDs do not automatically become anonymous information. If they can be linked back to a specific user, they must be treated as pseudonymous information or personal information. Retention periods should not be set uniformly; instead, they should be determined separately for raw data and aggregated data based on purpose, analysis cycle, and security risks.

Metrics Required for the Administrator Dashboard

• Search volume and number of unique search terms
• “No results” rate
• Search result click-through rate
• Cart addition rate and purchase conversion rate following a search
• Search term modification rate and filter removal rate
• Percentage of out-of-stock products displayed
• Concentration of top results and brand diversity
• Metrics that distinguish between the performance of ads and organic results
• Freshness of the search index and number of indexing failures

Since low-frequency raw search terms may contain personal information, it is also useful to display only those items that exceed a minimum aggregation threshold on the administrator’s screen.

Practical Prompt: How to Translate Policies into Code

It is more important to clearly define operational rules than to use a lot of technical jargon. You can fill out the following template to suit your service’s specific context and provide it to the AI.

Please design and implement the product search feature for our online store.

1. Eligibility Criteria
- Include only products that are currently for sale, publicly listed, and not subject to regulatory restrictions in search results.
- Display temporarily out-of-stock items, but rank them lower than in-stock items with the same conditions.
- Hide discontinued products and temporarily suspended products from search results and categories.
- For direct URLs of discontinued products, display a discontinuation notice and alternative products, and remove the purchase button.

2. Default Sorting
- Prioritize relevance to the search term above all else.
- Factor in the conversion rate over the last 28 days, sales velocity over the last 14 days, adjusted rating, and shipping quality.
- Allow each weighting factor to be adjusted via configuration files or administrator policies.
- In the event of a tie, sort reliably in descending order by product_id.
- Do not mix advertised products with organic results; place them in separate slots and label them as “Ads.”

3. List Navigation
- Return 40 items at a time.
- Allow users to restore search terms, sorting, filters, page numbers, or cursor position from the URL.
- When navigating back from a detail page, restore the list and scroll position.
- Use cursor pagination for large result sets.

4. Search Scope
- Give top priority to exact matches for SKUs and model names.
- Search by product name, brand, category, attributes, and synonym tags.
- Handle Korean spacing and variations in brand names between English and Korean.
- If no results are found, display typo suggestions, filter relaxation options, related categories, and alternative recommendations separately.

5. Search Logs
- By default, store only normalized search terms, time ranges, number of results, filters, and aggregated click and purchase metrics.
- Do not store member IDs or IP addresses in search analysis logs.
- Email addresses, phone numbers, and order numbers are masked.
- The retention periods for raw data and aggregated data are set separately.

6. Technical Requirements
- Design the data model, API contract, search index, synchronization method, exception handling, and administrator metrics together.
- Propose indexes that match actual query patterns and explain how to verify execution plans.
- Re-verify status, price, and inventory at the shopping cart and checkout stages even when search indexes are delayed.
- Create scenarios for unit testing, integration testing, performance testing, and accessibility testing.

Before beginning implementation, if there are any decisions that could affect the outcome but were not defined by me, please ask me first, and list any assumptions you’ve made on your own in a separate document.

The last sentence is the key mechanism that transforms the AI from a simple code generator into a requirements review partner. However, do not stop at simply receiving questions; you must reflect the confirmed answers in the policy documents and test conditions.

Implementation Design: Anchor Policies to Data and APIs

Example Data Model

products
- product_id
- sales_status
- stock_status
- visibility_status
- compliance_status
- brand_id
- category_id
- searchable_name
- search_tags
- price
- inventory_quantity
- ranking_feature_version
- updated_at

Do not assign multiple meanings to a single field. For example, if you simply set status = 1, it is unclear whether this means “available for sale,” “publicly visible,” “in stock,” or “pending regulatory approval.” Manage state transitions using a table to define the necessary reviews and events when moving from “draft” to “on sale” or from “on sale” to “discontinued.”

Information to Include in API Responses

• Normalized search terms
• Applied sorting and filters
• Result batches and next cursor
• Number of results or approximate result count
• Out of stock/on sale status badges
• Advertising status and ad copy
• Whether typo correction or search scope expansion was applied
• Search policy version and request ID for tracking

There is no need to expose raw scores—which are internal debugging information—or business-sensitive weights directly to the customer API. Instead, operators must be able to reproduce the ranking path using the request ID.

Design indexes to match actual query patterns

Generally, consider using B-tree-based indexes for columns used in status filters and sorting, and inverted index-based indexes for specialized search documents. In PostgreSQL, you can use tsvector and GIN indexes; if similar string search is required, use pg_trgm. The same principle applies even when using an external search engine.

CREATE INDEX idx_products_visibility
ON products (visibility_status, sales_status, compliance_status);

CREATE INDEX idx_products_search_document
ON products USING GIN (search_document);

The more indexes you create, the higher the write costs and storage requirements. Do not make decisions based on assumptions alone; verify using EXPLAIN ANALYZE, slow query logs, and load testing based on actual queries and data distribution. When the number of products increases, consider not only the average response time but also p95 and p99 latency, timeout rates, and index freshness.

Additional Safeguards When Integrating Generative AI

• Use only catalog API results for product availability, price, inventory, and delivery dates
• Log search term expansions generated by the model alongside the original text, and limit excessive expansions
• Prioritize exact SKU and model name searches over semantic search
• Apply filters for discontinued or recalled products equally to AI search suggestions
• Track product IDs and source fields exposed in responses
• Fall back to standard text search if the model fails
• Isolate prompt-injection phrases found in product descriptions or reviews so they are not executed as system instructions

Pre-launch Acceptance Testing

Tasks to Repeat During the Operational Phase

Search is not a feature that is developed once and then forgotten. Since product lineups, seasons, promotions, and customer language change, establish the following cycle as part of your operational process.

1. Review search terms with no results and those experiencing a sudden surge every week.
2. Update synonym and category mappings through the approval process.
3. Monitor out-of-stock exposure rate, click-through rate, conversion rate, and search term modification rate together.
4. Roll out weight adjustments only after offline evaluation and limited A/B testing.
5. Audit the exposure share of ads, in-house products, and organic results separately.
6. Regularly inspect the retention period, access permissions, and masking failures for search logs.
7. Re-evaluate index utilization and slow queries using actual traffic.

Conclusion

AI can quickly build search APIs and user interfaces, but it cannot determine which products are worthy of being presented to customers. A practical e-commerce search system is only complete when default sorting, product status, list navigation, search scope and “no results” handling, and search logs are first established as policies, and those policies are consistently reflected in the data model, API, indexes, testing, and administrative metrics.

While coding can be automated, merchandising principles and responsibilities do not arise automatically. The best AI prompt is not one filled with long, complex development jargon, but rather a document that clearly distinguishes between policies already decided by the operator and questions that have yet to be decided.