Данные из Google Analytics можно экспортировать в BigQuery. Сам экспорт — стандартная функция GA и ничего не стоит; тарификация идёт по нормам BigQuery: за количество просканированных байт.

Разбирался сегодня со структурой этих данных: колонок всего 22, но их них 10 со вложенной структурой (если всё разложить, будет 176!). Чтобы добраться до нужных значений внутри, приходится прибегать к ухищрениям типа UNNEST. И всё не мог понять зачем это нужно, пока не нашёл гайд как сделать из этого экспорта плоский формат.

Оказывается, изначальная задумка вложенного формата в том, чтобы в одну таблицу «запихнуть» как бы четыре нормализованные… Когда стал ясен смысл, то и на данные смотреть теперь проще.

А вот делать плоские таблицы всё таки не стоит: у меня из одной таблицы на 30Гб получилось три на 30, 60, 30Гб ¯\_(ツ)_/¯ Но хоть можно посмотреть все имеющиеся колонки в одном месте.

https://www.ga4bigquery.com/tutorial-how-to-flatten-the-ga4-bigquery-export-schema-for-relational-databases-using-unnest/

комментарии в канале у Красинского — золото

Да, это хорошая идея вообще, потихоничку описываем.

К сожалению, это не маленький список регшений и в формате комментариев к посту я не знаю как его уложить.

Ключевые метрики описывают свои классы проблем, например, низкая конверсия – описывает проблемы продажи – то как плохо мы продаем и причины этого.

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

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

Мы начали с конверсии. А есть и другие ключевые метрики CPUser, Users, Leads, Buyers, AvPrice, AvPaymentCount, Margin, COGS, Activation, Retention, еще лучше DailyUsage, виральность и расчетные AMPPU, AMPU и т.д.

Их соотношения дают классы проблем: в маркетинге, продажах в диджитал части (сайт, приложение), проблемы в отделе/команде продаж (если есть), в операционных процессах и издержках, в ценообразовании и сегментации по цене, в цикле сделки и CJM сделки и процессе продаж, в монетизации и т.д.

В каждом классе проблем свои вопросы:
- Почему мы делаем плановое число продаж?
- проблема у новых пользователей или у старых?
- У нас низкая конверсия у новых?
- низкая конверсия на посадочных?
- на шагах воронки на сайте? (или в приложении?)
- низкая конверсия в отделе продаж?
- Какие есть блокеры, что мешают пользователям купить?
- Какие возражения пользователей или вопросы необходимые для покупки мы не отрабатываем?
- какие воронки, события, шаги ведут к продаже, а какие мешают? Какие события триггеры, а какие анти-триггеры?
- есть ли ассиметрия по устройствам? по городам, регионам? доменам? и почему?

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

Продолжаю разбираться с вложенными данными в BigQuery — читаю наглядное пояснение (только посмотрите на эти гифки!) как и зачем применять к ним UNNEST:

> The problem here is that event_params is essentially an array (actually in BigQuery parlance it’s a “repeated record”, but you can think of it as an array). …

This is where the UNNEST function comes in. It basically lets you take elements in an array and expand each one of these individual elements. You can then join your original row against each unnested element to add them to your table.


автор плавно подводит к выводу, что UNNEST — это как CROSS JOIN, только запись короче (потому что так looks cooler):

> You’ll find that in practice, though, most BigQuery developers will replace the CROSS JOIN with a comma … It still does the same thing, it just looks cooler. (BigQuery developers are all about looking cool.)

https://medium.com/firebase-developers/using-the-unnest-function-in-bigquery-to-analyze-event-parameters-in-analytics-fb828f890b42

Не «если», а «когда»

когда только начинал, было страшно браться за работу — ведь любая работа делалась впервые. Поднять Постгрес на голой Убунте? → «Ну не знаю, смогу ли…»

сейчас с этим проще — во-первых, уже много чего успел поделать, а во-вторых, понял, что всегда будут попадаться задачи, которые придётся делать первый раз. И это нормально! Типа «поднять для проекта инфру с нуля в облаке на кубере и настроить туда доступ облачному BI» — пфф! легко!
(на самом деле совсем не легко, но опустим это))

навеяно:
⁃ известный архитектор тоже не знает как он будет строить заказанный у него небоскрёб (но, конечно, предусмотрительно не говорит об это клиенту) (прочитал у Бабаевой https://news.1rj.ru/str/changemarketing/718)
⁃ Артемий Лебедев старается брать проекты, где как минимум 50% придется делать впервые (типа зачем делать одно и тоже?)

Получается, там где джун не уверен сможет ли, миддл просто называет срок.

(математики в чате могут сказать, что джун тоже «называет срок» — ∞)

выводы из того что надо делать новые проекта

по-любому в работе встретиться новая неведомая хрень — к всему не подготовишься, но важно уметь работать в режиме неопределённости:

1. надо уметь искать ответы — да, пресловутый гугл и стэковерфлоу. Лучше сразу на английском: там по определению больше информации и проще формулировать (язык-то устроен проще).

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

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

Тут же в тему буду профильные сообщества и чатики в телеграме: там все на одной волне и встречаются с одинаковыми проблемами на своём пути. Вот как раз в чате про дата инжиниринг собрали известные:
- @deordie_chat
- @dataeng_chat
- @hadoopusers
- @moscowspark

и ещё в Слаке есть сообщество проекта DataLearn от Дмитрия Аношина (@rockyourdata) и команды — надо зарегистрироваться на сайте и пришлют ссылку.

Recommended Reading, Listening, Watching from Meltano Team

подборка дата- рассылок, блогов, ресурсов и комьюнити

https://meltano.com/handbook/resources/

Подкаст с Лёшей Никушиным

https://news.1rj.ru/str/internetanalytics/3641

Алексей известен как автор канала Интернет-аналитика ^^ и основатель конференции Матемаркетинг.

Понравился подход к делу:

… новая работа — «знакомьтесь, это Лёша, лучший аналитик страны… Посмотрим что ты умеешь». В пятницу утром получил задание — к понедельнику сделать отчёт по всем диджитал каналам трафика в компании. Руками такой отчёт делать — не то что выходных, месяца не хватит.

И дальше череда событий:
тут же вечером — он проходит курс по программированию на Пайтоне на Степике

утром в субботу — у него созвон с Ильёй Красинским, чтобы тот объяснил ему куда смотреть в Гугл Аналитиксе

днём в субботу — такой же созвон с человеком из Яндекс Метрики — рассказ как работае и помогает в настройке коннектора к АПИ через Пайтон.

в воскресение — созвон с ребятами из канал про эксель, чтобы помогли всё правильно настроить в таблице и собрать отчёт в одно.

в понедельник — готовый отчёт у начальства; «не без недочётов, конечно, но для первого подхода подойдёт».

-----

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

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

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

Слушать подкаст в iTunes и Overcast

реальный мир — единственный источник практических знаний

«Как стать X?» или «Что качать, чтобы прокачаться в Y?»

можно взять гигантский роадмап и пойти по порядку — через год будет результат (если дойдёшь и не умрёшь с голоду).

мне нравится подход из мира стартапов: любая идея — теоретическая туфта, пока не пройдёт испытание на реальных клиентах. Именно конечные клиенты — единственный источник реальных знаний.

если хочешь стать инженером данных — надо найти вакансии и посмотреть что там требуется.

Хоп! и уже первое открытие — везде требуются разные наборы навыков, потому что (сюрприз!) во всех компаниях свой стэк инструментов и свои обычаи. И это всё со временем меняется (быстрее, чем программы курсов).

Следующий шаг — пройти дцать собеседований:
⁃ во-первых, придётся выбрать в какие компании идти: уже надо подумать куда хочется.
⁃ во-вторых, может придётся поделать тестовые — тоже отличный опыт; лучше синтетических задач из интернетов.
⁃ в-третьих, на собеседовании будет технический специалист не ниже миддла, который уже работает по этой специальности — вот он-то и расскажет ЧТО ИМЕННО НУЖНО на эту конкретную должность в этой конкретной компании.
⁃ PROFIT!

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

для примера — вот красивый роадмап инженера данных. Интересно, сколько нужно лет, чтобы это всё выучить попробовать?

источник

когда пишу в SQL запросах GROUP BY 1, 2 вместо полного наименования колонок, меня всегда тревожила мысль, что я халавлю и недоделываю НОРМАЛЬНЫЙ КОД.

Прочитал, что в dbt делают так же и успокоился: писать через «1» проще и понятнее (заскринил пример ^). Если что, буду показывать эту заметку 🌚


So why do I still group by 1? Well, there's a few reasons:
…
- 1 is a single character (and I'm lazy, OK?!).


https://blog.getdbt.com/write-better-sql-a-defense-of-group-by-1/

эмпирически-оптимальное соотноешение: 2-3 дата инженеров на одного мл-инженера. Если дата инженеров меньше, то, получается, их работу делают мл-инженеры [а могли бы модели делать что-нибудь своё МЛ-ное].

https://twitter.com/dsunderhood/status/1420769858053103617

когда 2 года назад выбирал профессию, ориентировался именно на это соотношение. Кажется, не прогадал)

https://sashamikhailov.ru/blog/all/data-analyst-and-data-scientist/

Уровни аналитиков

Женя Козлов описал опыт Яндекса по формализации грейдов для аналитиков. Написано очень чётко, можно использовать как шпаргалку для команд или личного развития.

Понравилось чёткое разделение каждого грейда в разрезе подхода к задачам (мелко разжованные а в конце просто глобальное направление).

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

Ниже надёргал абзацев из каждого раздела, рекомендую почитать целиком:

----

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


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


1. Аналитик-стажер (trainee data analyst)

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


2. Младший аналитик (junior data analyst)

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

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


3. Аналитик 1 (Middle data analyst 1 step)

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

Аналитик 1 всё чаще и чаще докапывается до сути идей и вопросов, с которыми к нему пришли. Думает про задачи в терминах решений, которые будут приняты, а не в терминах работы с данными.


4. Аналитик 2 (Middle data analyst – 2 step)

Аналитик 2 — автономный аналитический юнит. Наносит пользу бизнесу. Это более опытная версия предыдущего грейда, но есть и отличия, которые являются качественными, существенными: это понимание контекста и выросший уровень рефлексии.

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

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


5. Старший аналитик (Senior data analyst)

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


6. Ведущий аналитик (Lead data analyst)

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


https://gopractice.ru/data_analysts_levels/

Два подкаста про игры с точки зрения машинного обучения

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

Особенно понравилась вставка про Доту с интернешнала с живыми криками комментатора. Фанфакт: перед матчем с Денди машина тренировалась 2500 лет игрового времени.

Слушать в iTunes и Overcast


Второй подкаст — уже серьёзный разговор с инженером из Google Deepmind о том что там под капотом у этого процесса и где эти навыки можно применить в реальном мире.

Ссылки на подкаст в посте автора

Не Спарком единым

за последние полгода в Эпохе поучаствовал в проектах по построению четырёх DWH для наших клиентов: 3 на BigQuery и ещё один на AWS Athena. Всё как надо — изучили источники, настроили пайплайны, собрали данные в одном месте, нарезали на слои, вывели на дашборды. Клиенты довольны.

При этом задействовано Спарка в проектах: ноль. Обошлись как-то и без Кафки с Хадупом.

Иногда кажется, что это какая-то ненастоящая дата инженерия. Но вот наш СТО скинул статью и я подуспокоился: ребята делают такие же DWH и так же обходятся без инструментов бигдаты.

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

Строим аналитическое хранилище данных с готовыми модулями ML на Google BigQuery: просто, быстро, доступно

Ищем дата инженеров в агентсво Epoch8

Эпоха — агенство заказной разработки, мы помогаем клиентам работать с их данными: понимать что было (аналитика) и что будет (ML). Сейчас в штате 20 человек — до бюрократии ещё не доросли, фаундеры в прямой доступности, каждый может влиять на курс и политику компании.

В клиентах как большие е-коммерсы типа Leroy Merlin и Пятёрочки, так и стартапы: например, BelkaCar или Brickit.

Ищем дата инженеров в отдел аналитики. Обычно инженер сопровождает проект от начала и до конца:
⁃ приходиться разбираться с источниками данных у клиентов;
⁃ поднимать и поддерживать хранилища данных (DWH);
⁃ проектировать автономные пайплайны;
⁃ придумывать архитектуру аналитических сущностей и слоёв данных;
⁃ делать actionable дашборды, чтобы бизнес-пользователи клиентов могли принимать чёткие и взвешенные решения.

Кажется, сейчас такое называют Analytics Engineer и вроде есть даже какой-то хайп вокруг этого направления. Если встречали такое, буду рад обсудить @sashamikhailov

Порог входа относительно низкий: работать надо будет в команде с опытными товарищами. В любом случае ожидаем определённого уровня автономности — нужен какой-то опыт работы с данными (SQL, Python).

Нужные навыки:
⁃ Любовь к людям и умение общаться — придёться общаться с клиентами напрямую, снимать требования и презентовать результаты работы.
⁃ SQL — джойны, агрегации, оконные функции.
⁃ Python — писать ELT пайплайны так, чтобы ничего не взорвалось.
⁃ Кроме кода инженеры ещё пишут документацию: на сам код, на данные, на архитектуру решения.

Стэк технологий на каждом проекте свой, зависит от ограничений клиента; но есть наиболее частые решения:
⁃ DWH на BigQuery;
⁃ оркестрация на Prefect (на старых проектах — Airflow);
⁃ модели данных в dbt;
⁃ дашборды на Metabase.


Почему мне нравится работа в агентстве:
⁃ быстрый технический рост: до Эпохи я собирал один DWH три-четыре месяца, в Эпохе — 4 за полдгода;
⁃ большая насмотренность на проектах: приходят разные большие е-коммерсы и видишь что там под капотом;
⁃ вокруг коллеги той же профессии — а не единственный аналитик в отделе маркетинга;
⁃ на каждом следующем проекте замечаешь всё больше общих закономерностей — «набиваешь руку» поднимать DWH с нуля;
⁃ доступны все проекты агентства — всегда есть где подсмотреть оптимальное решение или спросить совета.
⁃ не зря год работы в заказной разработки считается за два в продуктовой;
⁃ рядом отдел МЛ: можно подглядывать, смотреть на насущные проблемы или спросить совета.

Условия:
⁃ вилки: 80-100К для джунов, 100-150К для миддлов. Зависит от опыта и навыков.
⁃ полная удалёнка. Если в Москве, то можно приходить на ежемесячные встречи и прочие офлайн-сборища.
⁃ раз в полгода общие вылазки (уже были Сочи, Алтай, Байкал) — надо же куда-то тратить освободившийся бюджет на офис :-)


Если есть вопросы и предложения — всегда рад пообщаться @sashamikhailov

Если вакансия заинтересовала, надо заполнить анкету в Airtable. В ответ вышлем небольшое тестовое на SQL. После тестового приглашаем на собеседование (возможно, даже там буду я).


====

Планирую вакансию пошерить дальше, если знаете что можно было добавить, уточнить или исправить — пишите. Очень поможете :)

За одну минуту о том, зачем нужны дата инженеры для машинного обучения. С ГИФКАМИ!

https://www.youtube.com/watch?v=efFuNYqg-YU&list=PLRKtJ4IpxJpDxl0NTvNYQWKCYzHNuy2xG

у ребят из dbt появился свой подкаст, назвали актуальненько — Analtycs Engineering.

В первом эпизоде с Robert Chang из Airbnb, обсудили проблему управления метриками в компании. В Aribnb таких 12000 и чтобы как-то управляться они сделали систему Minerva как единый источник правды для всех метрик.

https://podcasts.apple.com/us/podcast/the-analytics-engineering-podcast/id1574755368

Data Engineering на Яндекс.Практикуме

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

Теперь можно получить профильный курс и выпускников с релевантными навыками (я не как я — учился на аналитика, чтобы потом изучать инжиниринг данных уже на реальном проекте ¯\_(ツ)_/¯ )

Сразу о главном: 80 000₽ и полгода обучения.

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

1. Знакомство с ETL / ELT, DWH / Data Lake, REST API → PostgreSQL
2. Продвинутый SQL: хранимые, тригеры, шардирование (!) и партиционирование
3. Разные базы данных: колоночные, No-SQL, графовые и key-value
4. Прочие источники данных: СУБД, файлики (Excel, хе-хе), API
5. Оркестрация: от крона до Airflow
6. Продвинутые пайплайны: параллельная обработка, Kafka / RabbitMQ / Celery.
7. Инфраструктура: Docker и Ansible.
8. Деплой на кластер: Kubernetes, Helm
9. Архитектура DWH: звезда, снежинка, Data Vault и Anchor Modeling.
10. BIG DATA: CAP теорема, Hadoop, MapReduce
11. BIG DATA часть 2: Spark, RDD (погуглил, спасибо!), Spark SQL
12. Облака: AWS, Яндекс, GCP, Azure, DigitalOcean
13. Безопасность: персданнные, аутентификация и авторизация, секреты
14. Логи и мониторинг: ELK, Grafana
15. Дипломный проект: всё серьёзно с CI/CD и data quality