Офлайн-конверсии – все что вы не знали, но боялись спросить

Для связывания событий, происходящих за пределами сайта/приложения, с источником трафика аналитики традиционно пользуются Measurement Protocol от Google или его аналогами. Это позволяет фиксировать в среде аналитки нетиповой ивент: квалификацию, офлайн-покупку, проведенную встречу и другие.

Однако, у этого инструмента есть ряд тонкостей, которые не лежат на поверхности, но являются крайне важными или просто примечательными. Например:

1. Вы всегда можете поиграться и отправлять через Measurement Protocol в Universal Analytics совсем специфические сущности – например факт нажатия на кнопку соцсетей на вебсайте (это обращение с типом взаимодействия social), ошибки на вашем сайте или обращения типа timing (временной интервал).

2. Вы можете трекать самые замысловатые события – не только встречи или покупки на кассе, но например возварты товара, открытия письма или переход на стороннюю площадку и просмотр определенного контента (последнее делается с помощью невидимого тега img, содержащего текст запроса).

3. Вы можете отправлять кучу предопределенных и кастомных параметров, например идентификатор эксперимента для пользователя, имевшего отношение к экспериментальной выборке из Optimize, или отдельных пользовательских свойств и разнообразнейших ecommerce-параметров.

4. Во второй версии протокола добавлен параметр timestamp_micros – теперь вы можете отправлять события в прошлое и более детально связывать их с источником трафика. В предыдущей версии также был параметр "время в очереди", но обращения все равно могли связываться с произвольным сеансом.

5. Все значения параметров должны быть кодированы в UTF-8 и URL-кодированы. Это значит – избегайте кириллицы при составлении запроса дабы не утяжелять его.

6. Вторая версия протокола безопаснее первой – используется только метод POST и теперь обязательно добавление номера счетчика и API-ключа. Это делает отправку фейковых обращений затруднительной.

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

8. Формат тела запроса для второй версии протокола – JSON. Это значит вы можете использовать удобные вложенные структуры данных.

У метода существует куча других особенностей, подробно описанных в документации. Пользуетесь ли вы какими-то хаками по отправке офлайн-конверсий? Напишите в комментарии.

Вам мог понравиться этот пост – прошу в этом случае оставить лайк и поделиться им с друзьями – для меня это очень важно.

#вебаналитика #ga #measurementprotocol #офлайнконверсии #модельатрибуции

@marketing_analysis

Simple ML for Sheets – новый убийца стартапов от Google

Один из простых способов валидации бизнес-идеи, предложенный Ash Maurya, – проверить, можно ли ее реализовать простыми средствами Microsoft Excel. Google пошел похожим путем, интегрировав машинное обучение в свои SpreadSheets. Выглядит как первый шажок для увольнения массы аналитиков, датасаентистов и ML-сервисов.

NoCode-продукт от команды TensorFlow называется Simple ML for Sheets и представляет собой add-on, работающий в среде браузера Google Chrome. Пользоваться им может даже юзер, не обремененный богатым опытом обращения с данными. Все что нужно – установленное расширение и датасет в Google-таблицах.

Конечно, Simple ML for Sheets решает крайне узкий круг задач. Если подробнее, то их всего две – заполнение пропущенных значений и выявление аномалий. Продвинутые пользователи смогут тренировать, оценивать модель и экспортировать в Google Collab.

Однако, после добавления быстрого экспорта с BigQuery использование Google Таблиц вместе с Simple ML выглядит очень интересным решением с большим потенциалом. Документацию можно почитать здесь.

А что вы думаете о Simple ML for Sheets? Успели ли поиграться? Напишите в комментарии.

Вам мог понравиться этот пост – прошу в этом случае оставить лайк и поделиться им с друзьями – для меня это очень важно.

#machinelearning #google #spreadsheets #модельатрибуции

Средняя продолжительность сеанса и поведенческое моделирование в GA4

Google Analytics анонсировала интересный апдейт: в обновлении добавлены новые поведенческие метрики - средняя продолжительность сеанса и среднее число просмотров страниц за сессию, а также поведенческое моделирование. Последнее актуально для веб-сайтов использующих cookie policy и соответствующий банер сбора разрешений. Начав за здравие (отказ от session-based аналитики в сторону событийной), GA все больше обрастает метриками и параметрами скоупа сессии. Видимо сегмент рынка, пока что не готового к таким измненениям, оказался более внушительным, чем ожидалось.

Подробнее об обновлении здесь.

#аналитика #googleanalytics #отчет #модельатрибуции

@marketing_analysis

Альтернативы Google Optimize

Google поэтично анонсировал свертывание своего сервиса для ab-экспериментов, назвав происходящее закатом Google Optimize. Шутки шутками, но на этом бесплатном (что крайне важно) приложении выросли целые поколения гроус-хакеров. Это делает вопрос смены вендора актуальным – особенно если вы регулярно проверяете большое количество гипотез на своем веб-сайте. Ниже подборка актуальных сервисов для сплит-тестирования с моими ремарками.

Optimizely
Одна из самых сильных альтернатив Optimize, когда-то имела бесплатный тарифный план и триальный доступ. Под капотом у нее – визуальный редактор кода, серверная и клиент-имплементации, мультивариативные эксперименты, Stats Engine и API для работы со статистикой. К сожалению фокус компании давно сместился в сторону энтерпрайза, цену на годовые планы (других нет) вам озвучат только по запросу. Для пользователей Google Optimize анонсирован специальный оффер.

VWO
Visual Website Optimizer предлагает продвинутый инструмент для внесения изменения, редактор кода, AI-рекомендации по изменению текста (!), кучу интеграций (в том числе с Google Analytics), возможность тестирования мобильных приложений, бесплатный тариф до 50тыс пользователей в месяц и 30-дневный триал. Стоимость на премиум-планы не раскрывается, в сети гуляют цифры от $359 в месяц.

ABtasty
Продвинутые возможности таргетинга и сегментации (AI-сегментация, кросс-девайс, данные из ваших CDP), тестирование с помощью встроенных виджетов, поддержка SPA, саппорт 24/7, тепловые карты (по аналогии с вебвизором). Встречал утверждения про 30-дневный бесплатный триал и стартовую стоимость месяца от $49. На самом вебсайте стоимость не раскрывается, но можно быстро забукировать слоты для демо и расчет квот.

Convert
Один из немногих игроков с прозрачным ценообразованием – от $99 в месяц для 50тыс пользователей с двухнедельным триалом. Предусмотрены интеграции практически со всеми популярными приложениями, анти-фликер, эксперименты с перенаправлением, возможность использования данных из CRM и вообще большинство функций актуальных для Google Optimize. Имплементация нетривиальна, но компенсируется отзывчивой поддержкой. Компания заботливо выкладывает на свой веб-сайт обзоры и сравнения с другими сервисами.

Kameleon
Ключевая фишка – AI-powered-эксперименты с участием моделей машинного обучения, которые предсказывают вероятность конверсии в реальном времени и мощный технический стек (решения для PHP, Java, Ruby, Flutter). Добавьте сюда строгое соответствие нормам GDPR и получите продвинутое решение для корпоративных команд. Стоимость не раскрывается, но я обнаруживал отзывы с цифрами около $30 000 в год.

Firebase A/B tests
Вертикаль бесплатного и горячо любимого разработчиками Firebase для ab-тестов. Используется для тестирования мобильных приложений и примечательна тем, что наследует функционал Google Optimize по реализации и отслеживанию результатов экспериментов. Управление происходит прямо в консоли Firebase, подмена вариантов – с помощью Remote Config.

Планируете ли вы переезд на другие сервисы ab-тестирования? Напишите об этом в комментарии.

Вам мог понравиться этот пост – прошу в этом случае оставить лайк и поделиться им с друзьями – для меня это очень важно.

#abtest #googleoptimize #analytics #модельатрибуции

@marketing_analysis

Все способы отслеживать поиск на сайте с помощью GA

Google Analytics (и четвертая, и предыдущая версии) предоставляют крутые возможности для отслеживания поиска на вашем веб-сайте: в Universal Analytics вообще предусмотрен достаточно богатый скоуп метрик (выходы после поиска, средняя глубина и уточнения) в разрезах страниц и поисковых запросов.

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

1. Самое простое – если поиск на вашем сайте организован с помощью добавления параметра в URL страницы, допустим "/search?q=" или "/search?term=". Для отслеживания поиска перейдите в настройки представления Google Analytics, включите отслеживание поиска на сайте и пропишите необходимый (-е) параметры. После можно будет идти в отчеты по использованию поиска в Unversal Analytics или формировать отчеты с автоматически регистрируемым событием view_search_results в GA4. Здесь есть детали.

2. Второй вариант посложнее – в случае если поиск осуществляется методом POST, без фиксации запроса в строке браузера. В этом случае вам нужно получить переменную с текстом поискового запроса в GTM (например с помощью dataLayer-переменной или переменной Собственный код JavaScript), а после немного видоизменить тег Google Analytics, дабы при посещении поиска он отправлял просмотр виртуальной страницы с URL, содержащей искомый запрос. Звучит сложновато, но у ребят с Netpeak описано достаточно толково. Можно посмотреть в этой инструкции.

3. Немного хардкора – автообновляемая страница поиска с саджестами под то, что вводит пользователь. То есть содержимое страницы заполняется результатами до того как пользователь нажмет на Enter. Элегантное решение предложил Simo Ahava, который в своей статье описал небольшую JS-функцию, обрабатывающую браузерное событие keydown (начало заполнения поиска), количество символов и таймаут с начала набора запроса. Подробности описаны здесь, но принцип тот же, что и в предыдущем пункте – задетектить поисковой запрос и отправить page_view виртуальной страницы.

Это все известные мне способы отслеживания поиска с помощью GA. Если вам известны другие варианты извлечения инсайтов с этого функционала – напишите об этом в комментарии.

Вам мог понравиться этот пост – прошу в этом случае оставить лайк и поделиться им с друзьями – для меня это очень важно.

#поиск #search #googleanalytics #модельатрибуции

@marketing_analysis

Дополнил и опубликовал на vc.ru статью с обзором сервисов AB-тестирования в качестве альтернативы уходящему в закат Google Optimize. Прочитать, лайкнуть и обсудить можно по ссылке.

Chamath Palihapitiya о необходимости постоянного экспериментирования

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

В этом смысле я был приятно удивлен ремаркой Chamath Palihapitiya (CEO Social Capital, ex-Facebook) из его недавнего интервью Lex Fridman. Он нарисовал простое и изящное уравнение, буквально по полочкам разложил необходимость упаковки большого количества экспериментов в единицу времени. Цепочка рассуждений примерно следующая:

1. Все мы боремся за дефицитные ресурсы (revenue, подписчики, внимание пользователей);

2. Все мы совершаем ошибки;

3. Выигрывает тот, у кого уравнение «свои ошибки минус чужие ошибки» будет лучше, чем у других;

4. Чужие ошибки всегда находятся вне зоны нашего контроля;

5. То есть в этом уравнении мы можем влиять только на собственный «коэффициент ошибок»;

6. Единственный эффективный способ снизить свой «коэффициент ошибок» – это совершать больше (!) ошибок;

7. Потому что: так работает математика (больше попыток = больше успехов);

8. Потому что: так растет экспертиза (больше попыток = больше знаний);

9. Поэтому: единственный путь расти – это агрессивно идти в новый опыт и совершать много ошибок в единицу времени (то есть – добавлю от себя – проводить больше экспериментов);

10. Это звучит неожиданно, потому что общество навязывает негативные коннотации самому определению слова «ошибка»;

11. Но на самом деле ошибки – это не «плохо», это обучение и опыт.

Не убавить, ни прибавить. Полностью интервью можно посмотреть по ссылке https://www.youtube.com/watch?v=kFQUDCgMjRc

Возможно у вас свой взгляд на проведение экспериментов в маркетинге – напишите об этом в комментарии.

Вам мог понравиться этот пост – прошу в этом случае оставить лайк и поделиться им с друзьями – для меня это очень важно.

#эксперименты #abтесты #analytics #модельатрибуции

@marketing_analysis

Отправка офлайн-конверсий в прошлое

В своей недавней публикации Simo Ahava коснулся того, о чем давно и регулярно ворчал Илья Красинский – рандомной атрибуции офлайн-конверсий при отправке их в Google Analytics через предыдущую версию Measurement Protocol.

Суть проблемы была вкратце описана в одном из предыдущих моих постов – ключевым параметром для привязки офлайн–события к конкретному сеансу в Unversal Analytics служил client_id. Что само по себе неплохо. Но в случае нескольких визитов пользователя на веб-сайт для связки одного из них с ивентом мог быть выбран совершенно случайный сеанс.

Это превращало игру в атрибуцию офлайн-конверсий в своеобразную рулетку – «попадем-не попадем». Увы, но наличия client_id и параметра «время в очереди» недостаточно для верного соотнесения с подходящим сеансом. Если перед продажей, зафиксированной скажем на кассе, пользователь трижды вернулся на ваш ресурс с разных источников и каналов – пиши пропало, конверсия могла записаться куда угодно. Теперь все по-другому.

В Measurement Protocol 2 можно отправлять события в прошлое и привязывать к конкретной сессии в GA4, используя несколько (три) параметров:

client_id – идентификатор пользователя;

session_id – то же самое, только в отношении сеанса;

timestamp_micros – время события в прошлом;

Достать их можно достаточно просто из событийных табличек в BigQuery. Располагая этими тремя параметрами, вы можете смело отправлять события (с помощью разработки или ноу-код сервисов) в GA4, связывать их с конкретными визитами – скажем когда пользователь зарегистрировался или оставил заявку – и наследовать от визита параметры источника или канала.

Что важно учитывать:

1. В случае если сессия активная (не прошел таймаут – обычно 30 минут), session_id можно не указывать;


2. Порог для отправки события в прошлое – 72 часа, об этом сказано в документации. Отправить в 1985 год не выйдет;


3. Событие отразится в real-time-репорте, но в исследованиях окажется в указанном вами отрезке времени.


4. Валидация обращений происходит точно также – с помощью Hit Builder.

Ниже ссылки на материалы:
Статья Simo Ahava
Документация по Measurement Protocol
Предыдущий пост про офлайн-конверсии
Hit Builder

Возможно у вас есть другое решение для отправки офлайн-конверсий в GA4 – напишите об этом в комментарии.

Вам мог понравиться этот пост – прошу в этом случае оставить лайк и поделиться им с друзьями – для меня это очень важно.

#офлайнконверсии #ga #analytics #модельатрибуции

@marketing_analysis

Уровни работы с конверсией

Конверсия – краеугольная метрика для экономики маркетинга и продукта. И вот почему.

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

Во-вторых, у нее, как правило, очень мощное «плечо». Иначе говоря, даже несущественные изменения в конверсии могут аукнуться серьезными потерями / выгодами на длинной дистанции – просто в силу того, что так работают когорты.

В-третьих, алгоритм работы с конверсией – весьма примитивен и в своей изначальной сути неповторим. Если проще – существует всего несколько уровней работы с конверсией, но работать с ними можно ТОЛЬКО последовательно – сначала одно, потом другое, и только затем третье.

Последнее кроме всего прочего означает, что
а) алгоритм этот и правда чертовски прост;
б) нарушение последовательности шагов создает огромное пространство для ошибок.

Итак, существуют следующие уровни работы с конверсией:

0 (нулевой). Идентификация. До того как начать копать, имеет смысл понять природу ямы, которой вы находитесь. И это только на бумаге выглядит очевидным. Но я утверждаю, что это самый базовый, жизненно важный этап. Масса команд / руководителей хватается за улучшения своей воронки без взвешенного анализа всей цепочки ценности. Даже если вы уверены, что хорошо знаете свои проблемы и что они допустим в конверсии – не поленитесь даблчекнуть себя, разложив промежуточные метрики с помощью AARRR-фреймворка.

1 (первый). Недоразумения. Это низковисящие фрукты, в реальность которых мы обычно не верим. Кривая мобильная верстка, недоступность биллинга, грубые ошибки в таргетинге, локализации, редиректах, браузерной совместимости и прочее. Простая проверка на дурака, тестовые покупки и пара коридорок даже поверх автотестов способны принести 1-2 миллиона выручки еще до начала процесса оптимизации.

2 (второй). Работа с противоречиями. Артефакт этого уровня – набор гипотез. Узкое место в производственной цепочке практически всегда является результатом противоречия. Пример: рост числа лидов приводит к росту бюджета на маркетинг. Пример как будет решаться противоречие – делать так, чтобы получать больше лидов на том же или меньшем бюджете.

Путь к разрешению противоречий – глубокое понимание «работ», на которые нанимает вас пользователь. Подбор релевантного решения будет суть рискованным предположением, которое мы предполагаем проверять. Крайне редко такие предположения – что-то в духе «перекрасить кнопку». И почти всегда самые «жирные» гипотезы рождаются только после серии из 5-10 JTBD-интервью с текущими и ушедшими пользователями.

3 (третий). Эксперименты. Технический уровень. Представляет собой набор рутин по извлечению самых многообещающих гипотез, их проверке и имплементации выводов. Про организацию, запуск и оценку AB-экспериментов написано достаточно много (лично я рекомендую интенсив от EXPF), главное на что стоит обратить внимание – гигиена и скорость. Все остальное за вас сделает эффект сложного процента.

Это все, что вы можете сделать для улучшения своей конверсии. Если у вас есть о чем подискутировать – обязательно выскажитесь в комментарии.

Вам мог понравится этот пост – прошу в этом случае оставить лайк и поделиться им с друзьями – для меня это очень важно.

Полезные ссылки:
Про «метрики тщеславия»
Про AARRR
Про JTBD
Про противоречия
Про AB-тесты

#конверсия #маркетинганалитика #analytics #модельатрибуции

@marketing_analysis

Правильная интеграция GA4 и Firebase

Чрезвычайно полезный совет по интеграции GA4 и Firebase для мобильных приложений от Himanshu Sharma.

В принципе существует два возможных пути — настроить интеграцию в Firebase или создать поток данных в GA4.

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

В противном случае — если вы создадите новый поток в ресурсе GA4 — Google автоматически создаст новые проекты в Google Cloud и Firebase. Но если у вас уже есть мобильное приложение и сопутствующие проекты в облаке и Firebase, то нет необходимости создавать дополнительные.

Так что настраивайте в Firebase )

#ga4 #googleanalytics #мобильноеприложение #модельатрбиуции

@marketing_analysis

Самые удобные отчеты в Amplitude

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

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

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

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

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

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

Это только некоторые из самых удобных отчетов в Amplitude. Однако, каждый отчет может быть настроен и изменен под индивидуальные потребности и запросы пользователя.

Если у вас есть любимые отчеты в Amplitude – обязательно напишите об этом в комментарии.

Вам мог понравится этот пост – прошу в этом случае оставить лайк и поделиться им с друзьями – для меня это очень важно.

#amplitude #продуктоваяаналитика #analytics #модельатрибуции

@marketing_analysis

Как удешевлять запросы в Big Query?

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

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

Используйте наиболее эффективные типы данных
Например, если вы используете тип данных INTEGER вместо FLOAT для числовых значений, вы можете сократить затраты на обработку данных. Также стоит избегать использования типа данных STRING для хранения дат и времени. Вместо этого используйте тип данных TIMESTAMP.

Используйте сжатие данных
Сжатие данных – это процесс уменьшения размера данных путем удаления избыточной информации. BigQuery поддерживает несколько методов сжатия данных, таких как Snappy и GZIP.

Используйте параметризованные запросы
Это способ повторного использования запросов с различными параметрами. Это может сократить количество запросов, которые вы отправляете в BigQuery, и снизить затраты на обработку данных.

Используйте Materialized Views для кэширования результатов запросов
Materialized View - это таблица, содержащая результаты запроса, предварительно вычисленные и сохраненные в кэше. Кэширование результатов запросов позволяет избежать повторного выполнения дорогостоящих запросов каждый раз, когда они запрашиваются, и ускорить время выполнения запросов.

Это самое главное о том, как удешевлять запросы в Big Query. Если у вас есть о чем подискутировать – обязательно выскажитесь в комментарии.

Вам мог понравиться этот пост – прошу в этом случае оставить лайк и поделиться им с друзьями – для меня это очень важно.

#bigquery #данные #etl #модельатрибуции

@marketing_analysis

Аналитическая платформа UX Rocket

Удалось поприсутствовать на демо нового аналитического сервиса UX Rocket. Заинтересовался их решением для экспериментов.

Платформа для A/B-тестов UX Rocket функционирует в рамках одноименного аналитического приложения от компании Excite Kit, позволяет довольно тонко настраивать таргетинг для проведения экспериментов на основе богатого набора своих и кастомных атрибутов и сегментов.

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

Стоимость предоставляется по запросу, но существует возможность внедрения пилотного проекта для тестирования возможностей сервиса и прогноза его окупаемости.

Добавил более развернутный обзор UX Rocket в свой материал о сравнении сервисов для A/B-тестирования.

#abтестирование #аналитика #модельатрибуции

@marketing_analysis

Слиты скриншоты нового сервиса Google Optimize + GA4!

Dennis van der Heijden из Convert.com опубликовал скриншоты и ссылку на бета-тестирование сервиса Google Optimize + GA4! Ссылка на доступ к бета-тесту есть здесь - https://www.convert.com/blog/a-b-testing/is-optimize-making-a-return/

#abтестирование #аналитика #модельатрибуции

@marketing_analysis

Разница в данных между GA4 и BigQuery Export

Получаете разные результаты при анализе данных Google Analytics 4 в BigQuery по сравнению с стандартным интерфейсом отчетности? Понимание различий между двумя методами анализа данных необходимо для точных и надежных выводов. В статье Минхаза Кази из Google описаны наиболее значимые расхождения между BigQuery и пользовательским интерфейсом GA4 и советы по обеспечению точного расчета метрик. Вот мое краткое резюме основных различий и способов как их избежать:

Сэмплирование
Предварительно обработанные таблицы базы данных в GA4 используются в стандартных отчетах и Data API. При исследованиях же используется необработанные данные, но они сэмплируются, если количество событий превышает квоту от 10 млн. Чтобы сопоставить данные с экспортом из BigQuery, проверьте отчеты без сэмплирования в исследованиях.

Различные определения пользователей в GA4 и BigQuery
Метрика "Всего пользователей" в GA4 считает пользователей, которые выполнили по крайней мере одно событие, но при этом "Активные пользователи" - это основная отчетная метрика. При расчете количества пользователей из BigQuery следует фильтровать активных пользователей на основе критериев для каждого типа потока. Реализация запросов может варьироваться, но в скором времени в BigQuery будет добавлено поле is_active_user для упрощения фильтрации.

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

Задержка во времени
BigQuery создает ежедневные таблицы после сбора всех событий из GA4 за день. Эти таблицы могут обновляться до 72 часов после даты. Эта проблема в основном влияет на реализации Firebase SDK или Measurement Protocol с отложенными событиями. Сравнения между BigQuery и GA4 должны проводиться на данных старше 72 часов из-за возможных расхождений между стандартными отчетами и экспортом из BigQuery.

Google Signals
Активация Google Signals в GA4 позволяет избежать проблемы учета нескольких пользователей для одного юзера, просматривающего ваш сайт на нескольких браузерах и устройствах. Однако, при экспорте в BigQuery могут по-прежнему отображаться несколько user_pseudo_id – поскольку BigQuery работает на основе cookie-идентификтаоров.

Режим согласия и Моделированные данные
Если пользователи не дали согласие на использование куки, то в GA4 используется моделирование, чтобы заполнить пробелы в данных. Но в BigQuery при этом user_pseudo_id может меняться в зависимости от сессии и это провоцирует различия между стандартными отчетами и BigQuery. Внедрение User-ID в GA4 снижает этот эффект.

Атрибуция трафика
В BigQuery данные об атрибуции трафика доступны на уровне пользователя и события, но не на уровне сессии, поскольку GA использует собственную модель атрибуции. Чтобы создать пользовательскую модель, вы можете объединить набор данных с first-party-данными. В будущем в BigQuery будет доступно больше данных для атрибуции трафика.

Ошибки вычислений
Для обеспечения точности метрик в BigQuery важно использовать правильные методы расчета, такие как подсчет уникальных комбинаций user_pseudo_id/user_id и ga_session_id. Также следует учитывать способ идентификации, область действия параметров и показателей, разницу в часовых поясах и ограничения на фильтрацию/экспорт данных, которые могут вызывать расхождения между данными экспорта событий BigQuery и стандартными отчетами.

Учитывайте эти моменты при работе с данными GA4 в BigQuery, чтобы получить точные и надежные данные.

Ссылка на статью Минхаза Кази

#bigquery #googleanalytics #аналитика #ga4 #модельатрибуции

@marketing_analysis

Что почитать об аналитике? «Lean Analytics: Use Data to Build a Better Startup Faster»

Начинаю серию постов о книгах о продуктовой и маркетинг-аналитике. Первый блин – «Lean Analytics: Use Data to Build a Better Startup Faster» - исчерпывающее руководство по использованию аналитики для развития успешных стартапов. Авторы предлагают читателям шаг за шагом научиться определять, какие метрики нужно отслеживать, как собирать данные, как анализировать результаты и как принимать решения на основе данных.

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

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

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

Ссылка на книгу на Amazon

Если вам хочется больше рецензий на книжки об аналитике от меня – прошу оставить лайк и поделиться им с друзьями – для меня это очень важно.

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

#книги #аналитика #чтопочитать #модельатрибуции

@marketing_analysis

Почему показатель отказов – зло

Когда дело доходит до анализа поведенческих, очень хочется смотреть на Показатель отказов. Или Долю сеансов с взаимодействием (Engagement Rate) в GA4. Очень это удобно. За одним небольшим исключением. Метрики эти – просто-напросто одно большущее допущение. Огромное.

Не надо.

Показатель отказов – это процент сеансов с просмотром только одной страницы без дополнительных запросов к GA. Аналог в GA4 – Доля сеансов с взаимодействием, то есть процент сеансов, продлившихся как минимум 10 секунд с хотя бы одним событием или двумя просмотрами страницы. Иначе говоря – то же блюдо, но с другим соусом. Такое же бесполезное и невкусное.

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

Более того, есть очень хитрый параметр Non-Interaction – он используется в настройках событий в теге Google Analytics для указания, будет ли событие рассматриваться как взаимодействие пользователя с сайтом или как техническое событие, которое не влияет на показатель отказов. Если не вдаваться в подробности, то неверное использование этого параметра легко сделает ваш показатель отказов равным 100%. Или 0%. Или чему угодно.

Это самый яркий пример метрики тщеславия – оторванные от действительности цифры. Удобные для манипуляции и бесполезные для бизнеса.

Поэтому при работе с показателем отказов нужно использовать два простых правила:

1. Не использовать его.
2. Не использовать его.

Если по каким-то причинам сильно хочется – создайте сегмент engaged users / sessions на основании конкретно вашей бизнес-логики и работайте с ним. Это не так удобно как показатель отказов, но гораздо эффективнее.


Это самое главное о показателе отказов. Если у вас есть чем поделиться об этой и других метриках – обязательно выскажитесь об этом в комментарии.

Вам мог понравиться этот пост – прошу в этом случае оставить лайк и поделиться им с друзьями – для меня это очень важно.

#ga #ga4 #метрики #аналитика #модельатрибуции

@marketing_analysis

Интеграция с third-party сервисами для анализа экспериментов в GA4

Google наконец-то анонсировал решение для проведения экспериментов. Это не свой сервис, а API-интеграция.

GA4 будет позволять пользователям запускать эксперименты в сторонних платформах A/B-тестирования, а затем интерпретировать результаты в GA4, используя API для передачи данных. Для этого предполагается использовать аудитории, а не параметры.

Когда пользователь создает эксперимент в стороннем инструменте, выбирает GA4-проперти, связанное с экспериментом и дает согласие на интеграцию. Затем GA4 создает аудиторию для каждого варианта эксперимента. Когда эксперимент заканчивается, каждая аудитория удаляется, чтобы не превышать лимит на их использование. Однако после вы все еще можете получить доступ к данным эксперимента в исследованиях и BigQuery.

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

Что это означает:

1. Эксперименты по всей видимости перестанут быть бесплатными. Вообще.

2. Использование GA4 для анализа экспериментов не имеет никакого смысла. Из-за отсутствия требуемой точности (имею ввиду влияние Hyperloglog++, сэмплирования и Google Signals).

3. Фактически единственно возможный вариант работать с GA-данными с экспериментов - самостоятельные исследования в Bigquery.

Сервисы, которые уже анонсировали возможность интеграции с GA4:

A/B-Tasty
Optimizely
VWO
Kameleon
Convert

Статья с анонсом от Google
Мой пост с обзором сервисов A/B-тестирования

Вам мог понравиться этот пост – прошу в этом случае оставить лайк и поделиться им с друзьями – для меня это очень важно.

#ga #ga4 #abтесты #аналитика #модельатрибуции

@marketing_analysis