Automated product attribute mapping to site filters

Suppliers call the same characteristics differently: "Цвет", "Цвет изделия", "color", "Colour", "RAL". On the product filter, there's a single "Color" attribute. Manually aligning characteristics from dozens of suppliers to product filters—that's hundreds of hours of work that need automation. We develop a turnkey attribute alignment system: you upload price lists, we configure dictionaries, normalization algorithms, and integration with faceted search. Our team has 5+ years of experience in e-commerce catalog automation and has completed over 20 similar projects. Budget savings per supplier: from 30,000 rubles annually (approx $300). Processing time per supplier drops from 40 hours to 2–3 hours—10–20 times faster. With 20 suppliers, you save over 700 hours per year, which can be directed to catalog development. Typical implementation cost starts from $2,500 for a single supplier integration, with ROI in under 6 months. Our automated system is 20x more efficient than manual data entry, handling thousands of attributes per minute with near-zero errors. We guarantee seamless integration with your product catalog. We use PostgreSQL with the pg_trgm extension for fuzzy search and queues for unrecognized values.

System architecture of attribute alignment

Three levels of abstraction:

Supplier characteristic → Site attribute → Filter value "Цвет изделия: Красный" → color → "Красный" "color: Red" → color → "Красный" (with value normalization) "RAL 3020" → color → "Красный" (via RAL reference) 

Mapping tables—attribute_name_mapping (attribute name) and attribute_value_mapping (value). Both support priority: first mapping for a specific supplier, then universal. This allows configuring exceptions for individual suppliers. The product_filter_values table stores denormalized data with indexes, ensuring fast faceted filtering. When mapping changes, data is recalculated via an artisan command.

Mapping algorithm

The main class AttributeMapper performs automatic matching of supplier values to site attributes:

1. Determines the internal attribute key (color, spec_weight_kg) from the supplier-supplied name.
2. Selects a normalized value—either from a mapping dictionary or via an auto-normalizer.

class AttributeMapper { public function mapAttribute( string $supplierName, string $supplierValue, ?int $supplierId = null ): ?MappedAttribute { // Step 1: find attribute name mapping $siteAttribute = $this->resolveAttributeName($supplierName, $supplierId); if (!$siteAttribute) { $this->logUnknownAttribute($supplierName, $supplierId); return null; } // Step 2: find value mapping $siteValue = $this->resolveAttributeValue($siteAttribute, $supplierValue, $supplierId); if (!$siteValue) { // Try normalization without mapping $siteValue = $this->autoNormalizeValue($siteAttribute, $supplierValue); } return new MappedAttribute($siteAttribute, $siteValue); } private function resolveAttributeName(string $name, ?int $supplierId): ?string { $normalized = mb_strtolower(trim($name)); // First, supplier-specific mapping if ($supplierId) { $mapping = AttributeNameMapping::where([ 'supplier_id' => $supplierId, 'supplier_name' => $normalized, ])->value('site_attribute'); if ($mapping) return $mapping; } // Then universal return AttributeNameMapping::whereNull('supplier_id') ->where('supplier_name', $normalized) ->value('site_attribute'); } } 

How are values automatically normalized?

Numeric characteristics (weight, dimensions, voltage) are normalized without dictionaries: "2,5 кг" → 2.5, "1000 г" → 1.0. String values are usually lowercased or capitalized first (if not a brand name). For colors, the RAL reference is used—we integrate it during setup.

private function autoNormalizeValue(string $attribute, string $raw): string { return match ($attribute) { 'spec_weight_kg' => $this->parseWeight($raw), 'spec_dimensions' => $this->parseDimensions($raw), 'spec_voltage' => $this->parseVoltage($raw), default => $this->capitalizeFirst($raw), }; } private function parseWeight(string $raw): string { // "2,5 кг" | "2500 г" | "2.5kg" → "2.5" if (preg_match('/(\d+[.,]\d+|\d+)\s*г(?:рамм)?/iu', $raw, $m)) { return (string) (((float) str_replace(',', '.', $m[1])) / 1000); } if (preg_match('/(\d+[.,]\d+|\d+)\s*кг/iu', $raw, $m)) { return str_replace(',', '.', $m[1]); } return $raw; } 

Example mapping for supplier "ТехноКом":

• Raw data: "Цвет: Red", "Вес: 2.5 kg"
• Mapping: "Цвет" -> color, "Red" -> Красный; "Вес" -> spec_weight_kg, "2.5 kg" -> 2.5
• Result: product appears in filter "Color: Красный" and "Weight: 2.5"

Why is fuzzy search important for new values?

Note: when a price list contains "Красн." but the dictionary only has "Красный", the system suggests to the operator to create a mapping based on string similarity. We use the similarity function from the pg_trgm module. At a threshold >0.6, options are shown. The operator confirms with one click—and on the next import, the value is already mapped automatically. This eliminates manual catalog searching.

Commercial deliverables

1. Design of mapping and normalization table structures.
2. Development of algorithms (dictionary mapping, auto-normalization, fuzzy search).
3. Integration with faceted search: writing values to product_filter_values and index setup.
4. Administrative interface for managing mapping and the queue of unrecognized attributes.
5. Access to source code and documentation for extending dictionaries and normalizers.
6. Operator training and ongoing support for the first month.
7. Guaranteed performance and compatibility with your product catalog.

Implementation timelines

Total timeline from 3 to 9 days depending on number of suppliers and complexity of reference data. Our system outperforms manual methods by an order of magnitude. Request a demo on your data—see the savings.

Typical mapping mistakes

• Ignoring the supplier context. If one supplier calls "длина" a dimension and another a characteristic, universal mapping breaks filtering. Always use supplier_id.
• Lack of unit normalization. Mixing kg and grams in one filter makes it useless. We configure auto-normalization for your assortment.
• Forgetting new values. Without a queue for unrecognized attributes, you will lose products from filtering. Our system accumulates statistics and highlights frequent misses.
• No recalculation of filters when mapping changes. If product_filter_values is not updated, search yields incorrect results. We automate recalculation on each change.