Веб-аналитика для мини-приложений в мессенджерах

Почему мессенджеры не предоставляют данные внутри мини-приложения

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

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

Какие есть технические особенности

При классической навигации по сайту переход между страницами сопровождается загрузкой нового документа. Счётчик аналитики автоматически фиксирует такой переход как новый просмотр.

Мини-приложения чаще всего работают как одностраничные приложения — SPA, или Single Page Application. В них переходы между экранами происходят без полной перезагрузки страницы: все внутренние экраны представляют собой разные состояния одного загруженного документа.

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

Как подключить аналитику

1. Установите счётчик с отложенной загрузкой

Счётчик Яндекс Метрики устанавливается в HTML-код мини-приложения по тем же правилам, что и на обычный сайт.

Только при инициализации используйте ещё и параметр defer: true. Он отключает автоматическую отправку первого просмотра страницы. Первый хит можно отправить вручную после того, как приложение получит данные об источнике перехода.

2. Настройте искусственные хиты и передачу referrer

Поскольку привычных переходов между страницами в мини-приложении нет, просмотры отдельных экранов нужно передавать в Метрику вручную с помощью искусственных хитов.

Вместе с разработчиком определите список ключевых экранов мини-приложения, например «Каталог», «Карточка товара», «Корзина». При переходе на каждый из них код должен вызывать метод hit и передавать виртуальный адрес страницы. Фактически таких страниц не существует, но Метрика будет учитывать их как отдельные просмотры.

При каждом вызове также важно передавать источник, с которого пользователь перешёл на текущий экран. Это позволяет связать экраны между собой и сохранить последовательность переходов.

Синтаксис метода для одностраничных приложений выглядит так:

```js
ym(номер_счётчика, «hit», url, [options]);
```

В объекте options можно передавать:

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

Пример вызова:

```js
ym(номер_счётчика, «hit», «app://cart», {
    referer: «app://catalog»,  // Экран, откуда перешёл пользователь
    title: «Корзина товаров»   // Заголовок экрана
});
```

Логика передачи referer зависит от этапа.

• При первом открытии приложения: в referer передаётся источник перехода, полученный из параметров диплинка
• При навигации внутри приложения: в referer подставляется адрес предыдущего экрана, например app://catalog при переходе на app://cart

Другие технические нюансы при работе с одностраничными приложениями описаны в Справке.

3. Передайте данные об источнике перехода

Чтобы Метрика определила, из какого источника пришёл пользователь, его нужно зафиксировать при запуске мини-приложения.

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

Как это работает:

1. Маркетолог формирует ссылку для рекламного поста и добавляет к адресу метку источника, например ?utm_source=promo_channel.
2. Пользователь переходит по рекламе, и мессенджер открывает мини-приложение.
3. При запуске скрипт считывает параметр utm_source=promo_channel и получает данные об источнике перехода.
4. Эти данные передаются в Метрику через параметр referer при отправке первого искусственного хита.

Так внешний рекламный переход связывается с дальнейшими действиями пользователя внутри мини-приложения.

4. Настройте цели с передачей параметров событий

Значимые действия пользователей фиксируйте методом reachGoal.

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

```js
ym(номер_счётчика, «reachGoal», «ORDER», { Screen: «app://catalog» });
```

Здесь ORDER — идентификатор общей цели, а Screen — название параметра, в котором передаётся текущий экран.

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

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

Что важно учитывать при сборе данных

Не отправляйте лишние хиты. Каждый искусственный вызов hit Метрика учитывает как просмотр страницы. Если на один переход приходится несколько хитов, показатели могут исказиться: глубина просмотра окажется завышенной, а показатель отказов — заниженным. Именно поэтому придерживайтесь правила: один переход на новый экран — один хит.

Проверяйте аналитику на разных ОС. Среда WebView внутри мессенджера накладывает собственные ограничения на работу с cookie. Особенно важно учитывать особенности iOS. О том, как настроить сервер и сохранить необходимые данные на устройствах Apple, читайте в статье.

Кроме того, рекомендуем протестировать работу аналитики отдельно на iOS и Android.

Чек-листы для проверки

Если вы разрабатываете мини-приложение или дорабатываете уже готовое, включите эти пункты в техническое задание.

Для разработчика

• Установить код Метрики с параметром defer: true
• Согласовать список ключевых экранов и настроить отправку метода hit с виртуальными адресами
• Настроить считывание меток из параметров диплинка
• Передавать эти метки в referer при отправке первого искусственного хита
• Настроить отправку целей через reachGoal и передавать текущий экран или источник в параметрах события, чтобы не создавать отдельные цели для каждого варианта в интерфейсе
• Подключить электронную коммерцию для сценариев продаж
• Проверить работу с помощью _ym_debug=2 на iOS и Android и убедиться, что просмотры не дублируются

Для маркетолога

• Разметить все посты и кнопки запуска мини-приложения уникальными ссылками
• Составить для разработчика карту целевых действий: определить, что считать конверсией и какие шаги входят в воронку продаж
• После запуска проверить отчёт «Параметры событий», чтобы проанализировать конверсию по отдельным экранам мини-приложения
• После релиза проверить, корректно ли выручка атрибутируется к постам

Коротко о главном

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

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

Дополнительные материалы