Dilshat Rakhimov
Июль 2026 · 8 мин чтения
Почти все советы по измерениям исходят из одного из двух миров. Либо у вас сайт - куки, пиксель, браузер, который вы контролируете, - либо приложение, с SDK, MMP и идентификатором устройства. Суперприложение не то и не другое. Суперприложение - это нативная оболочка, внутри которой несколько десятков сервисов живут как WebView, каждый на своём домене, доступный через диплинк-роутер, за сессией, которой владеет оболочка, а не веб-страница.
На этой границе ломается всё. Не эффектно - в этом и проблема. Ничего не падает с ошибкой. Пиксель грузится, события уходят, дашборды заполняются, и числа неверны так, что это замечают через квартал и объясняют ещё квартал.
Это оглавление к четырём частям проблемы - примерно в том порядке, в котором они вас настигнут, - плюс правила, которые оказываются одинаковыми во всех четырёх.

1. Переход: завести пользователя внутрь, не потеряв, откуда он
Человек нажимает на объявление. Если приложение установлено, диплинк открывает оболочку, а та открывает WebView на домене сервиса. Где-то в этой цепочке - редирект рекламной платформы, роутер, Universal Link, запуск WebView - click id теряется, и сессия падает в Organic.
Это первая проблема, потому что она выше всех остальных по течению. Нет источника на входе - нет источника нигде дальше, и никакая изобретательность внутри сервиса его уже не вернёт.
→ Диплинки для суперприложения Halyk-класса: WebView-сервисы, cross-auth и атрибуция UTM/MMP без потерь - контракт ссылки, cross-auth между доменами и как пронести UTM и данные MMP через переход, не потеряв их.
2. Внутри: отличить платный трафик от собственного трафика суперприложения
Как только WebView открылся, все сессии выглядят одинаково - и рекламный клик, и переход из меню самого приложения, и баннер-витрина. При этом внутренний трафик конвертируется так, как платный не будет никогда, потому что это уже клиенты, уже залогиненные.
Смешайте их - и получите самый дорогой сценарий отказа в этом наборе: завышенная конверсия платного сегмента, ставки, которые ползут вверх вслед за ней, и алгоритм, оптимизирующийся на людей, которых реклама никогда не приводила. Отчётность при этом всё время выглядит прекрасно.
→ Атрибуция внутри WebView SuperApp: как донести источник до Amplitude и не засорить платный канал - чтение launch-URL до того, как роутер его сотрёт, гейт атрибуции MMP строго на ad-origin запуски и отдельный серверный слой для денег.
3. Рост самой оболочки, дальше установки
У app-growth своя ловушка. Кампании нацеливают на установку и регистрацию, потому что эти события SDK отдаёт бесплатно, - и весь медийный бюджет начинает оптимизироваться на людей, которые проходят KYC и больше никогда не совершают транзакций. Регистрация - не продукт, это турникет.
→ Суперприложение не вырастить на одном KYC: события Firebase, модель ценности и tROAS для продуктового роста - набор событий после регистрации, модель ценности, отражающая реальную стоимость пользователя, и перевод кампаний на tROAS.
4. Зеркальный случай: чужой in-app браузер открывает ваш сайт
Та же структурная проблема приходит с другой стороны, когда TikTok или Instagram открывает ваш сайт внутри своего WebView. Теперь вы - сервис внутри чужой оболочки, с её обработкой куки, её поведением referrer и её ограничениями на ваш стек.
Читается как другая тема, но это не так - это та же граница, только вы с другой её стороны.
→ Когда TikTok и Instagram открывают ваш сайт внутри приложения: атрибуция, события и CAPI без костылей - что реально переживает in-app браузер и как сохранить атрибуцию и CAPI без хаков вокруг user-agent.

Что общего у всех четырёх
Прочитайте их подряд, и одни и те же три правила всплывут с четырёх несвязанных сторон.
Захватывайте в самый ранний момент и сразу фиксируйте значение. launch-URL перезаписывается роутером SPA на первой же навигации. Click id теряется на редиректе. Referrer исчезает к тому моменту, как in-app браузер закончит загрузку. Во всех случаях сигнал существует несколько сотен миллисекунд, а потом нет, и лечение всегда одной формы: прочитать на самом раннем доступном init и записать туда, где это не перезапишут. Ленивый захват теряет ровно то, что было нужно.
Гейт на платный сигнал ставьте осознанно. Параметры атрибуции принадлежат ad-origin сессиям и никаким другим. Проставьте их на каждую сессию - потому что так проще, потому что MMP с удовольствием отдаст вам протухшее значение от прошлой атрибуции - и внутренний трафик тихо затопит платный сегмент. Это стоит настоящих денег и почти не видно в отчётности: числа просто выглядят лучше, чем есть.
Денежное событие уходит на сервер. Браузерный рекламный стек внутри WebView регулярно выключен kill-switch'ем самой оболочки, а WebView - это как раз то место, где происходит большинство транзакций. Пиксель, который не загрузился, не может отчитаться о выручке. Отправляйте конверсии с бэкенда, дедуплицируйте по одному идентификатору, сгенерированному в точке действия, и браузерный стек перестаёт быть несущим.
А под всеми тремя лежит проблема наименования, самая скучная и потому не описанная нигде: ничего из этого не работает, если purchase означает шесть разных вещей в шести сервисах. Согласованные события по всему продуктовому портфелю суперприложения - это подложка, на которой держится остальное. Как схлопывают разросшуюся - отдельная работа и отдельная статья.
С чего начинать
Если вы стоите перед измерительным стеком суперприложения и не знаете, за какой конец браться:
- Проверьте, переживает ли источник переход. Посмотрите на долю установок и сессий, падающих в Organic. Если она неправдоподобна - начинайте с части 1: ничему ниже по течению доверять нельзя, пока это не починено.
- Проверьте, появляются ли параметры атрибуции на внутренней навигации. Там должен быть ноль. Если нет - ваш платный сегмент разбавлен прямо сейчас, и часть 2 это самые быстрые сохранённые деньги.
- Проверьте, отчитывается ли о выручке браузерный пиксель внутри WebView. Если да - выясните, грузится ли этот пиксель вообще. Часто нет.
- И только потом беритесь за структуру кампаний и стратегии назначения ставок. Часть 3 исходит из того, что первые две в порядке; модель ценности, построенная на смешанном трафике, - это уверенный неверный ответ.
