Серверный трекинг: сколько данных вы теряете без него

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

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

Где клиентский трекинг теряет события

При клиентском трекинге событие отправляет скрипт, который выполняется в браузере посетителя. Между моментом, когда человек нажал кнопку, и моментом, когда счётчик или рекламный пиксель успешно доложил об этом в аналитику, стоит длинная цепочка условий — и на каждом звене событие может не дойти. Причём не дойти тихо: в отчёте не появляется строчка «здесь потеряно событие», просто конверсий оказывается чуть меньше, чем реальных обращений. Именно поэтому потери почти никогда не замечают глазами. Никакой аварии — результат просто выходит чуть скромнее реального, и списать его можно на что угодно: сезон, усталость рынка, неудачный месяц.

• Блокировщики и расширения. Часть аудитории пользуется блокировщиками рекламы и трекеров, которые не дают счётчику и пикселю отработать. Клик реклама зафиксировала, а событие на сайте — нет.
• Ограничения браузеров на сторонние хранилища. Браузеры всё жёстче ограничивают сторонние cookie и время жизни клиентских идентификаторов. Событие может уйти, но потерять привязку к источнику и визиту.
• Обрыв соединения. Медленная мобильная сеть, потеря сигнала в лифте или метро — скрипт не успел достучаться до сервера аналитики, и событие исчезло вместе с закрытой вкладкой.
• Уход со страницы до отправки. Человек нажал «оплатить» и сразу переключился в приложение банка или закрыл вкладку. Событие, которое отправляется в последний момент, часто не успевает уйти.
• Мобильные приложения и вебвью. Внутри приложений и встроенных браузеров веб-счётчик работает нестабильно, а то и не запускается совсем. Часть пути клиента для клиентского трекинга просто невидима.

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

Как устроен серверный путь

Серверный трекинг меняет точку отправки. Событие сначала фиксируется на вашем сервере — там, где оно реально произошло: создалась оплата, подтвердилась заявка, сменился статус сделки. А уже ваш сервер отправляет это событие в системы аналитики и рекламные кабинеты через их API. Браузер посетителя перестаёт быть единственным свидетелем того, что конверсия случилась: главным свидетелем становится ваша собственная инфраструктура, которую не отключит блокировщик и не оборвёт слабая сеть.

Важно не путать это с «более мощным счётчиком». Серверный трекинг — это отдельный канал передачи данных, который работает параллельно клиентскому и обычно вместе с ним. Клиентская часть по-прежнему собирает поведение на сайте — прокрутки, клики, путь по страницам, — потому что эти вещи происходят именно в браузере. А серверная часть берёт на себя события, которые критичны для бизнеса и которые должны существовать независимо от того, доехал ли пиксель. Разделение труда, а не замена одного другим.

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

Главная выгода — достоверность ключевых событий

Соблазн продать серверный трекинг как «плюс сколько-то процентов конверсий» понятен, но он смещает фокус. Настоящая ценность — в достоверности ключевых событий; их количество вторично. Оплата, подтверждённая заявка, успешный платёж по счёту — это события, которые уже существуют в вашей системе как факт. Серверная передача просто доносит этот факт до аналитики без посредника в виде чужого браузера. В результате в отчёте оказываются данные, за которые не стыдно: ключевое событие соответствует реальной записи в CRM или платёжной системе.

У этой достоверности есть второй, часто более дорогой эффект — обучение автостратегий. Алгоритмы рекламных систем оптимизируются на конверсиях, которые вы им передаёте. Если до них доходит лишь случайная доля оплат, алгоритм учится на искажённой картине: он видит меньше результата, чем есть на самом деле, и хуже находит похожих покупателей. Передача настоящих ключевых событий с сервера даёт автостратегии полный и корректный сигнал — и это влияет на стоимость привлечения сильнее, чем лишние строчки в отчёте. Ниже — что конкретно меняется по ключевым событиям при переходе от клиентского пути к серверному.

Границы и честность: чего серверный трекинг не делает

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

Он не обходит отказ пользователя

Иногда серверный трекинг подают как способ «собирать данные тех, кто отказался». Никакая это не оптимизация — это нарушение. Серверная передача меняет техническую точку отправки события, но не меняет правового основания на обработку данных. Если посетитель не дал согласия, отсутствие события — это не потеря, которую надо «вернуть», а корректное поведение системы. Обходить отказ через сервер — прямой путь к претензиям, а не к росту конверсий, и любой подрядчик, предлагающий это как фичу, продаёт вам риск под видом выгоды.

Он не чинит сломанную разметку

Если UTM-метки проставлены как попало, источник в CRM необязателен, а события задваиваются — серверный трекинг аккуратно перенесёт весь этот беспорядок на сервер и продолжит отправлять недостоверные данные, просто надёжнее. От смены точки отправки кривые данные не выпрямляются: сервер доставит их точнее, но такими же кривыми. Порядок в разметке и определениях наводят до внедрения — само внедрение его не наведёт.

Он стоит внедрения и поддержки

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

Сколько теряете именно вы — не знает никто, кроме вас

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

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

Как измерить свои потери

Идея простая: возьмите событие, которое одновременно фиксируется и в веб-аналитике, и в системе, где оно существует как факт — в CRM или в платёжном сервисе. Разница между ними и есть ваша потеря на клиентском трекинге. Вот он, честный бизнес-кейс: «за месяц мы недосчитались вот стольких оплат, и вот во сколько это обошлось». Конкретная сумма вместо ссылки на рынок.

1. 01
   Задайте команде одно ключевое событие с денежным смыслом

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

2. 02
   Договоритесь о периоде, за который считаете

   Один день слишком шумный: случайные всплески исказят картину. Просите брать месяц или хотя бы несколько недель — тогда дневные колебания усреднятся и останется устойчивая разница.

3. 03
   Спросите у аналитика число событий в веб-аналитике

   Сколько оплат или подтверждённых заявок зафиксировала аналитика за период через клиентский трекинг. Это число «сверху» — то, что видит реклама и на чём учатся автостратегии.

4. 04
   Потребуйте тот же факт из системы-источника

   Сколько реальных оплат прошло через платёжную систему или сколько подтверждённых сделок в CRM за тот же период и в том же часовом поясе. Это число «снизу» — факт, который не подделаешь пикселем.

5. 05
   Проверьте, что команда сравнивает одно и то же

   Прежде чем радоваться или пугаться разрыва, убедитесь: одинаковый ли период, один ли часовой пояс, не считает ли аналитика лишнего из-за дублей. Половина «потерь» на дневном срезе объясняется сдвигом границы суток, а вовсе не блокировщиками.

6. 06
   Добейтесь, чтобы разрыв перевели в деньги

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

Результат этой сверки может удивить в обе стороны. Иногда разрыв невелик, и тогда честный вывод — серверный трекинг вам пока не окупится, деньги лучше потратить на разметку или скорость ответа на заявку. А иногда выясняется, что аналитика видит заметно меньше оплат, чем прошло через кассу, — и вот тогда у внедрения появляется измеренное, а не выдуманное обоснование. В любом случае вы принимаете решение по своим цифрам, и это ровно та позиция, которую невозможно оспорить ссылкой на чужую статистику.

Признаки, что вам пора

Серверный трекинг оправдан не всем и не всегда. Ниже — сигналы, при которых сверка потерь, скорее всего, покажет заметный разрыв, а внедрение окупится. Чем больше пунктов про вас, тем весомее аргумент в пользу проекта.

• Большая доля мобильного трафика и заходов из приложений. Там клиентский счётчик работает наименее стабильно, и потери ключевых событий выше всего.
• Вы активно используете автостратегии. Алгоритмам нужен полный сигнал о конверсиях; недосчитанные оплаты напрямую бьют по стоимости привлечения.
• Оплата и подтверждение происходят не на сайте. Платёж в приложении банка, подтверждение в мессенджере, звонок менеджера — эти события клиентский трекинг ловит плохо или не ловит вовсе.
• Средний чек высокий, а сделок немного. Каждое потерянное событие стоит дорого, и даже небольшая доля потерь превращается в ощутимую сумму.
• Сверка с деньгами уже показала устойчивый разрыв. Аналитика стабильно видит меньше оплат, чем платёжная система, и разница не объясняется дублями или часовыми поясами.

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

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