VelStyling

А в моем канале Аналитика FM выпуски про расчет Retention в разных бизнесах.

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

Подписывайся, если интересно как устроен мир аналитика!

Что важно новичку

Новичку в первые недели нужно не "вдохновение", а опора.

Ему важно:

• понимать, что считается хорошей работой

• понимать, по каким правилам принимаются решения

• знать, куда можно задавать вопросы

• понимать, что можно ошибаться

Самая частая тревога новичка:

Я не понимаю, правильно ли я делаю.

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

Что важно работодателю

Работодателю важно другое:

• чтобы сотрудник быстрее начал приносить результат

• чтобы не отвлекать команду постоянными вопросами

• чтобы человек стал самостоятельным

И здесь возникает классический конфликт:

Нужно ли подробно объяснять всё,
или лучше рассказать в общих чертах и “плыви сам”?

Две крайности

1. Гиперопека

Когда новичку:

• всё разжёвывают

• дают пошаговые инструкции

• контролируют каждый шаг

Минус:
человек не учится думать самостоятельно.
Он становится зависимым от системы.

2. "Разбирайся сам"

Когда говорят:

• Вот документация

• Вот коллеги

• У нас всё описано

Минус:
новичок не понимает негласные правила.
А в любой компании именно они самые важные.

Баланс

Хороший онбординг - это не лекция и не квест.

Это:

• объяснение принципов

• показ реальных кейсов

• и постепенное усложнение задач

Важно объяснить:

• как устроена логика компании

• какие решения типичны

• какие ошибки критичны

А дальше - да, человек должен идти и разговаривать с коллегами.

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

Пример условного Google

Представим офис Google. Там множество отделов, направлений, команд, людей.
И сделать программу ондординга, подходящую под каждый отдел/направление - мне кажется нереально. Поддерживать и адаптировать внедренную политику онбординга каждому отделу самостоятельно - тоже видится, что приведет к хаосу.

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

Уметь общаться, объяснять и договариваться - базовый минимум для всех в компании. Этот навык здесь как фильтр.

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

Для такой компании важно:

• чтобы сотрудник умел задавать вопросы

• чтобы он спорил аргументированно

• чтобы он предлагал решения

• чтобы он был автономным

Если новичка в такой среде постоянно "ведут за руку" -
он не впишется в культуру.

Но и бросать его в хаос нельзя.

Поэтому в сильных компаниях:

• есть чёткие процессы - иногда из четких процессов: Иди и разберись сам

• есть наставник - иногда... Документация твой наставник

• есть культура обратной связи - О боже, она бывает культурной...

Но при этом от человека ждут роста.

Вот тут важная аналогия

Когда-то динозавры были самыми крупными и доминирующими существами на планете.

Но они не смогли адаптироваться к изменениям среды -
и вымерли.

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

Онбординг - это первая проверка на адаптацию.

Для сотрудника:

• готов ли он учиться

• готов ли он задавать вопросы

• готов ли он менять привычные способы работы

Для компании:

• готова ли она объяснять

• готова ли она слышать нового человека

• готова ли она меняться вместе с ним

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

Новичку важно дать:

• ориентиры

• ценности

• границы

Но дальше он должен расти сам.

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

Выживают те,
кто умеет адаптироваться.

В канале Аналитика FM рассказываю про аналитику, SQL и аналитическое мышление.

Про особенности работы с данными.

Ну и пост о моем текущем опыте онбординга в новую компанию уже на подходе.

В новой компании я почти месяц уже!

Подписывайся!

• сразу пишут "большой правильный запрос",

• делают несколько JOIN подряд,

• не проверяют объёмы данных,

• не смотрят кардинальность,

• а потом говорят: "База тормозит".

Но чаще всего тормозит не база.
Тормозит наше понимание модели данных.

Для начала, важно понять логику. Таблицы - это реализация, а нам надо понять:

• что является сущностью,

• что является атрибутом,

• что является справочником,

• где факт, а где классификатор.

Затем, не надо делать сразу финальный запрос, который должен вернуть результат со сложной логикой:

Сначала:

• SELECT COUNT(*)

• LIMIT 100

• группировки по статусам

• проверка на NULL

• проверка дублей

Каждый JOIN нужно проверять отдельно:

• сколько строк было до соединения,

• сколько стало после,

• не раздули ли вы данные в 10 раз.

Это экономит часы.

Самый важный вопрос:

• по чему соединяются таблицы?

• это 1:1, 1:N или N:N?

• есть ли составные ключи?

Очень часто "медленный запрос" - это не индексы и не сервер,
а просто не тот ключ в JOIN.

Если запрос со сложной логикой и при запуске висит - не нужно грешить на "неповоротливость базы "

Нужно спросить:

• есть ли индексы на поля соединения?

• используется ли фильтрация до JOIN?

• не делаем ли мы unnecessary full scan?

База редко "плохая".
Она просто делает ровно то, что ты ей сказал.

Важно искать живые примеры:
Очень правильный шаг — смотреть запросы коллег.
Это даёт:

• понимание договорённостей,

• понимание "какие данные считаются валидными",

• понимание негласных ограничений.

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

Знакомство с новой БД — это не проверка твоего SQL.
Это проверка твоего мышления.

Новичку важно понять:

• база не обязана быть удобной

• справочники не обязаны быть очевидными

• описание не равно пониманию

И если запрос выполняется час —
в 80% случаев проблема не в сервере,
а в отсутствии структуры в голове.

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

• что здесь является "фактом",

• что "состоянием",

• что "справочником",

• и что вообще считается "актуальной записью".

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

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

В моем канале Аналитика FM все про мышление аналитика, про инструменты аналитика.
Мы рассматриваем SQL и Python в применении к данным.

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

А пока подписывайся на мой канала Аналитика FM.
Его я веду с нуля подписчиков. В этом канале я публикую информацию об инструментах аналитика (SQL, Python)
О мышлении аналитика, о метриках, об ошибках. Публикую чек-листы по стандартным видам работы аналитика.
Присоединяйся!

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

Возьмём простую вещь - Revenue (выручка).

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

Формально везде можно написать:

SUM(amount)

Но то, что именно лежит в amount, решает всё.

То же самое с конверсией.

В одном бизнесе конверсия - это "визит → покупка".
В другом — "регистрация → первый платёж".
В третьем — "лид → контракт через 3 месяца".

Цифра одна.
Слово одно.
А управленческие решения - совершенно разные.

Поэтому метрики не бывают универсальными.
Универсальными бывают названия, а не смыслы.

И именно здесь аналитика перестаёт быть "про формулы" и становится "про понимание бизнеса".

Одинаковая метрика в разных компаниях - это как одно и то же слово в разных языках.
Вроде знакомо, но если не знаешь контекста - легко ошибиться.

Кстати, в моём телеграм-канале Аналитика FM я как раз разбираю Revenue:
что под ним реально считают бизнесы и где чаще всего начинаются ошибки.
Если интересно копать глубже - буду рада видеть.

Есть метрики, которые принципиально живут без пользователя.

- Выручка за день.
- Количество заказов.
- Средний чек.
- Сумма транзакций по категориям.

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

Бизнес часто живёт именно на этом уровне, и на старте ему кажется, что этого достаточно.

Проблемы с клиентскими метриками возникают в тот момент, когда появляется аналитика "на повторы".

- Повторные покупки.
- Возвраты клиентов.
- LTV.
- Retention.
- Конверсия по шагам воронки.

Все эти метрики - не про события.
Они про людей.

А без user_id "человек" в данных перестаёт существовать.

И когда user_id отсутствует, бизнес начинает выкручиваться.

Вместо user_id появляются:

• номер телефона

• email

• cookie

• device_id

• хэш паспорта

• комбинации из "телефон + дата рождения + регион"

Это не плохие решения.
Это компромиссы.

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

Телефон:
- отлично для CRM
- плохо для веба и офлайна

Cookie:
- хорошо для сессий
- бесполезно для долгой аналитики

Email:
- стабилен
- но есть одноразовые email-ы

Device_id:
- у клиента может быть несколько устройств
- может жить до переустановки приложения
- может стоять запрет на трекинг

В итоге бизнес не считает "пользователей".
Он считает версии пользователей.

Из-за этого появляются странные эффекты:

• пользователей стало больше, но денег больше не стало

• retention упал, но продажи выросли

• конверсия пляшет, а поведение вроде то же

И это не всегда ошибка данных.
Это ограничение идентификации.

Важно понимать:
отсутствие user_id - это не техническая проблема, а продуктовая.

Она говорит о том, как система была спроектирована изначально:

• думали ли о пользователе как о сущности

• или думали только о событиях и операциях

Поэтому аналитика без user_id возможна.
Но она всегда:

• менее точная

• более приближённая

• и требует аккуратной интерпретации

Хуже всего - считать "пользовательские" метрики и делать вид, что всё ок.

Лучше честно сказать:

Мы считаем это так, потому что другого способа у нас нет

Данные могут существовать без user_id.
Запросы SQL может работать без user_id.
Отчёты можно построить без user_id.

Но аналитика поведения - нет.

НО... Главный НО...

Наличие user_id не спасет вас от того, что клиента "на входе" не идентифицировали и завели ему новый идентификатор. Либо при объединении клиентских баз у вас не задвоится один и тот же клиент.

Это повседневные процессы бизнеса. И уникальность клиента зависит от культуры ведения данных в базе, от технических процессов и бизнес процессов.

Для дедупликации клиентских записей существуют системы класса CDI (Customer Data Integration). Такие системы помогают идентифицировать клиента и вести его мастер карточку.

Ну а в моем канале Аналитика FM не только об инструментах аналитика, но и об аналитическом мышлении, метриках, логики.
Присоединяйся!