Как мы и обещали, мы начинаем серию постов о технологиях и техниках, которые используются в нашей компании. Начать бы мы хотели с внутреннего продукта, который называется OMPW — Oversun Media Players Wizard — помощник сопровождения пользователей. Эта система используется практически всеми отделами нашей компании и многое умеет.
OMPW состоит из кучи модулей, которые позволяют нам закупать трафик, контролировать его качество, экспериментировать с посадочными страницами, вести учет пользователей и их игровых событий, строить отчеты и вести аудит геймплея.
Сегодня будем разбираться с модулем закупки и оценки качества трафика. Эта часть получилась весьма объемной, поэтому рекомендуем запастись желанием, временем и предельным вниманием. Мы постарались сделать материал наиболее простым для усвоения, но теория не может обойтись без определений и терминов. Должно быть интересно :).
На что вы смотрите, когда крутите в руках бутылку йогурта с холодильной витрины магазина? На даты упаковки и производства, срок хранения, калорийность, полезные свойства и наличие витаминов. Если обобщить, то вы изучаете потребительские свойства товара и сопоставляете их с ценой. Даже если вы не учитываете цену 1 бутылки, со 100% вероятностью начнете это делать при оптовой закупке сотен тысяч бутылок.
Та же ситуация и с трафиком. Никто не покупает его без оценки эффективности потраченных средств — это было бы неразумно. Обычно производится тестовая закупка на пару тысяч посетителей и, если соотношение цены и качества приемлемо, начинаются оптовые закупки с постоянным контролем показателей.
Что нам нужно знать об играх?
Прежде чем перейти к трафику, нам необходимо рассмотреть жизненный путь игрока. И начнем мы с самого простого — с событий. Событие — это то, что происходит в жизни наблюдаемого объекта. В нашем случае это нечто, что произошло c игроком: посещение сайта, регистрация, создание игрового персонажа, взятие квеста, бой или повышение уровня.
Примечание: в тексте вы встретите множество названий событий. По внутреннему соглашению, название события формируется из двух строк, соединенных точкой. Первой строкой обозначается объект действия (в программировании — класс или объект). Второй строкой обозначается действие, которое совершается над объектом (в терминах программирования — метод, функция-член).
Примеры названий событий: «quest.get», «quest.cancel».
Практически всегда событие имеет параметры. Например, «взятие квеста» всегда сопровождается идентификатором квеста, бой — идентификатором боя и набором противников, повышение уровня — номером уровня. События, которые могут возникать более одного раза, принято дополнять параметром «номер события». Все совсем как в жизни: «Когда я женился третий раз...», «Мой первый компьютер был...», «Когда мне позвонили десятый раз за день,..».
Набор «событие + параметры» мы называем «точкой», т.к. есть всегда только один такой набор в жизни игрока. Игрок не может проходить через точку дважды. Все точки хранятся в базе данных игрового проекта и представляют собой историю игрока (лог).
Классификация трафика
Для того, чтобы начать разбираться с критериями оценки трафика, нам необходимо ознакомиться с классификацией трафика (по нашей версии).
По источнику, трафик разделяется на:
- баннерный;
- pop-up — всплывающие окна;
- click under — открытие страниц в фоне;
- тизерный — графические блоки с небольшим описанием;
- контекстный — контекстная реклама;
- органический — заказные посты и обзоры;
- социальный — из социальных сетей;
- биржи трафика — трафик собирается из разных источников;
- арбитражный трафик — «купил где дешевле, продал куда дороже».
Остальной трафик лежит вне наших интересов, т.к. в большинстве случаев он не имеет под собой легальной основы.
По типу оплаты трафик бывает:
- с разовой оплатой за публикацию материала — органический трафик;
- с арендой рекламного места — баннерный или органический трафик;
- с оплатой за просмотр рекламного материала (PPV — Pay Per View) — баннерный трафик;
- с оплатой за каждого посетителя (PPC — Pay Per Click) — все типы источников;
- с оплатой за совершение действия (PPA — Pay Per Action) — все типы источников;
- с отчислением процентов от произведенных игроком платежей (реферальная система) — все типы источников.
Возможны также различные комбинации типов оплаты. Например, «10 рублей за 1000 показов баннера + 15 рублей за 100 переходов на сайт + 20 рублей за 100 регистраций».
Оценка качества трафика
Очевидно, что невозможно выработать единую для всех партнеров схему покупки трафика. Поэтому с каждым поставщиком работа идет по его правилам, а оценка эффективности трафика считается «в попугаях».
Что это значит? Геймдизайн говорит, что человека можно считать «подсевшим на игру», если он провел в ней полчаса, что примерно соответствует второму уровню игрока. Таким образом, выгоднее всего будет платить за достижение второго уровня, а значит — считать стоимость пользователя нужно именно в этой точке. Чаще всего, эта точка называется «эффективной регистрацией».
В партнерках по игровому трафику часто можно увидеть, что оплата производится «за регистрацию», «за эффективную регистрацию» и «за активного игрока» — классические проявления PPA. С «регистрацией» все очевидно, с «эффективной регистрацией» мы уже разобрались, а вот с «активным игроком» все сложно. В каждой части из цикла о трафике мы будем определять 1-го человека, который получит футболку от компании Oversun Media. Как только мы соберем размеры с 5-ти человек, мы изготовим и отправим эти небольшие сувениры. Правила победы — далее. Дело в том, что никто, кроме игрового проекта, не знает о том, что такое «активный игрок». Это делается специально, во избежание накруток.
Примечание: при возможности неторопливой покупки трафика и большом количестве поставщиков у игры появляется «туз в рукаве» — возможность назначения второй точки, которая более точно определяет эффективность трафика. А также позволяет шалить с поставщиками, вводя бонусные условия по типу «активного игрока».
Простейшая схема потока трафика
Давайте разберем путь посетителя от увиденного баннера (или статьи) до сайта игры.
На рис. 1 схематично изображен поток пользователей от партнера, который разместил баннер на своем ресурсе, к сайту игры. Как видно на рисунке, мы не льем трафик напрямую на сайт. Вместо этого, мы пропускаем его через посредника — «PX_TDS». Остановимся на нем детальнее.
Система распределения трафика (PX_TDS)
TDS — Traffic (Directing | Distribution | Delivery) System — класс программного обеспечения, занимающегося распределением трафика. Основная задача TDS — весь входящий трафик распределять между потребителями в соответствии с определенными правилами (например, отправлять посетителей с разными языковыми настройками на разные языковые версии сайта).
На рынке существует огромное разнообразие TDS, заточенных под разные направления. Такими примерами могут быть TDS для дорвейного, для мобильного или любого другого трафика. Но наиболее востребованы TDS в черном бизнесе. Например, TDS используется для определения набора уязвимостей по параметрам браузера и ОС, отправляя посетителя на нужную связку сплоитов.
Чаще всего для коммерческой TDS есть много модулей, улучшающих работу с ней в специфичных областях.
Примечание: если в тексте вы встретили абракадабру, начинающуюся с префикса «PX_», помните — это название нашего сервиса. Обычно, название (часть после префикса) весьма точно передает суть этого сервиса. Мы ввели эти префиксы для того, чтобы вы не путали классы систем и наш софт (как это могло случиться, например, с PX_TDS и TDS).
PX_TDS — наша собственная система распределения трафика с горизонтальным масштабированием. При попадании на PX_TDS пользователю присваивается глобальный уникальный идентификатор посетителя (visitor_uid) и сохраняется событие «visitor.register», после чего происходит перенаправление на игровой сайт. К адресу страницы, на которую отправляется посетитель, добавляется параметр visitor_uid.
Несмотря на свою простоту, это очень важный проект. Благодаря своей легковесности и небольшой создаваемой нагрузке, он замечательно масштабируется на небольшие серверы (вплоть до виртуальных серверов) и служит безотказной точкой входа посетителя.
Дополнительная функция PX_TDS — это выборочное перенаправление, когда берется часть трафика и отправляется на другой URL. Благодаря этой возможности мы можем тестировать новые Landing Page («посадочные страницы») на конверсию из уже имеющегося трафика (качество которого уже известно).
Если приложить немного фантазии, то TDS может стать и системой экстренного реагирования. К примеру, если сайт игры недоступен, пользователей отправляем на аварийный блог или интерактивные системы удержания пользователя. Вопрос трафика в моменты перебоев — очень сложный вопрос, который захватывает маркетинг, геймдизайн, сценаристов, саппорт. Так что, сама по себе это отдельная тема для разговора.
Логические и физические узлы потока трафика
Возвращаясь к рисунку 1, хотелось бы сказать, что это была только схема. Все узлы можно увидеть на рисунке 2.
Физический узел — страница, через которую проходит посетитель.
Логический узел — сущность, которая существует лишь для того, чтобы вести статистику и строить отчеты.Покупатель — лицо, закупающее трафик (логический узел).
Сайт-цель — интернет-проект, который получает трафик от PX_TDS (логический узел).
Рекламная кампания — страница, расположенная на сайте цели, куда закупается трафик (физический узел).Продавец — лицо, продающее трафик (логический узел).
Сайт-донор — интернет-проект, который отправляет трафик на PX_TDS (физический или логический узел).
Источник — дочерняя структура сайта-донора (физический или логический узел).
Подробнее хотелось бы остановиться на продавце и его дочерних объектах.
Представим интернет-портал с огромным количеством посетителей. Стандартной схемой рекламы для сайтов являются баннеры и контекстные объявления. Оставьте первым комментарий «Беру футболку», и мы свяжемся с Вами в ЛС. Когда продавец заполняет «анкету» сайта-донора, с которого он бы хотел продать трафик, он указывает все доступные рекламные места (это и есть «источники»). Покупатель их видит и принимает решение — работать с этим рекламным местом или нет.
Тонкость заключается в том, что покупатель может доверить продавцу добавлять источники динамически (и они будут оплачены), а может не разрешать, если желает получать трафик только из тех источников, которые он проверил собственноручно. Эта опция называется «Разрешить автоматическое создание рекламных мест» (далее — «автосоздание»).
Даже если покупатель доверяет продавцу, последний обязан передавать трафик с уникальным ID рекламного места и своим ID. Это необходимо для того, чтобы отслеживать каждый источник отдельно.
Особенно актуальна эта штука при покупке посетителей на биржах трафика (cм. рисунок 3). Получая статистику и оценивая входящий трафик поставщика, мы можем отказаться от конкретных источников нашего партнера, тем самым добиваясь максимальной отдачи.
Такая схема нас вполне устраивает. Но, из-за поддержки двух уровней возникает парадокс:
- Из-за большого количества источников, управление рекламными местами возможно только на крупных порталах (на большом количестве мелких сайтов это становится утомительным)
- Из-за отсутствия третьего уровня вложенности, мы не поддерживаем двойные реферальные системы (когда поставщик биржи сам является биржей)
Сайт-цель
Помните, PX_TDS отправил на landing посетителя? В адресе страницы он любезно указал нам visitor_uid, который сайт заботливо ложит в cookies.
Когда игрок нажимает на кнопку играть (на самом деле, в наших играх, здесь происходит скрытый факт создания временного пользователя) или регистрируется через форму, из cookies берется наш visitor_uid и сохраняется в базе данных.
Кстати, если посетитель пришел на сайт-цель не с PX_TDS, то сайт сам генерирует visitor_uid и сообщает его PX_TDS. В этом случае, если источник действительно не удается вычислить (REFERER не содержит информации о популярных порталах типа google, facebook и других), то источник трафика считается «Неизвестным».
Есть еще один модуль OMPW, который не был рассмотрен, — PX_SERVER. Его основная задача — импортировать в себя события и предоставлять WebAPI для манипуляций с данными. Но есть еще одна его функция — он последовательно обходит источники событий (этот вопрос будет рассмотрен в следующих частях) и сохраняет их в свою базу (забегая наперед, скажем, что тут используется связка Python + Apache HBase).
Краткий алгоритм импорта таков:
- забираем у PX_TDS всех новых посетителей с их данными (visitor_uid, time, источник, сайт-донор, продавец, покупатель, сайт-цель, рекламная кампания и другое)
- забираем у сайта-цели список всех новых пользователей с их данными (visitor_uid, user_id, time и другое), совмещаем с данными от PX_TDS
Вместо заключения
Собственно говоря, мы рассмотрели лишь небольшую часть теории и практики, но уже сейчас понятно как считать CTR для Landing Page и эффективность трафика по точке «регистрация» для разных поставщиков, как связать посетителя на одном сервере с пользователем на другом сервере, что уже немало.
Вероятно, кому-то представленный материал покажется слишком тривиальным. Но мы все-таки надеемся, что нашелся хоть один читатель, кому пригодится этот пост. Так или иначе — это только начало, впереди нас ожидает еще 4 большие части «Повести о трафике». Подписывайтесь на наш блог, если не хотите пропустить продолжение ;).
Спасибо за внимание!
Автор: OverWeb
