Постбэки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Шаблон URL

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

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

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

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

Нажмите Добавить параметры.
Последовательно добавьте все параметры, указанные в документации партнёра.
Для каждого параметра:
1. Укажите Название — это значение будет соответствовать имени переменной в GET запросе.
2. Выберите Тип параметра. MyTracker поддерживает следующие типы:
  - Константа — конкретное значение. Оно будет отправляться партнёру без изменений.
  - Параметр трекинг-ссылки — если к рекламной ссылке добавлены дополнительные GET-параметры, то их можно использовать при отправке постбэка. В поле «название параметра из click url» при этом надо указать имя параметра из ссылки для подсчёта кликов.
  - JSON — объект JavaScript Object Notation, который можно передавать в постбэках.
  - Платформо-зависимый параметр — значение, используемое для конкретной платформы, которое будет отправляться партнёру без изменений. Платформенные значения необходимо записывать в объект JSON c использованием префикса mtpc_.
  - mt_* — макросы MyTracker, через которые могут быть переданы данные, уже имеющиеся в MyTracker: идентификаторы устройства, параметры события, информация о пользователе. Полный список приведён в разделе Макросы в постбэках.
  - mtpp_* — параметры рекламных кампаний. Список параметров подгружается автоматически из кампаний партнёра в MyTracker. См. Параметры кампаний.
3. Нажмите Добавить справа. В результате в поле Шаблон URL появится новый параметр, а в форме появится строчка для добавления следующего.

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

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

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

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

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

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

Установка

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

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

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

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

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

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

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

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

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

Реактивация

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Платёж LT/CA

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Регистрация LT/CA

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

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

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

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

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

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

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

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

Авторизация LT/CA

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

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

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

Кастомное событие LT/CA

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

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

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

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

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

Разница между LT/CA

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

Применение

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

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

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

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

Простое правило

Если вас не интересуют ремаркетинговые кампании, используйте только LT-события:

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

Справедливо и обратное. Для ремаркетинговых кампаний надо использовать CA-события:

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

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

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

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

Что такое LT и CA

LT — сокращение от LifeTime. Смысл LT-событий (и метрик в отчётах) в том, что они существуют в контексте «всей жизни пользователя/устройства»: с момента его появления в приложении (установки или первого посещения сайта) до смерти устройства. Промежуточные реатрибуции на них никак не влияют.

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

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

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