Протокол передачи данных Measurement Protocol – это базовый инструмент для разработчиков. Он активен на любом сайте, где стоит код счетчика Google Analytics.
С помощью протокола вы отправляете информацию о продажах, просмотрах страниц и других событиях на сервер Google Аналитики. Это можно делать практически из любого источника или устройства, подключенного к интернету.
В этой статье вы узнаете, как работает Measurement Protocol, как его применять и что при этом учитывать.
Команда Yagla ведет отличный телеграм канал, где публикует мнения экспертов и авторские лонгриды о бизнесе и маркетинге, многие из которых не попадают на этот сайт. Обязательно подпишитесь по ссылке https://t.me/yagla
Для чего нужен Measurement Protocol
Протокол помогает решать следующие задачи:
Отслеживать в разных средах (устройствах, источников), как пользователи взаимодействуют с компанией.
Допустим, в отделении банка с вами работает специалист и по окончании вы оцениваете качество обслуживания. Зеленая кнопка – отлично, желтая – нормально, красная – плохо. В тот самый момент, когда вы нажмете одну из них, данные поступают в Google Аналитику.
Связывать онлайн- и офлайн-действия аудитории, чтобы проследить весь путь пользователя к конверсии (звонка / заявки / заказа).
Один и тот же пользователь в ходе сделки может совершать действия на сайте и в офлайне: оформляет заказ, а оплачивает безналичным расчетом, или отдает деньги курьеру при доставке.
Дело в том, что мы не всегда получаем оплату сразу же по факту. Поэтому если передавать данные о покупке, когда платеж еще не состоялся, есть риск, что статистика будет некорректной. На этапе, когда заказ оформлен, не факт, что пользователь дойдет до оплаты – он может и отменить заказ.
Другой пример – вы предлагаете в офлайне покупателю оформить скидочную карту и просите его оставить данные – телефон, пол, возраст и т.д. Он активирует карту на сайте в личном кабинете. Впоследствии когда этот же покупатель приходит снова, вы распознаете его по данным в анкете.
Отправлять данные с прокси-сервера, если необходимо.
Некоторые среды не могут отправлять данные сразу в Google Аналитику. Например, устаревшие мобильные устройства, на которых нельзя запускать JavaScript, или корпоративный интранет. Брандмауэр блокирует такие запросы.
В таких случаях можно настроить промежуточное звено – прокси-сервер, чтобы отправлять сперва на него. Затем уже он передает данные в Google Analytics с помощью Measurement Protocol.
Чтобы получать данные об IP-адресе и агенте пользователя с клиентского устройства, а не прокси-сервера, укажите оба эти значения в протоколе. Они будут использоваться вместо тех, которые Google обычно получает из заголовков запроса.
Необработанные статистические данные о пользовательских взаимодействиях – событиях и обращениях.
Откуда можно их передавать?
С любых устройств, у которых есть доступ к интернету – помимо сайта и приложений это могут быть телевизоры, игровые консоли и т.д. В отличие от классического отслеживания, для которого обязательно, чтобы устройства выполняли JavaScript.
Также с любых источников – например, CRM-системы, Google Таблиц, базы данных, платежного терминала и других. Условие то же – подключение к глобальной сети.
В каком виде эти данные передаются?
В виде HTTP-запросов. Можно использовать для этого POST-запросы, чтобы отправлять данные, и GET-запросы, чтобы их получать данные. Технически оба вида работают одинаково.
Куда они поступают?
На серверы Google Аналитики. У протокола единая точка входа: www.google-analytics.com/collect.
Когда происходит передача данных?
Каждый раз, когда кто-либо просматривает страницу или совершает событие, запрос поступает в Google Analytics.
Как он выглядит и из чего состоит – разберем далее.
4) В строке поиска наберите «collect» и обновите страницу:
5) Выберите запрос, например:
Структура запроса
Как правило, запрос включает 3 строки:
1) Пользовательский агент (user-agent) – это то, что браузер пользователя отправляет в Google Аналитику. Выглядит примерно так:
Если вы отправляете запросы вручную, эта строка необязательная.
2) Строка отправки (transport) включает адрес Google Analytics и конечную точку URL (/collect или /batch, если в одном запросе несколько обращений). То есть куда именно вы отправляете запрос:
3) Набор данных с параметрами (payload data) – это параметры, которые вы передаете в запросе. Они представлены в одной строке в виде пар «название = значение», которые разделяются символом «&». Вместо пробелов – нижнее подчеркивание.
Measurement Protocol поддерживает следующие типы данных в значениях параметров:
Числа (целые или десятичные);
Текст. При этом в необработанном тексте удаляются начальные и конечные пробелы, а двойные, тройные и более символы разметки (включая пробелы, табуляцию, разрывы строки и т. д.) преобразуются в одинарные;
true / false (1/0);
Валюта (десятичный формат до 6 знаков). После отправки удаляется текст до первой цифры, дефиса (-) или десятичной точки. Таким образом, $-55.00 превращается в -55.00.
Все значения нужно кодировать в UTF-8 и URL. Если какие-либо символы закодированы неправильно, Google заменяет их подстановочным символом Unicode xFFFD.
Отличие запросов POST и GET
В POST-запросе следующий порядок представления данных:
POST https://www.google-analytics.com/collect (строка отправки)
payload_data (набор данных с параметрами)
Пояснения:
user_agent_string – используется при расчете следующих параметров: браузер, платформа и мобильные возможности. Если значение не задано, эти параметры не будут вычислены;
payload_data – тело запроса. Может включать только одну кодированную строку длиной не более 8 192 Б;
IP-адрес – неявно передается в HTTP-запросе и используется для вычисления всех параметров географического местоположения и сети в Google Analytics.
GET-запрос выглядит так:
GET /collect?payload_data HTTP/1.1 (конечная точка URL?набор данных с параметрами)
Host: https://www.google-analytics.com (адрес Google Аналитики)
В этом случае максимальная длина закодированного URL – 8 000 Б.
В некоторых средах (например, браузерах) HTTP-запросы GET могут кешироваться. В таком случае последующие запросы могут не отправляться в Google Analytics, а извлекаться из кеша.
Чтобы это предотвратить и обеспечить уникальность всех запросов, используйте очистку кеша. В Measurement Protocol для этого есть специальный параметр z, который принимает случайно выбранное число. Лучше добавлять его последним:
Google рекомендует использовать метод POST, поскольку так можно передавать больше данных. В средах, где POST не применяется, можно отправлять HTTP-запросы с помощью метода GET в ту же конечную точку.
Если запрос сформирован правильно, возвращается 2XX код статуса. Если данные неправильно сформатированы, неверные или Google Analytics не удалось их обработать – код ошибки не возвращается. Прежде чем отправлять повторный запрос, исправьте возможные ошибки в HTTP-запросе.
Далее рассмотрим сами параметры.
Обязательные параметры запроса
Строка набора данных с параметрами должна включать следующие 4 элемента:
v – версия протокола, на данный момент первая, поэтому v = 1;
tid – идентификатор отслеживания, или идентификатор вашего ресурса в Google Аналитике. С ним связываются все собираемые данные;
uid или cid. Оба параметра по отдельности необязательные, но один из них нужно указать.
Идентификатор пользователя (uid) – идентификатор, который пользователю присваивает владелец сайта или пользователь библиотеки отслеживания. Он должен быть анонимным, то есть не связанным с личной информацией, а его значение не должно сохраняться с помощью cookie или других средств хранения данных в Google Аналитике.
Уникальный идентификатор клиента (cid) берется из файла cookie в браузере сайта и генерируется случайным образом для каждого случая установки мобильного приложения. По этому значению выполняется анонимная идентификация пользователя, устройства или браузера.
t – тип обращения (взаимодействия). Например, pageview (просмотр страницы), event (событие) и другие.
То есть при каждой отправке данных указывайте следующие параметры:
Дополнительно для каждого типа обращения есть собственный набор обязательных и необязательных параметров. Информацию по ним ищите в справке по параметрам.
Например, t = event (событие). Согласно справке, к нему нужно добавить обязательные параметры события:
ec (event category) – категория события;
ea (event action) – действие события.
Если категория события – регистрация (ec = registration), а действие – заполнение формы (ea = form), строка набора параметров будет выглядеть примерно так:
А вот как формируется строка для обращения «Просмотр главной страницы» (тип – pageview):
dp – это дополнительный параметр для обращения типа pageview, обозначающий путь, в данном случае – к главной странице. Символ косой черты (/) обозначается как %2F. В запросе всё вместе выглядит как сочетание «dp=%2F».
Как отправлять несколько обращений в одном запросе
Используйте конечную точку /batch вместо /collect и укажите каждый фрагмент данных в отдельной строке.
Например, вы хотите отслеживать пользователя 5555, посетившего страницы «Главная», «О компании» и «Контакты». Чтобы передать информацию о просмотре сразу трех страниц, отправьте такой запрос:
При этом указывайте в одном запросе не больше 20 обращений. Их общий объем не должен превышать 16 КБ. Ограничение для одного фрагмента данных – 8КБ.
Обращение по отслеживанию посещений страниц при отправке в Google Аналитику со всеми строками будет выглядеть так:
1) Убедитесь, что у вас достаточно прав для работы, загрузки и использования данных в аккаунте Google Аналитики;
2) Сообщите конечным пользователям о том, какие данные вы собираете и связываете ли их с другими доступными вам данными, и получите их согласие. Или дайте возможность отключить функции Google Analytics;
3) Не загружайте данные, которые позволяют идентифицировать личность пользователя (имя, номер социального страхования, адрес электронной почты и т. п.) или отдельное устройство (например, уникальный идентификатор мобильного телефона, если его нельзя сбросить) даже в хешированной форме.
Не нарушайте эти правила, иначе могут закрыть ваш аккаунт Google Аналитики, и вы потеряете все данные из него.
Высоких вам конверсий!
Хотите тоже написать статью для читателей Yagla? Если вам есть что рассказать про маркетинг, аналитику, бизнес, управление, карьеру для новичков, маркетологов и предпринимателей. Тогда заведите себе блог на Yagla прямо сейчас и пишите статьи. Это бесплатно и просто
Оставляя свои контактные данные, вы принимаете условия Пользовательского соглашения и даете своё согласие на обработку персональных данных, в соответствии с Федеральным законом от 27.07.2006 года №152-ФЗ, на условиях и для целей, определенных Политикой конфиденциальности.
Генеральный партнер: Zitron Services LLP OC434997, 85 Great Portland Street, 1st Floor, London W1W 7LT, United Kingdom
Одно из источников естественных ссылок это справочники и бизнес каталоги, кому интересно размешенные вот вам ссылка https://ratingzona.ru/registratsiya-sajta-v-spravochnikah-org/
Отзывы на Яндекс картах - полезная функция, которая позволяет поднять авторитет и привлечь дополнительных клиентов, но это так же и угроза. Достаточно попасть в поле зрения недобросовестным конкурентам и им не составит труда заспамить купленными отзывами вашу страничку. Хорошо хоть Яндекс на такие вещи старается более менее реагировать. А есть отзовики, которым на это плевать.
Если отзыв некорректный или ложный, Яндекс дает возможность оспорить его, но процесс не всегда быстрый, и важно знать все тонкости модерации. Убедилась, что лучше заранее изучить правила удаления, чтобы минимизировать время на переписку с поддержкой.
Удалить реально сложно, да и отзывы даже правдивые имеют все шансы не пройти модерацию, она у яндекса сложная. Я всегда за то чтобы договариваться с человеком, который оставил негатив, в 90% все можно исправить.
Один недовольный клиент решил оставить на нас жалобу, мол, мы испортили его телефон при ремонте, хотя он даже не обращался к нам за услугами. Пришлось обратиться в службу поддержки, чтобы опровергнуть эту клевету. К счастью, нам удалось доказать свою правоту, и отзыв удалили.
Недавно прочитал статью «Как удалить отзыв на Яндекс Картах» и считаю её очень полезной. Автор подробно описал все шаги, которые необходимо выполнить для удаления отзыва, начиная с поиска нужного отзыва в профиле до подачи заявки на удаление через поддержку. Особенно порадовала простота инструкций, всё понятно даже для тех, кто не особо знаком с интерфейсом Яндекса. В статье упоминаются важные моменты, такие как возможные причины отказа в удалении, что позволяет избежать ошибок. Рекомендую эту статью тем, кто сталкивается с необходимостью удалить некорректный или ошибочный отзыв.
Даже те, кто заявляют о своем недоверии к отзывам, все равно их просматривают при поиске той или иной компании, исполнителя услуг. Негативные отзывы могут испортить репутацию для бизнеса. Важно, что некорректные, оскорбительные и недостоверные без подтверждений, отзывы с негативом можно удалить. Когда же критика обоснована, то стоит эти ситуации проработать и давать всегда обратную связь.
В нашем автосервисе один "клиент" оставил отзыв, что мы якобы поцарапали ему машину, хотя он даже не был у нас на обслуживании. Пришлось обращаться в поддержку, чтобы удалить этот бред. К счастью, удалось доказать, что отзыв не соответствует действительности и его убрали. Важно понимать, что отзывы на картах влияют на выбор клиентов, особенно в сфере услуг. Поэтому следить за своей репутацией и бороться с необоснованной критикой – это необходимость. Думаю, что алгоритмы Яндекса постепенно учатся распознавать фейковые отзывы, но пока что, к сожалению, такие случаи встречаются.
"У Rutube более адекватная проверка контента" В каком месте она адекватная? У платформы нет четких правил, какие-то абстрактные понятия, по которым их модерасты могут делать что угодно, а ты вообще никто.
В QuizBot есть один существенный недостаток. Если делаешь тест викторину, например, для учащихся, они сначала заходят с левого аккаунта, делают скины всех правильных ответов и затем с основного акканута отвечают быстро и правильно. Как решить эту проблему я до сих пор не придумала.