MXP Platform

Key terms, concepts, and conventions used across the MXP Merchandising Experience Platform

This glossary defines the key terms, concepts, and conventions used across the MXP Merchandising Experience Platform. It is intended for merchandisers, analysts, developers, and administrators who are new to search and personalization domain vocabulary. Terms are grouped by platform area. Where a term appears in multiple contexts its primary definition is given first.

Use the alphabet bar below to jump to terms starting with a specific letter.

1 · Platform & General

MXP (Merchandising Experience Platform): Grid Dynamics' composable search and personalization platform. It bundles semantic search, vector search, AI-driven catalog enrichment, merchandising rules, and real-time recommendations into a single deployable stack on Google Kubernetes Engine (GKE). Designed to be forked and customized per customer; integrates Google Retail API, Vertex AI, Gemini AI, Elasticsearch / OpenSearch, and custom ML models.
Merch Module UI: The browser-based web application used by merchandisers, search operators, and administrators to manage all platform features. Every configuration — rules, facets, enrichment, recommendations, users — is performed through this interface.
Tenant: A fully isolated environment within a single MXP deployment. Each tenant has its own product catalog, configuration, users, and rules. Multiple tenants can share the same infrastructure (e.g., separate regional storefronts, distinct brand properties, or staging vs. production environments).
Tenant ID: A short, unique identifier for a tenant (e.g., vortex_uk). Included in every API request and configuration file path to scope all operations to the correct environment.
Snapshot / Snapshot Date: A point-in-time export of the product catalog stored in BigQuery, named <tenant>_products_snapshot_YYYY_MM_DD. Enrichment runs always process a specific snapshot rather than the live catalog, ensuring consistency and reproducibility across runs. The snapshot date identifies exactly which catalog version was processed.; Note: If an enrichment run result looks outdated, check whether it was run against a stale snapshot.
GD Indexing Pipeline: The internal pipeline that ingests product catalog data from source systems and writes it into Elasticsearch/OpenSearch for search. Runs on a configurable schedule; supports incremental updates so only changed products are reprocessed.
History Log: A read-only audit trail available on most list pages. Records who made each change, what changed, and when. Use it to investigate unexpected behavior, trace a configuration change, or satisfy compliance requirements.
Approval Request: A formal change submission that routes a configuration edit through a review step before it takes effect. Required when the Approval Requests workflow is enabled for an entity type. See also: Pending Approvals, Approval History.
Multi-tenancy: The deployment model in which a single MXP installation serves multiple tenants on shared infrastructure. Data and configuration are logically isolated per tenant; no tenant can see another's catalog or settings.

2 · Product Discovery

Discovery Rule: A merchandising instruction that overrides the search engine's default ranking behavior for specific queries or product sets. Rules are tenant-scoped and take effect immediately on activation. Four rule types exist: Boost, Bury, Pin, and Filter.
Boostrule type: Increases a product's effective relevance score, moving it higher in search results. The product remains subject to competition from other high-scoring items — it cannot be guaranteed at a fixed position (use Pin for that). The same Boost concept applies to Recommendation Rules.
Buryrule type: Decreases a product's effective relevance score, pushing it lower in the ranked list. Unlike Filter, the product remains visible in results — just deprioritised. Use Bury when you want to reduce prominence without fully hiding the item.
Pinrule type: Forces one or more products to exact positions in the result list regardless of their relevance score or any other active rules (e.g., always position 1 and 2). Pins are absolute and cannot be displaced by Boost rules. Use sparingly — over-pinning degrades result quality for other queries.
Filterrule type: Removes matching products from search results entirely. Shoppers cannot see filtered products even if they search for them directly. Use for out-of-stock, discontinued, restricted, or ineligible items. A Filter applied at rule scope removes the product from all queries that match that scope.
Rule Scope: Defines the set of queries or contexts a discovery rule applies to. Options: a specific query string, a query pattern (wildcard match), a product set (attribute-based condition), or global (all queries on the tenant).
Effective Dates: Optional start and end timestamps on a discovery or recommendation rule. When set, the rule activates and deactivates automatically at the specified times. Useful for seasonal campaigns, flash sales, or promotional windows without requiring manual intervention.
Priority Level: A numeric value assigned to a discovery rule that determines which rule wins when multiple rules match the same query. Higher priority rules take precedence. When two rules of the same type conflict, the higher-priority rule's action is applied.
Query Understanding Service (QUS): An internal MXP service that parses natural language search queries into a structured semantic graph (queryGraph). QUS applies linguistic overrides, extracts entities and intent, expands synonyms, and removes stop words before the query reaches the search engine. Changes to Linguistic Overrides take effect through QUS immediately on save.
Linguistic Override: A tenant-scoped configuration that changes how QUS interprets search terms. The three override types are: synonym rules (one-way and two-way), stop words, and compound rules.
One-way Synonym: A synonym rule where expansion happens in one direction only. For example, television expands to include TV, but searching for TV does not expand to television. Use when terms are not fully equivalent but one is a subset of the other.
Two-way Synonym: A synonym rule where two terms are treated as fully equivalent in both directions. Searching for either term returns results for both. Use for genuinely interchangeable terms (e.g., couch and sofa).
Stop Word: A term that QUS removes from a query before processing, because it adds no search value on its own. Examples: prepositions, filler words, or generic terms like product.; Note: Misconfigured stop words are a leading cause of zero-result queries. If removing a word causes zero results (e.g., the remaining tokens don't match any products), review the stop word list. Use the Evaluation workspace to diagnose.
Compound Rule: A linguistic override that controls how multi-word or hyphenated terms are tokenised. For example, treating soft-shell and softshell as the same token ensures results appear regardless of how the shopper writes the term.
Facet: A filterable dimension presented to shoppers alongside search or browse results (e.g., Color, Size, Brand). Shoppers use facets to narrow results interactively. MXP maintains independent facet configurations for search result pages and browse/category pages.
Search Facet: A facet that appears on search result pages. Configured in Search Facet Management, independent from browse facets. Query-specific overrides can be added with + Add Query.
Browse Facet: A facet that appears on category/browse pages. Configured in Browse Facet Management. Can be set globally across all category pages or overridden per individual category.
Coverage: The percentage of products in the catalog that have a non-empty value for a given attribute. A coverage of 60% on Color means 40% of products have no color value and cannot be filtered by that facet. Low coverage reduces the usefulness of a facet and can mislead shoppers into thinking fewer products are available than actually exist.; Note: Coverage is displayed per attribute in Search Facet Management. Use it to prioritise attribute enrichment.
Facet Value Ordering: Controls the sequence in which individual filter values appear within a facet (e.g., ordering Color values alphabetically, by frequency, or in a custom manual sequence).
Dynamic Category: A virtual category page powered by a saved search query rather than a hand-curated product list. Product membership is evaluated at page-load time (query-time evaluation), so the category contents update automatically as the catalog changes. Compatible with all merchandising rules.
Query-time Evaluation: The mechanism by which Dynamic Categories determine their product contents. Membership is checked when a shopper loads the page, not when the catalog is indexed. This ensures real-time accuracy without requiring re-indexing when the query or catalog changes.
Autocomplete: The type-ahead feature that suggests complete search terms as the shopper types a prefix into the search bar. Served from the Suggestion Index by the TypeaheadService. Configurable via the Autocomplete section.
Suggestion Index: A pre-built index of autocomplete candidates, populated from catalog content and historical query frequency. When a shopper types a prefix, the TypeaheadService queries this index using prefix matching and ranks results by a combination of query frequency and relevance. The index is rebuilt on a schedule; changes to promoted or blocked terms take effect on the next rebuild.
Promoted Suggestion: An autocomplete suggestion manually surfaced by a merchandiser, ensuring it appears for a given prefix regardless of its organic frequency ranking. Useful for campaign launches, featured categories, or new product lines that haven't yet accumulated query history.
Blocked Term: A term explicitly excluded from appearing as an autocomplete suggestion. Used to suppress inappropriate, discontinued, out-of-season, or otherwise undesirable completions.
Visual Navigation Suggestion: An image-and-label card that appears in the search bar dropdown, typically triggered when a shopper types a matching prefix or focuses the search bar. Clicking it navigates directly to a category page, a pre-filtered search result, or any configured URL.
Lexical Mining: An automated pipeline that discovers new linguistic rules — synonyms and misspelling corrections — by analyzing real search behavior. It finds underperforming search terms, uses an AI agent to work out what shoppers meant, validates each proposed fix against the live search engine, and presents scored candidates for human review. Approved candidates become Linguistic Overrides.
Lexical Candidate: A single proposed linguistic rule produced by Lexical Mining. It maps one or more source terms (what shoppers type) to one or more target terms (what they meant) and carries the type, evidence, confidence, impact, and validation status the pipeline assigned. A candidate is a suggestion only — it has no effect until a reviewer approves it.
Misspelling Replacementcandidate type: A Lexical Mining candidate that rewrites a misspelled source term to its correct form (e.g., breaks → brakes). When approved, it becomes a replacement rule. Replacements are supported on CRS-backed tenants; on Elasticsearch-backed tenants the approval is skipped.
Misspelling Synonymcandidate type: A Lexical Mining candidate that treats a spelling variant as equivalent to the correct term rather than replacing it outright (e.g., airbag → air bag). When approved, it becomes a one-way synonym. See also: One-way Synonym.
Suspicious Term: A search term flagged by Lexical Mining as underperforming — its click-through, conversion, or zero-result rate is worse than the median for its traffic tier (head, torso, or tail). Suspicious terms are the pipeline's work list: each one is investigated by the agent for a possible synonym or spelling fix.
Blast Radius: An estimate of how many queries and sessions a proposed linguistic rule would affect, broken down by traffic tier. Lexical Mining uses it to set a candidate's impact level so reviewers can prioritize the changes that reach the most shoppers.
Validation Status: The result of Lexical Mining's automated check, run against the live search engine before a human sees the candidate. Passed — the change improves results. Needs review — the evidence is mixed. Failed — the change does not improve results (for example, the engine already returns identical results for both terms, making the rule redundant).
Impact Level: A prioritization label — Low, Medium, High, or Critical — assigned to a Lexical Mining candidate based on its blast radius. Higher-impact candidates affect more traffic and are worth reviewing first.

3 · Attribute Enrichment

Attribute Enrichment: The MXP feature that uses Gemini AI to automatically generate missing or inconsistent product attribute values (e.g., color, material, size, description). Generated values go through a two-phase generate→validate process, then are either auto-published or routed to a review queue based on their confidence score.
Two-phase Enrichment ("AI checks AI"): The quality mechanism at the core of attribute enrichment. Phase 1: Gemini AI generates candidate attribute values from product data. Phase 2: a separate, independent Gemini call validates the generated values. Because the validator has no knowledge of the generator's reasoning, this design significantly reduces hallucination risk compared to single-pass generation.
Confidence Scoreenrichment: A quality assessment assigned to each AI-generated attribute value after the validation phase. Determines whether the value is auto-published or routed to review:
enrichConfidenceThresholdLevel: Configuration setting that defines the minimum confidence level required for auto-publishing. Default: HIGH. Setting it to MEDIUM auto-publishes both HIGH and MEDIUM results, reducing review volume at the cost of lower accuracy. Configured in catalog_enrichment_config.json.
Needs Review Queue: The list of AI-generated attribute values that did not meet the auto-publish confidence threshold and require a human decision (Approve, Reject, or manual Edit). Displayed in the Review & Publish screen.
Auto-applied: Attribute values generated by enrichment that were automatically published to the catalog without human review because their confidence score met or exceeded the configured threshold. Visible in the Auto-applied tab of the Review & Publish screen. Can be reverted at any time.
Revert: An action in the Review & Publish screen that restores a product's original attribute value and removes the enriched one. Available for both auto-applied and manually approved values.
Product Typeenrichment context: A natural-language label for a category of products used to configure enrichment (e.g., Food › Milk Product, Footwear › Running Shoes). The product type description is the most critical enrichment configuration field — it tells Gemini AI what kind of product it is working with, and directly determines generation quality.
Attribute Path: Dot-notation field path that identifies where an attribute lives in the product data model (e.g., attributes.color, attributes.size). Used to map enrichment output to the correct catalog field.
Fill Rate: The percentage of products in a given product type that already have a non-empty value for a specific attribute, measured before enrichment. A low fill rate indicates an attribute is a strong enrichment candidate. Computed by Catalog Analytics (Step 1 of the enrichment pipeline).
Catalog Analytics: The first stage of the enrichment pipeline. Analyses the product snapshot to compute attribute fill rates, identify sparse attributes, and surface enrichment opportunities. The results guide which product types and attributes are prioritised in the run.
Enrichment Run: A single execution of the full enrichment pipeline against a product snapshot. Each run processes products of all configured and enabled types, generates and validates attribute values, and either auto-publishes results or routes them to the review queue based on the confidence threshold.
Triggerenrichment: Indicates what initiated an enrichment run. MANUAL means a user or API call started it (the initiating user's email is recorded). System means it was started automatically by Cloud Scheduler on the configured cadence.
Products Processed: The total count of products examined during an enrichment run, regardless of whether any attribute values were changed. Distinct from Updated Count.
Updated Count: The number of products whose attribute values were actually changed (published) by an enrichment run. A low Updated Count relative to Products Processed can indicate high existing coverage or a strict confidence threshold.
Configuration Version: A reference to the enrichment configuration snapshot that was active at the time a specific run was executed. Allows comparison of results across runs that used different configurations.

4 · Recommendations

Recommendation Model: An ML model trained to predict which products a shopper is most likely to engage with given their context (page, session, product being viewed). Models are configured with a type and optimization objective, trained on behavioral data, and then assigned to Recommendation Containers for serving.
Recommendation Container: A named mapping between a page location (page type) and a recommendation model. The storefront calls a container by its ID; MXP routes the request to whichever model is currently assigned to that container. Reassigning the model changes what shoppers see without any storefront code changes.
Page Type: The placement context used to route recommendation requests to the correct container. Supported values:
Similar Items: A recommendation model type that surfaces products similar to a reference product, based on shared attributes and co-view behavioral signals. Typically used on product detail pages.
Recommended For You: A recommendation model type that personalises suggestions based on the current user's session behavior. Results change as the session progresses. Requires active user context in the API request.
Best Sellers: A recommendation model type that ranks products by purchase count or revenue within a category. Provides reliable, non-personalised suggestions when no user context is available.
Optimization Objective: The business metric a recommendation model is trained to maximise. Options: Click Through Rate (CTR), Conversion, or Revenue. Choose based on the business goal for the placement.
Training Status: Indicates whether a recommendation model is actively incorporating new behavioral data. A Paused model stops updating but continues to serve predictions from its last trained state. A model must complete at least one training run before it can serve recommendations.

5 · Metrics & Analytics

Conversion Funnel: The chain of metric stages from search query to purchase: Query → View → Add-to-Cart → Purchase. MXP tracks all stages, enabling operators to identify exactly where shoppers drop off and which interventions (rules, synonyms, facets) are most likely to improve outcomes.
Zero-result Rate: The percentage of search queries that returned zero products. A high zero-result rate is one of the most actionable signals in the platform — it typically indicates missing synonym rules, overly strict facet filters, stop word misconfiguration, or catalog gaps.; Note: Drill into the Queries tab and sort by zero-result rate to identify the specific terms to fix.
View Rate: The percentage of search sessions where the shopper clicked through to view at least one product. Measures top-of-funnel result quality. Low view rate suggests poor relevance or unattractive result presentation.
Add-to-Cart Rate: The percentage of search sessions that led to at least one product being added to the cart. Measures mid-funnel intent conversion.
Purchase Rate: The percentage of search sessions that resulted in a completed purchase. The primary bottom-of-funnel conversion metric for measuring search ROI.
Trend Score: A numeric indicator of how rapidly a query's or product's search frequency is rising relative to a historical baseline. High trend scores identify emerging demand before it peaks. Use the Trending Queries and Trending Categories tabs to monitor and act on high trend-score items.
Trending Queries: Queries whose search frequency is rising significantly above their historical baseline, indicated by a high trend score. Reviewing this tab regularly helps merchandisers catch emerging demand early and respond with rules, synonyms, or catalog enrichment before the peak passes.
Count Mode: A metrics display toggle that switches between absolute counts (raw event numbers) and rates (percentages). Use absolute counts to understand traffic volume; use rates to compare performance across time periods with different traffic levels.
Group By: Controls the time granularity of metric charts and tables in the Metrics section. Options: Daily, Weekly, Monthly.

6 · User Management & Access Control

Role: A set of permissions granted to a user within a specific tenant. Multiple roles can be assigned to the same user. Roles are tenant-scoped, so a user may hold different roles on different tenants.
Admin: Full access to all platform features and settings, including user and role management.
System Viewer: Read-only access across all platform areas. Cannot create, edit, or delete any configuration.
Rule Publisher: Can create, edit, and publish discovery rules. Intended for merchandisers responsible for search ranking.
Models Editor: Can create and configure recommendation models and containers.
Attribute Enrichment Viewer: Read-only access to the Attribute Enrichment section. Can view enrichment results but cannot approve, reject, or publish.
Autocomplete Approver / Editor / Viewer: A set of roles controlling access to the Autocomplete section at different permission levels: view-only, edit, or approve and publish.
Conversation Search Publisher / Viewer: Roles controlling access to Conversation Search configuration. Publisher can activate flows; Viewer has read-only access.

7 · Approval Workflow

Pending Approvals: The shared queue of configuration changes that have been submitted for review and are awaiting a decision. Any user with approval permissions can act on items in this queue. Approving a change makes it active immediately; rejecting it returns it to the requester.
Entity Type: In an approval request, the category of object being changed. Values: Rule, Attribute Config, Linguistic Override.
Change Type: In an approval request, the operation being performed. Values: Create, Update, Remove.
Under Revision: An approval request status indicating the item was rejected by a reviewer and returned to the original requester for modifications and resubmission.
Approval History: A complete, immutable audit log of all past approval decisions, showing the reviewer, timestamp, and outcome (Approved, Rejected, Error) for every request. Useful for audits and compliance.
My Request History: A filtered view of Approval History scoped to the currently logged-in user, showing only requests that they submitted.

8 · Conversational Search

Conversational Search: An LLM-driven multi-turn search experience in which the platform guides shoppers through a structured sequence of clarifying questions to narrow results, rather than relying on a single keyword query. Configured via the Conversation Search section of the Merch Module.
Conversational Flow (Query): A named, configurable sequence of prompts and attribute filters triggered by a specific search intent or keyword pattern. Each step narrows the result set based on the shopper's answers. Built and managed in the Queries tab.
Fallback Phrase: A message shown to shoppers when no configured conversational flow matches their query. Defined in the Settings tab of the Conversation Search section.

9 · Technical & API Concepts

queryGraph: The structured semantic representation of a search query produced by the Query Understanding Service (QUS). Contains parsed intent, extracted entities, expanded synonyms, and applied stop-word rules. Returned in the search API response for debugging.
Vector Search / Dense Embedding: A search approach that represents queries and products as high-dimensional numeric vectors (embeddings) and finds the nearest neighbors using approximate nearest-neighbour (ANN) algorithms. Returns semantically similar results even when keywords don't match exactly. MXP vector search supports AWS Bedrock (Titan/Claude) and Google Gemini embedding models.
Visual Search: An image-to-product search capability. Shoppers upload an image (JPEG or PNG); MXP converts it to a vector embedding via the Vision API and returns visually similar products.
Google Retail API / VAIS: Google's Vertex AI Search for Commerce API, used by MXP as an optional search backend and fallback. Proxied internally through the VAIS C-API service on port 8082.
Attribute Flagsindexing: Per-attribute flags in Attribute Management that control how a field is treated in the search index:

Glossary & Terminology Reference