Feature Sets

The Feature Sets page is where you define the attribute vocabulary for your workspace: which attributes exist for each product category, what values those attributes may hold, and how raw data from source feeds is translated into that vocabulary. The resulting configuration controls which attribute filters appear on the Products page and which attributes are available as criteria when building equivalence rules. The page also lets you bulk-correct attribute values on products you already have, via its Product Updates tab.

For a workspace-wide overview of attribute coverage across the category taxonomy, and for the history of configuration uploads, see Attribution.

The configuration view

Once your workspace has at least one configured attribute, whether from a Feature Set upload or created from Attribution, the Configuration tab opens directly to the current configuration. A summary row at the top shows five counters:

Metric	What it counts
Categories	Product category nodes covered by the configuration
Attributes	Configured attributes across those categories
Key mappings	Source feed attribute keys mapped to configured attribute keys
Value mappings	Exact source value → allowed value mappings
Pattern mappings	Term-based rules that map many source values to one allowed value at once

Below the summary, the page is split into two panels.

Left panel: category tree. The category tree shows categories as a hierarchy, for example “Furniture > Sofas”. Each node displays a count of the attributes configured beneath it. Attributes are grouped inside categories; clicking an attribute name loads its detail on the right. A search box above the tree filters it by category or attribute name.

Right panel: attribute detail. For the selected attribute you can see and edit:

• Attribute type. Whether the attribute is Categorical, Boolean, Numeric, or Text, and, for numeric attributes, the numeric format and units, covered in Attribute type and numeric formats below.
• Allowed values. The controlled vocabulary for that attribute, shown as chips you can rename or remove, plus a field to add a new one. Only these values will appear as facet filter options. Only shown for categorical attributes; numeric attributes accept any number in their configured format instead of predefined choices, and text attributes accept any non-empty text.
• Default value. A value the attribute takes when no product evidence produces one, covered in Default values below. Only available for categorical attributes that have allowed values, and for boolean attributes.
• Explanation. An optional plain-language description of what the attribute means, shown under the attribute name. It is also used to help the system interpret product evidence correctly when it automatically determines attribute values for products.
• Filterable / Matching badges. Shown next to the attribute name when those flags are active, covered in What the configuration controls below.
• Source keys. Which source feed attribute keys are mapped to this configured attribute.
• Pattern mappings. Term-based rules, each showing include terms, shown as outlined chips, and exclusion terms, shown as red chips labelled “not …”, plus how many products the rule’s matched source values cover and up to five example values.
• Source values. Exact per-value mappings. Up to 80 are shown inline; a note indicates if more exist.

Every source key mapping, pattern mapping, and source value mapping has a Remove button that turns it off, and a Show rejected mappings toggle above the summary cards that reveals removed mappings, greyed out, with a Re-enable button to restore them. Removing or re-enabling a mapping immediately rebuilds the products in that category so the change takes effect at once. Re-enabling is blocked if the mapping’s target attribute or value is no longer part of the current configuration.

Only approved mappings, and rejected mappings if toggled on, appear in this view. Lower-confidence, conflicting, or zero-match pattern mappings, discovered automatically as covered in Mapping discovery below, are recorded as pending, do not take effect, and are not shown here.

If an attribute key’s definitions can’t produce one consistent range filter, meaning different value types across categories, numeric definitions with different formats, or a numeric definition with no numeric format set, the attribute detail panel shows a warning listing each conflicting category definition: its format, unit, source, and how many products it covers. Until the definitions are brought in line with each other, filtering on that attribute key falls back to matching exact values instead of one consistent range filter; display units can still differ between categories without causing this.

Attribute type and numeric formats

Every attribute has a value type that controls what values are accepted:

Type	Behavior
Categorical	Enforces the attribute’s allowed values as a controlled vocabulary. If no allowed values are defined yet, any value is accepted.
Boolean	Restricted to the fixed choices “yes” and “no”.
Numeric	Parsed as a number in a configured numeric format, covered below, rather than matched against a list of allowed values.
Text	Accepts any non-empty free text, with no vocabulary constraint.

For a Numeric attribute you also choose a numeric format: Number, Length, Mass, Volume, Dimensions, Count, Density, Area density, or Temperature. Number is a plain number with no units. Dimensions is a composite value such as “10 x 20 x 30”. Dimensions-format attributes are never filterable, since a composite value can’t support a range filter.

For every format except Number, you additionally choose:

• Display unit. The unit values are shown in. Leaving this on the canonical option displays the attribute’s base unit for that format, for example millimeters for Length.
• Assume bare values are. The unit to assume when a source value is a plain number with no unit attached, for example treating a bare 50 as centimeters. Leaving this unset means values without an explicit unit are rejected rather than guessed.

A Number-format attribute has no unit, so neither control is shown for it.

For Boolean, Text, and Numeric attributes, the panel also shows a list of valid example values for the selected type or numeric format, and unit where relevant, so you can see what will be accepted before you commit to a change.

Changing the attribute type, editing allowed values, setting a default value, and editing the explanation are all staged as a draft and committed together in two steps:

1. Preview change. Shows how many of the attribute’s current source values would fail to parse under the new type, how many products would be rebuilt, and how many manual overrides or catalog fallback values are incompatible with the new type. If you are moving away from Categorical or Boolean, it also notes that existing allowed values and their value/pattern mappings are kept but become inactive under the new type rather than being deleted.
2. Apply definition. Commits the change. When the change affects stored values (the type, numeric format, assumed unit, allowed values, or default value), it also rebuilds the category’s products immediately. Changes to only the explanation or the display unit are saved without a rebuild. If the attribute’s configuration changes elsewhere while a preview is open, you’ll need to preview again before applying.

Editing allowed values directly

Besides defining allowed values through a CSV upload, you can add, rename, or remove them directly in the attribute detail panel. Each edit updates a pending draft of the attribute’s definition. Nothing is saved until you click Preview change and then Apply definition, at which point the products in that category are rebuilt:

• Add. Type a new value and add it to the draft vocabulary.
• Edit. Click the pencil icon on a value’s chip to change its text in place. This has the same effect on Apply as removing the old text and adding the new one: mappings and the default value follow the rules below for the old text.
• Remove. Removes the value from the draft’s allowed set. If it was the attribute’s only allowed value, removing it means the attribute will accept any value until you add one back. On Apply, any exact or pattern mapping that targets the removed value is automatically rejected, and must be re-enabled separately if you add the value back later. If the removed value was also the attribute’s default value, the default is cleared.

Default values

An attribute can have a default value: a fallback used when no product evidence, meaning source data, mappings, extraction, enrichment, or a manual override, produces a value for it. Defaults are available for categorical attributes that have allowed values defined, and for boolean attributes, which always offer the fixed “yes” / “no” choices. Pick one from the dropdown in the attribute detail panel, or choose “No default” to clear it.

Choosing a default, or “No default”, updates the same pending draft used for allowed values and attribute type. Click Preview change and then Apply definition to commit it; applying rebuilds the affected products immediately:

• Setting a default fills it in only for products that currently have no other evidence for that attribute.
• Changing a default updates only the values that were created by the previous default. Values backed by real evidence are left alone.
• Clearing a default removes only the values that the default alone created.

A default is a stopgap, not evidence: the system may still find contrary evidence for a product later and correct it, at which point the manually configured default is replaced by that evidence.

Uploading a Feature Set

If no configuration exists yet, the page shows an empty state with an Upload configuration button. After a configuration is in place, the same workflow is available via Update configuration in the top-right corner, alongside an Export configuration button that downloads the current configuration, meaning its attributes, allowed values, and active (approved) mappings, as a CSV in the same advanced format the upload accepts, so you can edit it offline and re-upload it to apply changes in bulk. Rejected and pending mappings are not included in the export. Uploads replace or extend existing configuration; absent rows do not delete existing attributes or mappings.

The import follows three steps shown in a progress strip: Upload → Review → Apply.

Step 1: Download the template and fill it in

Click Download template. Before any configuration exists, this returns a starter template with the core columns: category, attribute, display_name, allowed_value, source_attribute, source_value, pre-filled with a few example rows you can replace.

Once a configuration is in place, the button is labelled Download configuration and instead returns your current configuration in the same advanced, full-column format as Export configuration, so editing and re-uploading it applies changes in bulk rather than starting from a blank sheet. That advanced format’s columns are: export_format, category, category_node_id, attribute_group, attribute, display_name, explanation, value_type, numeric_kind, display_unit, assumed_input_unit, filterable, used_for_matching, sort_order, allowed_value, allow_any_value, default_value, mapping_type, source_attribute, source_value, target_value, pattern_match_type, pattern_include_terms, pattern_exclude_terms, pattern_priority, example_values, matched_value_count.

Required columns

Column	Purpose
category	Taxonomy path, for example Furniture > Sofas. Use the > separator to follow the hierarchy.
attribute or display_name	The attribute identifier or human label. Attribute keys are normalized to snake_case automatically. For example, Upholstery Material becomes upholstery_material.
allowed_value	One allowed value for the attribute. Add multiple rows with the same category and attribute to define multiple allowed values.

Optional mapping columns

Column	Purpose
source_attribute	The source feed attribute key to map to this configured attribute.
source_value	A specific source value to map. When present, source_attribute is also required. The target value defaults to the allowed_value on that row unless target_value is set.

Advanced columns. Accepted but not required for most uploads.

attribute_group, value_type, filterable, used_for_matching, sort_order, target_value, category_node_id, default_value, explanation, allow_any_value. value_type accepts categorical, boolean, numeric, or text; for a new numeric attribute, add numeric_kind, display_unit, and assumed_input_unit to set its numeric format and units. default_value is only accepted for categorical or boolean attributes, and must be one of the allowed values defined for that category/attribute anywhere in the file, not necessarily the allowed_value on the same row. Set allow_any_value to true on a row instead of allowed_value to declare that a categorical attribute has no controlled vocabulary; it cannot be combined with allowed_value rows for the same attribute. Beyond exact source-value mappings, a row can also define a pattern mapping directly by setting mapping_type to pattern along with pattern_match_type, pattern_include_terms, and optionally pattern_exclude_terms.

Defaults when omitted: attribute_group = General, value_type = categorical, filterable = true, used_for_matching = true.

Note

For an attribute that’s already configured, value_type in the CSV must match its current type. A re-upload cannot change an existing attribute’s type, numeric format, or units. Use the attribute detail panel’s Attribute type and numeric formats controls instead.

Step 2: Upload and review

Drag the completed CSV onto the drop zone or click to browse. The file must be a .csv and is validated immediately on upload, with a maximum size of 10 MiB. The review screen shows:

• File, Rows, Valid, Errors. A four-card summary.
• A row-by-row table with a Valid or Error badge and an error message for any row that did not pass.

Common validation errors include: unrecognised category path, missing allowed_value, conflicting definitions for the same category/attribute pair, target_value not in the allowed value set, a value_type that doesn’t match an existing attribute’s configured type, and invalid filterable / used_for_matching values. Accepted formats are true/false, yes/no, or 1/0.

The Apply button is only enabled when there are no error rows and at least one valid row.

Step 3: Apply

Clicking Apply writes the attribute vocabulary and any manually specified source mappings, then rebuilds the products affected by the imported attributes so the changes are reflected immediately. A confirmation bar shows how many products were rebuilt.

Applying also automatically triggers mapping discovery, covered in Mapping discovery, for the affected categories, so new AI-generated mappings are created alongside your manually specified ones.

What the configuration controls

Flag	Effect when true
Filterable	The attribute appears as a filter facet on the Products page and can be used to narrow product lists.
Used for matching	The attribute is available as a criterion when authoring equivalence rules on the Equivalents page.

Attributes with filterable = false are still stored and available for matching. They just do not create filter facets. Attributes with used_for_matching = false are still stored and filterable. They are simply excluded from equivalence rule criteria.

For categorical and boolean attributes, the allowed values act as a controlled vocabulary: only values that resolve to an entry in the allowed set appear in filters. If the vocabulary includes a catch-all entry such as “Other” or “Unknown”, a raw source value that doesn’t match any allowed value is bucketed into that catch-all instead of being dropped; only when the vocabulary has no such catch-all is a non-matching value withheld from filters. The underlying source data is preserved either way. Numeric attributes instead accept any value that parses in their configured numeric format, and text attributes accept any non-empty value. Neither has a predefined list of choices, and a numeric value that fails to parse is still stored and shown as-is rather than withheld.

Mapping discovery

Mapping discovery is the process of automatically generating source-to-vocabulary translations so that messy or inconsistent data from source feeds gets normalized into your configured allowed values.

You can trigger it in two ways:

• Generate mappings. A button inside the attribute detail panel that runs discovery for that one attribute only.
• Generate all mappings. A button above the summary cards that runs discovery across the entire configuration, processing each attribute separately to avoid higher-volume attributes crowding out lower-volume ones.

Discovery also runs automatically each time you apply a Feature Set import.

How it works

1. Collecting values. The system scans observed source key/value pairs from existing products in the affected categories, counting how many products each value appears on. For each attribute, it processes all unmapped values relevant to that attribute, in batches of 240. Values that match the attribute more closely, by key and value similarity, come first, and values that appear on more products come before less common ones with the same similarity. Values that already have a decision, an exact mapping or no-match record, are skipped, so repeated runs only process genuinely new values.

2. Generating mappings. An AI model reviews the collected values against your configured attributes and their allowed values. It may return:

   • Exact mappings. A specific source value maps to a specific allowed value, for example PU leather → fake leather.
   • Pattern mappings. A term-based rule that applies to many values at once. Each pattern has include terms, where all must be present for contains_all and any for contains_any, and optional exclusion terms that prevent unsafe matches. For example, a rule can include “leather” but exclude “vegan” so vegan leather is not caught by a real-leather rule.
   • No-match records. Values the model determines are ambiguous, numeric measurements, or free-text descriptions that do not belong in the vocabulary. These are recorded durably so the same value is not re-evaluated on future runs.

3. Storing mappings. Exact mappings are stored as approved and take effect immediately. Pattern mappings with confidence ≥ 80 % that have no conflicting targets and match at least one observed value are stored as approved and take effect immediately. Pattern mappings that fail those confidence, conflict, or match checks are instead stored as pending: they do not appear in the configuration view and do not affect products. There is currently no in-app way to review or approve a pending pattern mapping. It can only become active if a later discovery run produces the same pattern again with sufficient confidence and at least one matched value. After storing, affected products are rebuilt so the new mappings are reflected at once.

A progress bar tracks the stages while discovery runs: Collecting source values → Generating mappings → Saving mappings → Rebuilding product attributes.

Note

Mapping discovery only processes categorical and boolean attributes that have allowed values defined. Numeric and free-text attributes are excluded; those value types rely on other normalization rules.

Note

If the retailers you track resolve to exactly one non-English language, mapping discovery adapts to it: the AI is told the source keys and values are in that language and must map them onto your English allowed values, and keep include/exclude terms in the source language. English-language retailers don’t block this, and the language can be any of Danish, Dutch, Finnish, French, German, Italian, Norwegian, Polish, Portuguese, Spanish, or Swedish; if the non-English retailers you track resolve to more than one distinct locale, including two regional variants of the same language, mapping discovery keeps the standard English behaviour. For German, there is also a built-in lexicon of common whole values: materials, colours, and yes/no states. For example, “Kunstleder” maps to “Faux Leather”. It is used automatically as a fallback whenever the AI step is unavailable or does not return a result.

Tip

If you have manually specified source mappings in your CSV, via the source_attribute and source_value columns, those are applied as approved mappings immediately on import and are not re-evaluated by mapping discovery.

Bulk-correcting product attribute values

The Product Updates tab is separate from the Configuration tab above: instead of changing the attribute vocabulary itself, it lets you correct attribute values on products you already have, for example fixing a batch of products where an attribute was filled in incorrectly or left blank.

Step 1: Prepare a product-level export

Start from a product-level export on the Products page that includes the Product ID column and the attribute columns you want to change. Blank cells are ignored, and the standard product-export context columns, meaning Product Name, Brand, price columns, and similar, are skipped automatically. Any other column whose header does not match one of the product’s current attributes is reported under Problems and skipped changes, with the message “The header does not match this product’s current Feature Set or Normalized Attributes”, rather than silently ignored, so remove unrelated custom columns before uploading. Product listings by retailer exports, also called product-retailer exports, are not supported here.

Step 2: Upload and review

Click Upload product attributes and drop or choose the CSV, up to 100 MiB and 100,000 rows, with at most 100 attribute columns and 2,500,000 non-blank cells to check. The file is validated and matched against your products and configured attributes, and a review screen shows:

• Input rows, Products changing, Valid changes, Changes skipped. A four-card summary covering the full uploaded file.
• Changed fields. A count of proposed changes per attribute.
• A list of the proposed changes, each showing the current value, the new value, and the CSV line it came from. For large files this list shows only the first 500 change details; the summary counts above still cover the whole file.
• Problems and skipped changes, grouped by reason, for example product IDs that could not be found, duplicate product rows, attribute names that could not be resolved, values that fall outside the allowed values for that attribute, or two columns in the same file targeting the same attribute with conflicting values. You can download the skipped changes as a CSV to correct and re-upload.

Step 3: Apply

Click Apply changes to write the valid changes to the affected products. The job and every individual change outcome are persisted while it applies, so you can close the dialog and reopen the upload later to see the result; if applying is interrupted, reopening the job lets you retry the remaining changes without re-uploading.

Reviewing history

The Product Updates tab lists every past upload with its outcome, one of Validating, Preview ready, Applying, Completed, Partially applied, or Failed, and how many products were updated, changes applied, and changes skipped. Opening a past upload shows a view appropriate to its state. A completed upload opens to a Summary view and a Product changes view. The Product changes view lists applied and skipped/problem changes, up to the first 500, with the job’s summary metrics covering the full job, rather than unchanged or de-duplicated cells. A failed upload opens to its results panel showing the failure summary and the Changes applied, Products updated, Changes skipped, and Products skipped counts. Retry and download-skipped-changes options are offered only when they apply: retry when the job failed after applying had started, or completed with write failures, and the download when there are skipped changes recorded, so a file that failed validation shows its failure summary and result counts with no retry or download option. A job still applying shows an in-progress state you can safely leave and come back to.