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

Город засыпает – просыпается Apple

Два года назад Apple выпустила обновление iOS 14.5, резко ограничив возможности рекламодателей и разработчиков в доступе к данным (персональным идентификаторам) пользователей. Писал об этом тут. Речь об ограничении на доступ к IDFA и насильном уменьшении срока жизни third-party cookies в Safari до 7 дней.

Для мобильного маркетинга это стало ударом в спину – точность таргетинга и эффективность кампаний упали, однако Apple от этого только выиграла – уже спустя неделю после выпуска новой iOS были опубликованы новые форматы Search Ads от Apple с тонкими возможностями трекинга и таргетинга.

Это был ход в духе российских ОПГ из 90-х. Наглый, массивный и эффективный – уже спустя полгода после анонса Apple отчиталась о трехкратном росте выручки Search Ads. Рекламодатели при этом продолжали плакать и колоться.

Однако на это дело не кончилось. Буквально недавно евангелист веб-аналитики Simo Ahava и Дмитрий Голубовский из stape.io (ссылка) обнаружили что Safari 16.4 ограничивает срок жизни некоторых first-party cookies до 7 дней.

Чтоооо???

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

1. Если сервер, устанавливающий cookie-файл, имеет отношение к CNAME-записи, связанной с third-party-доменом для текущего сайта.

2. Если сервер, устанавливающий cookie-файл, настроен с A/AAAA-записями, которые предполагают IP-адрес, у которого первая половина отличается от IP-адреса сервера самого веб-сайта.

За этими техническими тонкостями скрывается главное – Apple самостоятельно ограничивает срок жизни для cookie-файлов с first-party-контекстом. То есть тех, которые могут быть важны для адекватной работы веб-сайта и предоставления нормального пользовательского опыта.

Второй вывод – такое нововведение сильно подрывает эффективность прокси для отслеживания трафика в Safari, впервую очередь GTM Server Side.

Хорошая новость – есть обходной (и видимо в перспективе единственно верный) путь для управления пользовательскими идентификаторами – проектировать собственный Data Lake для хранения и обращения к критически важным cookie-файлам.

Статья с пруфом от Simo Ahava

Пример подобной реализации на примере Firestore / Stape.io описан здесь

Тут можно прочесть мою статью о GTM Server Side для начинающих

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

#safari #privacy #данные #аналитика #модельатрибуции

@marketing_analysis

Смотреть до конца

Очень крутой и смешной трейлер-пародия на закат Universal Analytics. It's the sunset.

https://youtu.be/_nAtC2Ps_x4

#видео #ga4 #universalanalytics #модельатрибуции

@marketing_analysis

Опубликовал статью с честным обзором косяков четвертой версии Google Analytics. Их оказалось много.
https://vc.ru/marketing/707341-sem-smertnyh-grehov-ga4

Дорогая Google Analytics 4

Сразу после моей статьи о смертных грехах GA4 похожий материал опубликовал в своем блоге Simo Ahava. У статьи многобещающее название Dear Google Analytics 4.

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

Огромное количество неотвеченных веток на Stackoverflow, LinkedIn или Measure Slack – грустная, но увы привычная картина для пользователей GA4. В итоге большинство ответов на вопросы рождается не в качестве фидбека от Google, а после самостоятельного рисеча «кулибиных»-одиночек.

Полностью статью можно прочесть здесь, а тут есть пример того как работает комьюнити – табличка с подборкой багов GA4 от Tag Manager Italia.

#simoahava #ga4 #universalanalytics #модельатрибуции

@marketing_analysis

Оценка инкрементальности в маркетинге без сплита на контрольную и тестовую группы

Простое и лаконичное решение для оценки инкрементальности (добавленной ценности) в маркетинге предложила Emily Kaegi. Суть идеи – моделирование данных контрольной группы с помощью алгоритмов машинного обучения с предсказанием на временных рядах.

Допустим, вы хотите оценить вклад кампании, но не имеете возможности разбить трафик на группы. В этом случае можете смоделировать показатели выручки / конверсий на основе исторических данных (подойдет библиотека Prophet от Meta) и затем сопоставить с фактическими данными. Разница и будет оценочным вкладом кампании.

Метод, как и многие предикитвные механики, имеет ряд ограничений. Подробнее можно почитать в статье Emily Kaegi по ссылке.

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

@marketing_analysis