Практика использования Measurement Protocol. Webprofiters. iMetrics 2015
•Download as PPTX, PDF•
8 likes•3,615 views
Презентация Webprofiters с iMetrics 2015. С момента релиза Universal Analytics у нас накопился огромный опыт работы с протоколом передачи данных. В докладе мы рассказали о 10 наиболее часто возникающих проблемах.
Recommended
Recommended
More Related Content
Viewers also liked
Similar to Практика использования Measurement Protocol. Webprofiters. iMetrics 2015
Similar to Практика использования Measurement Protocol. Webprofiters. iMetrics 2015 (20)
Практика использования Measurement Protocol. Webprofiters. iMetrics 2015
- 1. ПРАКТИКА ИСПОЛЬЗОВАНИЯ MEASUREMENT PROTOCOL ТОП-10 заковык Дмитрий Колотов, CEO
- 7. Пропуск одного из обязательных параметров
- 11. ga(function(tracker) { var cid = tracker.get('clientId'); }); Код JavaScript для получения значения ClientID
- 12. ga(function() { var cid = ga.getAll()[0].get('clientId'); }); Измененный код для получения ClientID
- 13. Использование значения ClientID при получении из cookie файла
- 15. Блокировка кода отслеживания Google Analytics в браузере посетителя
- 17. Генерируем уникальное значение CiD и подставляем в запрос Запрос будет отнесен к прямому переходу
- 19. ФИКСАЦИЯ CID ПРИ ПЕРВОМ ПОСЕЩЕНИИ САЙТА CPC
- 22. Пропуск обязательных параметров для выбранного типа хита (обращения)
- 23. ТИПЫ ХИТОВ GOOGLE ANALYTICS • pageview • appview • event • transaction • item • social • exception • timing
- 26. Типы данных параметров и их максимальные значения
- 27. Превышение максимальной длины запроса при отправке данных расширенной электронной торговли
- 29. Запрос сформирован верно, но данных в отчете нет
- 31. 8 kB max 2 kB max Максимальный объем запроса POST GET
- 32. ФИЛЬТРЫ
- 36. http://goo.gl/iziLIh Сервис проверки запросов по различным параметрам
- 37. Данные не корректны или не совпадают с CRM
- 38. ОТПРАВКА ТЕСТОВЫХ ДАННЫХ В РЕАЛЬНЫЙ СЧЕТЧИК FAIL №1
- 39. НЕОДНОКРАТНАЯ ОТПРАВКА ИНФОРМАЦИИ В GOOGLE ANALYTICS FAIL №2
- 40. ОШИБКИ В ЭЛЕКТРОННОЙ ТОРГОВЛЕ
- 41. День 1 День 2 Фактическая покупка и передача данных из CRM могут быть в разное время
- 42. ПРЕВЫШЕНИЕ ЛИМИТОВ ОБРАЩЕНИЙ С 1 по 500 обращение
- 43. С 1 по 500 обращение ПРЕВЫШЕНИЕ ЛИМИТОВ ОБРАЩЕНИЙ 501 и последующие обращения
- 44. Лимит не распространяется на хиты типа transaction и item В расширенной торговле транзакция может попасть в хиты сверх лимита и быть исключенной
- 45. 5% посетителей с транзакциями превышали лимит
- 48. Экспериментируйте с механизмом фиксации списка товаров
- 50. НЕ ИСПОЛЬЗУЙТЕ UTF-8 Лучше выбрать какой-нибудь экзотический вариант И не привлекайте разработчиков, делайте сами, ошибиться негде.
- 51. НИКОГДА НЕ ТЕСТИРУЙТЕ! ОНО ТОЧНО СРАБОТАЕТ
- 52. НЕ ТРАТЬЕ ВРЕМЯ НА ПЕРЕПРОВЕРКУ ЗАПРОСОВ ЛУЧШЕ ПОПИТЬ ЧАЙ
- 53. НЕ ФИКСИРУЙТЕ ОТПРАВЛЯЕМЫЕ ЗАПРОСЫ ЛУЧШЕ СЪЕСТЬ БУТЕРБРОД К ЧАЮ
- 55. КОНТАКТЫ Москва www.webprofiters.ru +7 495 255 17 15 Колотов Дмитрий Александрович Генеральный директор +79161072009 dk@webprofiters.ru facebook.com/dmitri.kolotov
Editor's Notes
- Принципы работы 10 проблем использования протокола на практике Способы решения обозначенных проблем Вредные советы
- Все запросы со страницы сайта «уходят» в Google Analytics через протокол передачи статистических данных Убедиться в этом можно перейдя в режим разработчика любого браузера и посмотреть запросы, которые передаются при загрузке страницы.
- Используя возможности протокола мы можем передавать различные сведения из множества ресурсов в Google Analytics путем формирования и отправки специальных запросов.
- Активное применение протокол получил при фиксации различных целевых действий пользователя, которые происходят в CRM системах. Мы можем передавать различные статусы заявок, фиксировать фактическое поступление оплаты за заказ и другие сведения.
- Несмотря на кажущуюся простоту его использования, существует ряд подводных камней, о которых нужно знать заранее, чтобы впоследствии не тратить массу времени на поиск проблемы. Итак, общий принцип протокола заключается в формировании и отправки запроса.
- Запрос состоит из нескольких основных блоков Зеленый – url конечной точки Как вам уже известно, обязательными параметрами являются следующие: v – версия протокола; tid – идентификатор или номер счетчика; cid – уникальный номер клиента; t – тип передаваемого хита или обращения.
- И вот тут начинаются первые ошибки. Ну а я, в свою очередь, начинаю повествование о топ-10 ошибок при использовании протокола. Итак номер 1:…
- Пропуск одного из обязательных параметров или использование не допустимого значения для этих параметров, приведет к тому, что отправленный запрос будет проигнорирован. В настоящее время параметр v всегда принимает значение равное единице, параметр tid должен принимать значение соответствующие по формату идентификатору или номеру счетчика Google Analytics, параметр t должен быть равен одному из возможных типов хитов или обращений Google Analytics. Параметр cid служит для передачи уникального номера клиента, по которому в Google Analytics происходит «склейка» всех действий пользователя в единый сеанс.
- В Universal Analytics, а это текущая версия Google Analytics, в отличии от ранних версий используется всего один файл cookie, который и содержит в себе уникальное значение идентификатора клиента.
- Каким образом может быть получено его значение? На стороне клиента, т.е. непосредственно на странице открытой в браузере пользователя с помощью следующего кода. Этот код взят из официальной документации. На практике встречались случаи, когда по каким-то причинам он не возвращал нужное значение. Чтобы исправить это, его необходимо немного изменить, а именно после (УТОЧНИТЬ ПАРАМЕТР) добавить индекс равный нулю:
- На серверной стороне, т.е. при работе скриптов, которые выполняют логику работы сайта значение можно получить, прочитав содержимое cookie _ga. Техническая реализация зависит от того, на каком языке программирования это будет реализовано.
- При получении значения куки будет возвращено вся строка, содержащаяся в нем
- но нам для решения задачи, а именно для связывания всех действий пользователя в единое целое, необходимы только 3-й и 4-й фрагменты. Фрагмент строки необходимый для использования при отправке запроса через протокол ниже Если пренебречь этим, сведения об источнике и канале будут потеряны.
- Это может быть произойти по ряду причин. Например, у пользователя может быть отключен JavaScript, пользователь может поставить плагин в браузере, который будет обрезать коды «рекламных» сервисов, в том числе и Google Analytics и другие подобные ситуации. В этом случае получить реальный client id будет или невозможно или крайне сложно. Если его значение не получится получить, то все-же можно отправить запрос, сгенерировав свое уникальное значение и подставив его в запрос. Но в этом случае источник и канал будут не определены и запрос будет отнесен к прямому переходу.
- Если его значение не получится получить, то все-же можно отправить запрос, сгенерировав свое уникальное значение и подставив его в запрос. Но в этом случае источник и канал будут не определены и запрос будет отнесен к прямому переходу.
- Несоответствие данных по источнику и каналу в отчетах у хитов переданных через протокол и на момент его фиксации. Подобная ситуация характерна для тех случаев, когда от заявки до фактического приобретения товара или услуги проходит значительное количество времени. Приведу пример.
- Пользователь переходит на ваш сайт с рекламной кампании, оставляет заявку, которая попадает в вашу CRM систему, в числе прочих данных вы фиксируете client id пользователя. Для принятия решение о покупке пользователю необходимо время, в течении этого времени он посещает ваш сайт, переходя с результатов поисковой выдачи, с закладки в браузере или с другой рекламной кампании.
- Наконец, он принял решение приобрести товар или услугу, звонит вам и вы оформляете окончательную покупку, после чего данные об этом через протокол, например, транзакцией, передаются в Google Analytics. Как вы думаете, какой источник или канал будет у транзакции? Правильный ответ последний не прямой переход, если он есть. Но у нас после первой фиксации заявки до момента приобретения прошло много времени, первоначальные данные по источнику и каналу уже «перезаписались», мы не увидим в отчете данные по первой рекламной кампании, которая привела нам клиента. Как поступить в подобной ситуации? Можно использовать дополнительные параметры в запросе, которые будут передавать сведения об источнике и канале, и эти данные будут присвоены тому хиту, который отправлен через протокол.
- Для того чтобы это осуществить, необходимо в момент фиксации client id фиксировать также сведения об источнике и канале, которые привели пользователя на ваш сайт.
- Схожа с первой проблемой и связана с пропуском обязательных параметров. Но если в самом начале мы говори об обязательных параметрах для любого типа запроса, то второй набор обязательных параметров связан с типом хита, который вы отправляете.
- Тип хита может принимать ограниченный круг значений Напомню, что каждая запись действия пользователя в Google Analytics называется хитом или обращением. Каждый хит или обращение имеет соответствующий тип. Это может быть: просмотр страницы, событие, социальное действие, транзакция и ряд других.
- Каждый тип хита содержит набор обязательных параметров В зависимости от типа хита, который вы передаете, запрос должен содержать обязательные параметры для него. Если вы их пропустите, данные не будут зафиксированы, Google Analytics их проигнорирует.
- Еще немного остановимся на параметрах и их значениях. Каждый параметр, используемый в запросе, имеет две характеристики: - тип данных; - максимальная длина его значения. Если не учитывать эти требования, то в отчетах может появиться искаженная информация. Значения параметров, превышающие максимально допустимое значение будут обрезаны. То, что мы планировали и фактически передали, отличается от того, что доступно в отчетах. Обращайте на это внимание при внедрении.
- Еще немного остановимся на параметрах и их значениях. Каждый параметр, используемый в запросе, имеет две характеристики: - тип данных; - максимальная длина его значения. Если не учитывать эти требования, то в отчетах может появиться искаженная информация. Значения параметров, превышающие максимально допустимое значение будут обрезаны. То, что мы планировали и фактически передали, отличается от того, что доступно в отчетах. Обращайте на это внимание при внедрении.
- При проведении аудита внедрения расширенной торговли на Deagostini была обнаружена проблема в превышении максимальной длины запроса. Если при фиксации транзакции длина запроса превышает максимально допустимый размер, может быть использован импорт данных о товарах и в последующем вместо описания товаров, в запросе, использоваться только его идентификатор
- При проведении аудита внедрения расширенной торговли на Deagostini была обнаружена проблема в превышении максимальной длины запроса. Если при фиксации транзакции длина запроса превышает максимально допустимый размер, может быть использован импорт данных о товарах и в последующем вместо описания товаров, в запросе, использоваться только его идентификатор
- Запрос сформирован верно, данных в отчете нет. На самом деле здесь может быть несколько проблем. Во первых, запрос может быть отправлен медами POST или GET.
- Во первых, запрос может быть отправлен медами POST или GET.
- В зависимости от того, какой из этих методов используется, мы имеем ограничение на максимальную длину запроса. Для метода POST это порядка 8 килобайт, для GET порядка 2 килобайт. Обращаю ваше внимание, что здесь идет речь не о количестве символов в запросе, а о том, сколько памяти занимает этот запрос.
- Фильтры в представлении тоже могут быть причиной отсутствия данных, отправленных через протокол если вы не видите запросов в отчетах, проблема заключается в том, что ip сервера, с которого вы отправляете запросы через протокол вместе с другими адресами может быть включен в число исключаемых согласно настроек фильтров в представлении. Проверяйте эти данные.
- Т.е. Google не информирует вас, принял он ваш запрос или же нет, коды ошибок тоже не возвращаются Но это не значит, что нет инструментов для проверки
- Получить подобную информацию можно используя отладчик для запросов от Google. Для этого ваши запросы, например тестовые, вы можете отправлять вот по этому адресу конечной точки и в ответ будете получать результат обработки запроса. Если будут ошибки, то Google вернет вам соответствующее сообщение.
- Сервер валидации Measurement Protocol возвращает ответы в формате JSON. Следующий пример представляет собой ответ на обращение выше. Если обращение верно, массив parserMessage будет пустым Поскольку я давно работаю с протоколом то для решения вопросов связанных с отладкой разработал собственный сервис, который позволяет выполнять проверки запроса, а также осуществлять его фактическую отправку. Сервис расположен по адресу который вы видите на экране
- После внедрения, всех проверок и отладки данные в отчетах не корректны и не сходятся со сведениями в CRM. Эта проблема также может возникать по нескольким причинам.
- Первая причина, это отправка тестовых данных в реальный счетчик. На практике приходилось сталкиваться с ситуацией, когда для проверки своей работы разработчики, которые внедряли возможность использования протокола, отправляли тестовые запросы, которые успешно фиксировались и были доступны в отчетах. Причем такими запросами могут быть и транзакции.
- Второе – это неоднократная отправка информации в Google Analytics. Причиной является то, что операторы, работающие с CRM системой, при изменении статуса заявки или при ее фиксации, неоднократно выполняют действия, при которых происходит отправка данных. Например, оператору необходимо изменить статус заявки путем выбора варианта из выпадающего списка, после чего нажать кнопку «сохранить». Запрос отправляется в момент нажатия кнопки. На рабочем месте оператора пропало соединение с интернетом и он несколько раз нажимает на кнопку «сохранить», затем соединение устанавливается, но оператор успевает нажать кнопку несколько раз, прежде чес увидит уведомление об успешной смене статуса заявки. Чтобы избежать подобной ситуации можно те элементы, которые осуществляют отправку данных из CRM, после первого взаимодействия с ними оператора делать не активными, до момента завершения операции.
- По большей части относится к сайтам электронной торговли. Она также состоит из нескольких вопросов, два из которых я раскрыл ранее, это: - корректное определение источника и канала транзакции; - искажение данных. Осталось еще два, которые требуют обратить на себя внимание, это: - дата и время транзакции; - отсутвие данных о транзакциях, при условии, что все, о чем говорилось ранее выполнено.
- Итак, дата и время транзакции. Хотя это касается в целом работы с протоколом, наиболее актуально для транзакций, т.к. оценка информации может происходить по датам продаж. Датой и временем транзакции при ее фиксации с помощью протокола будет являться время отправки запроса. Таким образом, время фактической покупки и сведения по транзакции в Google Analytics могут различаться. Наиболее актуально это для тех случаев, если вы осуществляете выгрузку данных в Google Analytics «пакетно», например, на следующие сутки. Еще одной причиной отсутствия данных является превышение лимитов Google Analytics. Я специально включил этот вопрос в блок связанный с электронной торговлей и транзакциями, поскольку такие ситуации типичны для сайтов, на которых внедрена расширенная электронная торговля.
- Напомню, что на 1 пользователя имеется лимит на 500 хитов/обращений за сессию
- Что произойдет с 501 и последующими обращениями пользователя? Они будут проигнорированы Google Analytics. У вас может возникнуть ситуация, когда пользователь длительное время принимал решение о покупке, просматривал списки, карточки товара и др. информацию и к моменту транзакции исчерпал выделенный на него лимит. Транзакция для такого пользователя будет хитом сверх лимита, и вы не увидите ее в отчетах??????????
- Лимит не распространяется на хиты типа transaction и item В расширенной торговле транзакция может попасть в хиты сверх лимита и быть исключенной, поскольку тип хита будет event или pageview
- При работе с сайтом бутик.ру была выявлена проблема с фиксацией транзакций в расширенной торговле При выяснении причин выяснялось, что от 3 до 5 процентов посетителей с транзакциями превышали лимит в 500 хитов за сеанс
- По поведению можно предположить, что это были девушки, которые долго выбирают товары (длительные сеансы по нескольку десятков минут, просмотры разделов с женскими товарами и карточки женских товаров)
- Как сократить число обращений? Во первых – посмотрите на механизм фиксации списка товаров, возможно у вас настроена отправка данных о просмотре по мере прокрутки экрана, тогда можно увеличить число товаров, которые включаются в список (отправлять просмотр не о каждой строке товаров в списке, а по нескольку строк), может быть есть возможность исключить из отслеживания те действия пользователя, которые не являются для вас критически важными. В любом случае здесь придется искать компромиссное решение.
- В заключение несколько советов по практическому применению протокола.
- Не забывайте о кодировке данных в протоколе и необходимости его url-кодирования. Это задача для разработчиков
- Тестируйте запросы через отладчик или на отдельном счетчике перед переходом на рабочий
- На период внедрения, а лучше на постоянной основе необходимо организовать протоколирование отправляемых запросов. Т.е. все запросы, передаваемые через протокол, записывайте вместе с временем фактической отправки. Реализовать это необходимо разработчикам. Такой подход позволит впоследствии сократить время на поиск проблем и устранение ошибок.