STOP WAR IN UKRAINE!

Facebook совсем недавно добавил метку fbclid во все ссылки в своей социальной сети. Я об этом недавно писал в своем Telegram-канале по digital-аналитике: В связи с этим многие могли заметить эту метку в своих отчетах Google Analytics. Обычно это выглядит так: Отслеживание метки fbclid несет несколько неудобств: Google Analytics получает проблемы с агрегированием просмотров страниц для страниц с такими метками. На сайтах с большой посещаемостью в запись Другие начинает попадать больше страниц. Это значит, что при большом количестве уникальных адресов страниц (больше 50 000 в день) вы не сможете в сводных таблицах GA правильно посчитать распределение просмотров страниц по этим адресам из-за того, что больше данных будет попадать в Другие. Подробнее об этой проблеме написано  справке . Эту проблему для Google Analytics можно решить двумя способами: удалять метку fbclid и ее значение прямо из payload. За основу такого решения можно взять решение Simo Ahava по удален

Иногда работая с большими данными на медленных компьютерах хочется по методу прогрессивного jpeg'a быстро получать ответы регулируя при этом процент выборки для изменения точности. Например, нужно посчитать пересечение аудиторий, данные о которых хранятся в разных ресурсах Google Analytics и понять, эта цифра ближе к 10% или к 90%? При этом не хочется выгружать полные данные и долго ждать точных вычислений. В таком случае, хотелось бы выгрузить какой-то процент случайных ClientID из обоих ресурсов и посчитать пересечение на этой выборке данных. Такой подход основан на методе Монте-Карло , который часто можно встретить для решения и других задач из разных областей. Возвращаясь к вопросу выгрузки данных из Google Analytics с заданным процентом выборки (семплирования) на помощь приходит малоизвестный параметр Google Analytics —  userBucket .  По умолчанию, в Google Analytics этот параметр случайным образом заполняется целым числом от 1 до 100. Это значит, что по этому параметру мо

На тему настройки системы аналитики для SPA-сайтов уже написано много хороших статей, ссылки на самые полезные из них я добавлю в конце этой статьи. Здесь я хочу рассказать об одной особенности настройки отслеживания, которая может незаметно поломать систему вашей отчетности для таких сайтов. Для начала в двух словах хочу рассказать, что такое SPA и чем такие сайты отличаются от обычных. Single Page Application (SPA) — это веб-сайты, контент на которых подгружается динамически, обычно посредством AJAX. Пример SPA-сайта:  https://flatfy.kz/ . На этом сайте страница загружается только один раз, все остальные страницы прорисовуются без фактической перезагрузки в браузере, как на обычных сайтах. Чтобы определить использует ли ваш сайт SPA можно зайти на сайт и перейти на какую-то страницу. Если при загрузке второй страницы поменялся URL, но браузер не обновил страницу (кнопка обновления страницы в браузере не поменяла режим) — значит у вас SPA. Главными особенностями таких сайто

Многие сайты уже собирают данные с помощью Facebook Pixel. Эти данные можно использовать, как для создания аудиторий ремаркетинга в Facebook Ads, так и для изучения поведения аудитории сайта через Facebook Analytics. Но не многие используют все возможности отслеживания Facebook Pixel. Например, в Pixel Code Reference  находится подробная информация о том, какие еще события вместе с различными параметрами можно собирать со своего сайта. Но настраивать все эти события «с нуля» часто бывает проблематично — разработчикам нужно разбираться в новой документации и программировать новый трекинг. Ниже приведен пример решения по стримингу данных в Facebook из уже настроенного Google Analytics кода. Что вы получите после настройки?  Данное решение позволяет добавить код в customTask, который анализирует тело запроса в Google Analytics и отправляет такие же данные через Facebook Pixel. В итоге, для каждого просмотра страницы будет отправлено стандартное для FB событие — PageView, а для дру

Нужно сделать несколько шагов: 1) Google готовится к выполнению требований GDPR (новый закон ЕС о защите данных, вступающий в силу 25 мая 2018 года) и добавил новую важную настройку в Google Analytics. Начиная с 25 мая 2018 года в GA автоматически  начнут удаляться данные пользователей, которые старше 26 месяцев, если не изменить этот период хранения данных.  Просмотрите свои настройки и внесите необходимые изменения (Ресурс -> Отслеживание ->Хранение данных). Например, можно выбрать "Do not automatically expire", чтобы данные не удалялись вообще. Как и где это сделать показано на скриншоте ниже: Подробнее об этом можно почитать в официальной справке Google Analytics . Или посмотреть в видео: P.S. так же, до 25 мая Google обещает представить новый инструмент, который позволяет управлять удалением всех данных, связанных с отдельным пользователем. 2) Второй момент который обязательно нужно проверить, это проследить за тем, чтобы в отчетах Google

Несколько дней назад я написал статью о том, как можно определить мошенничество CPA-сетей с помощью API Google Analytics.  В этой статье я решил реализовать тот же самый алгоритм, только используя Logs API Yandex.Metrika. Для тех, кто пока не понял о каком мошенничестве идет речь коротко излагаю суть проблемы: были замечены случаи, когда пользователям находящимся на сайте по прямому источнику трафика «внезапно» приписывались UTM-метки CPA-сетей. Участники таких сетей получают деньги тогда, когда целевое действие выполнено пользователями с такими метками. От себя добавлю, что я лично встречал такую подмену источников трафика на одном из украинских интернет магазинов. В подтверждение этому явлению можно прочитать  эту  и эту  публикацию, а так же  отдельный кейс  компании OWOX и Райффайзенбанка по этой проблеме. В этой статье я хочу показать готовый код на R, который используя Logs API выгружает данные из Yandex.Metrika и находит случаи перезаписи (смены) источника трафика пользов

Если ваш бизнес привлекает трафик на сайт с помощью CPA-сетей — обязательно прочтите историю о том, какие технические хитрости могут использовать недобросовестные партнерские сети:   И вот еще одно сообщение: От себя добавлю, что я лично встречал такое на одном из украинских интернет магазинов. Компания OWOX вместе с Райффайзенбанком уже успела сделать отдельный кейс по этой теме и рассказала, как можно обезопасить себя от такого мошенничества используя стриминг сырых даных о посещениях сайта в Google BigQuery. Для тех, кто не использует BigQuery в качество хранилища данных сайта я решил сделать решение на R, которое позволяет проверить свои Google Analytics (так же есть  версия скрипта для Yandex.Metrika ) данные на наличие такой проблемы. Сразу хочу сказать, что решение можно использовать, если в custom dimensions Google Analytics хранятся ClientID, SessionID, Hit Timestamp и Referrer ( или использовать версию скрипта для Yandex.Metrika ) — эти поля являются необходимым

Зачем это делать? Есть много различных проектов, у которых доход зависит от погодных условий. Например, горнолыжные курорты, парки отдыха, доставка еды или службы такси. Чтобы измерить влияние погоды на конверсию можно передавать данные о погоде для каждой сессии посетителей сайта.