Установки и события PWA считают так: клик-id кладут в рекламную ссылку, приложение сохраняет его при первом визите и затем отправляет обратно в трекер постбеком на каждое значимое действие — от добавления на экран «Домой» до депозита. Сложность в том, что PWA не живёт в магазине приложений: ни App Store, ни Google Play не подтверждают факт установки, поэтому её определяет каждый участник цепочки по-своему — рекламная сеть, трекер, конструктор, сама команда. Пока определения не сведены к одному словарю, отчёты расходятся всегда, и это не баг, а следствие архитектуры.
Что считать установкой PWA и почему цифры расходятся
Три разных «установки»
Добавление на экран «Домой» — физическое действие пользователя: он подтвердил установку в браузере или выбрал пункт меню «Добавить на экран». В браузерах на Chromium событие ловится в JavaScript, и приложение может отправить сигнал наружу. На iOS такого события нет: система не сообщает сайту о добавлении, и факт выводят косвенно — по запуску в режиме standalone, когда интерфейс браузера не отображается.
Первый запуск из иконки — открытие не по ссылке, а с иконки, в полноэкранном режиме. С точки зрения продукта это самый честный «инсталл»: человек вернулся. Но фиксирует его только код приложения, поэтому до трекера сигнал доедет лишь при условии, что вы его предусмотрели.
Регистрация или первый вход — событие на сервере, привязанное к аккаунту. Для арбитража это самая надёжная точка: не зависит от того, почистил ли пользователь хранилище браузера, и не теряется при смене устройства, если аккаунт восстановлен. Многие команды в отчётах называют установкой именно её — это осознанное решение, а не ошибка.
Почему статистика трекера и конструктора не сходится
Причин четыре, и все они устранимы только договорённостью, а не правкой кода.
Первая — разный момент фиксации. Конструктор может считать установкой добавление на экран, трекер — первое доехавшее до него событие, рекламная сеть — клик с последующей активацией. Один и тот же пользователь попадает в три разные строки отчёта.
Вторая — окно атрибуции. Трекер приписывает событие клику, если оно случилось внутри заданного окна. Пользователь может добавить PWA на экран сегодня, а вернуться и зарегистрироваться через месяц — во втором случае событие уже «ничьё»: установка есть, конверсии нет.
Третья — отсутствие арбитра. В магазине приложений установку подтверждает независимая сторона. В PWA её нет: каждый считает по своим логам, а логи у всех разные.
Четвёртая — дедупликация. Если приложение отправляет событие и с клиента, и с сервера, без сквозного идентификатора события в трекере появятся дубли, и цифры поедут вверх. То же бывает при ретраях постбека после таймаута.
Свой словарь событий: таблица, которую стоит зафиксировать до запуска
Единый глоссарий — самая дешёвая и самая недооценённая часть трекинга. Пока команда, разработчик и трекер называют установкой разное, аналитика превращается в спор о словах.
| Событие | Что означает | Кто фиксирует | Когда отправляем постбек |
|---|---|---|---|
visit | Первый визит по рекламной ссылке | Клиентский скрипт | Сразу, как «клик дошёл до лендинга» |
install_prompt | Показан нативный запрос установки | Клиент (где поддерживается) | Не отправляем, служебное |
install | Пользователь добавил PWA на экран | Клиент (где есть событие), иначе сервер по признаку standalone | По факту добавления |
first_open | Первый запуск с иконки в полноэкранном режиме | Клиент + сервер | Один раз на устройство/аккаунт |
registration | Создан аккаунт | Сервер | Сразу после создания, с ID пользователя |
deposit | Первое целевое действие с деньгами | Сервер, по данным платёжки | После подтверждения платежа |
push_subscribe | Оформлена подписка на пуши | Клиент/сервер | По факту подписки |
push_delivered | Пуш принят push-сервисом | Сервер | Агрегированно, не по каждому |
push_click | Переход из пуша | Клиент + сервер | По факту клика, с привязкой к клик-id |
Что такое PWA на уровне технологии и почему у него нет «магазинного» подтверждения установки, разобрано в материале про PWA простыми словами; там же — про манифест и service worker, без которых трекинг не к чему прикручивать.
Как передать клик-id в PWA и не потерять его
Что вообще прокидывать
Клик-id — идентификатор конкретного клика, который рекламная сеть или трекер выдаёт в момент перехода. В ссылке он приходит макросом, который подставляет сеть, а рядом едут служебные параметры: источник, кампания, креатив, саб-идентификаторы. Этого набора достаточно, если он доедет до момента регистрации.
Клик-id нужен не «для красоты в URL», а чтобы привязать будущее событие к конкретному клику. Всё остальное — способ не потерять связку между визитом и целевым действием, которые могут быть разделены днями.
Сохранение при первом визите
Скрипт на входной странице читает параметры адреса, достаёт клик-id и служебные метки и записывает их в постоянное хранилище браузера. Дальше приложение при каждом значимом событии берёт связку оттуда.
Тонкости, на которых чаще всего теряют данные:
- localStorage чистится. Пользователь может сбросить данные сайта, а некоторые браузеры вытесняют хранилище при нехватке места. Поэтому клик-id дублируют — в IndexedDB, в cookie и, главное, на сервер.
- Cookie живут не вечно. Механизмы ограничения трекинга в современных браузерах режут срок жизни cookie, выставленных скриптом, — опираться только на cookie нельзя.
- Серверная привязка обязательна. При первом визите клиент отправляет клик-id на бэкенд, тот выдаёт собственный идентификатор сессии и хранит связку у себя. Дальше все события идут через этот идентификатор, а клик-id подставляется на сервере.
Как не потерять клик-id при добавлении на экран
Главная техническая ловушка PWA: при добавлении на экран приложение запускается по адресу из манифеста — по start_url. Если клик-id в этом адресе нет, приложение стартует «чистым», и связка с рекламой рвётся, хотя в хранилище она лежала.
Рабочих подходов два.
Динамический манифест. Сервер отдаёт манифест, в start_url которого уже вписан клик-id текущего пользователя. Плюс: связка живёт в адресе запуска и переживает чистку хранилища. Минус: манифест нужно генерировать на лету и следить, чтобы он не кэшировался неправильно — service worker любит отдавать старую версию.
Статический манифест плюс подстановка на клиенте. Манифест остаётся общим, клик-id дописывается к адресу при первом визите через замену состояния истории браузера и сохраняется в хранилище; при старте приложение проверяет хранилище и подставляет идентификатор в атрибуцию. Плюс: проще в поддержке. Минус: если хранилище вычистили между визитом и установкой, идентификатор потерян.
Практика арбитражных команд — комбинировать: динамический start_url как основной канал, хранилище как резерв, серверная привязка как источник истины. Как эту конструкцию собирают из готового сайта, пошагово описано в гайде как сделать PWA-приложение из сайта.
Отдельно про iOS: события установки там нет, а запуск в полноэкранном режиме — единственный доступный признак. Логику «добавил на экран» на iPhone строят на паре условий: приложение открыто не в браузере и в хранилище нет отметки о том, что первый запуск уже был. Это приблизительно, и в отчётах такие установки честнее помечать отдельной веткой, а не смешивать с Android.
Постбек из PWA в трекер: что это и как настроить
Постбек — HTTP-запрос, которым приложение или его сервер сообщает трекеру: «по такому-то клик-id случилось такое-то событие, вот его статус». В отличие от пикселя, который просто фиксирует показ или визит, постбек несёт полезную нагрузку и обычно отправляется сервер-к-серверу — так его сложнее заблокировать, и он не теряется, если пользователь закрыл приложение.
Что обычно шлют: визит, добавление на экран, первый запуск, регистрацию, депозит и продуктовые события, нужные для оптимизации закупки. Набор зависит от вертикали: в гемблинге и беттинге критичны регистрация и первое пополнение, в товарке — оформленный заказ.
Проверено: 26.10.2026. Правила сторов и возможности платформ описаны на дату проверки; точные формулировки смотрите в официальной справке Apple, Google и MDN. Нашли неточность — напишите на redakciya@pwa-arbitrazh.com.