📌 Оконки LEAD и LAG

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

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

Смысл этих функций в притягивании соседа ДО или соседа ПОСЛЕ.

В общем виде выглядит как и любая другая оконка:

lag(some_col) over(partition by some_id order by some_dt)

Т.е. “внутри каждого потока some_id отсортируй строки по some_dt и достань мне предыдущее значение столбца some_col”.

Как и любую другую оконку можно засунуть эту конструкцию прямиком в select, в условие case или where, а при особом желании даже в join можно затянуть.

А что по примерам использования, когда полезно?

🟡При анализе пользовательских путей, если нужно достать название страницы / экрана, который предшествовал заданному. Например для поиска ключевых точек типа откуда юзеры чаще всего попадают на страницу товара;

🟡При осмотре каких-то метрик на текущий момент, чтобы быстро сравнить с предыдущим периодом и показать разницу, растёт или падает. Такое чаще практикуется в репортах, когда нужна одна конкретная цифра “на сейчас” и стрелка вверх-вниз;

🟡При анализе оттока, чтобы быстро посчитать разницу в количестве дней от текущей даты и последней датой активности юзера. Хотя тут и есть более ходовой вариант через max(date), тем не менее юзабельно;

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

#собесы

Спёр в рабочем слаке) Ох, если бы оно всё было так просто 😄

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

А пока гоу накидаем своих рабочих плейлистов 🙂

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

🎧 ностальгический (if u know u know) эмбиент на музыку Кая Розенкранца: https://www.youtube.com/watch?v=dJEngIaeEso&ab_channel=CraftofAmbience

🎧 просто 10 часов дождя с грозой 🙂 https://www.youtube.com/watch?v=l6fyiqeytaA&ab_channel=RainSoundNatural

Если думать не надо, то тут по настроению, разброс большой — от меланхоличных In Extremo и Corvus Corax (тут нужен мем про весьма специфичные вкусы), до драйвовых Talco или Goldfinger ✌️

📌 Про мой самый странный опыт АБ-тестов

Астрологи объявили неделю кулсторей 🍿

Как-то я работал в одной маленькой, но гордой (и прибыльной) компании, которая создавала инструмент для упрощение жизни маркетологов. Штат был человек 20 всего, включая офис-менеджера и ребят из поддержки.

Проводили мы там, значит, один забавный АБ-тест.

🤌 Суть такова мы проанализировали страницу с выбором тарифа. На этой странице располагалось четыре карточки тарифов, слева-направо от самого дешёвого к самому элитному. Изучили распределение покупок и увидели, что с огромным отрывом юзеры выбирают второй слева тариф. Естественно, стало интересно, что же там такое есть, что покрывает все запросы пользователей.

Начали изучать список плюшек, доступных на разных тарифах, но как не пытались найти эту киллфичу на втором тарифе — логически ничего не вырисовывалось. Все предлагаемые штуки были ну… обычными. Цена между 1-2-3 тоже не была какая-то разрывная. Почему второй, а не третий? Загадка дыры 🧐

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

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

И что бы вы думали? В поведении юзеров ничего не изменилось. Они как брали вторую карточку слева, так и продолжили её брать. Только теперь это был третий по цене тариф 🙂

Магическое место сработало, мы заработали на тестовом варианте раза в 2 больше денег, p-value улетел в ноль, никакие прочие метрики не пострадали. Тест был супер успешным.

На радостях мы с продактом пришли к СЕО (в нашей маленькой компании он был финальным лицом, принимающим такие решения) чтобы получить добро на раскатку тестового варианта, иии… нас развернули по причине: “да блин… похоже на какое-то НЛП… как-то стрёмно так людей обманывать”.

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

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

А в тусовом чатике этой команды я состою до сих пор, всегда в сердечке 🙂

#кулстори

📌 Перестановочный тест

Здраво, давненько я тут не появлялся, надо исправляться 🙂

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

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

Порядок действий такой:

🔵Сливаем все данные в одну кучу;

🔵Случайным образом достаём выборку того же размера что и группа A (без возвращения);

🔵 Из оставшихся данных случайным образом достаём выборку размера группы B;

🔵Тоже самое для групп C, D и т.д., если они есть;

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

🔵Повторяем эту процедуру множество раз для получения перестановочного распределения статистики;

🔵Дальше определяем долю перестановочных статистик, которые превышают наблюдаемую статистику. Это и будет p-value теста.

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

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

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

А ещё его периодически берут для сравнения несуществующих одновременно групп (как в классическом АБ), например, им иногда сравнивают периоды до и после какого-то события.

p.s. Как дела-то вообще? 🙂

Вообще не про аналитику, но фан-факт про вероятности.

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

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

Там в целом интересно, но самый сок в конце, когда он объяснял это на примере:

➡️ Представьте, вы решили пойти пешком в кругосветку по экватору.

➡️ Но идти вы будете не обычным шагом, а очень мелким, каждый шаг будет в 4.2 микрона (расстояние, равное толщине листа бумаги для принтера вы пройдёте за 23 шага).

➡️ На каждом шагу вы будете останавливаться и перемешивать колоду 1000 раз в секунду на протяжении срока существования Земли (4,5 млрд лет).

➡️ Потом ещё один микро-шаг, снова остановка и так далее, пока не пройдёте весь путь.

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

#funfact для пятницы 🙂

📌 Как решать аналитические задачи

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

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

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

Я стараюсь декомпозировать задачу с конца и двигаюсь к началу.

1️⃣ Всё начинается с этапа вопросов заказчику — зачем это исследование нужно, как его результаты будут использоваться, а что если ожидания не оправдаются и т.д. Твоя задача попытаться понять суть исследования, как так получилось что именно текущая постановка задачи отвечает на изначальный вопрос. Если логика не ломается и постановка норм, то переходим к следующему шагу.

2️⃣ Подумай, какой метод анализа лучше всего ответит на вопрос, какой график лучше опишет происходящее (не игнорируй графики, это всё ещё лучший способ представления данных). Отвечает ли твой анализ на вопрос задачи? Можно ли сделать выводы?

3️⃣ Когда с методом анализа определились, попробуй представить какая таблица тебе нужна будет на вход. Если это, например, модель, то какие параметры она требует, в каком формате и т.д. Это ключевой пункт, удели внимание и порисуй в блокнотике.

4️⃣ Когда ты понимаешь что хочешь получить, откатывайся ещё на шаг назад, к сырым данным. Теперь тебе нужно подумать как из потока хаоса собрать то, что тебе нужно. Вполне возможно, каких-то данных будет не хватать. Оцени, критично ли это, сработает ли модель без них или нужно блокировать задачу и дособирать данные.

5️⃣ Если логика запроса пока не укладывается в голове, используй промежуточные таблицы (Боже, храни Королеву CTE). Отдельно собери юзеров, отдельно сессии, отдельно транзакции. Упрощай составные таблицы, тащи только самое необходимое. С опытом ты будешь видеть запрос хоть за 10 шагов, и если тут пока сложности, это нормально. Специфика сукеля — easy to learn, hard to master.

6️⃣ В общем-то это и всё, теперь пошагово пройдись в обратную сторону и собери итоговый артефакт, проанализируй, сделай выводы, оформи красиво и неси заказчику 👌

📌 Аналитический департамент. Кто?

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

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

🌸 Ноги это дела всегда растут из маркетинга. В какой-то момент MVP стартапа запускается и появляется потребность обкатать его на реальных юзерах. Маркетологи создают рекламные кампании и зарождают первый аналитический артефакт — разметку. Их цель глобально в повышении стоимости потраченных денег, а локально в оценке эффективности кампаний и источников траффика, поэтому глубокую продуктовую разметку они не делают. Эта история скорее про UTM-метки и ключевые конверсии.

Тут подрубаются коробочные решения типа GA, AppsFlyer, AppAnnie и т.д., всё что умеет считать инсталлы и базовые ивенты.

🌸 Если MVP с треском не провалился, можно озадачиться повышением качества точек входа в продукт — рекламных лендосов и всего околомаркетингового. Это самая простая точка роста на стартовом этапе развития. Но т.к. маркетологам на это тупо не хватает времени, то в команде может появиться первый веб- (или маркетинговый) аналитик, который начинает крутить лендосы, чтобы повысить конверсии в регу.

Он притянет GTM, GA, Firebase, AppMetrica — кароч всякое для веб-аналитики.

🌸 Бизнес потихоньку растёт, бэклог активно наполняется продуктовыми задачами из головы ведущих лиц бизнеса и в целом всё хорошо. Вот тут уже появляется потребность в оценке эффективности самого продукта. Но прежде чем начинать его анализировать, нужно подготовить, так сказать, рабочее место. Идеальный момент чтобы нанять дата-инженера и инвестировать в будущее. Это важный ключевой момент в развитии аналитики. Задача инженера собрать все источники данных, которые уже нагенерили предыдущие ребята, и построить единую платформу для работы с данными.

Сквозная аналитика, warehouse, dataLake — вот это набор слов отсюда. Тут инфра сильно увеличивается на сервера, оркестраторы и всякую инженерную магию.

🌸 Когда инфраструктура более-менее подготовлена, можно расширяться на аналитиков — дата- для отладки качества данных, подхвата адхоков и построения всякой базы типа начальных BI + продуктового, для подготовки почвы под дальнейшую работу по улучшению продукта. Тут мы обычно начинаем с разметки событийки и отладки того, как это всё работает.

Подключаются user-based трекеры типа Segment (или пишутся свои), настраиваются ETL-процессы, ставится какая-то простая SQL-based BI-система вроде Redash или Superset.

🌸 В целом, базовый набор готов, параллельно с этими этапами (где-то ближе к началу) прикручиваем CDO, чтобы питчить идеи в C-level, выбивать бюджеты и содержать весь этот зоопарк.

🌸 С ростом объёмов обрабатываемых данных, бизнес начинает смотреть в сторону более узких специалистов, тут появляется BI-аналитик, который забирает на себя витрины и дашборды, параллельно плюясь, матерясь и переделывая то что уже наворотили.

Redash на этом этапе эволюционирует в какой-нибудь более сложный инструмент вроде QlickSense, Power BI или Tableau.

🌸 Когда бизнес уже основательно разросся, неизбежно появляются задачи предсказаний и персонализации. Так в отделе появляется элита в лице датасайентистов.

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