Tracking stack: MMP + трекер + CAPI для app-install кампаний

Tracking stack для app-install кампаний - это четыре системы, которые обязаны работать как одна: рекламные сети, продающие инсталлы, MMP, который их измеряет, трекер, ведущий вашу собственную математику ROI, и CAPI-канал, возвращающий конверсии платформам для оптимизации. Потеряете один стык - бюджет продолжит течь, а сигнал тихо умрет где-то между кликом и рекламным кабинетом.

Гайд собирает стек по порядку: роль каждого слоя, поток данных через три стыка, слой согласий iOS сверху и проверки, доказывающие работоспособность до масштабирования. Более широкая server-side рамка разобрана в серверном трекинге для перформанс-маркетинга; здесь держимся app-install пути.

Что такое полный tracking stack для app-install кампаний?

С покупкой все просто: вы покупаете инсталлы на Meta и TikTok. Слои появляются в измерении. Meta и Google Ads атрибутируют инсталлы по собственным device-level логам кликов без атрибуционных ссылок; TikTok тоже сверяет свои логи, но поверх этого использует кликовые трекинг-ссылки с макросами. MMP вроде AppsFlyer, Adjust или Singular измеряет инсталл изнутри приложения через SDK и превращает его в нейтральную отчетность и постбеки. Трекер вроде Keitaro, Binom, Voluum или RedTrack ведет клик-учет с вашими payout-данными. Нога доставки в CAPI замыкает петлю: она пушит подтвержденные конверсии в серверные API платформ - именно на них учатся их оптимизационные движки.

Каждый слой закрывает слепые зоны остальных. Цифры сети - это цифры сети. У MMP без трекера нет ROI уровня payout. Трекер без MMP вообще не видит инсталл: данные об инсталле рождаются в SDK. Без ноги CAPI платформы оптимизируют по кликам, а реальные конверсии для них остаются невидимыми. Рабочий tracking stack - это когда ни одна из этих дыр не осталась открытой.

Какую роль играет каждый слой?

Две документированные детали фиксируют роли. Первая: SRN сами атрибутируют инсталлы - когда MMP уведомляет сеть об инсталле, она сверяет его со своими логами кликов, безо всяких атрибуционных ссылок. Вторая: на iOS SRN-атрибуция в MMP идет через SKAdNetwork и Aggregated Advanced Privacy вместо детерминистического матчинга, а lookback-окна SRN колеблются от 1 до 28 дней в зависимости от сети. Где именно пересекаются два инструмента измерения и когда они нужны оба, разобрано в MMP против аффилейт-трекера.

Как данные идут через tracking stack шаг за шагом?

1. Пользователь кликает рекламу TikTok и попадает на трекинг-ссылку из дашборда MMP. Ссылка несет обязательные макросы атрибуции: idfa или gps_adid, ip, user_agent и clickid=CALLBACK_PARAM, где TikTok передает свой callback-параметр как click ID.
2. Приложение ставится, SDK MMP репортит инсталл.
3. Сеть сама атрибутирует инсталл по своим логам кликов, когда MMP уведомляет ее. В SAN-сетапе вроде интеграции Adjust интеграция отдает сети все инсталлы, и матчингом занимается сама сеть.
4. Постбеки вытекают из MMP: in-app события возвращаются в сеть в течение партнёрского периода retention, а настроенный фид везет события в сторону трекера.
5. Трекер записывает конверсию под своим кликом с subid и статусом.
6. Нога доставки пушит событие в Meta CAPI и TikTok Events API.

Клик      -> трекинг-ссылка MMP: clickid=__CALLBACK_PARAM__, idfa/gps_adid, ip, user_agent
Инсталл   -> MMP атрибутирует (self-attribution SRN или матч по device ID)
Постбек   -> трекер сохраняет subid + status
Доставка  -> датасет Meta CAPI и TikTok Events API с event_id и action_source=app

Каждая стрелка на этой схеме - место, где идентификаторы переписываются или теряются. Каталог поломок именно этой цепочки, хоп за хопом, живет в server side conversion delivery; здесь идем дальше.

Где живет event_id в стеке?

• Click ID сети. TikTok кладет свой callback-параметр в трекинг-ссылку как clickid=CALLBACK_PARAM; на веб-стороне TikTok ту же роль играет ttclid.
• Click ID трекера: subid, выданный в момент клика и ожидаемый обратно в постбеке вместе со статусом конверсии.
• event_id внутри CAPI-payload. Meta дедуплицирует события между своими каналами - SDK, MMP, App Events API - по паре event_id и event_name, а неверные event_id дают ложную дедупликацию и искажают отчетность.

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

Стык 1: от рекламной сети к MMP

Трекинг-ссылки берутся из дашборда MMP с макросами атрибуции из списка выше. У SAN-интеграций механика чуть другая: в Adjust интеграция с SAN создает ссылки автоматически, SAN получает из Adjust все инсталлы и атрибутирует их по собственным данным вовлеченности. Интеграции нужны network credentials - токен, пара логин-пароль или ключ - плюс Adjust SDK версии 4.0.0 и новее, чтобы partner-параметры SDK маппились в параметры сети.

Следите за направлением постбеков: здесь в tracking stack чаще всего путаются. Атрибуция течет из сети в MMP, а событийные постбеки - в обратную сторону: AppsFlyer отправляет in-app event postbacks обратно в SRN в течение партнёрского периода retention, а в интеграции с TikTok список постбэк-событий настраивается на стороне MMP, с маппингом имен событий TikTok в имена AppsFlyer, Adjust или Singular. Если ждать, что сеть сама запушит события в ваш MMP, вы дождетесь постбека, который никогда не должен был прийти.

Сам TikTok рекомендует апп-маркетологам мерить кампании через MMP; задокументированный запасной вариант без MMP - переключиться на цель Traffic и мониторить клики.

Стык 2: от MMP к трекеру

На этом стыке приходит постбек: HTTP-запрос от одного сервера к другому, сообщающий о конверсии, минимум с двумя параметрами - click ID (subid) и статусом. Keitaro документирует принимающую сторону конкретно: Postback URL защищен postback key, аутентифицирующим входящие запросы, а нестандартные имена параметров вроде clickid, type или profit ремапятся в subid, status и payout в настройках Postback URL.

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

Есть и задокументированный запасной путь, когда входящий запрос настроить нельзя: Keitaro позволяет загружать конверсии вручную или через API-импорт. Это инструмент починки, а не дизайн: регулярная доставка все равно требует автоматического пути.

Стык 3: в Meta CAPI и TikTok Events API

На стороне Meta апп-события могут приезжать тремя каналами - Facebook SDK, MMP и App Events API - и датасет Conversions API консолидирует их всех в одном интерфейсе. Серверные события аппа обязаны нести action_source со значением app и уходят на эндпоинт датасета:

POST graph.facebook.com/{API_VERSION}/{DATASET_ID}/events?access_token={TOKEN}

{
  "data": [
    {
      "event_name": "purchase",
      "event_time": 1788100000,
      "event_id": "install-2026-09-04-0137",
      "action_source": "app",
      "advertiser_tracking_enabled": 1,
      "application_tracking_enabled": 1,
      "user_data": {
        "client_ip_address": "203.0.113.24"
      }
    }
  ]
}

Два поля тут кусаются. client_ip_address нельзя хешировать и, в отличие от событий через SDK, на серверном пути его надо добавлять вручную внутри user_data. advertiser_tracking_enabled несёт результат ATT-промпта, application_tracking_enabled - настройку трекинга на уровне аппа, оба как ноль или единица.

На стороне TikTok Events API - серверное соединение между TikTok и маркетинговыми данными рекламодателя, покрывающее web, app и offline события. В настройке выбирается способ интеграции и режим: standalone или второй канал рядом с Pixel, причем второй канал - рекомендуемый. API требует access token, а после внедрения соединение валидируется диагностическими тулзами TikTok. Разводка этой ноги на стороне трекера, включая макросы токенов и тестирование событий, - в гайде TikTok Events API для аффилейт-трекеров.

Что меняет слой iOS и ATT в стеке?

Apple требует от приложений, собирающих данные о пользователях и шарящих их с другими компаниями для трекинга между аппами и сайтами, использовать фреймворк AppTrackingTransparency: requestTrackingAuthorization показывает промпт, trackingAuthorizationStatus возвращает результат. Этот статус согласия уезжает в CAPI-payload как application_tracking_enabled и является условием детерминистической атрибуции на iOS.

Рядом с детерминистическим стеком работают агрегатные фреймворки. SKAdNetwork определяет трех участников - рекламные сети, рекламируемые аппы и разработчика, который может opt-in'ом получать копии winning-постбэков. В SKAN 4 на iOS 16.1 и новее conversion value обновляется в трех conversion windows с максимум тремя постбэками на подписанное объявление, а postback data tier от Apple, управляемый crowd anonymity, ограничивает детальность каждого постбэка. Winning-постбэк получает одна сеть, еще до пяти сетей с квалифицированными показами получают non-winning копии. AdAttributionKit продолжает ту же модель и добавляет re-engagement и раздачу через альтернативные маркетплейсы, с Postbacks 1-3 и теми же тирами.

На практике эти фиды лежат рядом с вашим tracking stack, а не внутри него: AppsFlyer отдает SKAN-постбэки по API, включая отдельный фид blocked install postbacks, а iOS-атрибуция SRN-трафика идет через SKAN и Aggregated Advanced Privacy вместо матчинга по device ID. Расписание постбэков, conversion values и причины расхождений iOS-цифр со всеми дашбордами - в гайде SKAdNetwork и AdAttributionKit: репортинг iOS-трафика. Веб-фолбэк Meta для iOS, Aggregated Event Measurement, касается апп-стека только по краям, у него собственный гайд по настройке.

Как проверить tracking stack до масштабирования бюджета?

1. Кликните живую рекламу и убедитесь, что click ID появился в трекере с ожидаемыми sub ID.
2. Триггерьте одно in-app событие на тестовом устройстве и убедитесь, что постбек пришел с правильными subid и статусом.
3. В Meta Events Manager прогоните шаг Verify your setup из официального флоу внедрения CAPI: он подтверждает, что события дошли, дедуплицируются и матчятся корректно.
4. Валидируйте соединение TikTok Events API диагностическими тулзами TikTok.
5. Сверьте счетчики по слоям. Малые расхождения нормальны: lookback-окна SRN длятся от 1 до 28 дней, а SKAN-постбэки задерживаются по дизайну. Большая постоянная дыра указывает на сломанный стык, а не на "расхождение платформ".
6. Повторите весь проход после любого изменения макросов, шаблонов постбеков или имен событий; переименованный макрос ломает цепочку молча.

Порядок важен: проверяйте от клика вперед, потому что поломка на стыке 2 обесценивает все проверки ниже.

Где место Most в tracking stack?

Стек заканчивается на последнем стыке: подтвержденные конверсии должны течь в Meta CAPI и TikTok Events API столько, сколько живет кампания, с теми же event ID и той же дисциплиной дедупликации в каждом пуше. Most закрывает эту ногу доставки автоматически: маршрутизирует конверсии трекера в CAPI-каналы с очередями ретраев, так что собранный выше tracking stack продолжает отчетность после запуска без ручных выгрузок. Для разового проверенного тестового события до всякой разводки Pixel Activator делает это бесплатно.

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

Кластер мобильного стека

• App-конверсии Snapchat через MMP - MMP-путь к Snap
• Маппинг MMP-постбека в CAPI - как событие MMP становится серверным событием платформы
• SKAdNetwork и AdAttributionKit - iOS-атрибуция без девайс-идентификаторов

Источники