Начнём с того, что конференция проходила на площадке под названием «Домна». Это очень крутое место в самом центре города. Ребята из фонда поддержки предпринимательства переделали старый особняк, вынесли оттуда все те мелкие лавки, которыми кишела улица Вайнера, и сделали там арт-пространство для погружения молодёжи в творческие профессии.

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

Так вот, в здании по сути есть всё для разработки дизайна мерча: нужные принтеры, вышивальное оборудование и даже фотостудия, чтобы это всё потом отснять. И каждый может испытать это на своём опыте прямо там. В общем, очень круто, советую к посещению.

Но вернёмся к конференции. Она была посвящена развитию агентств. Там выступали основатели рейтингов Tagline и Ruward (Алексей Раменский и Андрей Терехов).

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

Ну а затем мы все пошли в Шалом на афтепати, где до 2 ночи… вы не поверите… обсуждали IT.

Если вернуться к теме поста, то какая же польза от конференций и зачем туда ходить?

1. Нетворкинг. Я познакомился с кучей классных ребят как с нашего местного рынка, так и со всей России. Это было классно.
2. Идеи. В процессе общения я услышал немало классных концептов, и уже даже появилась парочка идей, как переложить подход к сфере, на которой мы специализируемся.
3. Тренды. Мне было интересно сверить свое ощущение рынка с коллегами, и я активно расспрашивал про их ощущения относительно востребованности аналитики в разных сферах и нишах. Мысли были совершенно разные, но свои гипотезы я «обстучал».
4. Настроение. Я отлично переключился и вдохновился на развитие того направления, которым занимаюсь.

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

(Смотрите комментарии к посту — там опубликовал все полезные ссылки)

Сегодня 1 июля 2023 — официальная день закрытия GA3 Universal Analytics ✞. Он должен перестать работать и весь мир принудительно перейдет на GA4. (Хотя фактически мы видим, что GA3 принимает события — у Гугла всегда официально и фактически расходятся).

Удивительное ощущение 🤦‍♀️, понимать как мало людей в мире осознает, что на самом деле происходит: GA4 выглядит похоже на GA3, а под капотом все по другому — хотя бы потому, что это ужасно сырой, бажный релиз — которым придется и нужно научится пользоваться.

Так как через нашу команду проходят 1000+ кейсов и терабайты аналитических данных, то волей неволей накапливается экспертиза. В свое время, на митапе аналитиков я сделал популярное выступление: 💣 Как на самом деле работает GA3 Universal Analytics — где рассказал про проблемы сессионной аналитике (все ссылки, их много смотрите в 1-м комментарии к этому посту).

Про GA4 делать такое глубокое видео еще рано: нужно больше кейсов и экспертизы. Но в команде настояли, чтобы я поделился коротким видео про особенности GA4 известные на текущий момент, записанное для клиентов Рика (если вам про Рик не интересно, там не много — смело проматывайте).

Плюсы нового GA4:

1. Все еще бесплатная аналитика (ждем анонса платной Яндекс.Метрики 🍿)

2. Наконец-то нормальная событийная модель с параметрами. Привет Яндекс.Метрике, где пока нет нормальных событий от слова совсем.

3. Наконец-то user-based конверсии 🔥 которые считаются правильно — как же давно все этого ждали . Сессии еще остались внутри, но теперь не так сильно ломают расчет большинства метрик и атрибуции по каналам.

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

Минусы:

1. Больше нет точных цифр в интерфейсе — все считается примерно 😱 и это принципиальная позиция Гугла — им слишком дорого все точно обсчитывать. Смотрите в моем видео что такое алгоритм HyperLogLog++, Treshholding и high cardinality limit.

2. Цифры в обычных отчетах, кастомных отчетах (Exploration), GA4 API и Big Query расходятся — и это официальная и идеологическая позиция Гугла — теперь точные данные только в BigQuery, но не в интерфейсе. 🤦‍♀️

3. Интерфейс еще не поддерживает возможности движка: все самое важное перенесли в параметры события, но в интерфейсе фильтр по этим полям еще не добавили. Используйте более сложные кастомные отчеты (Exploration).

4. Релиз ужасно сырой, большая часть API официально! еще в альфа-версии и бета-версии.

5. Чтобы получить сырые данные не получится использовать API, только BigQuery — это был бы хорошо, если бы не сложность BigQuery и сырость: нужно настраивать мониторинг! 🥵 чтобы он не терял дни! не переполнсялся событиями, не удалял бы дни старше 61+ дня от сегодня и не стоил дорого!


6. Стриминг данных из GA4 в BigQuery содержит десяток дефектов 🤦‍♀️:
- пустые строки,
- not set каналы с продажами,
- каналы, лендинги и устроства названные Other
- google ads в сырых данных записан и перемешивается с google organic
- обрезание параметров, например, gclid если в событии > 250 символов и обрезание параметра события, если в нем > 100 символов — обрезаются обычно utm-метки или gclid — а значит сложнее связать событие с каналом привлечения и из сырых данных, без доп. алгоритмов

7. Из-за этих проблем и ограничений, команда Рика сделала колоссальную работу: нам пришлось переделать движек, и увеличить число мониторингов и проверок в несколько раз — чтобы промышленным образом сверять метрики по срезам и локализовывать и исправлять сырые данные GA, чтобы получить корректные цифры по всем срезам.

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

Так что всем нам предстоит веселый 2023 🤣. Добро пожаловать. 🎬 https://youtu.be/geSQTV6EEPw

(Все полезные ссылки в комментах)

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

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

Начал я с модулей посвященных Apache Airflow c курса Karpov.Courses для инженеров данных. Понял что ничего не понял. (Что должен был понять условный джун, кроме представления об инструменте категорически непонятно).

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

Пошел, скачал whitepaper на 100+ страниц про "Airflow для чайников".

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

А заодно и Obsidian протестировал, выбрал его как замену Notion для личных конспектов.

А ниже можно узнать про какой дашборд речь

На прошлой неделе Яндекс.Метрика выпустила очень нужное обновление – возможность более гибкого управления доступами к данным счетчика.

Именно о таком функционале я просил саппорт за два месяца до этого в ходе своего обращения. Тогда в одном из клиентских счетчиков Яндекс Метрики пропали сразу 4 важных для нас цели.

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

Что касается восстановления удаленных целей – оказывается такая возможность в метрике есть. Решается обращением в поддержку и указанием целей которые нужно восстановить. Я знал их идентификаторы, поэтому объяснить какие цели необходимо восстановить было не сложно.

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

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

В данном случае от потери данных нас спасла архитектура счетчиков – сайт состоит из нескольких доменов, на каждом стоит свой Google Tag Manager, в нем счетчик Метрики для этого домена, и в дополнение к нему – общий счетчик, который собирает данные со всех доменов. Во всех цели настроены по единому принципу.

Кстати, из исторических данных Logs API идентификаторы удаленных целей тоже пропали и появились только после восстановления целей в интерфейсе.

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

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

В продолжение предыдущего поста порассуждаю про доступы к аккаунту Яндекс.Метрики и как с ними быть.

В работе я часто встречаю счетчики, доступ к которым есть у 20-30 аккаунтов, обычно не менее половины имеют права на редактирование, а значит:

– имеют доступ ко всем данным на счетчике;
– могут вносить коррективы в то, как данные собираются (добавлять и удалять цели или фильтры);
– могут использовать данные счетчика в своих целях;

Как бы я подходил к организации структуры доступов:

1. Заводить счетчик с какого-то мастер-аккаунта, к которому будет подключена двухфакторная аутентификация и гарантированно будет возможность восстановить доступ;
2. Стараться держать минимум аккаунтов с доступом на редактирование, желательно чтобы это был владелец счетчика и подрядчик по аналитике, который обычно понимает ценность точности собираемых данных и стоимость ошибок;
3. Остальным выдавать права только и на просмотр, либо новую роль аналитика, но я считаю что у процесса должен быть owner который понимает как устроена аналитика, ведет документацию и т.д, поэтому новой ролью «аналитик» я бы тоже не разбрасывался;
4. Стоит подписывать кому принадлежит аккаунт в комментариях, чтобы легко было определить кто есть кто, просто по логину это зачастую сделать не удается;
5. С определенной частотой проводить аудит доступов, отзывать доступы потерявшие актуальность (перестали работать с подрядчиком, выдавали доступ агентству для тендера и т.д).

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

Тёма Ляпунов заморочился, вынес все мозги Матемаркетингу и смог достать мне эту футболку на день рождения, несмотря на то что до конференции оставалось еще полгода!

Спасибо, Тёма, ее на всех конференциях теперь отмечают!