Properly filled attributes are the foundation of the faceted filter in 1C-Bitrix. Without them, the bitrix:catalog.smart.filter component does not display parameters, and the buyer cannot narrow down their choice. We have repeatedly seen catalogs where all attributes are dumped into one text property via line breaks—in such a filter, half the items are lost. Incorrect or missing attributes lead to a 20–30% drop in conversion—the buyer cannot filter the desired models. Automating import from external sources solves this problem but requires a well-thought-out schema and data normalization. Over 5 years, we have implemented more than 50 projects for catalog automation on Bitrix and know the typical bottlenecks. Switching to auto-fill pays for itself on average in 2–3 months, significantly saving team resources. The implementation cost depends on the catalog size, but in most cases it pays off through reduced manual labor.
Why Attribute Automation Is Critical for an Online Store
Manual filling of 1000 products takes 30–40 working days and yields 10–15% errors. Attribute errors mean not only lost sales but also product returns due to mismatched expectations. Automation reduces time to 7–12 days and errors to 1%. Comparison of approaches:
| Parameter | Manual Fill | Auto-Fill |
|---|---|---|
| Time for 1000 products | 30–40 working days | 7–12 working days |
| Data errors | 10–15% of items | <1% after setup |
| Scaling | Requires hiring managers | No additional resources |
| Accuracy | Depends on the executor | Automatic updates |
Automation is 3–4 times faster than manual filling and reduces errors by 90%. Data accuracy increases 10-fold—this directly affects buyer trust.
For example, for a home appliance online store, we connected Icecat and the manufacturer's API. Previously, managers spent 2 days a week updating 300 products; after automation, it took 1 hour for monitoring. Errors dropped from 12% to 0.5%.
How to Design a Property Schema for Automation?
Before starting, conduct an audit of the current infoblock properties and identify issues. Typical mistakes in legacy catalogs that need fixing before automation:
- Attributes are stored in a single text property "Description" via line breaks instead of separate properties.
- The same property is created multiple times with different
CODE, leading to duplicates in the filter. - Numeric values are stored in string properties—the interactive filter does not work because it cannot compare values.
For successful auto-fill, a clean schema is required: each attribute is a separate property with the correct data type. Use types: Numbers – type N, categories (brand, color, material) – type L (list values), text descriptions – type S. For numeric attributes, always specify the unit of measurement in the property settings (field UNIT). This simplifies conversion between sources and automatic calculation.
Attribute Sources
-
Icecat XML — the most complete source for electronics and home appliances. Search by EAN via
https://icecat.us/api/. Data is structured, attribute names standardized according to international standards. In one project, we connected Icecat for a catalog of 50,000 products—setup took 2 days, after which 90% of attributes were filled automatically. Integration with Icecat is particularly effective for tech products: monitors, laptops, smartphones, where many precise parameters are needed. - GS1 / GEPIR — barcode database containing basic product attributes, manufacturer, and valid value ranges. Useful for validating data from unofficial sources.
- Manufacturer API — if the manufacturer provides partner access to specifications (e.g., official catalogs of Bosch, LG, Samsung). The most reliable source, but requires individual agreements.
- Site parsing of the manufacturer's site — fallback when there is no API. Parse specification tables carefully, filtering out HTML junk and checking for changes in page structure.
Normalization and Quality Control
The main problem is that the same parameters from different sources may have different names and units of measurement. This leads to catalog desynchronization and reduces buyer trust. Our solution is based on a three-level approach:
- Canonical name dictionary — a table
property_canonical_mapmapping all variants of parameter names to a single form:source: 'icecat', source_name: 'Screen Size', canonical: 'display_diagonal', unit: 'inch' source: 'supplier_a', source_name: 'Диагональ экрана', canonical: 'display_diagonal', unit: 'sm' source: 'supplier_b', source_name: 'Размер дисплея', canonical: 'display_diagonal', unit: 'inch' - Unit converter — automatically converts cm to inches (or vice versa) by
canonicalduring import. Supports metric and English conversion systems. - Range validator — numeric values are checked for realism (phone weight 5000 g is a clear error, laptop weight 15 kg is impossible). Configured for each product category respecting real attribute ranges.
Example unit converter code
```php class UnitConverter { public static function convert($value, $fromUnit, $toUnit) { // Implementation via coefficient array } } ```How to Manage Enum Values for List Properties?
Properties of type L require pre-creating values in b_iblock_prop_enum. During auto-fill, new values constantly appear. A strategy is needed:
- Auto-creation — a new value is automatically added to the enum. Risk: garbage values from parsing errors.
- Moderation queue — the new value is placed in a queue, and the manager approves or rejects it. Safer but requires attention.
We recommend a combination: auto-creation with filtering (length 2–100 characters, no HTML, no special characters) + notification to the manager about new values. For each product category, it makes sense to predefine an allowed dictionary of values—this prevents cluttering the reference with duplicates, spelling errors, or non-standard abbreviations.
Incremental Updates
Attributes change less often than prices—once a week is enough for most catalogs. Process optimization:
- Store a hash of the attribute set for an element:
md5(serialize($properties)). - When updating from a source, compare the hash—if unchanged, skip the DB write.
- This reduces the load on the
b_iblock_element_propertytable for large volumes and speeds up the synchronization cycle.
Practice shows that this approach reduces the full update cycle time by 60–70%. For a catalog of 100,000 products, a full update takes 15–20 minutes instead of an hour, which is critical for frequent synchronizations. When updating from multiple sources simultaneously, control the order of applying data: attributes from the priority supplier overwrite data from secondary ones. The priority order is configured in each provider's configuration and can be changed without code modification.
Implementation Process
- Audit of infoblock property schema — 1–2 days. Identify duplicates and incorrect types.
- Development of providers — 2–4 days. Connect Icecat, GEPIR, parsing if needed.
- Creation of canonical name dictionary — 2–3 days. Map source names to infoblock properties.
- Setup of unit conversion and validation — 1 day.
- Implementation of incremental update — 1–2 days.
What Is Included
- Audit and restructuring of infoblock property schema.
- Development of providers for each source.
- Creation of canonical name dictionary and unit converter.
- Setup of validation and enum value management.
- Implementation of incremental update with hashing.
- Testing on 1000+ products, manager training.
- Warranty on work — 3 months free support.
Timeline
| Stage | Duration |
|---|---|
| Audit and restructuring of infoblock property schema | 1–2 days |
| Development of source providers | 2–4 days |
| Normalizer, canonical name dictionary | 2–3 days |
| Enum value management | 1 day |
| Incremental update, monitoring | 1–2 days |
Total: 7–12 working days. The cost is calculated individually based on catalog volume and source complexity. Order a preliminary audit of your catalog—we will assess the property schema and data sources. Get a consultation by contacting us.
Source: CommerceML standard, description of data exchange with 1C.