Запуск мобильного ретаргетинга с Adjust: настройки, отчеты и ссылки
Если вы закупаете трафик в мобильное приложение, то в нем обязательно должен стоять мобильный трекер, чтобы отслеживать качество привлеченного трафика. Среди самых популярных решений на мировом рынке выделяют Adjust, Appsflyer, Tune, Branch. Среди рынка России и СНГ также известны решения от Яндекс (Appmetrica) и и Mail.ru (MyTracker).
Одной из самых сложных задач для запуска мобильного ретаргетинга является настройка трекера, ссылок, отчетности. А также понимание, как трекер реатрибуцирует пользователя и в дальнейшем определяет, к какому источнику записывать события. От лица автоматизированной системы ретаргетинга для мобильных приложений Getloyal, мы решили сделать цикл статей про каждый из мобильных трекеров: на конкретных примерах опишем, что важно знать перед запуском, что надо настроить и как считать revenue.
Ретаргетинговый отчет Adjust
Adjust позволяет не ограничивать возможность ретаргетинга и реатрибуции 90 днями. Например, если пользователь вернется к вам в приложение спустя 10 месяцев с момента удаления или последнего использования приложения — Adjust все равно распознает его. Если возврат пользователя был совершен в ходе ретаргетинговой кампании — Adjust реаттрибуцирует такого пользователя в новый источник вместо отправки его в органику.
Кейс: Представьте, что вы запускаете UA-кампанию на рекламной платформе, где вы не можете исключить текущую базу пользователей. Это означает, что вы будете привлекать новых или возвращать текущих пользователей.
Adjust на одной вкладке отобразит вам количество не только новых установок, но и количество реатрибуций. Также отчет позволяет сразу измерять уровень фрода, количество удалений и повторных установок, либо же количество деатрибуций — количество пользователей, которое переписано с оригинального источника на источник реатрибуции. Подробнее о всех возможных видах атрибуций можно почитать в документации Adjust.
Настройки ретаргетинга в Adjust
С чем надо разобраться в настройках Adjust перед запуском? Период неактивности в Adjust — период времени, в течение которого пользователь должен быть неактивен, чтобы быть реатрибуцированным на новый источник. Период неактивности настраивается от 0 до 365, стандартный — 7 дней. Если юзер был активен в течение периода неактивности, сессия будет записана на оригинальный источник. Следует отметить, что в Adjust при выставлении периода неактивности 0, открывается возможность динамической реатрибуции любого активного пользователя, в т.ч. в ту же сессию, что бывает важно для ретаргетинга в сфере E-Commerce. В Getloyal мы рекомендуем ставить окно от 0 до 7 дней. Подробнее про период неактивности можно почитать в документации Adjust.
Окно реатрибуции — период времени после клика, в течение которого, если юзер зайдет в приложение или повторно его скачает, он будет записан на источник ретаргетинга. Окно настраивается от 1 до 365 дней. Клиентам мы рекомендуем ставить от 1 до 7 дней.
Стоит отметить фичу Adjust касательно этих настроек: их можно настроить не только на приложение целиком, но и на любой трекер партнера, кампанию или рекламную группу. Это позволяет клиенту держать контроль над партнерами и выставлять разные настройки для разных партнеров, если такая задача имеется. Подробнее о настройке реатрибуции в трекерах.
Кейс: 3 дня назад вы приобрели нового юзера в Facebook ads, и он сделал платеж в первый же день и был неактивен последние 2 дня. Сегодня вы вернули его через ретаргетинговую кампанию, и он сделал еще один платеж после этого. Как обработает эти события Adjust?
В стандартных настройках, реатрибуция не засчитается, потому что юзер был активен менее 7 дней назад. Оба платежа будут засчитаны только источнику Facebook.
Adjust-ссылка для ретаргетинга
В Adjust контроль за реатрибуцией остается за рекламодателем, выставляющим необходимые настройки в дашборде, описанные ранее. Создается новый трекер и для увеличения точности атрибуции с рекламными сетями стоит добавить параметр с идентификатором. Также можно добавить параметр диплинка: если приложение установлено, юзер будет перенаправлен сразу в приложение. Пример ссылки: app.adjust.com/a1c4f?campaign=
Что касается открытий по прямому диплинку — не переживайте, что реатрибуции случаются без регистрации клика. Это происходит, потому что открытия по диплинку происходят без редиректа в браузере. Но, тем не менее, их можно отслеживать: параметры для Adjust-диплинков по ссылке;
Измерение ретаргетинга в Adjust
Самая важная часть — как трекер измеряет эффективность ретаргетинга, и как в дашбордах отследить эффективность. Стоит отметить, что у юзера в Adjust всегда есть оригинальный источник (в фильтрах Attribution source — First) и, если он был реатрибуцирован, то и источник реатрибуции тоже (Attribution source — Dynamic).
Давайте сразу рассмотрим на примере кейса. Пользователь был привлечен с Facebook, заплатил 24 доллара и был неактивен в течение 7 дней (период неактивности). После этого был возвращен по ретаргетинговой кампании и заплатил еще 18 долларов за следующие 15 дней.
Adjust в данном случае вариативен и путем фильтрации может предоставить отчет
как по оригинальному источнику (Facebook, в нашем случае). События и доход от пользователя уйдут только в Facebook. Доход по Facebook составит 42 доллара, по ретаргетинговой кампании — 0. Подходит для оценки LTV оригинального источника.
Так и по по финальному источнику реатрибуции. В этом случае будут учтены динамические источники (в нашем случае — это ретаргетинг). Тогда доход с ретаргетинговой кампании — 18 долларов, а с Facebook — 24 доллара. Подходит для оценки ретаргетига.
Вы заработали 42 доллара. Вы можете построить отчеты, исходя из того, какой источник вам надо оценить. В разных фильтрах доход может пойти только на оригинальный источник, в других — часть уйдет на ретаргетинговый. Во втором варианте график будет выглядеть следующим образом.
Attribution source — Dynamic
Оценка эффективности ретаргетинговых кампаний возможна также с помощью анализа сырых данных от Adjust. Вы можете легко настроить получение данных с помощью коллбэков на свой сервер. Реатрибуция будет в списке событий для коллбэков. Как настроить получение данных подробнее в документации Adjust.
А также все примеры использования фильтра Attribution source смотрите в документации Adjust.
Итоги:
Getloyal — автоматизированной ретаргетинговой платформе для мобильных приложений. Мы делаем ретаргетинг для разных вертикалей, начиная от е-коммерции и игр до нишевых приложений. Если же вы хотите начать возвращать пользователей в приложение и зарабатывать больше с помощью мобильного ретаргетинга, обращайтесь к нам.
Ликбез по запуску Istio
Istio Service Mesh
Мы в Namely уже год как юзаем Istio. Он тогда только-только вышел. У нас здорово упала производительность в кластере Kubernetes, мы хотели распределенную трассировку и взяли Istio, чтобы запустить Jaeger и разобраться. Service mesh так здорово вписалась в нашу инфраструктуру, что мы решили вложиться в этот инструмент.
Пришлось помучиться, но мы изучили его вдоль и поперек. Это первый пост из серии, где я расскажу, как Istio интегрируется с Kubernetes и что мы узнали о его работе. Иногда будем забредать в технические дебри, но не сильно далеко. Дальше будут еще посты.
Что такое Istio?
Istio — это инструмент конфигурации service mesh. Он читает состояние кластера Kubernetes и делает обновление до прокси L7 (HTTP и gRPC), которые реализуются как sidecar-ы в подах Kubernetes. Эти sidecar-ы — контейнеры Envoy, которые читают конфигурацию из Istio Pilot API (и сервиса gRPC) и маршрутизируют по ней трафик. С мощным прокси L7 под капотом мы можем использовать метрики, трассировки, логику повтора, размыкатель цепи, балансировку нагрузки и канареечные деплои.
Начнем с начала: Kubernetes
В Kubernetes мы создаем под c помощью деплоя или StatefulSet. Или это может быть просто «ванильный» под без контроллера высокого уровня. Затем Kubernetes изо всех сил поддерживает желаемое состояние — создает поды в кластере на ноде, следит, чтобы они запускались и перезапускались. Когда под создается, Kubernetes проходит по жизненному циклу API, убеждается, что каждый шаг будет успешным, и только потом наконец создает под на кластере.
Этапы жизненного цикла API:
Спасибо Banzai Cloud за крутую картинку.
Один из этапов — модифицирующие вебхуки допуска. Это отдельная часть жизненного цикла в Kubernetes, где ресурсы кастомизируются до коммита в хранилище etcd — источнике истины для конфигурации Kubernetes. И здесь Istio творит свою магию.
Модифицирующие вебхуки допуска
Когда под создается (через kubectl или Deployment ), он проходит через этот жизненный цикл, и модифицирующие вебхуки доступа меняют его, прежде чем выпустить в большой мир.
Во время установки Istio добавляется istio-sidecar-injector как ресурс конфигурации модифицирующих вебхуков:
Sidecar-поды
Sidecar-ы — это трюки нашего фокусника Istio. Istio так ловко все проворачивает, что со стороны это прямо магия, если не знать деталей. А знать их полезно, если вдруг надо отладить сетевые запросы.
Init- и прокси-контейнеры
В Kubernetes есть временные одноразовые init-контейнеры, которые можно запускать до основных. Они объединяют ресурсы, переносят базы данных или, как в случае с Istio, настраивают правила сети.
@jimmysongio нарисовал отличную схему связи между правилами iptables и прокси Envoy:
Envoy получает весь входящий и весь исходящий трафик, поэтому весь трафик вообще перемещается внутри Envoy, как на схеме. Прокси Istio — это еще один контейнер, который добавляется во все поды, изменяемые sidecar-инжектором Istio. В этом контейнере запускается процесс Envoy, который получает весь трафик пода (за некоторым исключением, вроде трафика из вашего кластера Kubernetes).
Процесс Envoy обнаруживает все маршруты через Envoy v2 API, который реализует Istio.
Envoy и Pilot
У самого Envoy нет никакой логики, чтобы обнаруживать поды и сервисы в кластере. Это плоскость данных и ей нужна плоскость контроля, чтобы руководить. Параметр конфигурации Envoy запрашивает хост или порт сервиса, чтобы получить эту конфигурацию через gRPC API. Istio, через свой сервис Pilot, выполняет требования для gRPC API. Envoy подключается к этому API на основе sidecar-конфигурации, внедренной через модифицирующий вебхук. В API есть все правила трафика, которые нужны Envoy для обнаружения и маршрутизации для кластера. Это и есть service mesh.
Обмен данными «под Pilot»
Pilot подключается к кластеру Kubernetes, читает состояние кластера и ждет обновлений. Он следит за подами, сервисами и конечными точками в кластере Kubernetes, чтобы потом дать нужную конфигурацию всем sidecar-ам Envoy, подключенным к Pilot. Это мост между Kubernetes и Envoy.
Из Pilot в Kubernetes
Когда в Kubernetes создаются или обновляются поды, сервисы или конечные точки, Pilot узнает об этом и отправляет нужную конфигурацию всем подключенным экземплярам Envoy.
Какая конфигурация отправляется?
Какую конфигурацию получает Envoy от Istio Pilot?
По умолчанию Kubernetes решает ваши сетевые вопросы с помощью sevice (сервис), который управляет endpoint (конечные точки). Список конечных точек можно открыть командой:
Это список всех IP и портов в кластере и их адресатов (обычно это поды, созданные из деплоя). Istio важно это знать, чтобы настраивать и отправлять данные о маршрутах в Envoy.
Сервисы, прослушиватели и маршруты
Когда вы создаете сервис в кластере Kubernetes, вы включаете ярлыки, по которым будут выбраны все подходящие поды. Когда вы отправляете трафик на IP сервиса, Kubernetes выбирает под для этого трафика. Например, команда
Istio и Envoy слегка меняют эту логику. Istio настраивает Envoy на основе сервисов и конечных точек в кластере Kubernetes и использует умные функции маршрутизации и балансировки нагрузки Envoy, чтобы обойти сервис Kubernetes. Вместо проксирования по одному IP Envoy подключается прямо к IP пода. Для этого Istio сопоставляет конфигурацию Kubernetes с конфигурацией Envoy.
Термины Kubernetes, Istio и Envoy немного отличаются, и не сразу понятно, что с чем едят.
Сервисы
Все те же сервисы есть в этом пространстве имен:
Как Istio узнает, какой протокол использует сервис? Настраивает протоколы для манифестов сервисов по полю name в записи порта.
Если использовать kubectl и админскую страницу переадресации портов в Envoy, видно, что конечные точки account-grpc-public реализуются Pilot как кластер в Envoy с протоколом HTTP2. Это подтверждает наши предположения:
Порт 15000 — это админская страница Envoy, доступная в каждом sidecar.
Прослушиватели
Прослушиватели узнают конечные точки Kubernetes, чтобы пропускать трафик в поды. У сервиса проверки адреса здесь одна конечная точка:
Поэтому у пода проверки адреса один прослушиватель на порте 50051:
Маршруты
В Namely мы используем Istio Ingress-Gateway для всего внутреннего GRPC-трафика:
Если переадресовать порт пода Istio-IngressGateway и посмотреть конфигурацию Envoy, мы увидим, что делает VirtualService:
Что мы гуглили, копаясь в Istio
Возникает ошибка 503 или 404
Причины разные, но обычно такие:
Что означает NR/UH/UF в логах прокси Istio?
По поводу высокой доступности с Istio
Почему Cronjob не завершается?
Когда основная рабочая нагрузка выполнена, sidecar-контейнер продолжает работать. Чтобы обойти проблему, отключите sidecar в cronjobs, добавив аннотацию sidecar.istio.io/inject: “false” в PodSpec.
Как установить Istio?
Спасибо Bobby Tables и Michael Hamrah за помощь в написании поста.
Антифрод-системы в популярных мобильных трекерах: AppsFlyer, Adjust, AppMetrica, TMC, Kochava
В конце прошлого года я писал на Хабре, какие существуют решения на рынке антифрода, и проводил сравнительный анализ некоторых из них. Тогда речь шла о системах, направленных именно на задачу обнаружения фрода в трафике. Сегодня хочу поделиться своим небольшим исследованием, как с фродом борются сами клиентские трекеры. Рассмотрю основные: Appsflyer, Adjust, Kochava, TMC Attribution Analytics (ex. MAT), AppMetrica.
Я расскажу, какие типы фрода определяет (или не определяет) трекер, как происходит сам анализ, насколько он эффективен, а также предоставлю для ознакомления ссылки самих трекеров с описанием антифрод-системы.
Сразу оговорюсь, что в данной статье я не сравниваю удобство самих трекеров и их качество — речь пойдет исключительно о встроенных в них антифрод-решениях.
Appsflyer
С Appsflyer мы работаем часто, их новинки не обходят нас стороной. Не так давно коллеги выпустили собственную систему защиты от фрода, с помощью которой можно обнаружить некачественный трафик и изучить каждый из источников.
Основной тезис Appsflyer в том, что у них есть огромная база IP и устройств, каждый из которых имеет собственную метку качества. То есть, если ранее определенное устройство заметили в подозрительной активности, то и установка по нему будет маркироваться как фродовая. Также, наличие самой базы позволяет узнавать количество новых устройств по каждому из источников. Если их слишком много, то Appsflyer считает это поводом подозревать источник в «создании» новых девайсов — по сути, в использовании эмуляторов.
Каждому из устройств присваивается собственный рейтинг: мошенническим девайсам присваивается оценка «C», подозрительным «B», новым устройствам «N» и т.д., в зависимости от уникальности взаимодействия настоящего живого пользователя с устройством, которое получает рейтинг «A», «AA» или «AAA». Устройства с оценкой «C» автоматически исключаются из списков атрибутируемых установок и аналитики AppsFlyer, то есть по ним не идет постбеков как таковых.
На скриншоте можно увидеть разбивку по источникам трафика и метрики антифрода —процент новых девайсов, лояльных пользователей, установок с устройств типа B и чистых конверсий\
По факту все не так просто. Громкие цифры в 98% известных Appsflyer устройств в том числе российского рынка могут быть не доскональными. По данным Gartner и IDC каждый квартал появляется около 350 тысяч новых девайсов. Не думаю, что Appsflyer способен уследить за каждым из них. Поэтому целиком полагаться на их БД не слишком разумно.
Впрочем, они и сами говорят, что метка фродовости — просто повод для дополнительной экспертизы. Также, рекомендуют обращать внимание на метрику «Лояльные Пользователи». Если она сильно ниже по другим источникам в сочетании с большим процентом новых девайсов, то следует изучить источник трафика.
Докажу на практике. Я столкнулся с кейсом, когда клиент, использующий Appsflyer, начал беспокоиться из-за числа новых устройств по одному из партнеров. Однако, при расспросе партнера, доскональном изучении источника его трафика и анализе с помощью дополнительной антифрод-системы выяснилось, что партнер распространяет оффер-волы на новых китайских устройствах, заключив договор с магазином, торгующим этими устройствами. То есть трафик был абсолютно нормальным и чистым, но Appsflyer посчитал его подозрительным. С другой стороны, данный трафик мог быть как раз-таки мошенническим, поэтому метка подозрительности AppsFlyer помогает изучать сложные случаи и выявлять партнеров с необычным трафиком. Либо же обнаружить реальный фрод. Поэтому использовать эту систему полезно, однако стоит быть крайне осторожным.
Вывод: 4 из 5. Можно ориентироваться на их метрики при собственном тщательном анализе, к тому же, продвинутый антифрод уже включен в расширенный аккаунт AF и не требует оплаты.
Adjust
Adjust предоставляет два инструмента борьбы с фродом в своем продукте. Первый, довольно стандартный, проверяет наличие IP в базе данных VPN и помечает конверсии со скрытым IP. В качестве защиты от прокси вполне подходит, свою работу выполняет. Но если прокси в базу не попал изначально, или фродер использует новые серверы, есть риск упустить мошенническую конверсию. Такие случаи, к сожалению, далеко не редкость.
Второй инструмент — анализатор клик-спама. Adjust — единственные, кто занимается подобным анализом, поэтому сравнивать особо не с чем. Способ проверки — изучение количества одинаковых кликов из одного источника и сравнение разницы между временем клика и конверсии с условным средним числом. Скажем так, сама идея анализировать трафик подобным образом весьма интересна, но ту же самую «норму» по времени выбрать не так просто. Существует вероятность ложного срабатывания, если произошло какое-то отклонение, например, человек просто забыл запустить скачанное приложение или намеренно отложил его запуск до того момента, как оно ему понадобится.
В общем, опять же, требуется изучать каждый случай такого срабатывания, чтобы достичь максимальной точности, иначе рискуете потерять адекватный источник, ложно обвиненный во фроде.
Есть еще третий инструмент — валидатор покупок, который проверяет валидность покупки, сверяя данные с информацией от стора, однако его мы, как агентство, оценить не можем.
В статистике антифрода можно сразу увидеть, в чем именно подозревается конверсия: AIP говорит о подозрительном или скрытом IP, TME — о слишком большом количестве одинаковых кликов, а DO — о странном времени между кликом и установкой. На скриншоте — один из «подозреваемых»
Оценка: 4,5 из 5. Пока никто другой не занимается подобным анализом, поэтому можно использовать инструмент Adjust’а в качестве рекомендаций для изучения аномалий трафика. Однако, нужно понимать, что встроенный инструмент не сделает за вас всей работы, поэтому не стоит целиком и полностью полагаться на него.
Также, к плюсам можно отнести применение антифрода к ретаргетинговым кампаниям. Из нашего опыта, Adjust справляется весьма хорошо, поэтому для подобных целей его можно однозначно положительно отметить среди остальных.
AppMetrica
В AppMetrica никаких встроенных инструментов антифрода нет, вот так все просто. Но достойно упоминания то, что коллеги решили не изобретать собственный велосипед, а провели интеграцию с продуктом FraudScore, сторонним инспектором трафика, о котором я подробно рассказывал в предыдущей статье про мобильный фрод.
Решение достойно уважения: зачем пытаться делать что-то, что другие делают гораздо лучше, разумнее делегировать это заслуженным лидерам.
Оценка для Appmetrica: без оценки.
Оценка для FraudScore: 5 из 5 — об этой системе я уже писал, но ее можно спокойно подключить и без использования AppMetrica.
TMC Attribution Analytics (ex. MAT)
Первый автоматически блокирует все конверсии, по которым есть аномалии (установки с одного Device ID дублируются, покупки в приложении сэмулированы и не совпадают с данными стора). Также есть 2 критерия, которые можно произвольно отключить — Jailbroken devices и максимум IP для одного Fingerprint. По сути, система справедлива — большинство критериев однозначны для фрода и отключать их нет смысла, а то, что может зависеть от пожеланий клиентам можно выключить.
Помимо этого, присутствует отчет по времени между кликом и установкой. Он никак не блокирует отправку постбеков, но по нему удобно искать аномалии самостоятельно. Покупки в приложении также можно проверить на фродовость, однако данную функциональность мы никак не можем протестировать со стороны агентства, поэтому ее я не стану включать в оценку.
Наконец, в системе представлена возможность формировать собственные «черные списки» — выставлять подходящее окно атрибуции (сколько дней может пройти со времени клика), блокировать саб-партнеров, модели устройств, страны.
Это не тянет на полноценный антифрод, однако иметь возможность кастомизировать трекинг на таком уровне — однозначно приятно.
Разбивка конверсий, не прошедших оценку качества — указан партнер, время и повод для подозрений
Вывод: 3,5 из 5. Нет слишком жестких критериев, есть кастомизация и инструменты для анализа. Можно порекомендовать как адекватное решение при наличии собственных аналитиков на вашей стороне.
Kochava
На практике мне не доводилось иметь дела с антифродом Кочавы, однако в их статье довольно неплохо описано, как можно самостоятельно находить фрод и на какие критерии смотреть. Трекер практически не берет эту работу на себя, однако подробно рассказывает клиенту, как можно вычислить подозрительный трафик.
Есть, правда, Trafic Verifier — небольшая утилита, которая по сути выполняет задачу трекинговой системы — ограничивает ГЕО, ОС и типы устройств. Дополнительная функция Frequency Capping выступает в роли инструмента, ограничивающего количество кликов с определенного IP и прочего за выбранный промежуток времени. Также, можно провести анализ What-If по трафику, который уже есть в статистике.
Из других решений — Kochava Blacklist — по сути, глобальный фильтр трафика, помечающий неподходящий по критериям: количества кликов с одного устройства и IP и разницы между кликом и установкой.
Как и было сказано выше — у меня не было возможности проверить его в деле, однако выставлять общие фильтры на все, не учитывая специфики приложения и трафика — идея далеко не рациональная.
Вывод: 2,5 из 5. Инструкция и инструмент хороший, но по факту трекер почти не выполняет функцию антифрода, лишь дает возможность управлять трафиком и пищу для размышлений о его качестве.
Результаты
Из всего вышеозвученного можно сделать вывод: на данный момент ни один из трекеров не выполнит полностью задачу определения фрода.
Трекеры, реализующие антифрод-решения, однозначно молодцы, так как раньше ничего подобного не существовало. Теперь же трекер может существенно облегчить задачу обнаружения фрода. Однако выносить решение о реджекте трафика, исходя исключительно из рекомендаций трекера, не общаясь с партнером и не изучая всевозможные метрики самостоятельно — проигрышная стратегия в долгосрочной перспективе.
Надеемся, что в будущем коллеги из систем трекинга не станут снижать темпы развития собственных антифрод-решений, сделав их досконально точными.
А пока выбирайте тот трекер, который вам больше всего подходит, обучайте собственных аналитиков для поиска аномалий и выбирайте партнеров, которые готовы к диалогу и внутреннему анализу — как, например, это делаем мы в Mobio.
