Product listing rules break at the synchronization stage
Product listing rules almost never break at the setup stage — they break during catalog export, when data is sent to the marketplace again. The typical picture: the product exists in 1C, exists in Bitrix, but a third card with the same SKU appears on the platform.
The reason is different matching keys: somewhere the link is by code, somewhere by name, and after manually editing the name, synchronization stops recognizing the product and creates a new one.
Duplicate cards are the most expensive failure: they blur positions in the platform's search, break accumulated reviews, and require manual merging.
The second group of errors is lost attributes. Product listing rules on the platform require mandatory fields: dimensions, weight, composition, country, barcode.
If a field in the catalog is empty or filled in from a different reference book, the export goes through, but the card goes into moderation or into hidden.
At scale, it looks like this: part of the assortment simply doesn't appear on sale, and no one notices until the export is compared against the storefront.
The third failure is desynchronization of stock and prices. Stock synchronization runs on a schedule, while sales on the platform and in retail happen between runs. The product was sold twice, the stock went negative, and the platform delisted the card for incorrect data.
With prices it's worse: product listing rules on the marketplace calculate price from different bases — including promotions, loyalty discounts, or commission.
If the price in 1C is one thing and a different one goes to the platform, the product is either sold at a loss or loses on price to a competitor.
All three failures share one thing: they are invisible at the moment of setup and only manifest on the stream. Let's break down how this is closed at the level of exchange rules, rather than manual edits.
What correct setup of export rules gives
Correctly configured product placement rules are not a one-time setting, but a mechanism that determines how much time passes from a change in the catalog to the appearance of the card on the marketplace and how often it gets rejected by moderation.
When the rules describe mandatory attributes, units of measurement, categories, and marketplace limits, the export proceeds without manual edits: the product is published in the same exchange cycle, rather than after a manager manually corrects the name and characteristics.
The first measurable effect is publication speed. With correct rules, a new item goes to the marketplace with the nearest exchange, without a queue for manual rework.
The reaction time to an assortment change is reduced from days to hours: price, description, and availability are updated within a single synchronization cycle, rather than as a separate task.
The second effect is the share of rejected cards. Moderation rejects products due to non-compliance with marketplace requirements: empty mandatory fields, incorrect category, incorrect units, prohibited wording in the description.
The rules cut off these causes before sending — the card goes out already valid, and the rejection rate drops predictably, rather than "depending on luck."
The third effect is the relevance of stock. The rules link warehouse accounting with the marketplace in such a way that a sold item is removed from sale in the same cycle, rather than remaining available for order.
This eliminates the class of rejections where a buyer orders a product that is no longer available, and reduces the load on support.
In total, export automation turns placement from a manual process into a managed one: the assortment changes — the marketplace reflects this without human involvement, and the team focuses on the product, not on editing cards.
Ways to configure rules: comparing approaches
In practice, rules for placing products on marketplaces are rarely set in a single way — more often several are combined, and the choice depends on the size of the catalog, the frequency of changes, and how strictly the marketplace validates listings.
Let's break down four working options and their limitations, so you don't switch tools where configuring the existing one is enough.
How the approaches differ
Manual rules live directly in the interface — a manager sets conditions and exceptions by category, brand, warehouse. This is fast to start and understandable for non-technical staff, but as the catalog grows it turns into dozens of inconsistent entries that no one reviews.
Exchange templates (rules for mapping properties, units of measurement, VAT rates) deliver predictable results at scale and are versioned together with the configuration, but they require discipline: any new field in the export must be described in advance.
Export scripts cover non-standard logic — calculating price across multiple warehouses, filtering by stock, substituting characteristics from external tables.
Their strength is flexibility, their weakness is maintenance: without tests and logging, they break silently at the first format change.
External services take on marketplace-specific requirements and updates to platform rules, but they add dependency on a third-party environment and a delay between a change in the accounting system and publication.
Comparison of options
| Option | When it fits | Limitations |
|---|---|---|
| Manual rules | Small catalog, infrequent edits, launch of sales | Doesn't scale, no change history, errors aren't tracked |
| Exchange templates | Stable product flow, standard categories | Require all fields to be described, handle non-standard cases poorly |
| Export scripts | Complex logic for prices, stock, characteristics | Require tests and monitoring, break when the format changes |
| External services | Many platforms, frequent requirement changes | Dependency on the vendor, publication delay, limited access to data |
In practice, the most common combination is exchange templates for standard categories and scripts for exceptions — this way the bulk of products follow a predictable path, and non-standard cases don't break the overall flow.
Stages of implementing product placement rules
The work proceeds sequentially: each subsequent stage relies on the artifacts of the previous one, so skipping any step surfaces as errors already in production — duplicate cards, incorrect stock levels, or positions rejected by moderation.
- Catalog audit. We verify the structure of sections, properties, and trade offers against the requirements of the marketplaces: mandatory attributes, units of measurement, barcodes, dimensions. We record which fields are missing and where values are filled in not according to the template.
- Designing the export schema. We determine which properties and reference lists become the source of truth, how catalog categories are mapped to marketplace categories, and by what criterion a product is included in or excluded from the export.
- Setting up the rules. We define the product placement rules: required fields, default values, handling of empty attributes, limits on the length of descriptions and titles. The rules are versioned so that a change can be rolled back.
- Test export. We run a limited sample — usually a few dozen positions from different categories — and see what goes to the marketplace: which fields are filled in, which are discarded, where a default value was applied.
- Rule verification. We compare the result against the marketplace requirements, analyze deviations, and address edge cases: products without stock, positions with multiple offers, discontinued SKUs.
- Documentation handover. We provide the schema description, the list of rules, and instructions for editing the catalog — so that a manager can add a product or change an attribute without breaking the export.
After handover, the rules live together with the catalog: when a new category appears or the marketplace requirements change, the schema is extended rather than rewritten from scratch.
What the customer receives after setup
Setting up product placement rules ends not with an "enabled module," but with a set of artifacts by which the system can be operated and handed over to another team. Below is what remains with the customer in the repository and in the documentation.
- Exchange configurations — export of the item master, prices, stock, and attributes from the accounting system to the website catalog and back, with run schedules and handling of partially successful sessions.
- Mapping schemas — tables mapping categories, properties, and units of measure between the accounting system and the marketplaces, including rules for items without a category.
- Access policies — roles for managers, content editors, and contractors: who edits the card, who changes the export rules, who sees the operations log.
- Update regulations — the procedure for edits when a new category or marketplace appears: where the rule is changed, how the result is verified, what counts as a rollback.
- Instructions for employees — step-by-step scenarios for typical situations: the product was not exported, the price diverged, the card went into moderation.
- Logging and notifications — which events are written, who receives a notification about an exchange error, and how often the queue is checked.
- A staging environment for testing rules — a test contour where a new rule is run on a limited set of items before publication to the production catalog.
Each artifact is versioned together with the code, so changes to product placement rules are visible in the history and are rolled back with a single operation.
This removes dependence on a specific engineer: a new specialist gets up to speed from the documentation, not from chat threads.
We separately record control points — the discrepancy in the number of items between systems, the share of cards with attribute errors, and the time it takes for a full exchange to complete. These show whether the schema works after edits, and when it is time to step in.
Case study: how the share of rejected listings was reduced
The client is a manufacturer of home goods selling through marketplaces. Listings were published manually: a manager exported items from the ERP system, edited descriptions and attributes to meet each platform's requirements, and uploaded them through the seller dashboard.
With a catalog of several thousand active items, this produced a constant stream of rejections — platforms returned listings due to unfilled mandatory fields, category mismatches, duplicate barcodes, and description violations.
What it was like before the changes
The share of rejected listings held steady at around 30% of those submitted during the period. Each rejection meant another pass by the manager: find the reason in the platform's response, fix the attribute, resubmit.
One listing took an average of 40-50 minutes of manual work, and some items got "stuck" in the publishing queue for several days. The reasons for rejections were never recorded anywhere — the same errors repeated batch after batch.
What was changed
We moved the product listing rules out of instructions and managers' memory into configuration: mandatory attributes, allowed values, description requirements, and "category — characteristics" mappings for each platform.
The export from the ERP system now undergoes a preliminary check against these rules before submission — a listing with an incomplete attribute or a duplicate barcode does not go to the platform but instead lands in a report indicating the specific field.
Separately, we set up mapping of categories and characteristics between the ERP system and the platforms' reference catalogs so that values are populated automatically rather than selected manually.
Rejection logs are collected in one place — they show which rules trigger most often and which fields in the ERP system are filled in incompletely.
What it became after
The share of rejected listings dropped to 4-6% of those submitted — mostly discrepancies remain that the platform interprets according to its own internal rules.
The average time to publish an item shrank from several days to several hours, because validation and export happen in a single pass. The number of manual edits per batch fell by roughly five times: managers only handle the listings that ended up in the preliminary check report.
The project was led by our engineer for integrations with ERP systems and marketplaces; the listing rules are described in configuration rather than in a paper policy — so they are applied automatically to every export.
How do the rules differ for different marketplaces?
Platforms differ in three things: mandatory card attributes, naming rules, and category structure.
One marketplace requires a barcode and supplier SKU in a separate field, another requires category nesting strictly according to its own taxonomy, and a third rejects a card without a filled-in country of manufacture.
The product is physically one, but there are three different sets of requirements for its description.
Because of this, the catalog cannot be uploaded "as is": the same item passes moderation on one platform and ends up rejected on another.
The reason is almost always not in the data itself, but in how it is laid out across fields — the value exists, but it is not where the platform expects it.
A unified catalog solves this through a layer of rules between the accounting system and the platforms.
The product is stored once in 1C or Bitrix, and placement rules describe how to build a card from it for each platform: which attributes are mandatory, how categories are mapped, and what to do with missing values. The nomenclature is not duplicated, and marketplace requirements live as separate settings.
Platform differences change — new mandatory fields appear, categories move. When catalog adaptation is described by rules, an edit takes one export profile rather than manually rebuilding cards.
A unified catalog with configurable layout per platform is the answer to the question: the rules are different, the data source is one.
Common technical questions about setting up rules
Placement rules almost never exist in a vacuum: they intersect with stock levels, prices, categories, and promotions, and sooner or later two rules start claiming the same product. Below are the technical questions that most often come up during setup and after launch.
What happens if two rules conflict with each other?
Rules are applied by priority, not by order of creation: the engine checks conditions sequentially and stops at the first match. If two rules overlap in conditions and have the same weight, a product may end up in the wrong category or receive the wrong set of attributes.
We set explicit priorities and add an overlap check — when saving the configuration, the system warns about duplicate conditions instead of silently choosing one of the rules.
Can rules be updated without stopping the site and exports?
Yes. Rules are stored separately from catalog data, so editing them does not require downtime: changes are applied to the next exchange cycle, while current exports to the marketplace continue using the previous configuration.
We run the new version of the rules on a test copy of the catalog, verify the result against a control sample of products, and only then enable it in the production environment.
Rollback — reverting to the previous configuration — takes minutes and does not affect already exported items.
Who is responsible for errors in the rules, and how are they tracked?
We delineate responsibility at the launch stage: the logic of the rules and its correctness are our area, while the accuracy of the source data in the accounting system is on the client's side.
Every rule trigger is logged: you can see which condition fired, which product was processed, and what changed.
Using these logs, we investigate incidents without the back-and-forth of "everything is correct on our end" — there is a specific record and a specific condition.
What happens to products that did not fall under any rule?
A default rule is set for them: usually a separate category or a temporary exclusion from the export. This way a product does not silently disappear from the catalog — it either goes into a reserve group or remains in its previous category until manual review.
We keep a separate list of such items to see whether the "tail" is growing and whether it is time to expand the conditions.
Let's discuss your product listing task
To make the conversation substantive rather than "tell us in a nutshell," it helps to gather a minimum of input in advance. Below is what we clarify and what data we prepare so we can come back with an estimate and a plan, not generalities.
What we clarify at the start
- Which marketplaces are already connected and which are planned: the set of product listing rules differs from channel to channel.
- Where the catalog comes from: an export from 1C, a separate database, or manual maintenance — the mapping scheme depends on this.
- How product cards are prepared now: description templates, photo requirements, mandatory attributes by category.
- Who is responsible for content and who approves the rules — you need a single decision owner, otherwise approvals drag on.
- What hurts most: rejected items, duplicates, price and stock discrepancies, or manual edits before every publication.
What to prepare
- A catalog export with categories and attributes — in the form in which it currently goes to the marketplaces.
- Examples of rejected product cards with the marketplace's wording: they show which rules are not being met.
- A list of mandatory fields for each category, if it is already fixed.
- The exchange scheme between the accounting system and the website: how often and in which direction data flows.
- Access to a test environment — there we check the rules before publication without touching the production catalog.
Next steps
- We get on a call and go through the current listing process: where the rules are set, where they are violated, where things are edited by hand.
- We compare your data against the marketplace requirements and find discrepancies.
- We fix the list of rules: mandatory attributes, formats, category restrictions.
- We prepare an estimate and an implementation plan with stages and checkpoints.
- We agree on the order of work and launch on the test environment.
Describe your task — which marketplaces, where the catalog comes from, and what is getting in the way now. We will come back with an estimate and a plan showing which rules we configure and in what order.