Где именно происходит сбор
При обычной схеме событие рождается в браузере: скрипт аналитики загрузился, отследил действие, отправил запрос напрямую в систему статистики. При серверной событие уходит на ваш сервер, а он уже отправляет его дальше — от своего имени, своим кодом, по своему расписанию.
Смена места сбора меняет список того, от чего он зависит. Браузерный сбор зависит от расширений посетителя, настроек приватности, скорости соединения и от того, дождался ли человек загрузки скрипта. Серверный зависит от вашего кода, доступности вашего сервера и корректности передачи параметров между сайтом и обработчиком.
Отсюда главный тезис, который стоит принять до начала работ: отказы не исчезают, они переезжают. Раньше данные терял браузер посетителя, теперь их теряет ваша инфраструктура. Разница в том, что первое вы не контролируете, а второе — контролируете и обязаны обслуживать.
Общая карта инструментов и их устройство описаны в разборе систем веб-аналитики; здесь речь только о способе доставки событий.
Что схема действительно чинит
Список выигрышей короче, чем в презентациях подрядчиков, но он реален.
События с этапов после браузера. Заявка подтверждена менеджером, оплата прошла, клиент не отказался от заказа — эти факты живут в учётной системе, а не на сайте. Отправить их можно только с сервера, и именно здесь серверная схема даёт то, чего браузерная не даёт в принципе. Тот же механизм лежит в основе сквозной аналитики.
Устойчивость к блокировке. Запрос уходит с вашего домена или вовсе не из браузера, поэтому его сложнее отсечь фильтрами. Полной неуязвимости не бывает, но доля потерь снижается.
Контроль над содержимым события. До отправки данные можно очистить: убрать лишние параметры, нормализовать значения UTM-меток, отфильтровать заказы-дубли и внутренний трафик. В браузерной схеме это делается настройками чужой системы, в серверной — вашим кодом.
Меньше сторонних скриптов на странице. Один запрос вместо нескольких пикселей заметно влияет на скорость загрузки, особенно на слабых устройствах.
Клиентский и серверный сбор рядом
| Параметр | Клиентский сбор | Серверный сбор |
|---|---|---|
| Точка отказа | Браузер посетителя | Ваш сервер и код обработки |
| Кто чинит поломку | Никто, потери принимаются как данность | Ваша команда, в свои сроки |
| Скорость настройки | Часы, интерфейсом | Недели, с участием разработчика |
| Данные после оплаты | Недоступны | Доступны из учётной системы |
| Заметность ошибки | Видна в консоли браузера сразу | Не видна, обнаруживается сверкой |
| Стоимость владения | Близка к нулю | Инфраструктура плюс регулярная проверка |
Строка про заметность ошибки — самая недооценённая. В браузерной схеме сломанную разметку видно при первом же открытии страницы с отладчиком. В серверной событие уходит молча, и о том, что месяц назад в него перестал попадать идентификатор сессии, узнают при разборе странного отчёта.
Что переносить, а что оставить в браузере
Полный перенос всего подряд — самая частая ошибка проектирования. Часть событий на сервере теряет смысл, потому что описывает поведение, которого сервер не видит.
В браузере разумно оставить всё, что связано с тем, как человек взаимодействует со страницей: прокрутка, открытие вкладок в карточке, воспроизведение видео, клики по элементам интерфейса, ошибки скриптов. Сервер об этих событиях не знает и узнать не может — ему в любом случае придётся получать их из того же браузера, только окольным путём.
На сервер переносят события, у которых есть подтверждение вне браузера: отправленная заявка, оплата, подтверждённый заказ, отказ, возврат, повторная покупка. Общий признак простой — такое событие можно восстановить из базы данных, даже если посетитель закрыл вкладку в момент отправки.
Промежуточная зона — просмотры страниц и старт сессии. Их переносят, когда важна устойчивость к блокировке, и оставляют на клиенте, когда важнее простота. Обе схемы рабочие, а вот смешение без правил приводит к тому, что один и тот же просмотр приходит дважды и все относительные показатели уезжают.
Порядок перехода
Последовательность не случайна: каждый шаг создаёт то, что проверяется на следующем.
- Зафиксировать текущие потери. До переезда посчитать расхождение между заказами в учётной системе и событиями в аналитике за месяц. Без этого числа оценить результат перехода будет нечем, и любые улучшения окажутся вопросом веры.
- Описать события до реализации. Список событий, их параметры, обязательность каждого параметра, правила именования. Документ пишется один раз и потом спасает от ситуации, когда одно и то же действие приходит под тремя именами. Основа для него — уже сформулированные цели аналитики.
- Поднять серверную схему параллельно старой. Две недели события идут обоими путями. Расхождение между потоками показывает, что реализовано неверно, — и показывает до того, как старый способ отключён.
- Прокинуть идентификатор сделки. Без него события с сайта и события из учётной системы останутся двумя несвязанными потоками. Идентификатор создаётся в момент заявки и живёт до закрытия сделки.
- Отключить старый сбор и оставить сверку. Ежемесячное сравнение с учётной системой становится постоянной процедурой, а не разовой приёмкой.
Шаг с параллельной работой пропускают чаще всего — и именно на нём обнаруживается большинство ошибок, которые иначе всплывут через квартал в виде необъяснимого провала конверсии.
После перехода число событий выросло на десятки процентов, а заказов в учётной системе столько же. Скорее всего, дубли: событие отправляется и с сайта, и с сервера, либо страница благодарности перезагружается. Проверяется сверкой по идентификаторам сделок — уникальных значений должно быть ровно столько же, сколько заказов.
Все посетители в отчёте выглядят прямыми заходами. Серверная схема потеряла источник: при отправке с сервера данные о переходе не передаются автоматически, их нужно сохранить в момент первого визита и приложить к событию. Пока это не сделано, любые выводы по каналам и атрибуции недействительны.
Отчёт совпадал с учётной системой три месяца, потом разошёлся без изменений в аналитике. Причина почти всегда снаружи: релиз сайта поменял вёрстку формы, поле переименовали, обработчик перестал получать параметр. Серверный сбор не сообщает о таких поломках — их находит только регулярная сверка.
Число уникальных посетителей стало неправдоподобно большим. Идентификатор посетителя генерируется заново при каждом запросе вместо того, чтобы храниться. В результате один человек считается десятью, а любые расчёты стоимости привлечения и когорт перестают иметь смысл.
Чего серверный сбор не делает
Не улучшает атрибуцию. Модель распределения заслуг между каналами остаётся той же. Данные приходят другим маршрутом, логика деления не меняется.
Не даёт «полные данные». Если посетитель не позволил себя идентифицировать, серверная схема получит ровно столько же, сколько браузерная. Обещание стопроцентной точности — маркетинговое, а не техническое.
Не отменяет различий между системами статистики. Две системы продолжат показывать разные числа по одному сайту, потому что у них разные определения сессии и посетителя. Причины разобраны в сравнении двух систем аналитики.
Не заменяет разметку офлайн-касаний. Звонки по-прежнему требуют отдельного механизма — за это отвечает коллтрекинг, и серверная схема лишь принимает от него готовое событие.
Не окупается на малых объёмах. Схема стоит времени разработчика и постоянного внимания. При десятках сделок в месяц эта цена выше, чем ценность добавленной точности.
Не убирает необходимость размечать сайт. Событие всё равно должно где-то родиться. Если кнопка отправки заявки не отслеживается, перенос сбора на сервер не сделает её отслеживаемой — он просто перевезёт отсутствие данных в другое место.
Отдельно стоит развеять ожидание, которое чаще всего и запускает проект. Расхождение между рекламным кабинетом и аналитикой серверный сбор не устраняет: кабинет считает по своим правилам атрибуции и своему окну учёта, аналитика — по своим. Совпадать эти числа не будут ни при какой схеме доставки событий, и попытка добиться совпадения обычно заканчивается подгонкой одного отчёта под другой.
Спорное место
Серверный сбор продают как способ вернуть контроль над данными, и формально это верно. Практически же он передаёт контроль от чужой системы, которая работает без вашего участия, к вашей команде, у которой уже есть очередь задач. Контроль без ресурса на обслуживание превращается в тихую деградацию: схема, которую никто не сверяет, ошибается свободнее, чем браузерный скрипт, потому что её ошибки не видно.
Второе сомнение — про причины перехода. Чаще всего переносить сбор начинают из-за расхождений в отчётах, надеясь, что после переезда цифры сойдутся. Они не сходятся: расхождения обычно происходят из разных определений и разных периодов, а не из способа доставки событий. Проект заканчивается работающей серверной схемой и теми же вопросами к отчётам, что были в начале.
Честная формулировка звучит так: серверный сбор оправдан, когда есть данные после браузера, которые нужно связать с рекламой, и есть кто-то, кто будет за схемой следить. При отсутствии второго условия первого недостаточно.
Частые вопросы
Серверный сбор возвращает потерянные данные?
Нужен ли серверный сбор небольшому сайту?
Чем серверный контейнер отличается от обычного?
Станет ли сайт быстрее?
Как проверить, что серверная схема ничего не потеряла?