Споры о серверном и клиентском трекинге годами остаются одной из тех тем, где правильный ответ — «всё зависит от ситуации», хотя такой ответ никого не устраивает. Ниже — понятное объяснение без рекламных обещаний поставщиков и честная таблица, которую можно отправить техническому директору.
Что представляет собой каждый подход
Клиентский трекинг работает в браузере посетителя. Небольшой скрипт запускается, считывает произошедшие события — просмотр страницы, клик, глубину прокрутки — и отправляет эту информацию напрямую в точку сбора данных. Серверный трекинг работает в вашей инфраструктуре. Браузер отправляет минимум данных на ваш сервер или в лёгкий пограничный обработчик, а тот решает, что и куда передавать дальше.
Ни один из подходов сам по себе не является более «конфиденциальным» или «точным». В зависимости от настроек каждый из них может быть и тем и другим. Разница заключается в том, где находится точка контроля и какая доля реальных данных до вас доходит.
Честная таблица компромиссов
| Параметр | Клиентский | Серверный |
|---|---|---|
| Трудоёмкость настройки | Низкая — достаточно вставить фрагмент кода | Выше — нужен сервис и небольшой слой маршрутизации |
| Устойчивость к блокировщикам рекламы | Низкая — скрипт блокируется в источнике | Высокая — собственная точка приёма данных на вашем домене |
| Потеря данных в современных браузерах | Существенная (Safari ITP, блокировщики, режимы защиты от отслеживания) | Небольшая — поверхность контролируете вы |
| Задержка при первой отрисовке | Добавляет один сторонний запрос | Ничего не добавляет, если сборщик кэшируется на пограничных узлах |
| Контроль над тем, что покидает вашу инфраструктуру | Определяется скриптом поставщика | Определяется вами |
| Удобство отладки | Вкладка Network в DevTools | Серверные журналы — нужен другой навык, зато данные полнее |
| Стоимость при масштабировании | Низкая, пока поставщик не переведёт вас на более дорогой тариф | Небольшой и прозрачный счёт за пограничные ресурсы или функции |
| Идентификация B2B-компаний | Работает, но ненадёжно | Идеальный вариант — сервер может конфиденциально сопоставить IP → компанию |
B2B-командам стоит особенно внимательно посмотреть на последнюю строку. Клиентская идентификация зависит от скрипта, который всё больше посетителей либо полностью блокируют, либо существенно ограничивают. При серверном подходе логика идентификации находится в вашей инфраструктуре, где её нельзя незаметно отключить обновлением браузера.
Где уместна идентификация компаний
Идентификация на уровне компаний естественным образом подходит для серверной обработки. Браузеру достаточно отправить очень небольшой запрос в собственную точку приёма данных на вашем домене. Она работает на пограничном узле — обычно <20 ms в Европе, — конфиденциально сопоставляет IP с компанией и не возвращает клиентской стороне никаких данных, раскрывающих результат. Пользовательский опыт не меняется. Ограничения блокировщиков обходятся. Данные остаются внутри контролируемого вами контура.
Это не уловка, а прямое следствие переноса вопроса «кто этот посетитель» с клиентской стороны в управляемый вами сервис. В действиях посетителя в браузере ничего не меняется — меняется ваша возможность получить ответ.
Чем серверный трекинг не является
Серверный трекинг — не способ обойти требование о согласии. Если обработка данных требует согласия, оно необходимо независимо от того, где выполняется код. Серверный подход меняет уровень потери данных и контроля, но не правовое основание.
Несколько слов о производительности
Часто считается, что именно «трекинг» замедляет страницу. В современных системах это устаревшее опасение. Хорошо реализованный загрузчик занимает несколько килобайт, запускается с задержкой и срабатывает после того, как страница стала интерактивной. Хорошо реализованная серверная точка отвечает за единицы миллисекунд с ближайшего пограничного узла. Ни то ни другое само по себе не ухудшит ваши Core Web Vitals. Их ухудшает диспетчер тегов с четырнадцатью сторонними скриптами, которые никто не проверял уже три года. Меньшее количество лучше контролируемых маршрутов данных почти всегда работает быстрее.
Когда клиентский трекинг всё ещё выигрывает
Клиентский подход сам по себе не ошибочен. Для аналитики с невысокими рисками, где вы уже готовы мириться с потерей данных из-за блокировщиков — например, при выборочном анализе использования продукта, отслеживании UX-событий в приложении или быстрых приблизительных тестах посадочных страниц, — его быстрее внедрить и дешевле эксплуатировать. Суть не в том, что один подход всегда лучше другого. Но если ваша работа зависит от этих данных — B2B-воронка вполне подходит в качестве примера, — серверный подход устойчивее и прозрачнее в отношении того, что именно он делает.
Правильный вопрос звучит не как «какой подход лучше?», а как «какое решение будет опираться на эти данные и какой объём потерь для него допустим?». Для вопроса «кто посещал наш сайт на этой неделе?» в идеале — никакой. Отсюда и следует архитектурное решение.
Published by
lead.box Team
More articles
Посмотрите lead.box на своём собственном трафике
Начните бесплатно — без банковской карты и без обязательного звонка. Либо забронируйте 20-минутную демонстрацию.