Нашумевшая тема, которая очень умно звучит и обещающая много возможностей - серверное отслеживание в Google Tag Manager или server side tracking. Само слово “сервер” уже многообещающее. Разберемся, действительно ли добавляется больше возможностей при установке серверного отслеживания в Google Tag Manager.
Мы эту тему изучали только по одной причине - consent mode. Есть ли серверное отслеживание решением для запретов в передаче данных cookies, из-за чего теряется множество данных для Google Analytics и Google Ads. Разберемся, так ли это.
Серверное отслеживание - прием и обработка данных аналитики сайта на уровне облачного сервера, передача их в места назначения в обход блокировщиков рекламы.
Данные при серверном отслеживании поступают из веб-контейнера в серверный контейнер Google Tag Manager, и далее распределяются по необходимым каналам.
Это выглядит примерно так:
Максимально простое объяснение без просмотра каких-либо видео и сотен страниц технической документации.
Сервер - это как промежуточный контейнер между вебом и сервисом получения информации, на котором Вы можете контролировать и управлять передачей данных.
Преимущества серверного отслеживания:
👉 Повышение информативности данных - самое главное и самое основное преимущество серверного отслеживания!
Серверное отслеживание помогает учесть данные, неучтенные из-за различной специфики настройки браузеров пользователей - блокировщики рекламы, отображение Java Script и т.д. На практике это плюс 10-15%, о чем знаем из настройки Facebook API Conversions.
👉 Дополнительный контроль за передачей данных (при тестировании отправки данных есть возможность проверки с серверного контейнера).
👉 Преобразование данных (работа с модификаторами, продление жизни cookies).
Недостатки серверного отслеживания:
👉 Сложность реализации. Не хватает специалистов в программной аналитике. Это не просто программисты, а программисты понимающие алгоритмы учета данных в Google Ads и Analytics.
👉 Финансовые расходы. Облачный сервер - это платная услуга. Фактически, некоторые данные аналитики станут для Вас платными, к чему не все готовы.
Запуск серверного отслеживания - с чего начать?
Если Вам кто-то скажет, что это легко и просто - это не так! Это не опция “прописать код аналитики в сайт”, а нечто сложнее. Мы постараемся объяснить, как это сделать, на максимально понятном языке.
- Регистрируете серверный контейнер в аккаунте сайта Tag Manager;
- Создаете облачный сервер через Google iCloud или любой другой сервис, указывая API key;
- В веб-контейнере Google Tag Manager, в нужных тегах размещаете серверный адрес обработки, а именно URL сервера.
Далее - вопрос Вашего творчества и бизнес процессов.
Consent mode (режимы согласия) и серверное отслеживание в Google Tag Manager
Основная проблема современной веб аналитики - это разрешение на распространение cookies, которое значительно влияет на качество учитываемых показателей, начиная от конверсий и заканчивая посещаемостью в Google Analytics.
Многие маркетологи по незнанию, с появлением серверного отслеживания возложили большие надежды на решение вопроса качества передаваемых данных именно в связи с внедрением consent mode. Но, это была ошибка, и вот почему:
☝ Серверное отслеживание берет данные из веб-контейнера Google Tag Manager, данные в котором, при настроенном режиме согласия, появляются только в случае согласия на распространение cookies пользователем.
Соответственно, если пользователь не дает разрешение на cookies, то данные в серверный контейнер не отправляются. Именно поэтому серверное отслеживание в Google Tag Manager не является решением проблемы запрета на передачу cookies для сохранения целостности статистических данных.
Вы можете вспомнить про CAPI Facebook…
Может возникнуть вопрос, почему реализация API Conversions Facebook стала решением в истории IOS 14+, а серверное отслеживание Google Tag Manager не может решить вопрос с consent mode и передачей данных?
Отвечаем, исходя из нашего опыта и экспертизы:
☝ В IOS14+ не было запрета на cookies, а только на передаваемые события.
Соответственно, имея данные из cookies о пользователе, Вы можете с помощью API Conversions Facebook отправлять данные о таких событиях, как purchase с ID события, которые впоследствии могут добавляться к данным о пользователе, если он выбрал “не передавать данные о событии”, либо дедуплицироваться на сервере Facebook, в другом случае. Это точная информация, так как мы эту тему изучили досконально.
Надеемся, что эта информация была полезной для Вас. До новых встреч.
Заказать услугу