In Supplier Data Manager (SDM), the Match History module lets you filter, enrich, and import products using a persistent Reference Base. It is commonly used to skip products that have already been processed, add attributes from an external lookup table, or build a history of known products for use in future jobs.

Overview

The Match History module in Supplier Data Manager accomplishes three main tasks:

1. Filter products automatically or manually based on whether they appear in a Reference Base or a static record list.
2. Enrich products by joining them with a Reference Base to create new attributes or override existing ones.
3. Import products into a Reference Base for use in future filtering or enrichment.

Filtered-out products are stored in a dedicated dataframe called matched. This dataframe can be targeted by an Output Format using the matched source, allowing you to export skipped products separately. See Outputs for details on configuring Output Formats.

Reference Base

A Reference Base is a persistent storage object in Supplier Data Manager that holds dynamic data between jobs. Each Reference Base has:

• A name used to identify it within the organization
• A set of unique columns that uniquely identify each entry (for example, ["sku"])
• A set of data columns that store any additional values (stored as JSON)
• Rows where the unique columns must be filled

Reference Bases belong to an organization and can be shared across multiple projects. They are the core mechanism behind Match History filtering and enrichment.

Interface

The Match History step in Supplier Data Manager uses a table layout with four filter tabs:

• Originally kept rows — rows kept automatically by the configuration
• Originally skipped rows — rows filtered out automatically
• Forced kept rows — rows that were automatically filtered out but that the user manually toggled to keep
• Forced skipped rows — rows that were originally kept but that the user manually toggled to skip

The screenshot above shows the Match History step table in the Supplier Data Manager interface, with the four filter tabs (Originally kept rows, Originally skipped rows, Forced kept rows, Forced skipped rows) and a toggle switch on each row to manually change its keep or skip status.

The only available actions at this step are toggling individual products or toggling products in bulk using a filter. At the start of the next step, only kept products are passed forward.

Configuration

The Match History step configuration is a JSON object with four top-level keys:

• filters — list of filters to apply to incoming products (default: [])
• filter_mode — how to combine multiple filters ("and" or "or", default: "and")
• enrichments — list of enrichments to apply to kept products (default: [])
• imports — list of Reference Bases to update when the step is finalized (default: [])

filters

Each entry in the filters list accepts the following parameters:

• mode (required): "blacklist" to filter out products that match the base, or "whitelist" to filter out products that do not match.
• reference_base (optional): Name of the Reference Base to match against. The base must belong to the same organization. Matching uses the Reference Base's own unique_columns. Use this for dynamic filtering.

If reference_base is not used, provide both of the following instead for a static filter:

• record_list: A static list of key/value records. Example: [{"sku": "100"}, {"sku": "200"}]
• unique_keys: The keys used to match each product against the records in record_list. Example: ["sku"]

Either reference_base or both record_list and unique_keys must be provided — not a combination of both.

filter_mode

Specifies how multiple filters are combined when more than one filter is configured:

• "and" (default): A product is filtered out only if it matches all filters.
• "or": A product is filtered out if it matches any filter.

enrichments

Each entry in the enrichments list accepts the following parameters:

• columns (optional): List of attributes to populate from the matched record. Each attribute must exist in the Reference Base or record list. If omitted when using a reference_base, all columns from that base are used.
• override (boolean, default: true): Whether to overwrite non-empty attribute values on the product when the matched record has a conflicting value.
• reference_base / record_list / unique_keys: Same definitions as for filters.

imports

Imports are applied at the end of the step, after filtering. Each entry in the imports list accepts:

• reference_base (required): The Reference Base to update.
• which (required): Which products to import. One of:
• "kept" — only products that were not filtered out
• "dropped" — only products that were filtered out
• "all" — all products regardless of filter outcome

Examples

Filter out already-imported products

This is a common Match History use case: importing only new products while skipping those already processed in a previous job.

Create a Reference Base named known_products with unique_columns: ["sku"]. Then configure the Match History step as follows:

{
    "filters": [
        {
            "mode": "blacklist",
            "reference_base": "known_products"
        }
    ],
    "filter_mode": "and",
    "imports": [
        {
            "reference_base": "known_products",
            "which": "kept"
        }
    ]
}

When a job runs, Match History removes all products already present in known_products (matched on SKU). When the step is finalized, the kept products are added to known_products so that future jobs will skip them.

Place this step immediately after the Mapping step to avoid unnecessary work on products that will ultimately be filtered out.

Enrich products with ERP-generated SKUs

In some setups, SKUs are generated by an ERP and are not available to the supplier at the time of file submission. Match History can enrich incoming products with their SKUs using a dedicated lookup project.

Step 1: Create the lookup Reference Base

Create a Reference Base named SKU List with: - unique_columns: ["supplier_name", "supplier_reference"] - columns: ["sku"]

Step 2: Create a dedicated feed project

This project keeps the SKU List Reference Base up to date. It contains two steps:

1. A Mapping step
2. A Match History step with the following configuration:

{
    "imports": [
        {
            "reference_base": "SKU List",
            "which": "kept"
        }
    ]
}

Both steps can be marked as Fast since they require no human review. This project is typically fed automatically via FTP from the ERP.

Step 3: Configure the main project

In the main project's Match History step, filter out unrecognized products and enrich recognized ones with their SKU:

{
    "filters": [
        {
            "reference_base": "SKU List",
            "mode": "whitelist"
        }
    ],
    "filter_mode": "and",
    "enrichments": [
        {
            "reference_base": "SKU List",
            "columns": ["sku"],
            "override": true
        }
    ]
}

Products whose supplier_name + supplier_reference combination is not found in SKU List are filtered out. Products that match are enriched with their corresponding sku value from the Reference Base.