Постбэки

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

Для большинства интегрированных партнёров мы уже подготовили постбэки. Вам остаётся только задать режим их отправки (см. раздел Отправка постбэков).

Но бывают ситуации, когда стандартных постбэков недостаточно:

Вы подключаете нового партнёра, которого MyTracker пока не поддерживает
Вы хотите отправлять постбэки в свою собственную или в стороннюю систему аналитики

В таких случаях вы можете создать постбэки самостоятельно.

Добавление постбэка

Прежде чем читать дальше, попросите у партнёра документацию или устное описание требований к постбэкам.

Выберите меню Маркетинг > Партнёры.
В появившемся списке найдите нужного вам партнёра и кликните по его названию или логотипу.
Перейдите на вкладку Постбэки и нажмите Добавить.
Заполните открывшуюся форму:

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

Рекомендуем выработать какой-то стандартизированный подход к именованию — так будет проще ориентироваться, если постбэков станет много. Например, постбэки могут называться так: Partner name | install

Метод запроса * — метод отправки постбэка. В большинстве случаев необходимо использовать метод get. Другой метод может потребоваться, если партнёр явно указал это в своей документации.
Событие * — установка, реатрибуция или in-app событие, при возникновении которого надо отправлять постбэк. Ниже приведён список поддерживаемых событий.
Шаблон URL * — шаблон, который будет использоваться при формировании конечного URL, по которому мы отправим постбэк (HTTP-запрос). Устройство шаблона и возможности интерфейса по управлению им подробно описаны ниже в разделе Шаблон URL.

* — обязательные поля.

Нажмите Добавить.

Теперь вы можете настроить отправку постбэка для всех кампаний партнёра и подключить постбэк в качестве «дополнительного» к конкретным кампаниям.

Шаблон URL

Шаблон URL — это обычный URL, в котором вместо значений параметров используются так называемые «макросы» (псевдо-значения, которые MyTracker заменит реальными значениями перед отправкой постбэка).

Рассмотрим процесс составления шаблона:

Введите в поле Шаблон URL базовую часть URL (до знака вопроса): http://site.com/postback/.

Параметры шаблона можно прописать вручную в строке Шаблон URL или добавить согласно инструкции ниже

Нажмите Добавить параметры.
Последовательно добавьте все параметры, указанные в документации партнёра.
Для каждого параметра:
1. Укажите Название — это значение будет соответствовать имени переменной в GET запросе.
2. Выберите Тип параметра. Подробнее см. раздел Типы параметров в постбэках.
3. Нажмите Добавить справа. В результате в поле Шаблон URL появится новый параметр, а в форме появится строчка для добавления следующего.

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

Нажмите Добавить в форме добавления постбэка (или Сохранить в форме редактирования).

Поддерживаемые события

В MyTracker можно отправлять постбэки на следующие события:

Установка
Новый пользователь
Реактивация
Повторная установка
Первый платёж
Платёж
Первый универсальный доход
Универсальный доход
Первая регистрация
Регистрация
Первая авторизация
Авторизация
Кастомное событие

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

Установка

Событие «Установка» возникает при первой установке и запуске мобильного приложения на устройстве.

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

Уникальное событие. Может произойти на устройстве только один раз.

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

Новый пользователь

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

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

Уникальное событие. Может произойти только один раз.

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

Реактивация

Реактивация — это активность, перед которой пользователь бездействовал в течение «окна неактивности» (по умолчанию 30 дней).

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

Постбэки на реактивацию можно отправлять по устройствам и пользователям:

Реактивация^d — уведомление партнёра о повторной установке или реактивации приложения на устройстве.
Реактивация^u — уведомление партнёра о возвращении зарегистрированного пользователя в проект. Подробнее

В качестве примера рассмотрим порядок действий, который приводит к Реактивации^d на мобильном устройстве:

Установка приложения на устройство. В этот момент «время последней активности» равно «времени появления».
(необязательно) Запуск приложения на устройстве, регистрация, авторизация, просмотр встроенной рекламы или платёж. При каждом таком дейстивии пользователя «время последней активности» обновляется и становится равным времени последнего действия пользователя.
С момента «последней активности» прошло более 30 дней (30 дней — это настраиваемое значение, которое называется «Окно неактивности» и задаётся для каждого приложения). В течение этого времени на устройстве не было зафиксировано ни одного действия пользователя.
MyTracker отслеживает активность → Засчитывает реактивацию.

Событие не уникально. Может возникать на устройстве много раз.

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

Повторная установка

Повторная установка — это установка мобильного приложения, перед которой пользователь устройства удалил приложение и бездействовал в течение «окна неактивности» (по умолчанию 30 дней).

Рассмотрим порядок действий, что приводит к повторной установке:

Установка приложения на устройство. В этот момент «время последней активности» равно «времени установки».
(необязательно) Запуск приложения на устройстве. При каждом запуске «время последней активности» обновляется — оно становится равным времени последнего запуска.
Удаление приложения с устройства.
С момента «последней активности» прошло более 30 дней (30 дней — это настраиваемое значение, которое называется «Окно неактивности» и задаётся для каждого приложения). В течение этого времени не было ни одного запуска приложения.
Повторная установка (и запуск) приложения на устройстве → MyTracker засчитывает повторную установку. Формально запуск не является обязательным условием для возникновения «повторной установки», но де-факто информация о повторной установке не может быть отправлена на сервер, пока пользователь не запустит приложение.

Событие не уникально. Может возникать на устройстве много раз.

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

Первый платёж

Первый платёж — первый платёж за всё время жизни пользователя/устройства.
Первый платёж CA — первый платёж с момента последней атрибуции (установки, реактивации или повторной установки мобильного приложения).

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

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

Используйте События в кампаниях по привлечению новых пользователей, CA-события — в ремаркетинговых кампаниях.

Платёж

Платёж — любой платёж.
Платёж CA — платёж в рамках действия текущей атрибуции (постбэки по текущей кампании перестанут уходить, если сработает реатрибуция).

Оба события не уникальны. Могут возникать много раз в течение жизни пользователя.

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

Первый универсальный доход

Первый универсальный доход — первый платёж за всё время жизни пользователя/устройства, загруженный в MyTracker через S2S API.
Первый универсальный доход CA — первый платёж с момента последней атрибуции (установки, реактивации или повторной установки), загруженный в MyTracker через S2S API.

Подробнее об универсальном доходе см. раздел Трекинг дохода

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

Универсальный доход

Универсальный доход — любой платёж, загруженный в MyTracker через S2S API.
Универсальный доход CA — платёж в рамках действия текущей атрибуции, загруженный в MyTracker через S2S API (постбэки по текущей кампании перестанут уходить, если сработает реатрибуция).

Подробнее об универсальном доходе см. раздел Трекинг дохода

Оба события не уникальны. Могут возникать много раз в течение жизни пользователя.

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

Первая регистрация

Первая регистрация — первая регистрация за всё время работы устройства.

Этот постбэк соответствует потоковой метрике Событие с названием mt_registration.
Обратите внимание, что постбэк отправляется именно по устройствам, но не по пользователям приложения. То есть если пользователь зарегистрирован в приложении под несколькими аккаунтами, то засчитана будет только одна первая регистрация.

Уникальное событие. Может произойти на устройстве только один раз.

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

Регистрация

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

Оба события не уникальны. Могут возникать много раз за время работы устройства. Например, на одном устройстве могут быть зарегистрированы два разных пользователя или один пользователь под разными аккаунтами.

Применение: постбэки на регистрацию можно использовать в комбинации с обычными постбэками на установки для информирования партнёра о качестве приводимой им аудитории (если партнёр поддерживает оптимизацию кампаний).

Первая авторизация

Первая авторизация — первая авторизация за всё время работы устройства.

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

Уникальное событие. Может произойти на устройстве только один раз.

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

Авторизация

Авторизация — любая авторизация на устройстве.
Авторизация CA — авторизация в рамках действия текущей атрибуции (постбэки по текущей кампании перестанут уходить, если сработает реатрибуция).

Оба события не уникальны. Могут возникать много раз в течение работы устройства.

Применение: постбэки на авторизацию можно использовать в комбинации с обычными постбэками на установки для информирования партнёра о качестве приводимой им аудитории (если партнёр поддерживает оптимизацию кампаний).

Используйте Cобытия в кампаниях по привлечению новых пользователей, CA-события — в ремаркетинговых кампаниях.

Кастомное событие

Кастомное событие — это любое событие, которое ваше приложение отправляет на сервер с помощью соответствующих методов SDK.

Если вы не знаете, как отправлять кастомные события из SDK, рекомендуем ознакомиться с документацией: iOS | Android | Unity | Flutter | Web

Например, это может быть «добавление товара в корзину», «достижение уровня в игре», «отправка сообщения».

Уникальность

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

Разница между Cобытием и CA-событием

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

Применение

Применение зависит от вида событий, от смысла, который вы в него вкладываете. Но основные идеи — такие же, как для остальных событий:

CPA-кампании (как замена или как дополнение к обычным постбэкам на установки).
Версия событий в первой атрибуции — для обычных кампаний, CA — для ремаркетинговых.

Также кастомные события удобно использовать для создания ремаркетинговых списков (для партнёров, которые их поддерживают — например, Google Ads).

События и CA-события: какие выбрать

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

События СА отправляются в текущей атрибуции, то есть для сайтов источник трафика определяется по модели last-visit, а для приложений включает реатрибуции.

Используйте События, если вы ориентриуетесь на привлечение новой аудитории, не взаимодействовавшей с вашим приложением или сайтом ранее.

Аналогия с отчётами

Если вы уже разобрались с Flow и CA (Current Attribution) метриками в отчётах, то понять алгоритм работы событий постбэков будет легко. Здесь действует та же логика.

Например, если включить отправку постбэка на «Платёж», то количество отправленных постбэков будет равняться значению метрики «Транзакции» в отчётах. Если же включить отправку на «Платёж CA», то количество отправленных постбэков будет равняться значению метрики «Транзакции CA».

Если у вас остались вопросы, наша служба поддержки с удовольствием ответит на них.

Была ли эта статья полезна?