Parsing product characteristics for Bitrix catalog population

When populating a 1C-Bitrix catalog, we often encounter: product descriptions exist, but characteristics are empty. Without filled properties (b_iblock_element_property), the smart filter returns no results, faceted search gives empty output. Buyers cannot filter products by required parameters — conversion drops, bounce rates rise. Parsing characteristics is technically more complex than parsing descriptions: you need not just extract text, but recognize the structure "parameter name — value" and correctly place data in infoblock properties. Our comprehensive bitrix characteristics parsing and 1c bitrix product specs parsing service handles HTML specification parsing, normalizes property names, and ensures accurate bitrix product characteristics population — all with a focus on smart filter performance. This process is 10 times faster than manual entry. Typical project cost: from $500 for 1000 SKUs to $2000 for complex cases, yielding up to 80% savings over manual data entry. We can assess your project in one day — just reach out to us. Our company has 5+ years of experience and over 50 successful Bitrix projects, ensuring reliable parsing.

Features of parsing characteristics in different formats

The source specification table can be of several types, each requiring a separate extraction approach:

• HTML table (<table>) — classic, parsed via XPath (see XPath) //table//tr. The first cell of the row is the name, the second is the value.
• dl/dt/dd list — often used in modern stores. We parse dt+dd pairs.
• JSON-LD or schema.org microdata — ideal. Data is already structured, no HTML parsing needed:

  preg_match('/<script type="application/ld+json">(.*?)<\/script>/s', $html, $m); $data = json_decode($m[1], true); 

• JS variables — data in window.productData or __REDUX_STATE__. Extract via regex.

Normalizing characteristic names

Different sources call the same thing differently: "Weight", "Net weight", "Weight (kg)". Direct mapping to an infoblock property without normalization creates chaos. Our solution — an alias table property_aliases:

CREATE TABLE parser_property_aliases ( alias VARCHAR(255), canonical_name VARCHAR(255), property_code VARCHAR(100) ); 

During parsing, each found name is looked up in the alias table. If not found — it is logged as "unknown property" for manual review and addition to the dictionary. This ensures data cleanliness even when working with thousands of SKUs. The alias dictionary is a key element that prevents duplication and filter errors.

Property types for the smart filter

Infoblock properties (b_iblock_property) have types: S (string), N (number), L (list), E (element binding). For characteristics we use:

For the faceted filter, values of type L work faster — they are indexed in b_iblock_element_prop_enum. Creating a value on import:

$propEnum = CIBlockPropertyEnum::GetList([], [ 'PROPERTY_ID' => $propId, 'VALUE' => $parsedValue ])->Fetch(); if (!$propEnum) { CIBlockPropertyEnum::Add(['PROPERTY_ID' => $propId, 'VALUE' => $parsedValue]); } 

Handling units of measurement

Sources provide "10 kg", "10kg", "10 kilograms". A unit parser is needed: split number and unit, normalize unit to standard. Simple regex: /^([\d.,]+)\s*(.*)$/. Numeric property values in Bitrix are stored as strings in b_iblock_element_property.VALUE — units should be moved to a separate property or added to the property CODE (WEIGHT_KG).

Case from our practice: electronics, 15,000 SKUs, 120+ characteristic types

Task: fill properties for the smart filter for laptops, phones, TVs — three infoblocks with different property sets.

Implementation:

• Parsing from the manufacturer's site via JSON-LD (70% of products) + HTML table (30%)
• Alias dictionary of 380 entries, collected in the first 3 days of development
• All numeric characteristics — type N, list ones (brand, color, country) — type L
• Parallel launch of 5 workers via PHP-CLI, each processing its own category

Result: the smart filter worked correctly for 48 parameters after 2 iterations of debugging the alias dictionary. Conversion from the filter increased by 15%. Economy: from $500 to $2000 per 1000 SKUs, depending on complexity.

Process: step-by-step plan

1. Analysis of source characteristic structure — determine specification format and data volume. 4–8 hours.
2. Parser development — write extraction module for your source type. 2–3 days.
3. Creation of alias dictionary — collect and normalize characteristic names. 1–2 days.
4. Configuration of infoblock properties — create or adjust properties for the filter. 1 day.
5. Data import and debugging — load characteristics, check types. 1–2 days.
6. Verification of smart filter operation — test filtering by all parameters. 4–8 hours.

What’s included

• Full documentation of the alias dictionary and parser configuration
• Access to the parser script with source code (can be integrated into your Bitrix environment)
• Training for managers on how to maintain the alias dictionary and handle new sources
• Post-launch support for 1 month, including fixes and adjustments

What is included in the work

We provide documentation, access to the parser, training for managers, and post-launch support. Total: 7–12 business days. This is one of the most labor-intensive catalog population tasks, but we perform it turnkey with a guaranteed result. Certified specialists with 5+ years of experience and over 50 successful Bitrix catalog population projects.

CREATE TABLE parser_property_aliases ( id INT AUTO_INCREMENT PRIMARY KEY, alias VARCHAR(255) NOT NULL, canonical_name VARCHAR(255) NOT NULL, property_code VARCHAR(100) NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );