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 engine that generates product suggestions for a shopper given their context (page, session, product being viewed). Models are trained on behavioral data (views, clicks, purchases) via Vertex AI Pipelines, tracked in MLflow, deployed to serving, and assigned to Recommendation Containers. MXP RecSys supports five model types: Customers Also Viewed, Frequently Bought Together, Similar Items, Good / Better / Best, and GetBundle.
Recommendation Container: A configurable placement that displays recommendations. It has a defined location and is connected to one or more recommendation models. The storefront calls a container by its ID; reassigning the model(s) inside it changes what shoppers see without any storefront code changes.
Placement (Page Type): The context a recommendation container serves. Supported values:
Customers Also Viewed (CAV): A recommendation model type that surfaces items other users browsed after viewing the current product. A session-sequence model served from a Vertex AI Endpoint. Typically used on product detail pages.
Frequently Bought Together (FBT): A recommendation model type that surfaces items commonly purchased alongside the current product, learned from co-purchase behavior. A session-sequence model served from a Vertex AI Endpoint. Typically used on the cart page for cross-sell.
Similar Items: A recommendation model type that surfaces products similar to the one being viewed, using nearest-neighbor search over the product's semantic embedding (text_embedding). Served inside PredictApp. Typically used on product detail pages to offer alternatives.
Good / Better / Best (GBB): A recommendation model type that presents three price-tiered options (budget, mid-range, premium) within the same category. A deterministic engine served inside PredictApp, personalized to the shopper's price range when browsing history is available.
GetBundle: A recommendation model type that recommends complementary products from related categories, grouped into a themed bundle. Bundles are precomputed from observed Frequently Bought Together co-purchase evidence and validated for functional compatibility by an LLM.
Deploy / Undeploy: The lifecycle actions a merchandiser takes on a recommendation model in MXP UI. Deploy activates a model so it starts serving recommendations; Undeploy deactivates it. A model must be deployed before it can be assigned to a container, and cannot be undeployed while still attached to one.

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.
ExperimentA/B testing: A named comparison between two versions of search or browse — a control arm and a test arm — run on live traffic and compared on real shopper behavior. Defined with a control arm, one or more test arms, a date range, and optional segments. Managed in the Experiment Analysis section.
Experiment Arm (Control / Test): The two versions being compared in an experiment. The control arm is the baseline (usually what is in production today); the test arm is the alternative being evaluated against it. Every shopper session is tagged with the arm it saw, so behavior can be attributed to one version or the other.
CTR (Click-Through Rate)experiment: The share of sessions (or requests) in which the shopper clicked through to at least one product. On the experiment dashboard each arm's CTR is shown side by side with the percentage change between them. The denominator is labelled on each view (sessions for session-level views, requests for channel-level views).
ATC Rate (Add-to-Cart Rate)experiment: The share of sessions (or requests) that led to at least one product being added to the cart. A mid-funnel intent signal, compared per arm in an experiment.
Conv. Rate (Conversion Rate)experiment: The share of sessions (or requests) that resulted in a completed purchase. The primary bottom-of-funnel signal for measuring whether a search change pays off in orders.
Revenue per Session (Revenue/Session): Total attributed revenue divided by total sessions, where revenue is the sum of price × quantity over purchased items. Blends conversion rate and order value into a single per-session figure, making it the most complete top-line comparison between experiment arms.
Avg Click Rank (Average Click Rank): The average 1-based position of the product a shopper clicked in the result list. Lower is better — a falling average click rank means relevant products are sitting nearer the top of results.; Note: Watch this alongside CTR: CTR can hold steady while average click rank rises, signalling shoppers are working harder to find what they want.
Head / Torso / Tailquery distribution: Popularity buckets that group queries by how much search traffic they carry. Used to slice experiment metrics by query type:; Note: Slicing by bucket shows whether a change helped popular queries, the long tail, or both.
Impact Score: The default ranking signal on the per-query and per-category experiment views. It combines the click, add-to-cart and conversion differences between arms (weighted by the relative business value of each event), smooths each rate toward a baseline so noisy low-volume rates are pulled back, and multiplies by the smaller arm's volume so a large swing on a few requests can't outrank a steady gain across many. Sort by impact to find the queries that actually moved the needle.
Contaminationexperiment: A session in which the shopper saw more than one experiment arm within the attribution window (two days). Such sessions can't be cleanly credited to either arm, so they are detected and excluded from every comparison. Typically a small share of sessions is affected.
Relevance Gradeexperiment metrics: A label from 0 to 4 assigned to a query–product pair indicating how relevant the product is to the query, derived from implicit shopper signals (clicks, add-to-carts, purchases). 4 = highly relevant, 0 = no signal. Relevance grades are the input to NDCG and MRR.; Note: IQ Score uses a different, named grade scale for the same idea — see Relevance Grade (IQ Score) in the IQ Score section.
NDCG (Normalized Discounted Cumulative Gain): A search-ranking-quality score from 0 to 1 that rewards placing high-relevance products near the top of the result list. It compares the actual ordering against the ideal ordering of the same products by relevance grade — 1.0 means the results are in the best possible order. Shown per query on the experiment product view when relevance grades are configured for the tenant.
MRR (Mean Reciprocal Rank): A ranking-quality score equal to 1 divided by the position of the first relevant product in the list. A relevant product at position 1 scores 1.0, at position 2 scores 0.5, at position 3 scores 0.33, and so on. Higher means relevant results appear sooner.

6 · IQ Score (Search Quality Evaluation)

IQ Score: MXP's search quality evaluation capability, also referred to as LLM-as-a-judge. An IQ Score run sends a list of queries to a search service, grades every product it returns, and computes ranking metrics from those grades. It runs offline, beside search and never in the serving path, so it adds no latency to production traffic. Used as a regression check after a code change or catalog upload, as an A/B comparison between configurations, and as a benchmark of a live search endpoint.
LLM as a Judge: The pattern of using a language model to grade the relevance of search results in place of slow, inconsistent manual annotation. In MXP it is implemented by the IQ Score Judgement Agent.
Judgement Agent: The LLM agent that assigns a relevance grade to a query–product pair, together with a failure bucket, a confidence, and its reasoning. It is an agent rather than a single prompt because it can look things up first: it queries a BigQuery catalog snapshot with SQL, calls related MXP services, and can use web search. The default model is Gemini 3.1 Flash; nothing is trained — the rubric and tools are configuration.; Note: The catalog tool is how a run detects misses. If the agent finds a better product than the one returned, it lowers the grade of what was returned — it does not substitute the better product into the results.
Relevance GradeIQ Score: One of four ordered labels assigned to a query–product pair, by the Judgement Agent or taken from the golden data set: EXACT (exactly what the shopper asked for), SUBSTITUTE (a different product serving the same need), COMPLEMENT (a product that goes with what was asked for rather than answering it), and IRRELEVANT. The middle two name the relationship to the query, not merely weaker relevance, which is what makes a low score diagnosable.
Gain: The numeric value a relevance grade maps to for metric computation — by default 3 for EXACT, 2 for SUBSTITUTE, 1 for COMPLEMENT, 0 for IRRELEVANT. NDCG uses the gain directly; precision, recall, MAP and MRR treat a product as relevant once its gain clears a configured threshold. The mapping is configurable per tenant and is recorded on each run so old numbers stay reproducible.
Golden Data Set: Approved query–product–grade triples held in BigQuery: IQ Score's ground truth and its main cost control. It is consulted before any judging happens — a pair that already has an approved grade is scored from it and never sent to the LLM. A tenant can maintain several golden data sets and choose which one a run scores against.
Golden Candidate: A judgment from a completed run that is proposed for a golden data set. The search team reviews each candidate — query, product, grade, and the agent's reasoning — and approves it into a chosen data set. High-grade, high-confidence judgments are the candidates for automatic acceptance, leaving people to arbitrate only the uncertain ones.
ConfidenceIQ Score: The Judgement Agent's own certainty in a grade it has just assigned. It is what decides whether a judgment can enter the golden data set without a human reading it first.
Failure Bucket: The category the judge assigns to explain a poor result — for example wrong category, when a query about a battery specification returns brake parts. The distribution of failure buckets across a run is what turns a low score into something a merchandiser or engineer can act on.
Run Descriptor: The BigQuery row that specifies a single IQ Score run: which search service to evaluate, which queries table to use, which golden data set to score against, and the run's scope. Written either by the IQ Score Runs API on demand or by a scheduled job; a Kubernetes job then claims it and executes the run.
Search Serviceas an evaluation target: The endpoint IQ Score evaluates — the service that actually answers shopper traffic, including merchandising rules, boosts and query understanding, rather than the bare search engine underneath it. Elasticsearch and Vertex AI Search are supported out of the box; any other search service is onboarded by mapping its response into the common result shape.
Precision@k (P@k): Of the top k results for a query, the fraction that are relevant. Measures how clean the top of the list is and ignores anything below k. IQ Score reports it at k = 4, 10 and 24 — the top row, the first screen, and the full first page.
Recall@k (R@k): Of all the relevant products that exist for a query, the fraction the search service surfaced in the top k. Measures coverage: high recall with low precision means the relevant products are present but buried in noise.
MAP (Mean Average Precision): The mean, across queries, of precision recomputed at every relevant hit in the ranking. Rewards both returning relevant products and ranking them early. Reported per run alongside NDCG and MRR.
Traffic-Weighted Metric: A run-level metric averaged with each query weighted by its traffic, so busy queries dominate the number the team watches. Every headline metric is reported both plain (every query counts equally) and traffic-weighted.

7 · 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.

8 · 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.

9 · 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.

10 · 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