Сайт-агрегатор: что это, как устроен и сколько стоит разработка

Агрегатор собирает предложения десятков независимых поставщиков в один каталог и зарабатывает не на товаре, а на том, что помогает покупателю выбрать. Снаружи это обычный сайт с поиском и фильтрами, внутри — конвейер: приём данных из разных источников, приведение их к общему виду, склейка одинаковых позиций, поисковый индекс и правила выдачи. В разборе — чем агрегатор отличается от маркетплейса и доски объявлений, из каких блоков он собирается, откуда берёт данные, как зарабатывает, что о нём говорит закон, а также этапы, сроки и порядок расходов на разработку.

7 сентября 2026 Бизнес 17 мин чтения

---

Что такое сайт-агрегатор простыми словами

Сайт-агрегатор — это площадка, которая собирает предложения множества независимых поставщиков в один каталог и приводит их к общему виду. Она даёт человеку то, чего у отдельного поставщика нет: возможность искать, фильтровать и сравнивать в одном окне. Своего товара у агрегатора нет. Его продукт — это выбор.

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

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

• Много независимых источников. Данные приходят от разных компаний, у каждой свой формат, своя частота обновления и своя логика цен.
• Единая структура данных. Разнородные выгрузки приводятся к общему справочнику категорий, характеристик и единиц измерения — иначе сравнивать нечего.
• Ценность в поиске и сравнении. Главные экраны площадки — это поиск, фильтры и карточка сравнения, а не витрина собственного бренда.
• Доход не от продажи товара. Площадка берёт деньги за переход, за заявку, за размещение или за место в выдаче, а не с наценки на товар.

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

Агрегатор, маркетплейс, доска объявлений и каталог

Эти четыре модели постоянно путают, и путаница стоит денег: под каждую нужен свой продукт, свой договор с поставщиком и своя команда сопровождения. Разделяются они по одному вопросу — где заканчивается сделка и кто за неё отвечает.

Две последние строки объясняют, почему у моделей разная экономика. Агрегатору проще подключать поставщиков: чтобы попасть в каталог, компании достаточно отдать выгрузку, а не перестраивать логистику. Но и рычагов у него меньше — если поставщик не отгрузил товар, площадка узнаёт об этом от покупателя. Маркетплейс устроен наоборот: подключение сложнее, зато вся сделка проходит внутри и площадка ей управляет. Это не «лучше» или «хуже», это разный набор обязанностей и разная стоимость продукта.

Если вы выбираете между этими моделями, а не разбираетесь в терминах, посмотрите разбор бизнес-моделей маркетплейсов — там подробно про комиссию, абонентскую плату продавца и их сочетание, — и материал о том, запускать площадку с нуля или на готовой платформе.

Отдельно отметим гибриды. Крупные площадки редко остаются в одной модели: агрегатор с ростом добавляет приём оплаты и превращается в маркетплейс, доска объявлений вводит безопасную сделку и делает то же самое. Это нормальный путь развития, но его нужно закладывать в архитектуру заранее — иначе приём платежей и расчёты с поставщиками придётся встраивать в систему, которая под них не проектировалась.

Пять видов агрегаторов и что меняется в разработке

Слово «агрегатор» описывает принцип, а не продукт. Между ценовым сравнением товаров и подбором страхового полиса общего только то, что данные приходят от разных компаний. Всё остальное — источники, скорость обновления, устройство поиска — различается настолько, что сметы отличаются в разы.

Разница между первым и третьим видом стоит того, чтобы её проговорить отдельно, — именно на ней чаще всего ошибаются в бюджете. Товарный агрегатор работает с выгрузками: поставщик присылает файл раз в час или раз в сутки, площадка кладёт его в свою базу и дальше ищет по себе. Агрегатор бронирования так не может: свободных мест на завтра во вчерашней выгрузке нет. Он обязан спрашивать поставщиков в момент запроса пользователя и ждать ответа от каждого. При этом нужно уложиться в приемлемое время отклика и решить, что делать с теми, кто не ответил. Это другая архитектура и другая стоимость: системы, рассчитанные на пиковые нагрузки, проектируются иначе с самого начала.

Ещё один практический вывод: чем ближе площадка к деньгам клиента, тем строже требования. У финансовых и страховых агрегаторов к обычной разработке добавляются требования к хранению персональных данных и к точности расчёта, а любая ошибка в правилах поставщика — это не «неверная цена на экране», а неверное обязательство перед человеком.

Как устроен агрегатор изнутри: семь блоков

Со стороны пользователя агрегатор — это строка поиска, список предложений и карточка. Со стороны разработки это семь подсистем, и каждая живёт по своим правилам. Ниже — что делает каждая и что в ней ломается чаще всего.

1. Приём данных

Модуль, который забирает предложения у поставщиков. По расписанию скачивает файлы, обращается к программным интерфейсам, принимает загрузки из личного кабинета. Здесь же — журнал загрузок и контроль качества: сколько строк пришло, сколько отклонено и почему. Без этого журнала разбор жалобы «у меня пропал товар» превращается в расследование на несколько часов.

2. Нормализация и склейка

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

3. Поиск и индекс

Поиск в агрегаторе — это отдельная система, а не запрос в базу данных. Ей нужны русская морфология, обработка опечаток, синонимы и мгновенные фильтры по характеристикам. Морфология отвечает за то, чтобы «кроссовки мужские» и «мужские кроссовок» давали один результат. На каталоге в несколько тысяч позиций разницу можно не заметить; на сотнях тысяч поиск по базе перестаёт отвечать за разумное время, и переделывать его придётся уже под нагрузкой.

4. Правила выдачи

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

5. Личный кабинет поставщика

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

6. Модерация

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

7. Учёт и расчёты

Подсистема, которая считает то, за что площадка получает деньги: переходы, заявки, показы. Сюда же входит защита от накруток и сверка с поставщиком — спор «мы получили не столько заявок» решается только журналом событий, который обе стороны считают достоверным. И отсюда же данные уходят в выставление счетов и закрывающие документы.

Отдельно про мобильное приложение. Для агрегатора оно не обязательно на старте: спрос проверяется сайтом, потому что человек приходит из поиска, а не из магазина приложений. Приложение становится нужным, когда у площадки появляются повторные визиты и есть что доставлять уведомлениями — изменение цены, новое предложение по подписке, статус заявки. Тогда полезно, чтобы сайт и приложение работали на одной кодовой базе: один каталог, один поиск, одни правила выдачи и один набор доработок вместо двух. Технически это делается на кроссплатформенной разработке — Flutter собирает из одного кода версии для App Store, Google Play, RuStore и веб.

Откуда берутся данные: четыре способа наполнения

Вопрос «где взять предложения» решается раньше, чем вопрос «на чём писать». Способов четыре, и в живой площадке обычно работают сразу несколько: крупные поставщики отдают программный интерфейс, средние — файл, мелкие заполняют карточки руками.

О четвёртом способе стоит сказать прямо. Сбор данных с чужих сайтов технически несложен и потому выглядит привлекательно на старте, но как основа для бизнеса он ненадёжен сразу по трём причинам. Он ломается при каждом изменении вёрстки источника, и его блокируют. Главное — он затрагивает пользовательские соглашения сайтов-источников и права на содержимое базы данных. Разумная область его применения — проверка гипотезы до первых договоров: посмотреть, есть ли вообще спрос на сравнение в этой нише. Всё, что дальше, строится на договорённостях с поставщиками.

Практический совет по формату. Не изобретайте свой формат выгрузки. У розничных поставщиков уже есть файлы для торговых площадок, и принять привычный формат почти всегда дешевле, чем убедить полсотни компаний собрать новый. Отдельно предусмотрите приём выгрузок из учётной системы. У большинства российских поставщиков товарные данные живут в 1С, и интеграция с учётной системой снимает половину вопросов об актуальности остатков и цен.

И заложите в план работ то, о чём вспоминают в последний момент: изображения. Ссылки на картинки в чужих выгрузках отваливаются, картинки приходят в разных размерах и весе. Своё хранилище изображений с перекодированием — небольшая по объёму, но обязательная часть площадки; без неё каталог со временем покрывается пустыми плашками. Как устроен обмен данными между системами и почему интерфейс поставщика стоит версионировать — в разборе проектирования программных интерфейсов.

Как агрегатор зарабатывает

Поскольку сделка чаще всего проходит не на площадке, комиссия с оборота агрегатору недоступна. Он продаёт доступ к своей аудитории, и делает это пятью способами. В зрелой площадке они обычно сочетаются.

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

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

Что закон требует от владельца агрегатора

Это тот раздел, который проще пропустить и дороже всего пропускать. Российское законодательство выделяет владельца агрегатора информации о товарах и услугах в отдельную фигуру: соответствующие поправки в Закон «О защите прав потребителей» действуют с 1 января 2019 года. Из этого следуют обязанности, которые превращаются в конкретные экраны и поля в базе данных.

• Информация о продавце — обязательна. Покупатель должен видеть, у кого он покупает в действительности: наименование компании, регистрационные данные, адрес. Значит, в карточке поставщика эти поля не опциональны, а в выгрузке их придётся требовать.
• Ответственность за достоверность. Владелец агрегатора отвечает за убытки, которые потребитель понёс из-за недостоверной информации о товаре или продавце, размещённой на площадке. Отсюда — журнал изменений цен и характеристик: нужно уметь показать, что и когда отображалось.
• Предоплата. Если площадка принимает предоплату, закон описывает случаи, когда она обязана вернуть деньги потребителю. Это меняет продукт: нужен возврат средств, статусы заказа и порядок разбора спора.
• Персональные данные. Площадка собирает контакты пользователей и передаёт их поставщикам. Обработка персональных данных требует согласия, политики обработки и уведомления регулятора — а передача данных партнёру должна быть описана в этом согласии.
• Реклама в выдаче. Платное продвижение позиций подпадает под правила распространения интернет-рекламы, включая маркировку. Пометка и учёт таких размещений — часть продукта, а не задача маркетинга «на потом».

Оговорка по существу: объём обязанностей зависит от того, как именно устроена площадка — принимает ли она оплату, чьё имя стоит в договоре с покупателем, что именно она обещает в интерфейсе. Разбирать это нужно с юристом под конкретную модель до старта разработки, потому что часть требований влияет на схему данных, а менять её после запуска дороже всего.

Практический вывод для команды разработки один: перечисленное — не «юридическая обвязка поверх готового сайта», а требования к продукту. Поля поставщика, журнал изменений, согласия, пометки в выдаче и возврат предоплаты закладываются в техническое задание вместе с остальными функциями.

Этапы разработки и сроки

Ниже — порядок работ и сроки в рабочих днях для площадки среднего размера: десятки поставщиков, файловые выгрузки, поиск по каталогу, кабинет партнёра и одна модель заработка. Сроки указаны для каждого этапа отдельно; итоговый календарь короче их суммы, потому что часть этапов идёт одновременно на разных ролях команды.

Сумма по этапам — от 51 до 88 рабочих дней. В календаре первый запуск обычно занимает 40–70 рабочих дней, и разница объясняется без всякой магии: дизайн начинается, пока идёт согласование технического задания, тестирование ведётся с первого рабочего модуля, а не после сдачи, а подключение поставщиков начинается до публикации. Кроме того, часть каталожных функций — витрина, карточка, поиск, личный кабинет, оплата — не пишется с нуля: это готовые модули, которые остаётся настроить под задачу.

Где чаще всего срывается срок

По нашему опыту проектов с большими каталогами срок ломается не в разработке, а в данных. Три типичные ситуации.

• Боевые выгрузки приходят в конце. Пока команда работает на демонстрационных данных, всё сходится. Настоящие файлы поставщиков приносят пустые характеристики, чужие категории и цены в неожиданных единицах. Лечится одним правилом: первую боевую выгрузку берут на этапе технического задания, а не на этапе запуска.
• Правила склейки не описаны заранее. «Похожие товары объединяем» — это не требование, а намерение. Требование выглядит иначе: по какому полю опознаём, что делаем при совпадении штрихкода и расхождении характеристик, кто разбирает спорные случаи.
• Поиск проверяют на маленьком каталоге. На тысяче позиций отвечает любая реализация. Проверять поиск нужно на объёме, близком к боевому, — для этого и существует нагрузочное тестирование, и делать его лучше до запуска, а не после первой рекламной кампании.

Сколько стоит разработка агрегатора

Итоговая сумма складывается из двух частей, и путать их не стоит. Первая — каталожная: витрина, карточка, поиск, личный кабинет, оплата, уведомления. Эта часть типовая, её умеют делать быстро и на готовых блоках. Вторая — собственно логика агрегатора: приём данных из разных источников, нормализация, склейка, правила выдачи, учёт переходов и заявок, расчёты с поставщиками. Она уникальна для каждой площадки и считается отдельно.

Отсюда три подхода к запуску. В таблице — их сравнение в одинаковых единицах: суммы в рублях, сроки в рабочих днях.

Разовая сумма кастомной разработки покрывает разный объём работ, и его стоит уточнять при сравнении: обычно в смету входят исследование, проектирование, дизайн, серверная и клиентская части, тестирование и запуск, а сопровождение после релиза в неё не входит. Две строки в этой таблице выигрывает не платформа, и это честно: у кастомной разработки нет ограничений архитектуры, а конструктор даёт самый дешёвый способ проверить, есть ли вообще спрос на сравнение в вашей нише. Слабое место конструктора видно сразу за этим: как только площадке понадобится собственная логика склейки или своя модель заработка, развиваться в его рамках будет некуда.

Из чего складывается коммерческое предложение

Модель оплаты в FITTIN состоит из трёх частей, и в статье про бюджет их стоит назвать все три, потому что по отдельности каждая вводит в заблуждение. Первое — единоразовый платёж за интеграцию: разворачивание платформы под бренд, настройка модулей, интеграции с учётной системой и оплатой, фирменный дизайн, публикация. Второе — ежемесячные лицензионные платежи, в которые уже включены все затраты на техническую поддержку команды FITTIN: наблюдение за работой, обновления модулей и обновления безопасности; собственная команда разработки при этом не требуется. Третье — новый функционал и доработки: они считаются отдельно, по модели Time & Materials, с оценкой по часам и сметой до старта задачи. Логика агрегатора относится именно к третьей части. Действующие пакеты и суммы — на странице тарифов; про выбор между фиксированной ценой и оплатой за затраченные часы — в разборе Time & Materials и Fix Price.

Что обычно не входит в смету разработки

• Серверная инфраструктура и хранилище изображений — оплачиваются провайдеру, растут вместе с каталогом.
• Внешние сервисы: карты, отправка сообщений, приём платежей, антифрод — у каждого свой тариф.
• Люди в модерации и поддержке поставщиков — постоянная статья расходов площадки.
• Наполнение и подключение партнёров: переговоры, помощь с выгрузками, проверка данных.
• Привлечение аудитории — поисковое продвижение, реклама, работа с содержимым страниц.

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

Как выбрать подрядчика: чек-лист

Агрегатор — не сайт с каталогом, и проверять команду стоит по тем местам, где такие проекты обычно ломаются. Восемь вопросов, которые имеет смысл задать до договора.

• Просят ли боевую выгрузку до оценки. Команда, которая называет срок, не посмотрев на данные поставщиков, оценивает витрину, а не площадку.
• Как описаны правила склейки. В предложении должно быть сказано, по каким полям объединяются позиции и что происходит при расхождении. Формулировка «объединим похожие товары» — это ещё не требование.
• Что предлагается для поиска. Ответ «поиск по базе данных» на каталоге в сотни тысяч позиций означает переделку в первый же сезон высокого спроса.
• Есть ли кабинет поставщика в первой версии. Если нет — уточните, кто и сколько часов в месяц будет вести партнёров вручную.
• Как считаются переходы и заявки. Спросите про журнал событий и защиту от накруток: это то, чем закрываются споры с поставщиками.
• Что с правовой частью. Заложены ли данные о продавце, согласия на обработку персональных данных, пометка платных мест в выдаче.
• Кому принадлежит код и данные. Условия по исходному коду и по выгрузке базы фиксируются в договоре — это вопрос к юристам обеих сторон, и задавать его нужно до подписания.
• Как устроена поддержка после запуска. Что входит в регулярный платёж, что считается доработкой, за какое время разбирается сбой загрузки данных.

Формальную часть удобно проверить за десять минут: сведения о юридическом лице, наличие компании в реестре аккредитованных ИТ-организаций, публичные проекты со ссылками. Если проект достаётся вам по наследству от другой команды, начинать разумно не с доработок, а с аудита кода и аудита интерфейсов — это дешевле, чем чинить архитектуру по ходу.

По технологиям для площадки такого класса всё довольно стандартно: серверная часть на Django или FastAPI, отдельный поисковый индекс, очередь для обработки выгрузок, клиентская часть — сайт и, при необходимости, приложение. Наша платформа зарегистрирована в реестре российского программного обеспечения — для площадок, работающих с государственными заказчиками, это иногда обязательное условие.

Проекты, где решались задачи агрегатора

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

Если площадка ближе к доставке или к логистике, полезны разборы смежных форматов: своё приложение доставки или агрегатор и приложения для служб доставки.

Итог: агрегатор на одной странице

Агрегатор — это площадка, которая собирает предложения независимых поставщиков в один каталог и зарабатывает на том, что помогает выбрать. Витрина в нём — самая простая часть; стоимость и сроки определяют данные: как они приходят, как приводятся к общему виду и как ищутся.

Что делать дальше

• Посчитать порядок бюджета и срока под состав первой версии.
• Заказать разработку технического задания — схема данных и правила склейки фиксируются здесь.
• Сравнить тарифы на каталожную часть и посмотреть, что входит в лицензию.
• Обсудить проект с командой — федеральная команда FITTIN с центром разработки в Воронеже.

Смежные материалы кластера: сколько стоит приложение для маркетплейса, минимальная работающая версия продукта и услуги — разработка информационных сайтов и порталов, разработка SaaS-платформы, кастомные сайты, разработка программного обеспечения на заказ, B2B-платформы для юридических лиц, техническая поддержка и тестирование.

Часто задаваемые вопросы

Чем сайт-агрегатор отличается от маркетплейса?

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

Можно ли запустить агрегатор на данных, собранных с чужих сайтов?

Как способ проверить спрос — да, как основа бизнеса — нет. Автоматический сбор чужих страниц ломается при каждом изменении вёрстки источника, его блокируют, и он затрагивает пользовательские соглашения сайтов и права на содержимое баз данных. Кроме того, у такой площадки нет главного — договорённостей с поставщиками, а значит, ей нечего им продать: без договора не будет ни оплаты за переходы, ни ответственности за актуальность цен. Разумная последовательность — собрать небольшой срез данных, проверить, есть ли интерес к сравнению в этой нише, и на этих цифрах идти договариваться о выгрузках.

Сколько стоит разработка сайта-агрегатора?

Считать удобно по двум частям. Каталожная — витрина, карточка, поиск, личный кабинет, оплата — собирается из готовых модулей: интеграция под бренд от 525 000 ₽ единоразово и от 150 000 ₽ в месяц за лицензию, в которую уже включена техническая поддержка. Логика самого агрегатора — приём выгрузок, нормализация, склейка, правила выдачи, учёт переходов и заявок — уникальна для каждой площадки и считается отдельно, по модели Time & Materials с оценкой по часам до старта задачи. Для сравнения: разработка такой площадки с нуля обычно начинается от 5 000 000 ₽ — в эту смету входят исследование, проектирование, дизайн, серверная и клиентская части, тестирование и запуск, а сопровождение после релиза в неё не входит и оплачивается отдельно, своей командой или подрядчиком. Точная сумма зависит от числа источников, их форматов и размера каталога, поэтому оценку дают после того, как посмотрят боевую выгрузку поставщика.

Сколько времени занимает запуск агрегатора?

Для площадки среднего размера — десятки поставщиков, файловые выгрузки, поиск по каталогу, кабинет партнёра и одна модель заработка — первый запуск занимает 40–70 рабочих дней в календаре. Сумма отдельных этапов больше, от 51 до 88 рабочих дней, но часть работ идёт одновременно: дизайн начинается во время согласования технического задания, тестирование ведётся с первого рабочего модуля, подключение поставщиков начинается до публикации, а каталожные функции не пишутся с нуля — это готовые модули, которые настраиваются под задачу. Дольше всего обычно тянутся не работы, а данные: пока поставщики не прислали боевые выгрузки, срок оценивается приблизительно.

Нужно ли агрегатору мобильное приложение сразу?

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

Как агрегатор зарабатывает, если оплата проходит не у него?

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

Поставщики отдают данные в разных форматах — что с этим делать?

Это нормальное состояние, а не проблема конкретного проекта, и решается оно на двух уровнях. Первый — приём: площадка поддерживает несколько привычных форматов выгрузки и умеет принимать данные через программный интерфейс, а для мелких партнёров даёт заполнение карточек в кабинете. Изобретать собственный формат и просить полсотни компаний под него перестроиться дороже, чем принять то, что они уже умеют отдавать. Второй уровень — нормализация: входящие категории и характеристики сопоставляются с внутренним справочником площадки по заранее описанным правилам. Именно эти правила стоит зафиксировать в техническом задании, потому что переписывать их на работающем каталоге дорого.

Какие требования закон предъявляет к владельцу агрегатора?

В российском законодательстве владелец агрегатора информации о товарах и услугах выделен в отдельную фигуру: соответствующие положения Закона «О защите прав потребителей» действуют с 1 января 2019 года. Из общих требований следует несколько вещей, которые видны прямо в продукте: покупатель должен видеть сведения о продавце, площадка отвечает за достоверность размещённой информации о товаре и продавце, а при приёме предоплаты закон описывает случаи её возврата. Добавьте сюда обработку персональных данных с согласием пользователя и передачу контактов партнёру, а также маркировку платных мест в выдаче. Точный объём обязанностей зависит от модели площадки, поэтому его разбирают с юристом до старта разработки: часть требований влияет на схему данных, а менять её после запуска дороже всего.

Материал носит информационно-аналитический характер, отражает оценку команды FITTIN на дату публикации.