🫨 Почему отчеты в системах веб-аналитики не отражают точную ситуацию?

Некоторые аналитики, которые не работали с настройкой системами веб-аналитики могут думать, что сырые данные, которые они видят в БД или данные в интерфейсе системы являются валидными и полными, но зачастую это не так. Давайте обсудим, какие могут быть проблемы.

1. Кривая разметка сайта
У сайта может быть несколько шаблонов для разных страниц и в какие-то из них могли забыть воткнуть код счетчика и вы не собираете данные с этих страниц

Либо для части форм не настроено отслеживание отправки или отправка формы трекается при клике по кнопке, а не при валидной отправке формы.

Это лишь некоторые из проблем с разметкой.

2. Кривая utm разметка
utm метки используются для определения источника трафика. Кто-то из трафик менеджеров может забыть их поставить или заполнить не правильно и вот вы уже не можете понять откуда пришел трафик.

3. Серверные редиректы удаляющие utm метки
Иногда на сайтах не правильно настроены перенаправления между страницами. Например я встречал сайты где при открытии сайта происходил редирект и все get параметры удалялись из url, соответственно utm метки тоже.

4. Блокировки
Некоторые системы для блокировки рекламы, например adblock могут блокировать отправку запросов на сервера яндекс метрики. Соответственно таких пользователей вы просто не увидите в статистике систем веб-аналитики.

5. Удаление кук
Часть пользователей периодически чистят куки своих браузеров. При заходе на сайт система веб-аналитики проверяет наличие нужной куки и если её нет, то дает новую. По факту человек один и тот же, а кука новая и соответственно в статистику запишут 2 разных пользователей

6. Один пользователь использует несколько браузеров, устройств
Человек может посещать сайт с разных устройств или браузеров. Как и в примере с куками для счетчика веб-аналитики это 2 разных пользователя, хотя человек 1 и тот же.

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

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

9. Медленный сайт
Если ваш сайт грузится медленно, то есть часть пользователей, которые не готовы ждать долгой загрузки сайта и покидают сайт до того как загрузится страница, а также до того как счетчик отправит данные на сервер системы веб-аналитики.

10. SPA сайты
Есть специальные библиотеки на которых пишут сайты Single Page Application. У таких сайтов не происходит перезагрузки страницы.
Для того чтобы корректно отслеживать все страницы на таких сайтах нужно применять специальные настройки систем веб-аналитики

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

Ставь 🔥, если инфа полезная

Пишите ваши дополнения в комменты 👇

Вакансия продуктового аналитика в Альфу ❤️

Помогаю центру продуктовой аналитики найти клевых людей в команду

Требования

- Уверенное владение SQL и опыт работы с базами данных (Oracle/Postgres/MySQL, Google BigQuery, Hadoop, Vertica, SQL Server).

- Опыт работы с системами визуализации (Power BI, Tableau, Datalens, Superset, Google Data Studio, QlikView/QlikSense)

- Опыт построения автоматизированной отчетности: от сбора, хранения, подготовки данных до построения отчетов/дашбордов и проведения анализа данных.

- Владение Excel (сводные таблицы, формулы)

- Опыт работы с одной или несколькими системами аналитики: Appsflyer, Amplitude, Firebase, Mixpanel, Google Analytics, Яндекс.Метрика, AppMetrica или аналогами (не обязательно).

- Знание инструментов для автоматизации сбора, статистической обработки сырых данных (Python/R)

ЧЕМ ПРЕДСТОИТ ЗАНИМАТЬСЯ?
- Организовать и автоматизировать сбор данных для отчетности, объединить данные систем-источников и строить регулярную отчетность/дашборды по клиентской активности.

- Принимать участие в исследованиях эффективности коммуникаций и точек входа, путей пользователей при совершении операций, помогать командам в генерации гипотез и проведении экспериментов.

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

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

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

Писать сюда https://xn--r1a.website/FleurDeLysss

🔥Новичкам пламенный привет!

За вчерашний день из канала Job for Analysts & Data Scientists добавилось около 100 человек.

Предлагаю познакомиться. Расскажите кто вы, чем заинтересовал мой канал?

Старички, тоже могут присоединяться к беседе.

Начну с себя

✅ Я продуктовый аналитик в Альфа Банке. Развиваю направление АБ тестов на сайте банка.

✅ Много работал с системами веб-аналитики, руками настраивал трекинг событий, ecommerce и прочее.

✅ Участвовал в разработке нескольких систем сквозной аналитики на базе сырых данных систем веб-аналитики, рекламных систем и CRM.

✅ Проводил разные качественные и количественные исследования для поиска точек роста бизнеса.

✅ Когда-то давно руками делал маркетинговые стратегии, проектировал сайты, запускал рекламу. Помогал крупным российским компаниям выстроить системный интернет-маркетинг.

🔜 Провожу консультации. Карьерные консультации для аналитиков. Консультирую бизнес по вопросам аналитики и точек роста.

Как проверить корректность системы сплитования трафика для АБ тестов? 😵


1. Определите тестовые сценарии
Определите наиболее массовые и важные сценарии настроек АБ тестов и таргетингов. Например возьмите десктоп и мобилку и в каждом по 5 сценариев настройки.

Под сценарием настройки я имею в виду: долю пользователей попадающих в эксп, число вариантов теста, баланс выборок, таргетинги(гео, источники и прочее)

2. Выберите целевую метрику
При выборе метрик выбирайте такую метрику, чтобы единица рандомизации и единица анализа совпадали. Большинство сплит систем рандомизирует пользователей, значит нужно выбирать пользовательские метрики.

Если вы возьмете сессионные метрики, то велика вероятность поймать дисбаланс выборок(SRM) и множество ложных прокрасов FPR. По сессионным метрикам будет сложно оценить работу сплитовалки.

3. Запустите АА тесты и соберите данные
Какой-то формулы для расчета размера выборок для АА тестов я не знаю.

Руководствуйтесь 2 идеями. Выборки должны быть репрезентативны, т.е. в них должны попасть пользователи из разных источников с разными характеристиками, чтобы они отражали вашу ГС.

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

Как проверить корректность системы сплитования трафика для АБ тестов? Часть 2 😵

4. Оцените результаты АА тестов

4.1 Доля пользователей попавших в АА тест
Проверьте, что все пользователи, которые должны были попасть в АА тест попали в него. Например если в точке входа в эксперимент за неделю было 10000 пользователей, то все они должны иметь метку эксперимента

4.2 Корректность работы таргетингов
Проверьте, что в АА тест попадают только пользователи соответствующие таргетингу. Если вы запустили тест с Гео Москва, то в выборке пользователей попавших в эксп не должно быть пользователей из Твери.

4.3 Доля пользователей попавших в АА тест с первого раза
Проверьте, что пользователи, которые попали в АА тест получили вариант сразу при первом попадании в точку входа в эксперимент.

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

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

4.5 Баланс раскатки в соответствии с дизайном
Если вы заложили в эксперимента, что будете использовать для эксперимента 70% трафика, то важно чтобы система сплитования правильно деражала этот баланс.

4.6 Баланс веток АА теста в соответствии с дизайном
Здесь мы проверяем SRM (simple ratio mismatch) - несоответствие баланса выборок. Если мы заложили в настройки деление трафика 60/40%, то система сплитования должна выдавать очень близкий результат. Иначе результаты АБ тестов могут быть невалидными.

4.7 Баланс параметров внутри веток
Внутри выборок пользователи имеют разные параметры (гео, источники, браузеры и прочее). Если мы сплитуем 50%:50%, то в обоих вариантах доли этих параметров должны быть очень близки.

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

4.8 Число АА тестов со стат значимым результатом
Посмотрите в скольких из ваших АА тестов вы получили стат. значимое отличие метрик. Если вы запустили 10 АА тестов и например в 7 получили стат значимые отличия, то тут скорее всего есть проблемы сплитования. Если прокрасов нет или их 1-2, то такая ситуация может быть просто случайность.

4.9 Распределение p value
Распределение p value должно стремиться к равномерному. Как правило для того чтобы судить о распределении метрики нужно много наблюдений. Но даже если у вас есть всего 10 наблюдений, т.е. 10 АА тестов где вы считали p value, то вы ожидаете что какая -то часть будет иметь p-value близкое к 1, какая-то часть около 0,5, какая-то часть будет стремиться к 0. Если все p value сосредоточены только в нижнем или только в среднем или только в высоком диапазоне значений, то это тоже повод задуматься.

4.10 Оцените FPR на симуляциях АА тестов
Можно сгенерировать 10000 подвыборок из наших данных по эксперименту и провести искусственные АА тесты, чтобы понять корректно ли удерживается уровень ложно положительных срабатываний FPR. Мы ожидаем, что доля FPR на симуляциях АА тестов будет стремиться к уровню альфа, если выборки сформированы рандомно и не имеют серьезных дисбалансов.

4.11 Оцените распределение p-value полученное на симуляциях АА тестов
Здесь как и в пункте 3.9 нам нужно обратить внимание на форму распределения p value. Т.к. у нас есть много данных по симуляциям, то можно построить распределение. Если данные получены из корректного механизма рандомизации, то распределение p value будет стремиться к равномерному.

P.S.
Делитесь своими дополнениями к алгоритму проверки системы сплитования

🤖 В каких задачах ML пригодится аналитику?

Я не сторонник пихать ml в любую задачу, но для некоторых задач он полезен. Предлагаю сегодня поговорить о том для чего аналитику может понадобиться ML.

Я выделяю 2 направления ML.

ML как часть продукта. Например, какая-то рекомендательная система. Этим занимаются ML инженеры. ML как инструмент для решения задач аналитика. Поговорим, где ML может помочь аналитику.

1. Прогнозирование LTV для оценки ROMI
Если у вас продукт, который окупается не сразу, а через 6 месяцев, то возникает проблема с оценкой эффективности рекламы.

Деньги вы вкладываете сегодня, а посчитать отдачу сможете через 6 месяцев. Решение по рекламе нужно принимать сейчас, а не через 6 месяцев. Тут может помочь ML. Можно создать модель, которая будет прогнозировать LTV пользователя и на основе этой оценки посчитать ROMI.

2. Исследование пользователей(клиентов)
На основе имеющихся данных о пользователях можно создать кластеры. Кластеры - это группы пользователей, которые ML алгоритм посчитал похожими.

Например с помощью Retentioneering можно выделить группы юзеров на основе отличающегося поведения. Для каждой группы можно разработать отдельную стратегию коммуникации или внести какие-то изменения в продукт, чтобы поменять поведение.

3. Поиск кандидатов на прокси метрики для АБ тестов
Про прокси метрики мы говорили в отдельном посте На основе ML модели, которая предсказывает факт конверсии можно оценить какие фичи(действия пользователя) имеют большой вес в прогнозировании и на основе этого события разработать метрику и использовать в АБ.

4. Прогнозирование оттока
Пользователи перестают использовать продукт. Чтобы понять кто из пользователей может покинуть продукт создают ML модель прогнозирующую отток. Можно точечно работать с пользователями, если вы знаете что они скоро уйдут.

5. Создание искусственного контроля для квази экспериментов
Помимо АБ тестов есть такое понятие как квази эксперименты. Т.е. это такие методы оценки изменений, которые нарушают важные допущения АБ тестов. Обычно квази эксперименты используют когда проведение АБ недоступно по каким-то причинам.

Например, вы выкатываете в прод. какую-то новую фичу без АБ теста, а через некоторое время вам нужно оценить эффект от неё. Можно сравнить исторические периоды, но это не всегда релевантно и разные периоды времени несут разные внешние эффекты.

Один из подходов в таком случае - это построение прогнозной оценки на основе ML модели для ситуации, что в продукт не вносили никаких изменений. Т.е. по сути мы генерируем некоторую искусственную оценку, а какую бы целевую метрику мы получили если бы не было никаких изменений.

После мы сравниваем эту искусственную оценку с реальными данными, которые были получены после внедрения фичи и пытаемся определить есть ли стат значимые отличия между оценкой и реальностью.

6. Оценка вклада рекламных каналов в достижение конверсии, атрибуция на основе ml
Одна из вечных (холивраных) тем среди маркетинговых аналитиков - выбор модели атрибуции для оценки эффективности рекламных источников. Здесь тоже можно попробовать использовать разные ML штуки для того, чтобы оценить веса от вклада в конверсию для каждого из рекламных каналов.

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

Например, в продукте что-то сломали и выручка упала, а мы думаем что это сезонность. Тут тоже можно использовать ML алгоритмы, строить прогнозную метрику и сравнивать её с фактической.

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