Что такое серверный трекинг и как его настроить?

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

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

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

• Что здесь означает серверный трекинг?
• Зачем использовать серверные события? Конфиденциальность: полный контроль над отправляемыми данными Качество данных: фиксация подтвержденных действий без блокировщиков браузера Совмещение браузерных измерений с подтвержденными результатами
• Конфиденциальность: полный контроль над отправляемыми данными
• Качество данных: фиксация подтвержденных действий без блокировщиков браузера
• Совмещение браузерных измерений с подтвержденными результатами
• Что может упустить серверный трекинг?
• Как работает Plausible Events API Пример: отслеживание подтвержденной регистрации 1. Добавьте цель 2. Отправьте событие после сохранения аккаунта 3. Передайте данные посетителя корректно 4. Предотвратите дублирование отправок и защитите регистрацию 5. Проверьте результат
• Пример: отслеживание подтвержденной регистрации 1. Добавьте цель 2. Отправьте событие после сохранения аккаунта 3. Передайте данные посетителя корректно 4. Предотвратите дублирование отправок и защитите регистрацию 5. Проверьте результат
• 1. Добавьте цель
• 2. Отправьте событие после сохранения аккаунта
• 3. Передайте данные посетителя корректно
• 4. Предотвратите дублирование отправок и защитите регистрацию
• 5. Проверьте результат
• Начните с одного подтвержденного действия

Что здесь означает серверный трекинг?

Серверный (server-side) означает, что сбор данных происходит на сервере, а не в браузере посетителя. Затем сервис аналитики превращает эти данные в отчеты. Вы можете настроить сбор данных на своем веб-сервере или использовать сервис, который измеряет трафик, проходящий через его серверы.

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

• Серверные логи фиксируют запросы к страницам, изображениям и другим файлам, поступающие на веб-сервер, включая запросы от ботов. Инструменты анализа логов превращают эти записи в отчеты.
• Клиентский трекинг использует JavaScript в браузере посетителя для записи просмотров страниц и таких взаимодействий, как клики.
• Серверные события фиксируют действия, подтвержденные сервером вашего сайта (например, успешно созданный аккаунт), и отправляют их напрямую в ваш инструмент аналитики.

В нашей статье о сравнении серверных логов и JavaScript-аналитики подробно описаны эти различия. Здесь мы сосредоточимся на настройке серверных событий. Вы сами выбираете, когда действие считается совершенным, и отправляете событие в этот момент. Импортировать или анализировать серверные логи не требуется.

Зачем использовать серверные события?

Серверные события дают вам контроль над тем, что отправляет ваш сайт, и позволяют фиксировать успешные действия без зависимости от отдельного запроса аналитики из браузера.

Конфиденциальность: полный контроль над отправляемыми данными

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

При успешной регистрации вы можете отправить событие с описанием действия, сохранив email пользователя и данные аккаунта в собственной базе данных. Отправляйте только необходимые сведения, а не все содержимое формы регистрации. Также проверяйте URL-адреса страниц и настраиваемые свойства (дополнительные параметры, прикрепляемые к событиям) на наличие персональных данных.

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

Перенос сбора данных на сервер не делает его автоматически соответствующим GDPR. То, что вы собираете и как получатель это использует, по-прежнему имеет значение. Передача данных в Google Analytics или рекламный сервис через ваш сервер сама по себе не меняет того, как эти сервисы их обрабатывают. Серверные логи также могут сохранять IP-адреса и конфиденциальные URL-адреса, поэтому проверьте, что именно сохраняют ваш сайт и хостинг-провайдер.

Качество данных: фиксация подтвержденных действий без блокировщиков браузера

Блокировщик рекламы в браузере может помешать загрузке скрипта аналитики или заблокировать отправку данных. Но как только сервер вашего сайта выполнил действие, он может отправить событие напрямую в ваш инструмент аналитики. Браузерное расширение не может заблокировать этот межсерверный (server-to-server) запрос, и посетителю не нужно держать вкладку открытой для его отправки.

Вы также можете фиксировать результат ровно в момент его наступления. Отправляйте событие регистрации (Signup) после того, как ваш сайт создал аккаунт, а не считайте клик по кнопке «Создать аккаунт» или посещение страницы благодарности. Если событие отправляется один раз после создания аккаунта, то неудачная отправка формы или перезагрузка страницы подтверждения не приведут к повторному событию регистрации.

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

Совмещение браузерных измерений с подтвержденными результатами

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

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

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

Что может упустить серверный трекинг?

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

• Взаимодействия, которые не обращаются к серверу. Прокрутка статьи, клик по внешней ссылке или открытие меню могут происходить полностью в браузере. Вам нужен браузерный код для отслеживания этих действий и отправки события, если вы хотите их измерять.
• Просмотры страниц, которые не доходят до вашего сервера. Страница, загруженная из кэша браузера, или навигация внутри одностраничного приложения (single-page application) могут не создавать новый запрос к вашему серверу. Фиксация только серверных запросов упустит такие просмотры.
• Откуда изначально пришел посетитель. Регистрация на стороне сервера автоматически не сообщает первоначальный источник перехода или кампанию посетителя. Ваша настройка должна передавать эти данные или связывать событие с визитом, где они уже были записаны. То, как работает эта связь, зависит от вашего аналитического инструмента. Запись регистрации не восстанавливает просмотр целевой страницы, который никогда не фиксировался.

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

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

Как работает Events API от Plausible

Plausible по умолчанию является конфиденциальным сервисом, в том числе при использовании нашего JavaScript-сниппета в браузере. Он не использует файлы cookie или постоянные идентификаторы посетителей и не отслеживает пользователей на разных сайтах. Сбор данных на стороне сервера дает вам дополнительный контроль над тем, что вы отправляете, но он не обязателен для того, чтобы сделать Plausible конфиденциальным.

Эти принципы конфиденциальности применяются как к нашему скрипту, так и к нашему API. Наш хостинговый сервис обрабатывает и хранит данные посетителей в ЕС. Plausible использует IP-адреса посетителей и данные браузера для подсчета посетителей без сохранения этих исходных значений. В нашей политике работы с данными объясняется, как они используются.

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

Events API — это способ для сервера вашего сайта отправлять аналитические данные напрямую в Plausible. Ваш сервер отправляет запрос с описанием того, что произошло, и Plausible обрабатывает его для той же панели управления, которая используется при трекинге в браузере.

API принимает два типа событий:

• Просмотры страниц, отправляемые с названием события pageview. Отправляйте одно такое событие, когда посетитель просматривает страницу, которую вы хотите зафиксировать.
• Кастомные события, отправляемые с выбранным вами именем, например Signup (Регистрация) или Purchase (Покупка). Они фиксируют действия, которые вы определяете. Добавьте соответствующую цель кастомного события, чтобы видеть их конверсии в вашей панели управления.

Каждое событие должно содержать имя, полный URL страницы и домен, который вы добавили в Plausible. Ваш сервер также должен правильно передавать данные браузера и IP-адрес посетителя, как описано в шаге 3 ниже.

Вы можете включать дополнительную информацию:

• Источники переходов и кампании: отправляйте URL источника в параметре referrer и UTM-кампании в URL страницы.
• Кастомные свойства: используйте props для добавления таких деталей, как категория товара или тип подписки, без отправки личной информации.
• Доход: используйте revenue для отправки суммы и валюты с целью отслеживания доходов, используя настройку панели управления, описанную в нашем руководстве по трекингу доходов.

API записывает то, что вы отправляете. Он не обнаруживает автоматически просмотры страниц, регистрации или другую активность на вашем сайте. Вы сами решаете, когда ваш сервер должен отправлять каждое событие. Измерения в браузере, такие как глубина прокрутки, по-прежнему должны собираться в браузере.

Пример: отслеживание подтвержденной регистрации

Оставьте трекинг в браузере и добавьте одно событие, когда ваш сервер успешно создает аккаунт. Вам понадобятся сайт, добавленный в Plausible, и разработчик с доступом к коду сервера вашего сайта. Если вы управляете только редактором страниц, обратитесь к нашим руководствам по интеграции.

1. Добавьте цель

В настройках вашего сайта Plausible добавьте цель кастомного события с именем Signup, строго соблюдая регистр букв. Ознакомьтесь с инструкциями по настройке целей.

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

2. Отправьте событие после сохранения аккаунта

При обработке отправки формы регистрации отправьте этот запрос после того, как аккаунт будет успешно сохранен:

Здесь показан формат запроса, а не полная интеграция регистрации. Добавьте эквивалентный запрос в код вашего сервера. Замените example.com как в полном URL страницы, так и в домене сайта. Установите две переменные на основе реальных данных браузера и IP посетителя, как описано далее.

3. Передайте данные посетителя корректно

Скопируйте исходный заголовок User-Agent посетителя, который описывает его браузер и устройство, и установите для X-Forwarded-For его IP-адрес. Использование данных вашего сервера может исказить подсчет посетителей или привести к отклонению события фильтрами ботов.

Если ваш сайт использует CDN или прокси-сервер, следуйте инструкциям вашего хостинг-провайдера по определению реального IP посетителя. Доверяйте заголовокам пересылки только от настроенных вами сервисов. Если X-Forwarded-For содержит список, IP-адрес посетителя должен быть первым допустимым адресом.

Cloudflare: если присутствует заголовок CF-Connecting-IP, Plausible использует его вместо X-Forwarded-For. Установите в нем также IP посетителя, а не исходящий адрес прокси-сервера. Ознакомьтесь с рекомендациями по заголовкам.

Чтобы присоединиться к существующему визиту, событие должно содержать собственный IP-адрес и User-Agent посетителя, использовать то же имя хоста сайта и поступить в течение 30 минут с момента его последнего события. В этом случае сохраняется информация об источнике перехода и кампании этого визита.

Если совпадений нет, начинается новый визит (и потенциально новый посетитель). Его источник берется из дополнительного поля referrer или UTM-параметров в url; если ничего из этого нет, он отображается как Direct / None (Прямой заход / Неизвестно). В примере выше не отправляется ни то, ни другое. Для сбора данных исключительно на сервере укажите эти детали при первой фиксации визита. Последующие сопоставляемые события сохраняют исходный источник. Ознакомьтесь с правилами атрибуции.

4. Предотвратите дублирование отправок и защитите процесс регистрации

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

Установите лимит времени для запроса аналитики и обрабатывайте сбои отдельно. Проблема с подключением к аналитике не должна препятствовать созданию аккаунта.

5. Проверьте результат

• Выполните тестовую регистрацию на собственном сайте, а затем убедитесь, что событие Signup появилось в конверсиях целей в Plausible. Также проверьте общее количество конверсий, так как дубликаты событий от одного посетителя могут не увеличивать количество уникальных конверсий.
• Отправьте форму с ошибкой: она не должна отправлять событие регистрации. Убедитесь, что просмотры страниц и показатели вовлеченности в браузере по-прежнему поступают.
• Начните новый визит по ссылке из известного источника перехода или кампании, затем зарегистрируйтесь и проверьте источник конверсии.
• Изучите заголовки ответа. Сам по себе статус 202 Accepted не гарантирует запись; заголовок x-plausible-dropped: 1 означает, что событие было отброшено.

Чтобы проверить, какой IP видит Plausible, отправьте отдельный тестовый запрос с заголовком X-Debug-Request: true с того же сервера или воркера, что и ваши реальные события. Он вернет HTTP 200 с IP-адресом. Убедитесь, что этот адрес и исходящий User-Agent принадлежат посетителю. Отладочные запросы не записываются, поэтому удалите отладочный заголовок для реальных событий. Ознакомьтесь с инструкциями по отладке.

Начните с одного подтвержденного действия

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

Как только это заработает, используйте тот же подход для других действий, которые подтверждает сервер вашего сайта. В справочнике по Events API описаны просмотры страниц, пользовательские свойства и доход, если вам потребуется расширить настройку.