Сленг и термины которые услышишь на собесе или в чатах команды. Ctrl+F для быстрого поиска.
Метрика, изменение которой запускает конкретное действие в команде.
«Conversion rate упал с 5% до 4%» → actionable: разобраться где в воронке провал, починить, отчитаться.
«У нас 100k registered users» → НЕ actionable (что с этим делать?).
Конкретное действие в продукте после которого юзер осознаёт ценность и retention резко возрастает.
Часто связан с моментом первой ценности (first time-to-value).
Процесс определения какому маркетинговому каналу засчитывается полученная конверсия / выручка.
Модели атрибуции:
В реальности никакая модель не «правильная» — все упрощения. Главное: выбери одну и используй последовательно для сравнения каналов.
Процесс пересчёта исторических данных в таблице. Обычно потому что:
Pitfalls:
Pattern: batched backfill (по 10K рядов), in off-peak hours, с продолжением state в отдельной таблице.
Когнитивный bias: люди игнорируют базовую частоту события и фокусируются на specific data.
Классический пример: Bayes-задача с редкой болезнью — «99% точный тест → 99% больна» (правильный ответ: ~9%).
Самая простая возможная модель для задачи. Используется для сравнения с complex models — без baseline нельзя определить «good ли» complex performance.
Типы: random, majority class, rule-based, simple LogisticRegression. Если complex model не превосходит baseline — значит её сложность не оправдана.
В группе 23 человек вероятность совпадения дней рождения у двух — около 50%. Counterintuitive.
Применение: hash collisions, UUID, idempotency keys.
Ошибка в SQL/pandas: после JOIN-а нескольких таблиц with one-to-many relationships суммы и средние искажаются из-за дублирования строк.
Самый частый bug в analytical queries.
Группа пользователей, объединённая общим временным окном или другим признаком.
Чаще всего — когорта по дате регистрации: «зарегистрировавшиеся в неделю 14 мая 2026».
Зачем нужны:
Кумулятивный revenue per user в зависимости от месяцев с момента acquisition. Построена per cohort (например, месяц регистрации).
Показывает: shape value extraction (linear / decay / step), payback period, comparison cohorts (улучшается ли продукт). Используется для forecasting future cohorts через extrapolation.
Способ хранения таблиц в БД — по колонкам, не по строкам.
Row-based (PostgreSQL OLTP): строка хранится непрерывно. Хорошо для SELECT * WHERE id = ?.
Column-based (ClickHouse, BigQuery, Parquet): значения одной колонки лежат вместе. Хорошо для аналитики:
SELECT SUM(amount) FROM transactions читает только колонку amount, остальное игнорируетFormat: Parquet (Apache), ORC, Avro — стандарт data lakes.
Controlled experiment Using Pre-Existing Data — техника снижения variance метрики в A/B-тестах с помощью pre-period данных.
Идея: контролируешь на «исходный уровень» юзера (его revenue/engagement до теста), оставшаяся variance ниже → меньше выборка нужна для той же мощности.
Может уменьшить выборку в 2-3 раза. Внедрён в Microsoft, Booking, Netflix, Каспи.
Соглашение между producer и consumer данных о структуре, частоте, качестве данных.
Включает:
Зачем: producer не может тихо удалить колонку или изменить тип — это сломает downstream pipelines. Data contract фиксирует обязательства.
Tools: dbt contracts, Schema Registry, Great Expectations.
Постепенное изменение распределения входных данных модели/процесса, из-за чего модель ухудшается без явного бага.
Типы:
Мониторинг: statistical tests (KS-test, PSI), мониторинг feature distributions over time.
Ошибка в ML-pipeline когда модель получает информацию из test set (или будущего) во время тренировки. Результат — overfitted метрики, плохая производительность в продакшене.
Самые частые leaks: preprocessing на всех данных, target encoding без CV, random split на time-series.
Карта происхождения данных: откуда пришли, какие трансформации прошли, где сейчас используются.
Зачем нужна:
Инструменты: dbt строит lineage автоматически из SQL-моделей. DataHub, Atlas, Marquez — отдельные платформы.
Practice мониторинга здоровья данных в продакшене по 5 pillars: freshness, volume, schema, distribution, lineage.
В отличие от backend observability (metrics/logs/traces) — фокус на data quality, не на performance/availability.
Tools: Great Expectations (validation), dbt (testing), DataHub (catalog/lineage), Monte Carlo / Datafold (managed observability).
«Активный» = совершил core action (открыл ленту, выполнил заказ — зависит от продукта).
DAU/MAU ratio = stickiness — насколько часто месячный юзер возвращается.
Бенчмарки stickiness: соцсети 50%+, мессенджеры 70%+, банкинг 20%.
«Eating your own dog food» — практика когда команда сама пользуется своим продуктом в боевых условиях, до выпуска.
Зачем: ловишь UX-проблемы которые в QA не видны. Чувствуешь продукт как юзер.
В data-команде: используй свои дашборды для своих же решений. Если ты сам не открываешь дашборд каждое утро — он плохой.
Процесс создания input variables для ML-моделей из сырых данных. Часто important чем выбор модели — хорошие features + simple model > сложная модель на сыром.
Включает: extraction (timestamp → hour, dayofweek), aggregation (groupby + transform), encoding (categorical → one-hot, target encoding), normalization, interaction features.
Последовательность шагов пользователя к целевому действию — с измерением конверсии на каждом шаге.
Классический ecommerce funnel:
Landing → Product page → Add to cart → Checkout → Completed
100% 40% 10% 7% 5%
Каждый «шаг» — drop-off рейт. Цель аналитика — найти наибольший drop и понять почему.
Типы funnels:
Classic SQL-задача: найти consecutive runs значений (islands) в данных где могут быть пропуски (gaps).
Пример: даты активности юзера. Найти самую длинную серию подряд идущих дней (streak).
Trick: для consecutive дат, разница date - ROW_NUMBER даёт одинаковое значение для последовательных. Группируешь по этому и считаешь.
«Когда метрика становится target — она перестаёт быть хорошей метрикой.»
Юзеры (сотрудники, агенты, юзеры) оптимизируют именно ту цифру, иногда в ущерб реальной цели.
«Метрики-ограничители» — те которые не должны просесть пока ты гонишь рост основной метрики.
Допустим, главная — конверсия в paid. Guardrails:
Группа пользователей которым не показывают новую фичу для измерения её долгосрочного эффекта.
Отличается от A/B-теста тем, что holdout продолжается месяцы или годы, а A/B обычно 1-4 недели.
Зачем:
Ситуация когда эффект эксперимента/treatment различается для разных подгрупп пользователей. Противоположность Average Treatment Effect (ATE) — единое среднее.
Современный ML-подход — uplift modeling: предсказать кто из юзеров получит положительный эффект, target треатмент именно на них.
Свойство операции: многократное выполнение даёт тот же результат, что и однократное.
Пример:
UPDATE users SET status = 'active' WHERE id = 1 — idempotent (можно запустить 100 раз — результат тот же)UPDATE users SET balance = balance + 100 WHERE id = 1 — НЕ idempotent (каждый запуск +100)Где критично:
Idempotency-Key)Pattern: добавляй уникальный ключ + INSERT ... ON CONFLICT DO NOTHING / ON CONFLICT DO UPDATE.
ROAS (Return on Ad Spend) но учитывая что часть конверсий случилась бы без рекламы.
Last-click ROAS: 4.5x. Incremental ROAS: 2.8x (часть юзеров пришли бы organic). Это реальная эффективность рекламы.
Дополнительная ценность от treatment, по сравнению с тем что было бы без него.
Опровергает observational «correlation»: если retain'ятся юзеры с фичей — может быть selection bias, нужно causal experiment чтобы доказать incrementality.
Метрика виральности продукта. Сколько новых юзеров в среднем приводит один существующий.
K = (invites per user) × (conversion rate of invite).
Если K > 1 — продукт растёт экспоненциально без paid marketing.
Соотношение визуального эффекта на графике к реальному эффекту в данных. Lie factor 1.0 = честный график. >1.05 = манипулирующий.
Источник: Edward Tufte, «Visual Display of Quantitative Information».
Период, за который мы смотрим назад чтобы атрибутировать событие к источнику.
Пример: юзер кликнул рекламу 1 января. Купил 15 января. Если look-back window = 7 дней — покупка не атрибутируется к этому клику (15 - 1 = 14 дней). Если 30 дней — атрибутируется.
Окно сильно влияет на ROI каналов:
Маркетинговая техника: находишь аудиторию похожую на твоих лучших клиентов по характеристикам и таргетируешь на неё.
Источник аудитории — твой CRM с топ-юзерами (например high LTV, frequent buyers). Платформа (Facebook, Google) ищет других пользователей со схожим behavior pattern.
Pitfall: если seed-аудитория мала (<1000) — lookalike модель плохо обобщает. Чем больше seed — тем точнее матчинг, но менее «глубокий» (захватывает больше похожих, но менее похожих).
Метрика efficiency growth investments в SaaS. Показывает сколько annualized recurring revenue приносит каждый ₸ S&M spend.
Magic Number = (Net New ARR × 4) / S&M spend в том же квартале
Benchmarks: < 0.75 (cut budget), 0.75-1.5 (healthy), > 1.5 (invest more).
Сохранённый результат SQL-запроса как физическая таблица. В отличие от обычной view (пересчитывается на каждое чтение), materialized view возвращает данные мгновенно.
Trade-off: данные устаревшие. Нужно явное REFRESH MATERIALIZED VIEW (часто через cron). Альтернатива: summary tables, OLAP cubes.
Проблема: если ты делаешь много статистических тестов одновременно — растёт шанс хотя бы одного ложного срабатывания, даже если все нулевые гипотезы верны.
20 тестов при α=0.05: 1 - (1 - 0.05)^20 ≈ 64% шанс false positive.
Поправки:
В A/B-тестах: если тестируешь 5 secondary метрик одновременно с primary — применяй FDR.
Механизм PostgreSQL для concurrent доступа без блокировок read-операций. Каждая транзакция видит snapshot базы — её собственную консистентную версию.
Под капотом: каждая строка имеет версии. UPDATE не overwrite — пишет новую версию. DELETE помечает текущую как dead. VACUUM освобождает место от dead versions.
Trade-off: bloat (растущий size без cleanup), но zero locking для reads.
Главная метрика компании, отражающая создаваемую ценность для пользователя, к росту которой стремится весь продукт.
Не путать с финансовыми метриками (revenue, ARR) — Северная звезда опережает деньги.
Примеры:
Кратковременное повышение engagement в A/B-тесте просто из-за того что что-то изменилось, без долгосрочного improvement.
Пример: новый дизайн → юзеры активно исследуют первые недели → метрика +15%. После 4-8 недель эффект затухает.
Противоположность — primacy effect (power users привыкли к старому → новое работает хуже первое время, потом нормализуется).
Два класса баз данных под разные задачи.
OLTP (Online Transaction Processing):
OLAP (Online Analytical Processing):
Правило: не делай аналитику на OLTP — повесишь продакшен. Реплицируй данные в OLAP для analytics.
Подгонка анализа под желаемый результат через множественные сравнения или выбор данных до тех пор пока p-value не упадёт ниже 0.05.
Способы p-hacking (не делай так):
Решения:
Одна из самых частых ошибок в data science: p-value НЕ говорит вероятность что результат случаен или что фича работает.
p = 0.03 означает: «при условии что эффекта НЕТ, вероятность увидеть такую разницу = 3%».
Это не «фича работает с вероятностью 97%».
SQL запрос где user input передаётся отдельно от шаблона SQL. Драйвер БД сам экранирует значения — injection невозможен.
Все драйверы (psycopg2, sqlalchemy, supabase) поддерживают. Не использовать string concatenation никогда.
Оптимизация PostgreSQL когда планировщик автоматически исключает партиции которые не нужны для конкретного запроса.
WHERE created_at >= '2026-05-01' → читаются только партиции за май+, остальные ignored. Дает огромный speedup для time-range queries на партиционированных таблицах.
Смотреть на p-value до окончания запланированного A/B-теста и принимать решение остановить рано.
Почему плохо: классические t-test и z-test предполагают одну проверку в конце. Если ты проверяешь ежедневно, шанс ложного срабатывания растёт с 5% до 25–30% за 2 недели.
Решения:
Дизайн A/B-теста который позволяет подсматривать результаты и останавливать тест досрочно без потери валидности.
В отличие от fixed-horizon test (где смотришь только в конце), sequential design корректирует пороги по мере накопления данных.
Методы: mSPRT, Group Sequential Testing (GST), Bayesian A/B.
Метод interpretability для ML-моделей. Считает вклад каждой фичи в predict для конкретного samples — based on game theory Shapley values.
Преимущества над feature_importances_:
Ситуация когда ETL/процесс завершился успешно по логам, но данные неверные или неполные. Самый опасный тип bug потому что не triggert alerts.
Типичные causes: schema evolution без updates, type coercion, batch boundary issues, pagination missed, deduplication bug, floating-point precision.
Защита: cross-validation (source vs DWH totals), audit logs, anomaly detection.
Статистический парадокс: эффект, видный в каждой подгруппе, исчезает или меняет направление в общей суммарной выборке (и наоборот).
Причина — confounder (mediator) который коррелирован и с группой, и с outcome.
Принцип: для каждого факта существует ровно одно место в системе которое его хранит и обновляет.
Без SSOT: в финансовом дашборде revenue = 10М, в маркетинговом = 12М, у CEO в Excel = 11М. Все используют разные источники, никто не знает правду.
С SSOT: есть одна таблица core.revenue, все дашборды смотрят туда. Любое расхождение = баг конкретного дашборда, не «у нас данные разные».
Признаки нарушения SSOT:
Тип измерения в DWH, значения которого меняются со временем, и нужно решить как хранить историю.
Например, юзер сменил город с Алматы на Астану. Что хранить?
SCD Type 1 — перезаписать. Истории нет. Простой, но теряем «откуда юзер пришёл».
SCD Type 2 — добавить новую строку с effective_from / effective_to. История есть, но таблица растёт.
SCD Type 3 — добавить колонки previous_city, current_city. Только одна предыдущая версия.
Для аналитики юзеров чаще всего SCD Type 2 — он позволяет правильно атрибутировать события («юзер на момент покупки был в Алматы»).
Vulnerability когда атакующий внедряет произвольный SQL через user input. Возникает когда query строится через string concatenation вместо parameterized queries.
Защита: всегда использовать parameterized queries (driver сам экранирует). Для dynamic column/table names — whitelist подход.
В A/B-тесте: фактическое распределение трафика не соответствует запланированному (50/50, 80/20).
Признак: пропорция в группах статистически отличается от заданной (p < 0.001 в chi-square).
Что значит: в твоей рандомизации баг. Юзеры распределены не случайно — значит группы не сравнимы, и результаты теста нельзя доверять.
Причины:
Питон-операторы для unpacking аргументов.
*args — variable positional arguments → tuple**kwargs — variable keyword arguments → dictfunc(*list) распаковывает в позиционные, func(**dict) в keyword* в signature — после него только keyword-only argsАрхитектурный pattern data warehouse: одна центральная fact table + несколько dimension tables вокруг неё.
Стандарт для Power BI, BigQuery, Snowflake аналитических моделей. Альтернатива — snowflake (dim'ы join'ятся между собой) — обычно хуже.
Sampling technique где populace делится на strata (сегменты) по ключевым признакам, потом sample проводится внутри каждой страты отдельно (часто equal или proportional allocation).
Зачем: equal precision per segment. Простая случайная выборка может underrepresent small segments (например VIP клиентов).
Время от регистрации до первого «aha moment». Чем короче — тем выше activation и retention.
Цель UX-команды — снижать TTV. Long onboarding с tutorials часто увеличивает TTV — лучше «learn by doing».
Метрика, которая выглядит впечатляюще, но не помогает принимать решения.
Классика:
Главный тест: «если эта метрика вырастет в 2 раза, что я сделаю по-другому?». Если ответа нет — vanity.