Работа информационного агрегатора 2023

Привет, друзья. Я запустил свой первый агрегатор в нише школ английского языка. Вывел проект в плюс, затем продал его. Далее я опробовал следующие ниши: онлайн-сервисы, онлайн-курсы, мрт-центры, детские лагеря. Какие-то агрегаторы я вывел в плюс и продал, какие-то оставил как активы.

Пробую новые ниши.

Про весь этот опыт я написал 12 статей на vc.ru. В каждой из этих статей я затрагивал какие-то отдельные аспекты этого направления, делился личным опытом. Так же я продаю движок для агрегатора тем, кто хотел бы создать и развить свой агрегатор.

Все эти люди изначально изучают вопрос и задают разные вопросы.

Цель данной статьи попытаться сделать краткую выжимку из всех 12 статей и вообще из моего опыта работы с агрегаторами.

Что такое агрегатор?

Агрегатор — сайт, который агрегирует (собирает) и классифицирует информацию и предложения разных компаний на одном ресурсе. Сам сайт-агрегатор зарабатывает на комиссии с продаж товаров и услуг тех компаний, которые представлены на портале.

Какие типы агрегаторов бываю?

Образовалось достаточно много похожих терминов в данном направление:

агрегатор услуг, товарный агрегатор, маркетплейс, справочник, классифайд, каталог. Достаточно легко запутаться, чем один тип сайта отличается от другого. Но различия всегда есть.

1. Агрегатор компаний, оказывающих услуги. (он же каталог, он же справочник)

2. Товарный агрегатор. (Маркетплейс). С возможностью добавлять товар в корзину.

3. Товарный агрегатор (без продажи на сайте). В отличие от маркетплейса, такой агрегатор не является полноценной площадкой для купли-продажи товара. Это просто справочник, который собирает товары и услуги со всех интернет-магазинов и дает на них ссылки.

Самым ярким представителем такой модели был Яндекс-маркет, который со временем поменял модель и стал маркетплейсом.

4. Классифайд (пользователи сами создают объявления). Один из самых известных примеров — Avito

Агрегаторы компаний, оказывающих услуги

Лично я занимался и занимаюсь именно такими агрегаторами. Плюс такого направления для меня в том, что нужно прокачивать одну область — ваш сайт. Это сам сайт (со всей технической составляющей), SEO, платные каналы трафика.

Если у вас есть хороший трафик на сайте монетизировать его уже намного проще.

В случае например с товарными агрегаторами часто на свою сторону нужно брать такие процессы как доставка, возвраты товаров. Тоже имеет место быть, но скажем так — лишние трудности.

Итак, я просто приведу некоторые разноплановые примеры сайтов агрегаторов с показателями трафика и доли SEO трафика, чтобы наглядно было понятно на примерах, что такое агрегаторы из сферы услуг:

1. Учебные заведения. ucheba.ru 1 400 000 визитов.% SEO трафика = 72%

2. Квесты mir-kvestov.ru 827 000 визитов. %SEO трафика = 34%

3. Финансы banki.ru 1 500 000 визитов. %SEO трафика = 47%

4. Букмекеры bookmakers-ratings.com 1 691 000 визитов. %SEO трафика = 52%

5. Детские лагеря incamp.ru 366 200 визитов. %SEO трафика = 68%

6. Клиники и врачи docdoc.ru 1 727 000 визитов. %SEO трафика = 65%

7. Недвижимость за рубежом tranio.ru 326 000 визитов. %SEO трафика = 75%

8. Солянка большого кол-ва ниш. zoon.ru 11 000 000 визитов. %SEO трафика = 81%

Как выбрать нишу для агрегатора

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

1) В какой области у вас есть минимальный опыт, или какая область вам интересна. Как бы тривиально это не звучало, но я вспомнил слова психолога М.А. Лабковского: «Делай то, что нравится». С агрегатором возиться придётся долго.

Лучше пусть это будет ниша, которая вам близка и интересна.

2) Есть ли в нише агрегаторы. Это очень просто проверяется. Вводим высокочастотные поисковые запросы в Яндекс или Гугл. Если в Топ10 есть хотя бы 1 агрегатор, значит уже есть с кем равняться. Если агрегаторов нет, это не значит, что в этой нише их делать не стоит, но я бы как минимум задал себе вопрос — почему их тут ещё нет?

Большая вероятность, что они в этой нише нерентабельны.

3) Сколько SEO трафика собирает лидер ниши, и какова структура трафика этого лидера. Для данного анализа я использую инструмент similarweb. У него есть бесплатная версия, которая даёт возможность посмотреть необходимые базовые цифры. Кол-во трафика — это сигнал для вас, сколько в идеале сможете собрать вы.

Это базовый параметр для первичной оценки. Давайте разберём на двух примерах ниш, в которых я работал сам. Сравним 2 лидера двух разных ниш: школы английского языка и онлайн сервисы для бизнеса:

Нас интересует циферка — кол-во визитов в месяц.

И структура трафика.

Теперь смотрим те же показатели у лидера ниши онлайн сервисов:

У Starpack видим 190 410 визитов в месяц.

В нише онлайн сервисов, вы можете пробовать выйти на 190410 * 83% = 158040 SEO трафика. В нише английского же это будет 8840*63%=5569 SEO трафика в месяц. Это базовые общие неточные цифры, но они хорошо отражают общее положение дел. Если за основу брать только количество агрегаторного SEO трафика, то ниша онлайн сервисов выглядит более перспективно.

Так вы можете проверять любые ниши: клиники, школы танцев, авиабилеты и так далее.

Итак, предположим, вам нравится ниша (или вы в ней специалист) и вы просчитали, что в ней можно собрать достаточно SEO трафика. Пока это ещё очень малое кол-во данных для каких-либо выводов. Идём дальше.

4) Как высока конкуренция в данной нише? Конкуренцию можно пытаться определить по-разному. Что смотрел лично я:

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

И вы поймёте с кем вам придётся конкурировать. С 2-мя сильными игроками или с 10-ю.

б) Сколько стоят клики по Семантическому ядру данной ниши. Возьмите хотя бы 30-50 высокочастотных запросов, можно для точности взять ещё СЧ и НЧ запросы и в том же Яндекс Директ (прогноз бюджета) посмотреть сколько стоят клики. Это тоже своеобразный показатель конкуренции.

в) Можно ещё использовать разные сервисы или программы. Например старый добрый Key Collector, который считает коэффициенты конкуренции по нише.

Чем меньше конкуренция, тем проще Вам будем пробиться на верх поисковой выдачи. Всё просто:)

5) Какой средний чек в нише. Вы должны понимать, что платить вам будут либо комиссию с продаж, либо какие-то рекламные бюджеты. В любом случае, есть разница, если вы зарабатываете 10% от продажи в 30 000 рублей (например, ниша детских лагерей) или 10% от 1200 рублей (парикмахеры).

Второй вариант тоже имеет место быть, но тогда вам нужны большие объёмы.

6) Смотрим структуру трафика. Я использую инструмент https://www.keys.so/ru/. Нужно понять на какие страницы лидеры ниши собирают основной трафик.

Нас интересует данная вкладка.

Делаем экспорт из вкладки Страницы сайта, сортируем по Видимости. Через фильтры смотрим какие страницы собирают основной трафик. У агрегатора как правила 4 основные типа страницы: а) страница объекта; б) страница отзывов объекта; в) страница листинга (списка всех объектов); г) главная страница.

Эта информация важна, чтобы понять, на какие страницы вам делать упор при развитии.

Делаем Customer Development — есть ли инфраструктура.

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

Это очень важный пункт. Даже если в нише есть агрегаторы, может ниша перегрета и Ваш новый агрегатор уже будет лишним.

Сколько нужно денег на развитие агрегатора в конкретной нише?

Последний в списке, но главный, на мой взгляд, по значимости пункт. Поэтому написал кэпслоком. Постарайтесь максимально детально спрогнозировать сколько вам нужно денег.

Ещё раз повторюсь, агрегаторы, как правило, работают на SEO трафике, нужно терпение и средства, чтобы дождаться его и весь пазл сошёлся. Что считал лично я:

Сколько денег нужно на создание контента?

Вы хотите делать агрегатор в нише детских лагерей. Смотрим лидера ниши. https://incamp.ru/camps/

У них добавлено 4400 лагерей. Контент можно парсить, можно делать уникальным. Если хотите бороться за SEO, нужно максимально делать уникальный контент. Предположим, вы прикинули, что на создание контента для 1 лагеря вы потратите 200 рублей( беру плюс/минус среднюю условную цифру)

4400*200 = 880 000 рублей.

Вопрос. Вы тяните? или может взять нишу уже?

Возможно, можно сделать агрегатор для какого-то узкого сегмента. Например, детские лагеря только в Подмосковье. Вы теряете в объёме, но минимизируете риски.

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

Сколько денег нужно на движок?

Агрегатор — это всё-таки далеко не лендинг пейдж. Это сайт с достаточно сложной архитектурой. У вас должны чётко работать шаблоны. Вы должны уметь генерировать десятки тысяч уникальных страниц. На этих страницах будет работать уникальный для агрегатора функционал.

В одном пункте не описать все технические особенности такого сайта, но могу сказать на своём примере, что мы переделывали движок не один раз, пока не пришли к последней версии, в которой всё уже работало как часы. Я уже говорил, что на каком-то этапе мы приняли решение продавать свой движок ( вы можете детальнее узнать условия у нас на сайте agregator-wp.ru), так как он универсальный, а мы просто физически не можем закрыть все ниши. На одну нишу уходит много сил и фокуса.

Если Вам интересно напишите мне в личку, или в комментах, я расскажу подробнее. Но хочу подчеркнуть, что выбор купить готовый движок или делать свой — это выбор каждого. Если Вам интереснее разработать движок с нуля, пройдя все этапы — это тоже отличный, интересный вариант, но вдруг Вы хотите не тратить деньги и время на движок, а скорее начинать работать над контентом, SEO и заработком, то возможно тогда вариант с готовым движком для Вас наиболее актуален.

Могу Вам честно сказать, что мы вложили в движок намного больше, чем его текущая цена у нас. В студии же с вас возьмут ещё больше.

Но в любом случае посчитайте, и заложите эту сумму (купите ли готовый или будете развивать свой) в ваш бизнес-план в самом начале!

Сколько денег нужно на команду.

Я перечислю роли специалистов, которые так или иначе в какие-то периоды участвовали в работе над агрегатором:

Архитектура агрегаторов: паттерны веб-сервисов (Часть 1)

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

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

Разные принципы работы с сервисами: некоторые из них предоставляют API, а с другими приходится работать посредством бота — имитации действий человека.
Неоднородность ответов от сервисов — одни возвращают json, другие — xml, третьи — веб страницу.
Вытекает из 2 — неоднородность структур данных — например, структура объекта Project
c freelancer выглядит так:

  588582 sign design web software http://www.sandbox.freelancer.com/projects/PHP-ASP/sign-design-web-software.html http://www.sandbox.freelancer.com/users/1353095.html 1353095 billk89  Create and upload sign design web software for our client nlsigndesign.com Public internet users must be able to create there own signs online, then save and submit as a file. PHP  .

в то время как Odesk отвечает следующим образом:

. . 0 December 18, 2011 Russia (UTC+06) A social network client app for iPhone/iPad ~~05d405f2d5b8eb27 . ipad,ui-design,iphone-development . Hello, We need a social network client app for iPhone/iPad to be developed.

It should support Facebook, Twitter and Linked-In. .

Создаем интерфейс

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

interface ServiceInterface

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

Далее, для каждого сервиса мы создаем сервис адаптеры (вариация паттерна «Adapter» применительно к веб сервисам), которые будут реализовывать этот интерфейс.

Оба класса работают с сервисами через API, но скрывают разницу в реализации вызовов.

Freelancer Service Adapter:

class FreelancerService implements ServiceInterface < private $_serviceName = 'freelancer'; private $_service = null; public function __construct(ModelCredential $credential = null) < Yii::import('ext.freelancer-api-wrapper.*'); $this->_service = new Freelancer(Yii::app()->params['freelancer']['token'],Yii::app()->params['freelancer']['secret'], 'http://geeks-board.local/authorizeService/freelancer/?'); if($credential !== null) < $this->setCredential($credential); > > public function authorize() < if(!isset($_GET['oauth_token'])) < $requestToken = $this->_service->requestRequestToken(); $redirectUrl = $this->_service->getRedirectUrl($requestToken); header('Location: ' . $redirectUrl); > else < $oauth_verifier = $this->_service->getRequestTokenVerifier($_GET['oauth_token']); $auth = $this->_service->requestAccessToken($oauth_verifier,$_GET['oauth_token']); $this->_service->oauth->setToken($auth['oauth_token'],$auth['oauth_token_secret']); $this->_service->auth = $auth; return $auth; > return false; > public function getServiceName() < . >public function setCredential(ModelCredential $credential) < . >public function searchProjects() < . >>

Odesk Service Adapter:

class OdeskService implements ServiceInterface < private $_serviceName = 'odesk'; private $_service = null; public function __construct(ModelCredential $credential = null) < Yii::import('ext.odesk-api.*'); Yii::import('classes.mapper.service.RequestMapper'); $this->_service = new oDeskAPI(Yii::app()->params['odesk']['secret'], Yii::app()->params['odesk']['token']); if($credential !== null) < $this->setCredential($credential); > > public function authorize() < return $this->_service->auth(); > public function getServiceName() < . >public function setCredential(ModelCredential $credential) < . >public function searchProjects() < . >>

Обратите внимание, что оба класса имплементируют интерфейс ServiceInterface, но реализация метода authorize различна для каждого. Тут необходимо упомянуть также модель ModelCredential, которая хранит данные для авторизации.

При Oauth авторизации это token и secret.

Создаем фабрику

В будущем нам необходимо легко добавлять новые сервисы, не изменяя кода существующих классов (Следуем OCP принципу). Для этого воспользуемся паттерном «Factory Method».

class ServiceFactory < public static function create($serviceName, $credentials = null) < $className = ucfirst(strtolower($serviceName)).'Service'; $serviceObject = Yii::createComponent($className, $credentials); if(!($serviceObject instanceof ServiceInterface)) < throw new Exception('Not an instance of Service'); >return $serviceObject; > >

Мы также добавили проверку на то, что данный класс реализует ServiceInterface. Для чего здесь используется интерфейс и проверка на его реализацию классами сервисов? В случае, если разработчик ошибется и забудет имплементировать какой либо метод интерфейса, php не даст возможности запустить код в принципе. Это дает нам уверенность в том, что метод реализован. Также это дает понимание, какие конкретно методы необходимы будут системе для работы.

По этому поводу поделюсь своей историей.
На одном из проектов, над которым я работал, была поставлена задача имплементировать сервис адаптер для Google+. В проект уже были интегрированы Facebook и Twitter адаптеры. Когда я открыл класс одного из них, я ужаснулся от количества кода внутри.

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

Если бы у нас был один интерфейс для таких сервис адаптеров — было бы сразу понятно какие из методов нужно было создать.

Собираем все вместе

Итак, мы подготовили классы сервис-адаптеры и фабрику, которая будет создавать их. Давайте посмотрим как эти части работают вместе:

 Yii::import('application.models.ModelCredential'); //Для того чтобы работать с общей информацией - такой как проекты, нам необходимы публичные Credentials - не принадлежащие // ни одному пользователю в системе. $credentialsRecords = ModelCredential::model()->findAllByAttributes(array( 'type' => 'public' )); if(!empty($credentialsRecords)) < Yii::import('classes.service.ServiceFactory'); $aggregatedProjects = array(); foreach($credentialsRecords as $serviceCredential) < try < // Используя нашу фабрику создаем сервис адаптер соответствующий указанному в credentials. $service = ServiceFactory::create($serviceCredential->service, $serviceCredential); $foundProjects = $service->searchProjects(); // унифицированный вызов метода для всех сервисов if(is_array($foundProjects)) $aggregatedProjects = array_merge($aggregatedProjects,$foundProjects); > catch(Exception $e) < print_r($e); >> > else

Итог

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

В следующей статье я расскажу, что делать с неоднородностью возвращаемых ответов и структур данных.

Что такое агрегатор услуг и товаров?

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

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

Маркетплейс — что это?

Маркетплейс или агрегатор — это онлайн-магазин электронной торговли, где различные коммерческие сайты могут размещать свои товары или услуги.

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

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

Примеры успешных агрегаторов товаров и услуг

В числе самых известных агрегаторов товаров такие площадки, как Amazon, Aliexpress, eBay.

Яндекс.Маркет – пример российского маркетплейса с обширным каталогом товаров из разнообразных интернет-магазинов. Тут имеется своя система рейтингов, отзывов, поиска и фильтрации, а также подробно заполненные карточки товаров.

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

Сервис товаров ВКонтакте — бесплатный сервис товаров, который можно подключить к своему паблику или сообществу в социальной сети ВКонтакте.

Большой популярностью пользуются и тематические агрегаторы, например:

Drom.ru — портал, содержащий сотни тысяч объявлений по автотематике. Дает возможность не только найти нужное предложение от продавцов по всей России, но и прочесть отзывы владельцев автомобилей. Также на сайте имеются форумы для общения автолюбителей.
ЦИАН — агрегатор информации из сферы недвижимости с посещаемостью свыше 6 млн посетителей в месяц, содержащий объявления о покупке, продаже и аренде жилья.
Банки.ру — агрегатор предложений российских банков по вкладам, а также другим банковским услугам: ипотека, кредитование, дебетовые и кредитные карты, депозиты и т.п. Данный портал посещают 10 млн человек в месяц.

Плюсы и минусы агрегаторов

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

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

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

Достоинств у агрегаторов товаров и услуг много, однако нельзя не упомянуть минусы таких торговых площадок для продавцов. К ним относятся:

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

Как конкурировать с агрегаторами?

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

Стоит зарегистрироваться в справочниках «Google Мой Бизнес» и «Яндекс.Справочник», указав в них максимально полную информацию о своей компании. Информация из этих справочников часто показывается на первой странице поисковой выдачи.
Зарегистрируйте свою компанию в тематических каталогах. Это благотворно скажется на узнаваемости самой компании и ее сайта и повысит доверие со стороны поисковых систем за счет естественных ссылок.
Следует использовать геозависимые запросы, а именно: присвойте сайту определенный регион с помощью Яндекс.Вебмастер, разместите обратные ссылки на региональных площадках, а в анкоре ссылок пишите название своего города.
Продвигайте сайт посредством релевантных запросов. На сайте должна быть размещена максимально полезная для пользователя информация, дающая ответы на самые популярные запросы.
Старайтесь наполнить свой сайт полезным контентом: информационными статьями, рекомендациями по выбору товаров, ответами на часто задаваемые вопросы, обзорами товаров. Качественный контент играется немаловажную роль в ранжировании.

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

Как создать маркетплейс?

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

Возникает вопрос: как создать агрегатор услуг или онлайн-площадку для продажи товаров с меньшими затратами? Решением может стать создание маркетплейса на основе одной из популярных CMS (систем управления контентом сайта), например, WordPress. На этом движке имеются готовые варианты решений, которые вы вполне можете адаптировать под задачи своего бизнеса.

Кроме того, некоторые компании, имеющие написанный специально для них сайт-агрегатор, предлагают приобрести его шаблон как CMS для различных ниш.

Как продвигать агрегатор?

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

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

Сайт-агрегатор также можно использовать в качестве площадки для рекламы своего интернет-магазина.

Подведем итог

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

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

Так вам быстрее удастся занять лидирующие позиции и обойти конкурентов.

Реализация семантического новостного агрегатора с широкими поисковыми возможностями

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

Зачем это нужно?

В идеале, семантическая система «понимает» содержание обрабатываемых статей в виде системы смысловых понятий и выделяет из них главные («о чем» текст). Это дает огромные возможности по более точной кластеризации, автоматическому реферированию и семантическому поиску, когда система ищет не по словам запроса, а по смыслу, который стоит за этими словами.

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

Ответ на семантический запрос в общем случае состоит из следующих компонентов:

Онтология

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

В нашей онтологии, простые семантические понятия (объекты) можно разделить на следующие классы:

Материальные предметы, люди, организации, нематериальные объекты (например, фильмы), географические объекты и т.п.
Действия, показатели («продать», «инфляция», «сделать»).
Характеристики («большой», «синий»), назовем их атрибутами.
Периоды времени, числовая информация.

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

Характеристики, примененные к семантическим понятиям первого и второго класса, как правило можно считать «второстепенной» информацией применительно к поисковым задачам. Например, в выражениях «сохраняются низкие цены на нефть»,»стабильные поставки нефти в Европу» выделенные курсивом атрибуты имеют меньшую значимость, тем другие объекты. Такая информация не входит в узлы, а привязывается к ним в привязке к определенному месту в документе.

Аналогично к узлам привязываются числовая информация и периоды времени.

Рисунок ниже иллюстрирует семантическое преобразование двух несложных фраз. Цветные прямоугольники – это элементы шаблонов узлов, а прямоугольники над ними – элементы узла, построенного по этому шаблону.

При таком подходе мы имеем два сорта информации:

Определенный узел существует («цены на нефть»). Накопитель таких узлов назовем «Базой знаний».
Этот узел существует в определенных местах документов с определенными атрибутами, числовыми значениями и периодами времени.

Преобразование текста в семантическое представление

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

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

Например, в узле «торговые операции» активным объектом (продавцом или покупателем) может быть объект типа «человек или организация», а также объекты всех нижележащих типов (компании, магазины, культурные учреждения и т.д.). В шаблонах узлов заводим и синтаксические ограничения. В отличие от большинства других систем семантического анализа текстов, мы не делаем предварительный синтаксический разбор с формированием сети синтаксических зависимостей, а применяем синтаксические ограничения параллельно с семантическим анализом.

Кратко поясню основные этапы.

Сначала производится идентификация простых объектов, которые определяются отдельными словами или известными словосочетаниями. Далее, определяются комбинации имен и фамилий как указания на людей, и работает алгоритм анализа отдельных слов и последовательностей слов, которые могут быть неизвестными системе объектами.

На втором этапе формируем узлы на основе объектов класса 1 с уточняющими их объектами. Фразы типа «генеральный директор московской торговой компании «Рога и копыта» свертываются в один объект. Содержащаяся в этих узлах дополняющая информация («московская» как признак расположения и «торговая» как признак отрасли в этом примере) может быть добавлена в граф семантических связей для указанной компании.

В следующей главе граф семантических связей рассмотрим подробнее.

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

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

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

Последний блок преобразования в семантическое представление – учет объектов, которые в тексте удалены от узлообразующих объектов, но по смыслу подразумеваются. Например, «В Москве тепло, идет дождь. Завтра похолодает, и пойдет снег».

Семантический анализ конца предложения оставляет вакантной роль географического объекта, и по ряду признаков можно определить, что подходит «Москва».

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

Наконец, в каждом документе определяем основные объекты («о чем» этот документ). Помимо количества вхождений, учитывается участие объектов в узлах разных типов.

Имея богатую семантическую информацию, можно построить достаточно точную меру семантической близости документов. Объединение документов в кластер делаем при превышении мерой семантической близости определенного порога. Формируем семантические профили кластеров (основные объекты кластера, по ним обычно идет поиск) и сеть семантических связей между кластерами, позволяющую выводить «облако» документов, связанных по смыслу с определенным документом.

Как работает семантический поиск

Алгоритм семантического поиска состоит из следующих основных блоков:

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

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

Следующий этап – поиск семантически связанных объектов и узлов. Для одиночных объектов класса 1 это выборка семантически связанных объектов. В случае комбинации «действие + объекты» идет поиск узлов, имеющих такой же или подчиненный тип узлообразующего объекта, и при этом имеющих в своем составе объекты, совпадающие или семантически связанные с объектами запроса.

Также, производится раскрытие в список конкретных объектов комбинаций типа «московские компании» или «страны Европы».

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

Для материальных предметов этот граф строится от более общих понятий к частным и частично совпадает с графом типов.

Для ряда объектов количество «подчиненных» может быть очень велико и возникает необходимость в выборе наиболее значимых. Для этого между элементами графа установлен числовой коэффициент семантической связи, который рассчитывается на основе значимости объектов. Для разных типов объектов значимость определяется по-разному, например, для компаний – исходя из экономических показателей (оборота) или количества сотрудников, для географических объектов – по количеству населения.

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

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

Наконец, ранжируем найденные кластеры и документы, формируем сниппеты и прочие элементы выдачи (ссылки на связанные объекты и др.). Ранжирование обычно идет по степени семантической связи между объектами запроса и объектами, через которые найдены документы. Также, при ранжировании может быть учтен семантический профиль интересов пользователя.

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

Отдельный алгоритм требуется для «широких» запросов – «экономика», «политика», «Россия» и т.п., которые характеризуются очень большим количеством связанных объектов и релевантных документов.

Например, с объектом «политика» связаны:

Люди-политики – занимающие высшие государственные посты или авторитетные эксперты
Организации — политические партии, органы гос. власти.
Ряд событий и действий (выборы, назначения на определенные должности, деятельность Госдумы и др.).

Основные проблемы реализации данного подхода и их решения

Проблема 1. Система должна «знать» все объекты, которые встречаются в текстах.

Возможные решения включают следующие:

В решающих аналогичные проблемы распределения объектов по семантическим ролям англоязычных системах SRL (Semantic Role Labeling) используются алгоритмы машинного обучения с использованием уже размеченных корпусов. В качестве системы конструкций «действие + роли» используется, например, Framenet. Однако, для русского языка нет подходящего размеченного корпуса.

Кроме того, реализация этого подхода имеет свои проблемы, обсуждение которых выходит за рамки этой короткой статьи.

В нашем подходе, как было описано выше, распределение объектов по ролям идет на основе соответствия типов объектов семантическим ограничениям, установленным для ролей в шаблоне узлов. Всего в системе сейчас около 1700 шаблонов узлов, большинство которых было сформировано полуавтоматически на основе фреймов Framenet. Однако, семантические ограничения для ролей приходится в основном устанавливать вручную, по крайней мере для наиболее часто встречающихся узлов.

Можно попробовать автоматическое формирование узлов с помощью машинного обучения на основе уже сформированных. Если есть некая комбинация объектов и слов (неизвестных системе) с определенными синтаксическими характеристиками, то можно формировать узлы, аналогичные уже существующим. Хотя по этим узлам все равно нужно будет вручную делать шаблоны, наличие такого узла все равно будет лучше, чем его отсутствие.

Проблема 3. Высокая вычислительная сложность выполнения многих семантических запросов.

Некоторые запросы могут включать в себя обработку очень большого количества промежуточных объектов и узлов и выполняться медленно. Эта проблема вполне решаема техническими методами.

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

Работа информационного агрегатора