Контент завод для Ozon: автозаполнение характеристик через Make.com

Контент завод для Ozon: автозаполнение характеристик через Make.com — схема настройки

Есть такой особый вид боли у продавцов на маркетплейсах: когда карточки вроде бы заведены, фотки нормальные, цена окей, а характеристики… характеристики живут своей жизнью. Где-то забыли материал, где-то перепутали цвет, где-то размер «универсальный», потому что в пятницу в 23:40 уже не было сил. На Ozon это потом превращается в странные показы, вопросы от покупателей и тихий внутренний монолог «я же это точно заполнял… или нет?». И самое смешное, что чаще всего это не лень, а просто масштаб: пятьдесят SKU еще можно руками, триста уже превращают человека в принтер.

В какой-то момент начинаешь мечтать о простом чуде: чтобы один раз аккуратно положить данные в понятное место, а дальше они сами, без нервов, улетали в карточки и обновлялись по расписанию. И вот тут Make.com (раньше Integromat) заходит как нормальный рабочий инструмент, а не как «еще одна штука, которую надо освоить». Сценарий читает ваши строки из Google Таблицы, собирает атрибуты и через API Ozon обновляет характеристики товара. Никакой магии, только дисциплина данных и немного терпения на настройке.

Что получится настроить и зачем это вообще нужно

После настройки у вас будет схема, которая берет характеристики из вашего источника (чаще всего Google Sheets), проверяет, что там нет мусора, и отправляет обновления в Ozon через API. Это значит, что вы сможете поддерживать карточки в актуальном состоянии без ручного «копипаста» и без риска, что один менеджер заполнил «полиэстер», а второй через неделю исправил на «хлопок» и забыл обновить половину товаров. Плюс это хороший фундамент под контент-завод: сегодня вы автоматизируете характеристики, а завтра прикручиваете генерацию описаний нейросетями, разбор отзывов, проверку запрещенных слов и другие радости взрослой жизни. Если захочется сразу потрогать Make.com, регистрация вот тут: https://www.make.com/en/register?pc=horosheff.

Пошаговая схема: автозаполнение характеристик Ozon через Make.com

Шаг 1. Готовим «источник правды» в Google Sheets

Сначала делаем одну таблицу, которая станет главным местом, где характеристики хранятся «как правильно». Обычно это Google Sheets: удобно, знакомо, можно давать доступ команде и быстро править. В таблице вам понадобятся идентификаторы товара, по которым вы будете обновлять карточки на Ozon (SKU, product_id или то, что вы используете в своей связке), название для ориентирования и отдельные колонки под характеристики. Зачем так строго? Потому что автоматизация любит структуру: если сегодня «цвет» в одной колонке, а завтра вы решили писать «цвет товара» в другой, сценарий не угадает ваши творческие поиски.

Типичная ошибка здесь простая и очень человеческая: смешивают форматы. В одной строке размер «42», в другой «42-44», в третьей «L», а потом удивляются, почему часть атрибутов не проходит. Проверка тоже простая: возьмите 5-10 SKU и руками пробегитесь глазами, нет ли пустых обязательных полей, странных пробелов в начале/конце, и совпадает ли формат у похожих товаров. Если на этом этапе чуть-чуть занудства, то дальше Make.com будет работать без истерик.

Шаг 2. Достаем доступы к Ozon API и не теряем ключи

Чтобы Make.com мог обновлять характеристики, ему нужен доступ к Ozon API. Вы получаете API-ключи в кабинете Ozon, дальше они используются в запросах. В Make.com обычно это делается через HTTP-модули (если у вас нет готового коннектора под нужный метод), и там важно аккуратно хранить секреты. Зачем такая осторожность? Потому что ключи это по сути «пропуск» к вашему магазину: потеряли, засветили в общем чате, и потом сами же будете бегать, перевыпускать и восстанавливать.

Частая ошибка: вставляют ключ в явном виде в поле, которое потом копируют коллегам «посмотри, что не работает», и ключ улетает в переписку. Проверка: делайте один тестовый запрос к API из Make.com (пустой или к безопасному методу, который возвращает данные) и убедитесь, что получаете ожидаемый ответ без 401/403. Если видите ошибки авторизации, сначала проверьте правильность ключа и заголовков, а уже потом ругайте Ozon и погоду.

Шаг 3. Собираем сценарий в Make.com: чтение строк из таблицы

Теперь в Make.com создаем сценарий, первым модулем ставим Google Sheets и настраиваем чтение данных. Обычно выбирают «Watch rows» или «Get a range» в зависимости от логики: вам нужно обновлять при изменении или по расписанию пачками. Зачем это выбирать заранее? Потому что разные режимы по-разному ведут себя на объеме: «смотреть изменения» удобно, но если у вас массовые правки, может быть шумно; «пачками по расписанию» проще контролировать, но обновления не мгновенные.

Типичная ошибка: тянут сразу всю таблицу на тысячи строк и удивляются, что сценарий идет долго или упирается в лимиты. Проверка: начните с диапазона на 10-20 строк или добавьте условие «обновлять только где стоит флаг Update = TRUE». Убедитесь, что Make.com реально получает нужные колонки и не путает их местами, иногда вобще (ой) бывает, что кто-то переименовал заголовок, и модуль начинает возвращать пустоту.

Шаг 4. Приводим характеристики к виду, который любит Ozon

На этом шаге вы превращаете «человеческие» значения в структуру, которую ожидает API Ozon: набор attributes, где каждому атрибуту соответствует нужный идентификатор и значение в правильном формате. Это та часть, где чаще всего люди залипают, потому что кажется: ну что там, «цвет» да «размер». А потом выясняется, что один атрибут принимает только справочник, другой только число, третий требует единицы измерения. Зачем возиться? Потому что Ozon не обязан угадывать, что вы имели в виду, он просто вернет ошибку или молча не применит обновление.

Типичная ошибка: отправляют «как есть», без сопоставления атрибутов и без валидации пустых значений. Проверка: берите один товар, формируйте payload в Make.com и смотрите, что уходит в запросе. Если в ответе приходит ошибка валидации, не пытайтесь «продавить» ее ретраями, лучше выяснить, какой атрибут ругается, и поправить маппинг. Мини-кейс из жизни: у знакомого менеджер контента за два вечера настроил таблицу под 120 SKU, но половина атрибутов не обновлялась, потому что «материал» был текстом, а в категории ожидался справочник. Исправили сопоставление и добавили проверку на допустимые значения, и дальше все стало стабильно.

https://kv-ai.ru/obuchenie-po-make

Шаг 5. Отправляем обновление характеристик в Ozon через HTTP и API-метод

Теперь ставим модуль HTTP в Make.com и настраиваем запрос к Ozon API на обновление характеристик. В теле запроса обычно передаются product_id и attributes, а также нужные поля, которые требует конкретный метод. Зачем это делать через HTTP? Потому что так вы не зависите от «готовых интеграций»: API Ozon меняется, методы дополняются, а HTTP модуль дает гибкость и прозрачность, вы видите весь запрос и ответ. Кстати, официальную документацию Ozon API лучше держать открытой рядом, это экономит массу времени и снижает желание швырнуть ноутбук в стену.

Типичная ошибка: путают идентификаторы, отправляют SKU вместо product_id или наоборот, и запрос проходит, но обновляет не то или ничего. Проверка: сначала гоните один товар, фиксируйте в таблице конкретный product_id и сравнивайте результат в кабинете Ozon. Мини-кейс: у небольшого бренда одежды обновления «вроде уходили», но в карточках изменения не появлялись. Оказалось, менеджер выгрузил IDs из отчета, где были идентификаторы другого уровня. После правильной привязки и одного контрольного обновления стало видно, что система работает, просто «ключ» был не тот.

Шаг 6. Добавляем фильтры и защиту от мусора

Дальше включаем взрослый режим и ставим фильтры. Например, обновляем только те строки, где есть обязательные поля, где статус «готово», где последняя правка была сегодня, или где не пустой product_id. Зачем? Потому что автоматизация без фильтров очень быстро начинает «усердно делать ерунду», а потом вы разгребаете последствия. Make.com хорош тем, что позволяет вшить логику прямо в сценарий: проверка условий, преобразования, пропуск пустых значений.

Типичная ошибка: фильтры делают слишком жесткими и сценарий перестает обновлять нормальные товары, или наоборот, слишком мягкими и он шлет пустые атрибуты. Проверка: включите логирование, посмотрите, сколько строк проходит фильтр, и сравните с ожиданиями. Еще полезно добавить «контрольное поле» в таблице, условно Updated_at, чтобы видеть, что строка реально отработала. Мини-кейс: владелец магазина электроники настроил обновление раз в ночь, но утром находил часть карточек без «мощности». Причина банальная: в таблице были пустые значения, которые перетирали заполненные в Ozon. Добавили правило «если пусто, не отправляй атрибут», и проблема исчезла.

Шаг 7. Тестируем на малом объеме и ставим расписание

Когда все собрано, не надо сразу запускать на весь каталог, даже если руки чешутся. Прогоните 3-5 товаров разных категорий и посмотрите, как они обновляются, какие ответы возвращает API, как быстро изменения появляются в интерфейсе Ozon. Зачем так осторожно? Потому что «в бою» всплывают детали: где-то атрибут обязателен, где-то формат другой, где-то товар в другой категории и у него другой набор характеристик. Малый тест сохраняет нервы и репутацию карточек.

Типичная ошибка: запускают по расписанию каждую минуту и создают себе же нагрузку и путаницу, особенно если в таблицу правки вносят пачками. Проверка: поставьте разумный интервал, например раз в час или раз в ночь, а для срочных правок оставьте ручной запуск сценария. И обязательно настройте уведомления об ошибках в Make.com, иначе узнаете о проблеме по отзывам покупателей, а это такой себе мониторинг.

Подводные камни: где чаще всего ломается и куда утекает время

Самая частая точка поломки это несоответствие справочников и форматов. Ozon может ожидать конкретные значения или тип данных, а в таблице живет «как привыкли». Когда каталог растет, появляются исключения: один и тот же атрибут по-разному устроен в разных категориях, и если вы маппите «в лоб», часть товаров будет возвращать ошибки. Здесь помогает дисциплина: отдельные листы под категории, явные поля под обязательные атрибуты и небольшая валидация до отправки. И да, документация Ozon API это не художественная литература, но иногда один абзац там экономит полдня.

Вторая зона риска это идентификаторы. Люди путают SKU, offer_id, product_id, а потом долго спорят с реальностью. На практике лучше один раз выбрать, что является основным ключом в вашей системе, и хранить вторые идентификаторы рядом, чтобы можно было сверить. Еще момент: доступы и ключи. Если вы работаете командой, не раздавайте ключи всем подряд, лучше держать сценарии в одном рабочем пространстве и выдавать доступы на уровне Make.com. Так меньше шансов, что кто-то случайно «пофиксит» прод в пятницу вечером.

Третья неприятность это обработка ошибок и повторные попытки. Если API временно отвечает ошибкой или сеть шалит, сценарий может остановиться и вы не заметите. Или наоборот, вы включили ретраи бездумно, и он начинает долбиться в API, пока не словит лимиты. Нормальная тактика: ловить ошибки, писать их в отдельный лог (хотя бы в ту же Google Таблицу), уведомлять в Telegram и оставлять возможность вручную переотправить конкретную строку. Кстати, если вам нужна инфраструктура, где многое уже подключено и настроено под автоматизации, присмотритесь к MCP сервис автоматизации «ВСЁ ПОДКЛЮЧЕНО», там удобно собирать такие штуки в систему, а не в набор разрозненных костылей.

Когда стоит учиться этому серьезнее, а не «по видосам на фоне»

Если у вас больше одного человека трогает данные, если каталог растет, если карточки обновляются регулярно, то навыки Make.com превращаются из «интересно попробовать» в «это экономит недели жизни в год». Особенно когда вы начинаете собирать не один сценарий, а связку: характеристики, цены, остатки, контент, уведомления, контроль качества. Тут важна не только кнопка «Run once», а умение проектировать поток, хранить секреты, делать валидацию, логировать ошибки и не превращать автоматизацию в хрупкий домик из спичек.

Полезнее всего заходят форматы, где есть разбор ваших реальных кейсов и обратная связь, потому что у всех разные категории, разные таблицы и свои «вот тут у нас исторически так». Если хочется выстроить систему быстрее и спокойнее, вот материалы и обучение: Обучение по Автоматизации, CursorAI, маркетингу и make.com, а если вам ближе подход «дай готовые схемы и я адаптирую», то есть Блюпринты по make.com. И да, хотите научиться автоматизации рабочих процессов с помощью сервиса make.com и нейросетей ? Подпишитесь на наш Telegram-канал. Отдельно напомню про MCP сервис автоматизации «ВСЁ ПОДКЛЮЧЕНО», он часто спасает, когда нужно не «собрать один сценарий», а наладить рабочую экосистему.

FAQ

Вопрос: Можно ли обновлять характеристики на Ozon только для части товаров, а не для всего каталога?

Ответ: Да, это делается фильтрами в Make.com и логикой в таблице. Самый понятный вариант: отдельная колонка-флаг, по которой сценарий берет только строки со значением TRUE или «Готово», а остальные игнорирует.

Вопрос: Почему Ozon API принимает запрос, но в карточке ничего не меняется?

Ответ: Обычно причина в неправильном идентификаторе товара или в том, что атрибуты отправлены не в том формате, который ожидает категория. Проверьте, что используете корректный product_id, и посмотрите ответ API: там часто есть подсказки по полям, которые не прошли валидацию.

Вопрос: Что лучше: обновлять по расписанию или «по изменению строки» в Google Sheets?

Ответ: Если правок немного и они точечные, удобно обновлять по изменению. Если вы часто редактируете пачками и хотите контроль, лучше расписание раз в час или раз в ночь, плюс ручной запуск для срочных случаев.

Вопрос: Как не перетирать заполненные характеристики пустыми значениями из таблицы?

Ответ: В сценарии нужно добавить проверку: если значение пустое, не включать этот атрибут в payload для API. Тогда вы обновляете только то, что реально задано, и не затираете карточку «пустотой».

Вопрос: Make.com обязательно подключать к нейросетям или можно без них?

Ответ: Можно вообще без нейросетей и получить отличный результат: чистая автоматизация импорта и обновления данных. Нейросети подключают, когда хотят масштабировать описания, названия, анализ отзывов или контроль качества текста, но это уже следующий слой.

Вопрос: Где хранить API-ключи, чтобы не словить проблемы с безопасностью?

Ответ: Держите ключи в настройках соединений Make.com и не вставляйте их в поля, которые копируются между людьми или отправляются в чаты. Если доступ нужен команде, лучше управлять правами в Make.com и фиксировать, кто может редактировать сценарии.

Вопрос: Если сценарий упал на ошибке, как понять, что именно сломалось?

Ответ: Смотрите историю выполнения в Make.com и конкретный шаг, на котором произошел сбой: там будет запрос и ответ. Полезно заранее настроить уведомления и логирование ошибок в отдельный лист Google Sheets, чтобы не искать проблему «по ощущениям».