Price Range Filter Generation Prompt Template

This prompt is designed for e-commerce search engineers who need to extract structured price constraints from natural language shopping queries before they hit the retrieval engine. The core job-to-be-done is converting user expressions like 'wireless headphones under $100', 'laptops between $500 and $1000', or 'cheap running shoes' into machine-readable filter clauses that a search backend can execute. It belongs in the query understanding stage of a hybrid search pipeline, sitting between the raw user input and the retrieval step, and it works alongside other metadata extraction prompts that handle categories, brands, ratings, and other facets. The ideal user is a platform engineer or search relevance developer who already has a search index with indexed price fields and needs a reliable way to bridge the gap between how users talk about price and how the search API expects to receive price filters.

Use this prompt when your search interface accepts free-text queries that may contain price constraints, when your product catalog has numeric price fields that can be filtered, and when you need consistent, validated filter output that downstream systems can consume without additional parsing. The prompt handles several price expression patterns: explicit ranges ('$20 to $50'), comparisons ('under $30', 'above $200', 'less than $15'), single thresholds ('around $100'), and qualitative price signals ('cheap', 'affordable', 'premium', 'luxury'). It also detects currency symbols and codes, normalizes them to a configured default currency, and interprets boundary inclusivity—whether 'under $50' means strictly less than 50 or less-than-or-equal-to 49.99, depending on your business rules. The output is a structured filter object with fields for operator, value, currency, and boundary type, ready to be translated into your search backend's filter DSL.

Do not use this prompt when price constraints are already captured through structured UI controls like sliders, dropdowns, or input masks. If users select price ranges from a faceted interface, you already have structured data and adding an LLM extraction step adds latency and cost without benefit. Similarly, avoid this prompt for non-ecommerce use cases where 'price' has a different semantic meaning—financial data queries, invoice line items, or cost analysis questions require different extraction logic. The prompt is also not a substitute for proper price indexing: if your search backend cannot filter by numeric price ranges, no amount of query understanding will help. Finally, for queries that combine price with complex boolean logic across multiple facets ('Sony or Bose headphones under $100 but not refurbished'), use this prompt in sequence with the Combined AND/OR Filter Logic prompt rather than expecting it to handle cross-facet operator precedence on its own.

This template provides a production-ready prompt for converting user queries like 'wireless headphones under $100' or 'laptops between $500 and $1000' into structured price constraints. The prompt is designed to handle range expressions, comparison operators, and currency-aware thresholds while producing a consistent JSON output that your search backend can consume directly. Replace each square-bracket placeholder with your application's specific values before use.

textCopy
You are a price filter extraction system for an e-commerce search engine. Your job is to analyze a user's shopping query and extract any price constraints into a structured JSON object.

[CONTEXT]
- Supported currency: [CURRENCY_CODE]
- Default currency if none specified: [DEFAULT_CURRENCY]
- Maximum allowed price value: [MAX_PRICE]
- Treat unspecified boundaries as: [BOUNDARY_DEFAULT]

[INPUT]
User query: [USER_QUERY]

[OUTPUT_SCHEMA]
Return ONLY a valid JSON object with this exact structure:
{
  "price_filter": {
    "detected": boolean,
    "currency": string | null,
    "min_price": number | null,
    "max_price": number | null,
    "min_inclusive": boolean,
    "max_inclusive": boolean,
    "expression_type": "range" | "less_than" | "greater_than" | "exact" | "none",
    "original_phrase": string | null,
    "confidence": number
  }
}

[CONSTRAINTS]
1. If no price information is detected, set "detected": false and all other fields to null or their zero values.
2. For "under $X" or "less than $X", set max_price to X and max_inclusive to false.
3. For "over $X" or "more than $X", set min_price to X and min_inclusive to false.
4. For "between $X and $Y", set both boundaries with min_inclusive and max_inclusive both true.
5. For "around $X" or "approximately $X", set min_price to X*0.9 and max_price to X*1.1 with both inclusive.
6. Normalize all prices to the smallest currency unit (e.g., cents) as integers.
7. Set confidence between 0.0 and 1.0 based on how explicit the price constraint is.
8. If multiple price constraints conflict, extract only the most specific one and set confidence lower.
9. Ignore prices that appear to be product names, model numbers, or unrelated numbers.
10. Do not include any text outside the JSON object.

[EXAMPLES]
Query: "bluetooth speaker under 50 dollars"
Output: {"price_filter":{"detected":true,"currency":"USD","min_price":null,"max_price":5000,"min_inclusive":false,"max_inclusive":false,"expression_type":"less_than","original_phrase":"under 50 dollars","confidence":0.95}}

Query: "Samsung Galaxy S23"
Output: {"price_filter":{"detected":false,"currency":null,"min_price":null,"max_price":null,"min_inclusive":false,"max_inclusive":false,"expression_type":"none","original_phrase":null,"confidence":1.0}}

Query: "office chair between 200 and 400 EUR"
Output: {"price_filter":{"detected":true,"currency":"EUR","min_price":20000,"max_price":40000,"min_inclusive":true,"max_inclusive":true,"expression_type":"range","original_phrase":"between 200 and 400 EUR","confidence":0.95}}

Before integrating this prompt into your application, verify that the output schema matches your search backend's filter interface. The examples use integer cents to avoid floating-point comparison issues, but you may need to adjust this for your system. Test the prompt against queries with ambiguous price language ('cheap', 'affordable', 'premium') to ensure your confidence thresholds align with your tolerance for false positives. For production use, add a post-extraction validation step that rejects filters where confidence falls below your configured threshold and falls back to a price-agnostic search.

The price range filter prompt is not a standalone widget—it is a structured extraction step inside a search query understanding pipeline. In production, the user's raw query arrives at an API gateway, passes through normalization, and then hits this prompt to extract price constraints before the system constructs the final search request. The prompt's output must be a machine-readable JSON object containing min_price, max_price, currency, operator, and confidence fields, not free text. This contract allows downstream services to merge extracted price filters with other metadata constraints, apply business rules (e.g., default currency, maximum range width), and build the final Elasticsearch or vector search query without parsing ambiguity.

Wire the prompt into your application with a thin extraction service that handles the full lifecycle: input assembly, model invocation, output validation, retry logic, and observability. On input assembly, inject the user's raw query into the [USER_QUERY] placeholder and set [DEFAULT_CURRENCY] from the user's session or store configuration. After receiving the model response, validate the JSON schema strictly—reject any output where min_price exceeds max_price, where currency is not in your allowed list, or where confidence falls below a configured threshold (start at 0.7 and tune based on false-positive rates). On validation failure, implement a single retry with the validation error message appended to the prompt as additional context; if the retry also fails, fall back to no price filter rather than applying a broken constraint. Log every extraction attempt—including the raw query, extracted values, confidence score, validation result, and latency—to enable offline eval and threshold tuning.

Model choice matters for this task. Price extraction is a structured extraction problem with clear right and wrong answers, not a creative generation task. Smaller, faster models (e.g., Claude Haiku, GPT-4o-mini, or fine-tuned open-weight models) often perform well here and reduce latency and cost compared to frontier models. If your e-commerce catalog spans multiple currencies, add a currency normalization layer after extraction that maps extracted currency codes to your canonical currency list and applies exchange rate conversion when the user's session currency differs from the catalog currency. For boundary interpretation—whether 'under $50' means < 50 or <= 50—define your house convention in the prompt's [CONSTRAINTS] section and enforce it in post-extraction validation rather than relying on the model to guess correctly every time.

Testing this prompt requires a dedicated eval harness, not manual spot checks. Build a golden dataset of at least 100 query-price pairs covering exact prices ('$29.99'), ranges ('between $20 and $50'), comparisons ('cheaper than $100', 'above $200'), currency variants ('€50', '£30-£60'), boundary cases ('free', 'under $5'), and negative examples ('best price', 'affordable', 'cheap') where no structured price filter should be extracted. Run this eval suite on every prompt change and model upgrade. Track precision (did we extract a price when we shouldn't have?) and recall (did we miss a price that was present?) separately, because the business impact of each error type differs—false positives return zero results and frustrate users, while false negatives show irrelevant products and waste browsing time.

Do not use this prompt in isolation. Price filters must be combined with other extracted constraints—category facets, brand filters, availability flags—before constructing the final search query. The price extraction service should emit its output to a filter merge layer that resolves conflicts (e.g., a price range that contradicts a category's known price floor) and applies safety limits (e.g., capping maximum range width to prevent queries that scan the entire catalog). If your system supports conversational search with follow-up turns, cache the extracted price filter in the session context and reapply it on subsequent queries unless the user explicitly changes or removes it. Finally, expose a human-override mechanism in your search UI so users can correct mis-extracted price ranges, and feed those corrections back into your eval dataset to drive continuous improvement.