Мобильный маркетинг предполагает взаимодействие двух или трех ключевых фигур.
Клиент — рекламодатель или разработчик мобильного приложения, желающий купить трафик хорошего качества.
Паблишер — арбитражник, администратор группы в соц. сети, разработчик приложения со встроенной (in-app) рекламой.
А также зачастую посредник — агентство мобильного маркетинга, которое занимается подбором офферов от клиентов и оптимизацией трафика партнеров.
Так как Mobio является агентством, то в статье мы рассмотрим, как именно, с нашей точки зрения, происходит работа с трафиком.
В основном используется 2 вида работы с трафиком:
Мануал (ручной) — каждый оффер вручную создается в трекере, после чего к нему также вручную подключаются источники трафика, настраиваются выплаты. Изменения тоже контролируются менеджером самостоятельно.
API-feed (автоматический) — автоматизированный сбор большого количества (нескольких тысяч) офферов, их обработка, загрузка в систему и подключение источников. В том числе, автоматическое внесение всех изменений, поступивших от рекламодателя в режиме реального времени.
Когда мы в Mobio только начинали работу с API-feed, мы решили изучить уже существующие на рынке решения. Задача стояла найти то, что можно адаптировать под потребности компании. Но мы столкнулись с рядом трудностей, которые тормозили эффективность работы команды. Поэтому было принято решение пойти по своему собственному пути, создав свою систему работы с API-feed (feed-management).
Сторонние решения на рынке
Axonite
Axonite — один из крупнейших игроков на рынке решений для API-feed. Изначально был заточен под трекер HasOffers. Mobio успешно настроило интеграцию с Affise. В системе присутствует готовая интеграция с большинством крупных рекламодателей, достаточно вставить ключ и дополнительные данные для нужного клиента, после чего офферы автоматически загружаются в систему.
Выбор подключения в Axonite. Список большой, на скриншоте лишь малая его часть.
Далее происходит их фильтрация по настраиваемым параметрам. Выбираем, каких партнеров необходимо подключить к каждому из потоков (потоком называется выборка офферов от одного/нескольких рекламодателей согласно указанным в фильтре параметрам). Система экспортирует данные в трекер и поддерживает их актуальность.
Но после запуска мы столкнулись со многими трудностями:
1. Неудобное формирование потока
Каждый поток должен быть отдельно для каждого рекламодателя. Для подключения партнера также нужно создавать отдельную связь “Поток-источник”. На практике это оборачивается тем, что для подключения 20 источников на 2 потока необходимо создать (вручную!) 40 связей. Это отнимает уйму времени. К тому же, стоимость тарифного плана ограничивает количество таких связей. Это заставляет тратить время еще и на то, чтобы удалять связи, когда их становится слишком много. Или платить больше денег.
Создание подключения поток-источник. Ввести все данные, сохранить, открыть новую форму — повторить N раз
2. Лимит запросов с IP-адреса
При нагрузках сервер не справляется с оперативной отправкой информации. Сотрудники Axonite объяснили это лимитами трекера, но в дальнейшем, при разработке своей системы, мы убедились, что это было не совсем правдой.
Конечно, нам расширяли инстанс, но это было сделано далеко не так оперативно, как требовалось для комфортного расширения бизнеса.
3. Устаревшие подключения
Многие подключения сильно устарели. Тот большой список клиентов, к которым было настроено подключение, был не так актуален, как мы ожидали. Зачастую приходилось ждать, пока подключение будет перенастроено, т.к. сами Axonite не актуализируют информацию до запроса со стороны пользователя.
4. Невозможность сделать копию подключения как отдельную категорию
Например, рекламодатель Advertiser предоставляет 2 списка офферов: один без сложных KPI, второй — высокочувствительные офферы с трудно выполнимыми KPI. Первый можно подключить всем источникам, второй — только самым лучшим. Однако Axonite будет смешивать все офферы в один поток, что портит всю картину.
В итоге, проработав с Axonite несколько месяцев, мы поняли, что будет проще и полезнее сделать собственную систему. За все время с работой Axonite у нас накопилось достаточно кейсов с нюансами, на которые мы могли ориентироваться при разработке.
CPAPI
CPAPI — реализованное самими Affise решение по апи-интеграции. Мы тестировали их до Axonite, но в постоянную работу не взяли. На тот момент, когда мы только начинали свою активность по АПИ, система была довольно сырой. Готовых подключений было немного, влиять на очередь их создания мы никак не могли. У CPAPI был свой собственный список приоритетов. Сейчас список расширился, однако до сих пор есть некоторые недоработки:
1. Список небольшой, многих крупных клиентов нет, особенно китайских.
Список доступных подключений
2. Подключение партнеров не автоматизировано.
После отправки офферов в трекер необходимо вручную подключать партнеров к офферам. Учитывая объемы источников, появляющихся со временем, — это крайне неоптимально. Особенно, когда речь идет о системе, призванной избавить от подобных заморочек.
Зато можно выбрать, какие поля синхронизировать постоянно, а какие — нет. Например, если хочется что-то изменить, а не оставлять «как есть».
Помимо специфических минусов, есть еще и общие “хотелки”, не реализованные по умолчанию в системах на рынке. Это не является недостатком системы, но при этом, внедрение чего-то подобного потребует немалого времени, затрат и согласований. Например, нельзя блокировать отдельные sub-id источников трафика, а это является неотъемлемой частью бизнеса. Или же аналитика уровня конверсии офферов с отключением неконвертящих — для подобного анализа требуется доступ к статистике трекера, которым системы API не обладают.
В итоге, мы поняли, что аутсорсингом можно обойтись только на начальном этапе работы, а так как наши темпы роста требовали расширения технических ограничений, мы засели за продумывание и разработку собственной системы API-офферов.
Построение собственного решения: общая схема работы и дополнительные фишки
К системе предъявлялись следующие требования, которые вошли в ТЗ для разработчиков:
1. Унифицированность информации
В нашей сфере многие рекламодатели используют свои собственные трекеры. У всех разные АПИ и форматы хранения данных. Категории офферов (оплата за установку или за событие) передаются по-разному. В конечном итоге, всю эту информацию нужно не просто собирать, но и приводить к единому виду. Более того, этот вид должен адекватно проходить в наш собственный трекер, учитывая его возможности.
Было принято решение писать под каждый трекер клиента отдельный коллектор на GoLang. Это позволило быстро собирать и обновлять «сырые» данные.
2. Соответствие полей
Далее разработчик создавал пул-реквест для системы, помогающий ей понять, какое поле в коллекторе чему соответствует. При необходимости дописывались простые вычисления, например, если рекламодатель передает monthly cap (максимальное число установок за месяц), его приходилось делить на 30, т.к. в трекере Affise есть только daily cap (за день) и total cap (за все время).
3. Проверка активности оффера
Проверка осуществлялась таким образом: если при очередном запросе данных не был найден оффер, уже загруженный ранее, он переводился в статус неактивности.
При первой загрузке данных в систему затрагивались только активные записи из коллектора. Далее система так же сравнивала статусы уже загруженных офферов.
4. Фильтрация офферов
После первой загрузки данных производилась фильтрация согласно заданным правилам. Убирались офферы с неинтересным бизнесу ГЕО, низкими выплатами, неподходящей валютой, ОС, типом устройства и оффера, мотив или не мотив (мы работаем исключительно с немотивированными офферами).
В базовой версии фильтрация была единственным уровнем проверки перед тем, как оффер попадал в наш трекер. Однако это было неоптимально — многие офферы приходили к нам «сломанными», т.е. ссылка вела не туда, куда нужно. Некоторые офферы имели столько редиректов на пути к конечной ссылке, что работать было совершенно с ними неинтересно.
На помощь пришло решение от наших коллег по бизнесу. Mobrand дал нам возможность использовать свой Offertest — это сторонняя система, которая проверяет, что клик с нужного ГЕО и ОС ведет именно туда, куда необходимо, а также сообщает через сколько редиректов пришлось пройти. Условия работы с данной системой куда более выгодные, чем с популярным аналогом Affilitest, при этом функциональность ничуть не меньше. Следовательно, после фильтрации офферов, те из них, которые прошли фильтр, подвергались проверке на Offertest. Основным правилом фильтрации является соответствие финальной страницы заявленной в оффере. Помимо этого, индивидуально выставлялось максимально допустимое число редиректов.
Мы удовлетворены системой и можем рекомендовать данный продукт к использованию. Он позволяет значительно улучшить качество получаемых наборов офферов и стоит в разы дешевле аналогов. Стабильность работы проверена лично нами на максимально возможных мощностях — падений замечено не было. При всем при этом коллеги регулярно улучшают свою систему, соблюдая версионность, т.е. свежий апдейт не сломает старые настройки.
Но и это еще не все! Даже после всех проверок оставались офферы, дублирующие друг друга. Например, было 5 офферов условного Яндекс.Браузера на Андроид и РУ-гео, но с разными выплатами. Наша система анализировала их, создавая top-group — группу офферов с уникальным идентификатором приложения и ГЕО, после чего выбирала 2 с наиболее высокой выплатой. Если один или оба оффера останавливались, на их место приходили следующие по списку.
Все подобные проверки осуществляются в реальном времени по всем активным или новым офферам, чтобы максимально улучшить существующий поток офферов.
Наконец, все оставшиеся офферы загружаются по API в наш трекер Affise. Работа источников трафика с офферами происходит уже исключительно в нем, оставляя систему фидов закрытой от стороннего пользователя.
5. Работа с источниками трафика
Помимо обработки и загрузки офферов также необходимо было удобно работать с источниками трафика, оперативно подключая и отключая их от разных рекламодателей. Это производилось также в интерфейсе системы фидов. Не нужно было формировать какие-либо потоки, как это было в Axonite, подключение было сделано интуитивно понятным. Кроме того, можно было настраивать подключения отдельно на каждый оффер, чтобы дать возможность наиболее подробной настройки потока трафика.
Дополнительно была реализована система оценки CR (соотношение конверсий по отношению к кликам). В случае, если он слишком низкий (оффер не конвертит на трафике из определенного источника), источник отключается от конкретного оффера, чтобы переключиться на те, которые будут иметь хороший CR и давать положительную прибыль.
В планах — добавить интеграцию с системой FraudScore. Для того, чтобы при попадании в источник случайного фрода — блокировать этот источник. На данный момент это делается вручную, но в остальном уровень ручной работы максимально низок, особенно в сравнении с теми решениями, которые представлены на рынке.
Возникшие сложности
1. Унификация
Как уже было сказано ранее — все полученные в коллекторы данные было необходимо привести к общему виду. Иногда формат ответа от рекламодателя был сложен для понимания и унификации. Например, трекер FuseClick считает CPI-офферы подвидом CPA — что с точки зрения нашей системы является грубой ошибкой. Или же иногда в ответе нет preview-link — приходилось брать package_name (идентификатор приложения) и самостоятельно создавать ссылку, ведущую в магазин приложений.
Подобные аспекты часто возникают при написании коллектора, поэтому крайне важно было как самому понимать, что имеется в виду в том или ином поле, так и поддерживать постоянный контакт с рекламодателем при разработке — для уточнения неясных моментов.
2. Ограничения числа запросов
Как и у любой системы, у трекера Affise есть лимит запросов, которые можно отправить с IP. В связи с этим скорость работы системы фидов ограничена данным лимитом — нам пришлось учесть этот фактор. При текущих мощностях можно было бы достичь большей скорости работы, однако стоит сказать спасибо коллегам, повысившим лимит для системы в 2 раза. На текущий момент средняя скорость обновления составляет 10 минут для всего потока, что является очень хорошим рыночным показателем.
3. Изменение логики
В процессе постоянных доработок разных систем зачастую приходится продумывать и переписывать те модули, которые отвечали за логику работы — так как она может неоднократно измениться. Тут все зависит от разработчика — наш сотрудник отлично продумал модульность и расширяемость компонентов. Важно не жертвовать этим в угоду низким срокам разработки — потому что если сделать монолитную систему, то доработки займут уйму времени (осмелюсь предположить, что решения, представленные на рынке, грешат именно этим — потому что наши мысли добавить реально нужный клиентам модуль зачастую натыкались на отказ из-за “технических сложностей”)
4. Ограничения трекера
Еще одна проблема — это ограниченные возможности трекера, в который экспортируются офферы. Несмотря на то, что у Affise нет с этим особых проблем, некоторые вещи, привычные на рынке фидов, изначально отсутствовали. Например, в трекере нет отдельного поля для package_name, а его передача критически важна для источников. Конечно, можно придумать “костыль”, используя под этот параметр другое текстовое поле, присутствующее в трекере, но не особо нужное для фидов — но было бы здорово сделать все красиво. Что ж, мы уверены, что коллеги не подкачают и уберут те ограничения, которые на данный момент присутствуют
Заключение
В процессе постоянных доработок разных систем зачастую приходится продумывать и переписывать те модули, которые отвечали за логику работы, так как она может неоднократно измениться.
Тут все зависит от разработчика. Наш сотрудник отлично продумал модульность и расширяемость компонентов. Важно не жертвовать этим в угоду низким срокам разработки, потому что, если сделать монолитную систему, то доработки займут уйму времени.
Несмотря на все трудности, возникшие на пути разработки собственного решения, команда ни разу не пожалела о том, что решила потратить собственные силы и средства на данный проект. То время, которое было в итоге сэкономлено, и те уникальные преимущества, которые мы получили, многократно окупили все затраты на разработку. Возможно, мы задумаемся о том, чтобы подготовить паблик версию продукта, чтобы любой желающий мог оценить нашу работу.
А пока — если вы хотите получить отличный трафик из проверенных источников, или же вы сами имеете хороший инвентарь трафика и ищете подходящий под него набор офферов, будем рады пообщаться о потенциальном сотрудничестве.
Подписывайтесь и читайте интересные новости, аналитику и прочие инсайты о мобильном маркетинге в блоге Mobio.
Автор: Илья Серёгин
