Информационные модели в PIM. Как правильно структурировать данные о товарах
Почему информационная модель критична
Информационная модель товара — это архитектура, которая определяет, какие данные вы собираете, как они организованы и как они взаимодействуют между собой. Это не просто список полей. Это фундамент, на котором стоит вся работа с товарными данными.
Вот в чём разница:
Без правильной модели: категорийный менеджер добавляет случайные поля, маркетолог структурирует данные по-своему, интегратор с маркетплейсами ломает голову, потому что требования не совпадают. Результат: хаос, ручная переработка данных, ошибки при выгрузке.
С правильной моделью: данные поступают структурированно, легко масштабируются, автоматически синхронизируются с маркетплейсами, не нужна постоянная переделка.
Плохая информационная модель стоит компании дороже, чем хорошая PIM-система. Потому что система — это инструмент, а модель — это то, как вы думаете о своих товарах.
Что такое информационная модель
Информационная модель — это набор правил и структур, которые описывают, какую информацию вы храните о товаре, в каком формате, с какими ограничениями.
Состоит из четырёх элементов:
1. Иерархия категорий — как вы организуете товары в дерево категорий. Это не просто удобство для навигации, это основа для применения разных моделей к разным товарам.
2. Атрибуты — свойства товара (размер, цвет, материал, вес, мощность). Каждый атрибут имеет тип данных, обязательность и допустимые значения.
3. Группы атрибутов — логическое объединение атрибутов по смыслу. Например, "Основные характеристики", "Размеры и вес", "Медиа", "Категоризация", "SEO". Группы упрощают навигацию для менеджеров и структурируют карточку товара.
4. Справочники и словари — предопределённые списки значений для атрибутов (например, все возможные цвета или материалы). Это обеспечивает консистентность данных.
Иерархия категорий: Как правильно построить дерево
Категоризация — это первое, что нужно определить. От этого зависит, сможете ли вы потом применять разные правила к разным товарам.
Принцип 1: Одна логика классификации
Дерево категорий должно быть построено по одному признаку на каждом уровне, иначе получится путаница.
Неправильно:
Электроника
├── Бытовая техника
├── Для кухни
├── Мощностью до 1000W
└── Чёрного цвета
Правильно:
Электроника
├── Кухонная техника
│ ├── Чайники
│ ├── Микроволновки
│ └── Блендеры
├── Уход за домом
│ ├── Пылесосы
│ └── Паровые швабры
└── Климатическое оборудование
├── Кондиционеры
└── Обогреватели
Принцип 2: Глубина дерева
Не нужно создавать категории глубже, чем это необходимо. 3–4 уровня обычно достаточно. Если углубляетесь на 7–8 уровней, значит, где-то ошибка в логике.
Принцип 3: Один товар — одна категория
В PIM-системе товар существует в единственном экземпляре и принадлежит только одной категории. Это не ограничение, это архитектурное решение:
- Категория определяет модель данных. Если товар в категории "Смартфоны", к нему применяется набор атрибутов для смартфонов. Если бы товар мог быть одновременно в "Смартфонах" и "Подарках", непонятно, какой набор атрибутов применять.
- Изменения вносятся один раз. Обновил описание — оно обновилось везде. Нет риска, что в одной категории актуальная цена, а в другой устаревшая.
- Нет дублирования данных. Один SKU = одна запись в системе. Это основа Single Source of Truth.
А как же навигация на сайте?
На сайте или маркетплейсе товар может отображаться в нескольких разделах. В PIM это решается через отдельную группу атрибутов "Категоризация", где для каждого канала создаётся свой справочник с деревом категорий этого канала.
Группа атрибутов: Категоризация
Категория сайта (справочник):
- Подарки к 8 марта
- Новинки
- Распродажа
- Хиты продажКатегория Ozon (справочник):
- Электроника > Аксессуары > Наушники
- Электроника > Аксессуары > КолонкиКатегория Wildberries (справочник):
- Электроника > Портативная акустика и наушникиКатегория Kaspi (справочник):
- Электроника > Аудиотехника > Наушники
Товар по-прежнему живёт в одной категории информационной модели (например, "Электроника > Аудио > Наушники"), которая определяет его атрибуты. А в какие разделы он попадёт на сайте или маркетплейсе — управляется через эти дополнительные справочники. Один товар может быть одновременно в "Подарках", "Новинках" и "Хитах продаж" на сайте, оставаясь единственной записью в PIM.
На практике: в GS1 есть стандарт GPC (Global Product Classification), который рекомендует эту логику. Используйте его как отправную точку, потом адаптируйте под вашу бизнес-логику.
Атрибуты: Типы, обязательность, группы
Атрибуты — это конкретные свойства товара. Каждый атрибут имеет:
Имя: понятное обозначение (например, "Материал корпуса", а не "Мат_корп")
Тип данных:
- Идентификатор — артикулы, SKU, любые идентификационные номера с ограничением по длине
- Текстовое поле — произвольный текст (описания, названия) с возможностью AI-генерации
- Блок с форматированием (HTML) — детальные описания с разметкой, ссылками и форматированием
- Список (одиночный выбор) — выбор одного значения из словаря (цвет, бренд, страна)
- Множественный список — выбор нескольких значений из словаря (доступные расцветки, совместимые аксессуары)
- Числовое поле — цены, рейтинги, количество с настройкой диапазона и формата
- Числовое поле с единицей измерения — вес, длина, объём с выбором единицы из словаря
- Изображение — фото товара с контролем формата, размера и количества
- Файлы — документация, сертификаты, инструкции (PDF и другие форматы)
- Ссылка (URL) — ссылки на внешние ресурсы
- Email — контактные адреса с валидацией формата
- Телефон — номера с автоматическим форматированием по стране
Обязательность:
- Обязательный — без этого поля товар не может быть выгружен на маркетплейс
- Рекомендуемый — желательно заполнить, но не критично
- Опциональный — заполняется если применимо к товару
Уровень применения:
- На товар (SKU) — уникальные для конкретного товара
- На категорию — одинаковые для всех товаров в категории
- На бренд — характеристики, общие для всех товаров бренда
Группы атрибутов:
Атрибуты объединяются в логические группы, чтобы менеджерам было проще ориентироваться в карточке товара:
Группа: Основные характеристики
- Название товара
- Описание
- Бренд
- МодельГруппа: Размеры и вес
- Длина
- Ширина
- Высота
- ВесГруппа: Медиа
- Фото
- Видеообзор
- Инструкция (PDF)Группа: Категоризация
- Категория сайта
- Категория Ozon
- Категория Wildberries
- Категория KaspiГруппа: SEO
- Meta title
- Meta description
- URL slug
Пример структуры атрибутов для смартфонов:
Категория: Электроника > Мобильные устройства > Смартфоны
Обязательные атрибуты:
- Название товара (текстовое поле)
- Описание (блок с форматированием)
- Фото (изображение, минимум 3 штуки)
- Бренд (список)
- Модель (текстовое поле)
- Цена (числовое поле)
- Остаток (числовое поле)Рекомендуемые атрибуты:
- Операционная система (список: iOS, Android)
- Объём памяти (список: 64GB, 128GB, 256GB)
- Экран (числовое поле с единицей измерения: дюймы)
- Батарея (числовое поле с единицей измерения: мАч)
- Камера (числовое поле: мегапиксели)
- Цвет (список)
- Гарантия (числовое поле: месяцы)Опциональные атрибуты:
- Комплектация (текстовое поле)
- Видеообзор (ссылка URL)
- Сертификаты (файлы)
Справочники и словари: Почему это критично
Справочник — это контролируемый список значений для атрибута. Вместо того чтобы каждый менеджер писал "красный", "Red", "алый", вы говорите: вот список цветов, выбирай из него.
Почему это важно:
- Консистентность: все данные имеют одинаковый формат
- Аналитика: можно правильно считать, сколько товаров красного цвета
- Фильтры и поиск: на сайте и маркетплейсах фильтры работают только с контролируемыми значениями. Если цвета заполнены через справочник, покупатель найдёт все красные товары одним кликом. Если через свободный ввод — часть товаров потеряется, потому что кто-то написал "алый" или "RED".
- Интеграции: когда данные синхронизируются с другими системами, они уже в правильном формате
Пример справочника цветов:
ID: RGB-001 → Красный
ID: RGB-002 → Чёрный
ID: RGB-003 → Белый
ID: RGB-004 → Синий
ID: RGB-005 → Зелёный
ID: RGB-006 → Жёлтый
ID: RGB-007 → Серебристый
Канал: Ozon
RGB-001 → Красный
RGB-002 → Чёрный
RGB-003 → БелыйКанал: Wildberries
RGB-001 → красный
RGB-002 → черный
RGB-003 → белыйКанал: Kaspi
RGB-001 → Қызыл / Красный
RGB-002 → Қара / Чёрный
RGB-003 → Ақ / Белый
Это разделение важно: справочник — это ваш внутренний стандарт, а маппинг на канал — это адаптация под требования конкретной площадки. Менеджер работает с понятными ему значениями, а система автоматически преобразует их в нужный формат при выгрузке.
Где это особенно критично:
- Размеры — одежда, обувь (S, M, L, XL vs. 42, 44, 46 vs. российская размерная сетка)
- Материалы — в зависимости от товара используются разные наборы материалов
- Страны производства — коды ISO для автоматизации таможенных данных
- Единицы измерения — кг, г, мл, л, м, см (особенно важно для интеграции с логистикой и 1С)
На практике: ISO 8000 рекомендует вести справочники в отдельной системе Master Data Management (MDM), откуда они подтягиваются в PIM. Это даёт одну точку управления для всех систем.
Принципы построения информационной модели
Когда вы начинаете с нуля или переделываете существующую модель, следуйте этим принципам:
1. Начните с аудита текущего состояния
Посмотрите, какие данные у вас есть сейчас. Где они хранятся? Как они структурированы? Какие поля используются, какие мёртвые? Это даёт понимание, что реально нужно, а что наследство из старой системы.
2. Определите источник истины для каждого атрибута
Откуда приходит информация? Цены из 1С, описания пишет маркетинг, фото загружает дизайн, спецификации поставщик прислал? Каждый атрибут должен иметь собственника и источник.
3. Думайте о маркетплейсах с самого начала
Посмотрите требования Ozon, Wildberries, Kaspi, Uzum. Какие поля обязательны? Какие форматы? Спроектируйте модель так, чтобы она покрывала требования большинства площадок.
4. Планируйте на масштабирование
Если сейчас 500 товаров, но планируете 50 000, модель должна это потянуть. Не создавайте специальные поля для одного товара, создавайте общие справочники.
5. Валидация на входе лучше, чем коррекция на выходе
Установите правила прямо в системе: какие поля обязательны, какие форматы допустимы. Это дешевле, чем потом чистить данные.
6. Версионируйте модель
Когда меняете структуру, не удаляйте старую. Создавайте версии: Model v1.0, v1.1, v2.0. Это упрощает миграцию и откат, если что-то пошло не так.
На практике: Примеры для разных индустрий
FMCG (Продукты питания и напитки)
Информационная модель должна включать:
Обязательные поля:
- Название продукта
- Описание
- Фото (фронт упаковки минимум)
- Состав (важно для аллергенов)
- Пищевая ценность (калории, белки, жиры, углеводы)
- Вес/объём
- Срок годности
- Условия хранения
- Знак ЕАС (для стран ЕАЭС)
Справочники:
- Тип продукта (напиток, закуска, молочное, мясо и т.д.)
- Аллергены (глютен, молоко, орехи, соя и т.д.)
- Страна производства
Электроника (техника, гаджеты)
Обязательные поля:
- Модель, производитель
- Технические характеристики (мощность, напряжение, размеры, вес)
- Гарантия
- Фото (разные ракурсы)
- Инструкция (PDF)
- Сертификат соответствия ЕАС
Справочники:
- Тип товара (микроволновка, холодильник, кофеварка)
- Цвет
- Материал корпуса
- Класс энергоэффективности
Одежда и обувь
Обязательные поля:
- Размер
- Материал (основной и подкладка)
- Цвет
- Фото (минимум спереди и сзади)
- Уход (как стирать)
- Состав ткани (в процентах)
Справочники:
- Размерная сетка (S, M, L, XL vs. 42, 44, 46 vs. российские размеры)
- Цвета (с учётом модных названий: "пыльная роза", "графит")
- Материалы (хлопок, полиэстер, шерсть, лён, смесовые)
- Сезон (весна-лето, осень-зима, демисезон)
Фармацевтика и товары для здоровья
Здесь требования жёстче из-за регуляторных ограничений.
Обязательные поля:
- Торговое наименование
- МНН (международное непатентованное наименование)
- Форма выпуска (таблетки, капсулы, сироп, мазь)
- Дозировка
- Количество в упаковке
- Производитель
- Регистрационное удостоверение
- Срок годности
- Условия хранения
- Инструкция по применению (PDF)
- Рецептурный/безрецептурный
Справочники:
- АТХ-классификация (анатомо-терапевтическо-химическая)
- Лекарственные формы
- Пути введения (перорально, наружно, инъекционно)
- Возрастные ограничения
Важно: в фармацевтике данные должны соответствовать требованиям Минздрава и Росздравнадзора. Ошибка в дозировке или противопоказаниях — это не просто плохой UX, это потенциальный судебный иск.
Локализация модели под разные рынки и маркетплейсы
Одна информационная модель редко подходит для всех каналов продаж. Каждый маркетплейс имеет свои требования, и модель должна это учитывать.
Разные маркетплейсы — разные требования
Ozon:
- Rich-контент (расширенные описания с графикой)
- Видеообложки
- Свои справочники цветов и размеров
- Обязательные характеристики зависят от категории
Wildberries:
- Фото на модели обязательно для одежды
- Специфичные размерные сетки
- Ограничения по длине названия
- Баркод обязателен
Kaspi (Казахстан):
- Двуязычный контент (казахский/русский)
- Локальные сертификаты
- Специфичные требования к доставке
Uzum (Узбекистан):
- Контент на узбекском и русском
- Местные требования к маркировке
- Специфичные категории товаров
Как это решается в информационной модели
Подход 1: Базовая модель + расширения
Создаёте ядро модели с общими атрибутами, а для каждого маркетплейса добавляете специфичные поля.
Базовая модель:
- Название
- Описание
- Цена
- Фото
- ХарактеристикиРасширение для Ozon:
- Rich-контент
- ВидеообложкаРасширение для Wildberries:
- Фото на модели
- Баркод
Подход 2: Маппинг атрибутов
Ваши внутренние атрибуты маппятся на атрибуты маркетплейса автоматически.
Внутренний атрибут "Цвет" → Ozon "Цвет" → Wildberries "Цвет" → Kaspi "Түсі/Цвет"
Внутренний атрибут "Материал" → Ozon "Материал" → Wildberries "Состав" → Kaspi "Материал"
PIM-система должна хранить этот маппинг и автоматически трансформировать данные при выгрузке.
Подход 3: Локализация контента
Для разных рынков нужны разные языковые версии. Модель должна поддерживать:
Название [RU]: Беспроводные Bluetooth-наушники
Название [KZ]: Сымсыз Bluetooth құлаққаптары
Название [UZ]: Simsiz Bluetooth quloqchinlariОписание [RU]: ...
Описание [KZ]: ...
Описание [UZ]: ...
При этом технические атрибуты (вес, размеры, мощность) остаются едиными, а текстовые локализуются.
Типичные ошибки при построении информационной модели
Ошибка 1: Плоская структура вместо иерархии
Проблема: Все товары в одной категории, все атрибуты применяются ко всем товарам. Менеджер видит 200 полей, из которых к его товару относятся 15.
Решение: Иерархия категорий + наследование атрибутов. Общие атрибуты на верхнем уровне, специфичные на нижнем.
Ошибка 2: Свободный ввод вместо справочников
Проблема: Поле "Цвет" — свободный текст. В базе: "красный", "Красный", "red", "алый", "RED", "краснй" (опечатка).
Решение: Справочник с контролируемыми значениями. Менеджер выбирает из списка, а не пишет руками.
Ошибка 3: Атрибуты-свалки
Проблема: Поле "Дополнительная информация", куда менеджеры пишут всё подряд. Невозможно использовать для фильтров или аналитики.
Решение: Если информация важна, создайте для неё отдельный структурированный атрибут. Если не важна — не собирайте.
Ошибка 4: Игнорирование требований маркетплейсов
Проблема: Модель спроектирована под внутренние нужды, а потом оказывается, что для Ozon нужен rich-контент, которого в модели нет.
Решение: Изучите требования всех каналов продаж ДО проектирования модели. Заложите эти поля сразу.
Ошибка 5: Отсутствие владельца данных
Проблема: Непонятно, кто отвечает за каждый атрибут. Маркетинг думает, что цены ведёт закупка. Закупка думает, что маркетинг. В итоге цены устаревшие.
Решение: Для каждого атрибута определите владельца и источник данных. Зафиксируйте это в документации.
Ошибка 6: Слишком жёсткая модель
Проблема: Модель спроектирована идеально, но бизнес меняется. Появился новый тип товара, а в модели для него нет места. Приходится всё переделывать.
Решение: Закладывайте гибкость. Используйте расширяемые справочники, опциональные атрибуты, возможность добавлять новые категории без переделки всей структуры.
Ошибка 7: Миграция без очистки
Проблема: Переезжаете на новую PIM-систему и просто переливаете старые данные. Вместе с мусором, дубликатами и ошибками.
Решение: Миграция — это возможность почистить данные. Сначала аудит, потом очистка, потом перенос в новую модель.
Инструменты и подходы к реализации
Где хранить информационную модель
В PIM-системе: Большинство современных PIM позволяют конфигурировать модель прямо в интерфейсе. Создаёте категории, добавляете атрибуты, настраиваете справочники.
В отдельном репозитории: Для крупных компаний модель может храниться в MDM (Master Data Management) системе, откуда синхронизируется в PIM, 1С, CRM и другие системы.
В документации: Как минимум должна быть спецификация модели в виде документа. Это помогает при онбординге новых сотрудников и при интеграции с внешними системами.
Стандарты, на которые стоит опираться
GS1: Глобальный стандарт идентификации и классификации товаров. GPC (Global Product Classification) даёт готовую иерархию категорий. GDSN (Global Data Synchronisation Network) определяет, какие атрибуты нужны для обмена данными между ритейлерами и поставщиками.
ISO 8000: Стандарт качества данных. Определяет требования к точности, полноте, консистентности и своевременности данных.
ГОСТ и ТР ТС/ЕАЭС: Технические регламенты Таможенного союза определяют обязательные атрибуты для разных категорий товаров на территории ЕАЭС.
Schema.org: Стандарт разметки данных для поисковых систем. Если ваши товары должны хорошо индексироваться, модель должна учитывать атрибуты из Schema.org Product.
Процесс внедрения
Шаг 1: Аудит текущих данных
- Где хранятся данные сейчас?
- Какие атрибуты используются?
- Какое качество данных?
- Какие проблемы возникают?
Шаг 2: Сбор требований
- Какие каналы продаж?
- Какие требования маркетплейсов?
- Какие внутренние процессы зависят от данных?
- Какие отчёты и аналитика нужны?
Шаг 3: Проектирование модели
- Иерархия категорий
- Атрибуты по категориям
- Группы атрибутов
- Справочники
Шаг 4: Валидация с командой
- Покажите модель категорийным менеджерам, маркетологам, интеграторам
- Соберите обратную связь
- Скорректируйте
Шаг 5: Пилот
- Загрузите 100–500 товаров
- Проверьте, что всё работает
- Выгрузите на один маркетплейс
- Найдите проблемы
Шаг 6: Масштабирование
- Загрузите остальные товары
- Подключите остальные каналы
- Настройте автоматизацию
Шаг 7: Поддержка и развитие
- Модель будет меняться вместе с бизнесом
- Назначьте ответственного за её развитие
- Регулярно пересматривайте и обновляйте
Заключение
Информационная модель — это не техническая деталь, которую можно отдать на откуп IT-отделу. Это бизнес-решение, которое влияет на скорость вывода товаров на рынок, качество данных на маркетплейсах, эффективность работы команд и возможность масштабироваться.
Правильно спроектированная модель:
- Упрощает работу менеджерам (они видят только нужные поля)
- Гарантирует качество данных (валидация на входе)
- Ускоряет интеграции (данные уже в нужном формате)
- Масштабируется без переделок (новые товары и категории добавляются легко)
- Обеспечивает точную фильтрацию и поиск (покупатели находят нужные товары, а не теряют их из-за разнобоя в данных)
Плохо спроектированная модель:
- Создаёт хаос (каждый заполняет как хочет)
- Порождает ошибки (несовместимые данные проходят валидацию)
- Тормозит интеграции (нужна ручная доработка при каждой выгрузке)
- Требует переделки при росте (модель не тянет новые требования)
Начните с аудита того, что есть. Изучите требования каналов продаж. Спроектируйте модель с учётом масштабирования. Валидируйте с командой. Внедряйте итеративно.
И помните: модель — это живой организм. Она будет меняться вместе с вашим бизнесом.
Заложите эту гибкость с самого начала.
Источники и стандарты:
- GS1 Global Product Classification (GPC): gs1.org/standards/gpc
- ISO 8000 Data Quality: iso.org/standard/60805.html
- Технические регламенты ЕАЭС: eaeunion.org
- Schema.org Product: schema.org/Product