Аналитика визитов с устройств Apple: как снизить потери данных

Если визиты одного пользователя не связываются в единую историю, могут возникнуть сложности:

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

Как обнаружить проблему

Оценить, насколько корректно связываются визиты, помогают стандартные отчёты Метрики.

1. Откройте отчёт, например «Источники, сводка». Удалите все группировки и добавьте метрику «Доля новых посетителей».
2. Создайте сегмент с условием «Визиты» → «Технологии» → «Операционная система = iOS».
3. Включите режим сравнения и для сегмента В задайте условие «Визиты» → «Технологии» → «Операционная система = Google Android».
4. Сравните долю новых посетителей на iOS и Android. Если на iOS она заметно выше, это может быть одним из признаков того, что часть вернувшихся пользователей определяется как новая.

Почему происходит разрыв истории пользователей

Причины потери данных часто накладываются друг на друга. Это могут быть:

• Ограничения ITP в Safari. Технология Intelligent Tracking Prevention (ITP) удаляет cookie, установленные через JavaScript, если пользователь не заходил на сайт семь дней. Счётчик Метрики по умолчанию использует JavaScript: идентификаторы _ym_uid и _ym_d.
• Потеря referrer. На SPA-сайтах (Single Page Application) или при переходах между доменом и поддоменом система не всегда автоматически распознаёт новый просмотр как продолжение предыдущего визита. Это повлияет на определение источника и последовательности просмотров.
• Ограничения для серверных cookie. Начиная с Safari 16.4 технология ITP ограничивает срок хранения до семи дней даже для cookie, установленных сервером, если он технически определяется как сторонний. Например, из-за особенностей CDN или размещения статики на отдельном поддомене.

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

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

Проверьте работу счётчика

Иногда признаки разрыва истории на iOS связаны не с ограничениями браузера, а с ошибками при установке или настройке Метрики.

Убедитесь, что:

• Код счётчика размещён в <head> или в начале <body> и его загрузку не задерживают сторонние скрипты, из-за которых может потеряться источник первого перехода
• Для SPA-сайтов в коде инициализации счётчика прописан параметр defer: true, а внутренние переходы фиксируются с помощью метода hit
• На всех связанных доменах и поддоменах, между которыми пользователь переходит во время визита, установлен один и тот же счётчик Метрики: используется одинаковый номер счётчика, а в коде внесены одинаковые изменения — параметр defer: true и вызовы hit

Настройте cookie на стороне сервера

Это ключевой этап. Чтобы обойти ограничения браузера, сервер должен самостоятельно переустанавливать файлы _ym_uid, _ym_d и _ym_ucs на длительный срок при каждом ответе. Ограничения Safari не распространяются на HTTP-заголовки ответа сервера Set-Cookie.

Конкретная реализация зависит от инфраструктуры сайта. При настройке нужно учитывать HTTPS, структуру доменов и поддоменов, особенности CDN и уже действующие правила обработки заголовков.

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

Учитывайте передачу referrer

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

```js
ym(номер_счётчика, ’hit', ’https://cabinet.example.ru/', {
  referer: window.location.href
});
```

Второй аргумент — адрес целевой страницы, а referer — адрес страницы, с которой перешёл пользователь.

Так Метрика получит данные о том, что просмотр — это продолжение текущего визита.

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

```js
ym(номер_счётчика, «hit», «https://cabinet.example.ru/', {
  referer: window.location.href,
  params: {
    landing_page: window.location.href
  }
});
```

Здесь params — это стандартный способ Метрики передать вместе с хитом любые дополнительные данные о визите или событии. А landing_page — сохранённый адрес страницы, с которой начался нужный пользовательский путь.

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

Подробнее формат передачи таких параметров, ограничения и дополнительные примеры описаны в Справке.

Учитывайте отказы и глубину просмотра

Если происходит повторный искусственный вызов hit с указанным referrer, Метрика определяет его как дополнительный просмотр страницы. В результате такой визит перестаёт считаться отказом, а показатель «Глубина просмотра» увеличивается.

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

Как проверить результаты

После настройки сервера не оценивайте изменения в отчётах сразу. ITP в Safari по умолчанию удаляет старые скриптовые cookie после семи дней неактивности пользователя, поэтому для оценки результата потребуется больше времени.

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

После этого сравните показатели до и после настройки в сегменте Safari/iOS:

1. Структура источников трафика. Откройте отчёт «Источники, сводка» и установите фильтр по iOS. Посмотрите, как распределяются визиты между каналами. Со временем структура трафика в относительных значениях может приблизиться к данным на Android. Показатели не должны совпадать полностью, но данные Android можно использовать как ориентир.
2. Доля новых посетителей. В том же отчёте проверьте метрику «Доля новых посетителей». Если система реже теряет связь с уже известными пользователями, доля новых посетителей должна снизиться, а вернувшихся — вырасти.
3. История посетителя. Если у вас настроена передача ClientID или сквозная аналитика, например интеграция с CRM, проверьте историю касаний пользователей перед покупкой. После настройки в ней должно быть меньше разрывов между визитами одного человека.
4. Показатель роботности. Добавьте в отчёт метрику «Роботность». Из-за разрыва cookie реальные пользователи Apple могут выглядеть для системы как новые посетители без истории. После объединения связанных визитов доля роботности в сегменте iOS должна снизиться.

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

Разделение задач поможет внедрить изменения без ошибок и корректно оценить их влияние на статистику.

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

• Разместить код Метрики в верхней части HTML-документа и отключить кастомные скрипты отложенной загрузки
• Для SPA-сайта включить параметр defer: true при инициализации счётчика и настроить вызовы hit при смене страницы или экрана и адреса в URL
• Настроить серверное продление cookie _ym_uid, _ym_d и _ym_ucs через HTTP-заголовок ответа Set-Cookie
• Настроить явную передачу referer в вызовах hit при первом переходе на сайт из внешнего источника и при переключении между доменом и поддоменами
• Протестировать интерфейс с параметром _ym_debug=2 и убедиться, что при кликах хиты не дублируются

Для маркетолога и аналитика:

• До внедрения изменений зафиксировать базовые показатели в сегменте Safari и iOS: долю прямых заходов, процент новых посетителей и показатель роботности
• Сразу после внедрения проверить показатель отказов и глубину просмотра, чтобы убедиться, что хиты не дублируются
• Через две-три недели после обновления сервера сравнить показатели до и после изменений в сегменте Safari и iOS
• Проверить длину цепочек визитов пользователей с помощью отчётов сквозной аналитики или ClientID
• Если сайт собран на конструкторе, настроить интеграцию с передачей User ID и офлайн-конверсий из CRM
• Добавить UTM-метки для всех кампаний и рассылок, чтобы дополнительно сохранять данные об источнике перехода

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

Ограничения Safari и iOS могут мешать связывать повторные визиты одного пользователя и из-за этого влиять на аналитику, атрибуцию и данные для рекламных алгоритмов.

Снизить эти искажения помогают корректная настройка счётчика, продление срока действия cookie, корректная передача referrer и дополнительная идентификация пользователей.

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

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