Все вопросы

Порядок выполнения SQL-запроса движком базы данных:

1. FROM — определяются таблицы-источники, выполняются JOIN
2. WHERE — фильтрация строк по условию
3. GROUP BY — группировка строк
4. HAVING — фильтрация групп
5. SELECT — выбор столбцов, вычисление выражений
6. DISTINCT — удаление дубликатов
7. ORDER BY — сортировка результата
8. LIMIT / OFFSET — ограничение выборки

Важно: оконные функции (OVER()) вычисляются после WHERE, GROUP BY, HAVING, но до DISTINCT и ORDER BY.

WITH daily AS (
  SELECT
    date,
    SUM(CASE WHEN service = 'rec' THEN revenue ELSE 0 END) AS rec_revenue,
    SUM(revenue) AS total_revenue
  FROM orders
  WHERE date BETWEEN '2023-02-01' AND '2023-02-28'
  GROUP BY date
)
SELECT
  date,
  rec_revenue * 1.0 / NULLIF(total_revenue, 0) AS rec_share,
  AVG(rec_revenue * 1.0 / NULLIF(total_revenue, 0))
    OVER (ORDER BY date ROWS BETWEEN 2 PRECEDING AND CURRENT ROW) AS moving_avg_share
FROM daily
ORDER BY date;

Скользящее среднее рассчитывается по окну в 3 дня (текущий + 2 предыдущих). Сначала считаем дневную долю сервиса rec, затем применяем оконную функцию AVG с ROWS BETWEEN.

data = [[1, 'a', True], [2, 'b', False], [3, 'c', True]]

# Способ 1: list comprehension
result = [item[1] for item in data]
# ['a', 'b', 'c']

# Способ 2: map + operator.itemgetter
from operator import itemgetter
result = list(map(itemgetter(1), data))

Оба подхода извлекают элемент с индексом 1 из каждого вложенного списка. List comprehension — более читаемый и Pythonic способ.

# Способ 1: collections.Counter
from collections import Counter

def count_chars(s: str) -> dict:
    return dict(Counter(s))

# Способ 2: вручную
def count_chars(s: str) -> dict:
    result = {}
    for char in s:
        result[char] = result.get(char, 0) + 1
    return result

print(count_chars('abcabb'))  # {'a': 2, 'b': 3, 'c': 1}

Counter — самый лаконичный способ. Ручной вариант показывает понимание работы с dict.get() и итерацией по строке.

import random

# Базовый вариант O(n) на каждый вызов
def weighted_random(d: dict) -> str:
    names = list(d.keys())
    weights = list(d.values())
    return random.choices(names, weights=weights, k=1)[0]

# Оптимизированный вариант для 10^6 вызовов:
# Предварительно строим кумулятивные веса O(n),
# затем каждый вызов — бинарный поиск O(log n)
import bisect

def make_sampler(d: dict):
    names = list(d.keys())
    cum_weights = []
    total = 0
    for w in d.values():
        total += w
        cum_weights.append(total)

    def sample():
        r = random.uniform(0, total)
        idx = bisect.bisect_left(cum_weights, r)
        return names[idx]

    return sample

sampler = make_sampler(d)
for _ in range(10**6):
    sampler()  # O(log n) каждый вызов

Базовый random.choices работает за O(n). С предвычислением кумулятивных весов + bisect получаем O(log n) на вызов и O(n) на подготовку.

Фреймворк анализа:

1. Декомпозиция среднего чека: Средний чек = GMV / Кол-во заказов. Что именно ниже — GMV на заказ или количество товаров в заказе?

2. Анализ ассортимента: Какие товары рекомендуются в rec? Средняя цена товара в рекомендациях vs. в других сервисах.

3. Поведение пользователей (events):

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

4. Сегментация: Разбить по категориям товаров, по сегментам пользователей (новые/старые, частота покупок)

5. Гипотезы:

   • Рекомендации показывают дешёвые товары
   • Пользователи rec — другой сегмент (новички, casual buyers)
   • Рекомендации неточные → пользователь покупает меньше товаров из выдачи

WITH data AS (
  SELECT
    name,
    SUM(salary) OVER (
      ORDER BY skill DESC, salary, employee_id
    ) AS cum_sum
  FROM employees
)
SELECT name
FROM data
WHERE cum_sum <= 500;

Используем оконную функцию SUM() OVER() для нарастающего итога зарплат, отсортированных по убыванию скила. Берём всех сотрудников, пока кумулятивная сумма не превысит бюджет. Сортировка по salary, employee_id при одинаковом скиле обеспечивает детерминированный результат.

WITH data AS (
  SELECT
    name, employee_id, salary,
    SUM(salary) OVER (ORDER BY skill DESC, salary, employee_id) AS cum_sum
  FROM employees
),
budget AS (
  SELECT name, employee_id, salary
  FROM data
  WHERE cum_sum <= 500
),
emp_rank AS (
  SELECT
    salary,
    ROW_NUMBER() OVER (ORDER BY salary) AS rn,
    COUNT(*) OVER () AS cnt
  FROM budget
)
SELECT AVG(salary) AS median_salary
FROM emp_rank
WHERE
  -- нечётное: берём средний элемент
  (cnt % 2 = 1 AND rn = (cnt + 1) / 2)
  OR
  -- чётное: среднее двух центральных
  (cnt % 2 = 0 AND rn IN (cnt / 2, cnt / 2 + 1));

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

def rle(s: str) -> str:
    if not s:
        return ''
    if not s.isalpha() or not s.isupper():
        raise ValueError('Строка должна содержать только A-Z')

    result = []
    count = 1

    for i in range(1, len(s)):
        if s[i] == s[i - 1]:
            count += 1
        else:
            result.append(s[i - 1])
            if count > 1:
                result.append(str(count))
            count = 1

    # Последняя группа
    result.append(s[-1])
    if count > 1:
        result.append(str(count))

    return ''.join(result)

print(rle('AAAABBBCCXYZ'))  # A4B3C2XYZ

Алгоритм за O(n): проходим по строке, считаем подряд идущие одинаковые символы. При смене символа записываем символ и счётчик (если > 1).

Метрики эффективности поддержки:

Объём:

• Общее количество обращений
• Доля обращений от всех заказов
• Доля обращений от активных пользователей в Грузии

Качество:

• NPS / среднее количество звёзд в отзывах
• SLA — доля обращений, закрытых в рамках целевого времени
• Доля положительных отзывов

Влияние на бизнес:

• Доля и количество купивших пользователей после общения с поддержкой
• Retention пользователей, обратившихся в поддержку vs. не обращавшихся

Операционные:

• Среднее количество сообщений внутри одного обращения
• Среднее время ответа (first response time)
• Доля вернувшихся с повторным обращением в течение дня

Фильтры для анализа: тема обращения, канал (чат/звонок), тип проблемы.

import pandas as pd

# Находим пользователей в нескольких группах
user_groups = df_ab_groups.groupby('user_id')['ab_group'].nunique().reset_index()
user_groups.columns = ['user_id', 'group_count']

multi_group = user_groups[user_groups['group_count'] > 1]
print(f'Пользователей в нескольких группах: {len(multi_group)}')

Если таких пользователей много — это признак SRM (Sample Ratio Mismatch). Их нужно исключить из анализа или разобраться в причинах перетекания между группами.

# Суммарная выручка на клиента
user_revenue = df_financial.groupby('user_id')['revenue'].sum().reset_index()
user_revenue.columns = ['user_id', 'total_revenue']

# Присоединяем группу эксперимента
result = pd.merge(user_revenue, df_ab_groups, on='user_id', how='inner')

# Средняя выручка по группам
print(result.groupby('ab_group')['total_revenue'].mean())

Важно: используем inner join, чтобы исключить пользователей без определённой группы. Если пользователь был в нескольких группах — предварительно исключаем таких (см. задачу 1).

import matplotlib.pyplot as plt
from scipy import stats
import numpy as np

def ab_results(df, remove_outliers=False, percentile=99):
    if remove_outliers:
        threshold = np.percentile(df['total_revenue'], percentile)
        df = df[df['total_revenue'] <= threshold]

    a = df[df['ab_group'] == 'a']['total_revenue']
    b = df[df['ab_group'] == 'b']['total_revenue']

    # Бокс-плот
    fig, ax = plt.subplots()
    df.boxplot(column='total_revenue', by='ab_group', ax=ax)
    ax.set_title('Выручка по группам')
    plt.suptitle('')
    plt.show()

    # Статистика
    uplift = (b.mean() - a.mean()) / a.mean() * 100
    _, p_value = stats.ttest_ind(a, b)
    n = len(df)

    print(f'Uplift = {uplift:.2f}%')
    print(f'p_value = {p_value:.4f}')
    print(f'Аудитория эксперимента = {n}')

Функция принимает параметры remove_outliers и percentile для управления выбросами. T-test проверяет разницу средних между группами.

Задача на фильтрацию по набору признаков пользователя, а не отдельных строк. Ключевая сложность: условия «смотрел 1 и 3» и «не смотрел 2» относятся к разным строкам одного пользователя, поэтому обычным WHERE их не выразить.

SELECT user_id
FROM watch_content
GROUP BY user_id
HAVING MAX(CASE WHEN video_id = 1 THEN 1 ELSE 0 END) = 1
   AND MAX(CASE WHEN video_id = 3 THEN 1 ELSE 0 END) = 1
   AND MAX(CASE WHEN video_id = 2 THEN 1 ELSE 0 END) = 0;

Читается по строчкам: «есть хотя бы один просмотр видео 1», «есть хотя бы один просмотр видео 3», «нет ни одного просмотра видео 2». MAX здесь работает как логическое ИЛИ по строкам группы, поэтому повторные просмотры одного видео результат не искажают.

Главная ловушка задачи. Напрашивается сначала сузить выборку через WHERE, а условие про видео 2 дописать в HAVING:

-- НЕВЕРНО
SELECT user_id
FROM watch_content
WHERE video_id IN (1, 3)
GROUP BY user_id
HAVING COUNT(DISTINCT video_id) = 2
   AND SUM(CASE WHEN video_id = 2 THEN 1 ELSE 0 END) = 0;

WHERE video_id IN (1, 3) выбрасывает строки с видео 2 до группировки, поэтому внутри группы информации о просмотре видео 2 уже нет. Слагаемое SUM(CASE WHEN video_id = 2 ...) тождественно равно нулю для всех групп — условие всегда истинно и не фильтрует ничего, лишь создавая иллюзию проверки.

Проверка на данных:

Неверный запрос возвращает 1 и 2 — пользователь 2 просачивается, хотя видео 2 он смотрел. Корректный запрос возвращает только 1.

Другие рабочие варианты:

Если хочется сохранить WHERE, в выборку нужно включить и видео 2, а разделение перенести в агрегаты:

SELECT user_id
FROM watch_content
WHERE video_id IN (1, 2, 3)
GROUP BY user_id
HAVING COUNT(DISTINCT CASE WHEN video_id IN (1, 3) THEN video_id END) = 2
   AND COUNT(CASE WHEN video_id = 2 THEN 1 END) = 0;

В PostgreSQL то же самое компактнее через FILTER:

SELECT user_id
FROM watch_content
GROUP BY user_id
HAVING COUNT(DISTINCT video_id) FILTER (WHERE video_id IN (1, 3)) = 2
   AND COUNT(*) FILTER (WHERE video_id = 2) = 0;

Вариант через EXISTS / NOT EXISTS — самый читаемый и обычно хорошо оптимизируется при наличии индекса по (user_id, video_id):

SELECT DISTINCT w.user_id
FROM watch_content w
WHERE EXISTS (SELECT 1 FROM watch_content x WHERE x.user_id = w.user_id AND x.video_id = 1)
  AND EXISTS (SELECT 1 FROM watch_content x WHERE x.user_id = w.user_id AND x.video_id = 3)
  AND NOT EXISTS (SELECT 1 FROM watch_content x WHERE x.user_id = w.user_id AND x.video_id = 2);

Почему NOT EXISTS, а не NOT IN. Формулировка с user_id NOT IN (SELECT user_id FROM watch_content WHERE video_id = 2) даёт правильный ответ на чистых данных, но молча возвращает пустой результат, если подзапрос вернёт хотя бы один NULL: сравнение с NULL даёт UNKNOWN, и условие NOT IN не выполняется ни для кого. Проверено: достаточно одной строки с user_id IS NULL — и корректный до того запрос выдаёт ноль строк. NOT EXISTS к этому устойчив.

Что проверяет задача: понимание того, что WHERE фильтрует строки до агрегации и безвозвратно удаляет информацию, а HAVING работает уже с группами. Признак «пользователь чего-то не делал» невозможно проверить, если строки с этим действием отфильтрованы заранее.

WITH first_order AS (
  SELECT
    user_id,
    MIN(transaction_datetime) AS first_dt
  FROM raw.orders
  GROUP BY user_id
),
first_items AS (
  SELECT
    o.user_id,
    i.name,
    i.price,
    ROW_NUMBER() OVER (
      PARTITION BY o.user_id ORDER BY i.price DESC
    ) AS rn
  FROM raw.orders o
  JOIN first_order fo
    ON o.user_id = fo.user_id
    AND o.transaction_datetime = fo.first_dt
  JOIN dicts.items i ON o.item_id = i.item_id
)
SELECT user_id, name, price
FROM first_items
WHERE rn = 1;

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

WITH cohorts AS (
  SELECT
    user_id,
    DATE_TRUNC('month', MIN(transaction_datetime)) AS cohort_month
  FROM raw.orders
  GROUP BY user_id
),
activity AS (
  SELECT DISTINCT
    o.user_id,
    c.cohort_month,
    DATE_TRUNC('month', o.transaction_datetime) AS activity_month
  FROM raw.orders o
  JOIN cohorts c ON o.user_id = c.user_id
),
cohort_size AS (
  SELECT cohort_month, COUNT(*) AS size
  FROM cohorts
  GROUP BY cohort_month
)
SELECT
  a.cohort_month,
  cs.size AS cohort_size,
  COUNT(DISTINCT CASE
    WHEN DATEDIFF('month', a.cohort_month, a.activity_month) = 2
    THEN a.user_id END
  ) AS retained_m2,
  ROUND(
    COUNT(DISTINCT CASE
      WHEN DATEDIFF('month', a.cohort_month, a.activity_month) = 2
      THEN a.user_id END
    ) * 100.0 / cs.size, 2
  ) AS retention_m2_pct
FROM activity a
JOIN cohort_size cs ON a.cohort_month = cs.cohort_month
GROUP BY a.cohort_month, cs.size
ORDER BY a.cohort_month;

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

Тест показал, что эффект есть. Но «значимо выше» отвечает только на вопрос «работает ли», а решение о запуске принимается по деньгам.

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

При равных размерах групп прирост покупателей:

1100 − 1000 = 100 дополнительных покупателей

Именно эти 100 человек — весь результат программы. Число 300 (воспользовались кэшбэком) эффектом не является: большинство из них купили бы и без кэшбэка.

Шаг 2. Каннибализация — ключевая мысль всей задачи.

Из 300 получивших кэшбэк инкрементальных только 100:

• 100 человек (33%) пришли благодаря кэшбэку — это новая выручка;
• 200 человек (67%) купили бы и так — им мы просто подарили скидку, снизив маржу с продаж, которые и без того состоялись бы.

Отсюда главный принцип расчёта: выгода считается только от 100 инкрементальных покупателей, а затраты — по всем 300. Ошибка «300 воспользовались, значит программа привела 300 клиентов» завышает эффект втрое и типична для отчётов по промо-механикам.

Шаг 3. Экономика.

Инкрементальная выручка   = 100 × средний чек
Инкрементальная маржа     = 100 × средний чек × маржинальность
Затраты на кэшбэк         = 300 × средний чек × ставка кэшбэка   ← платим всем
Прочие затраты            = интеграция с банком, комиссия партнёра, поддержка
Эффект = Инкрементальная маржа − Затраты на кэшбэк − Прочие затраты

CAC программы = все затраты / 100 привлечённых. Программа окупается, если LTV инкрементального покупателя > CAC, а не если «выручка выросла».

Числовой пример: при среднем чеке 2000 ₽, марже 20% и кэшбэке 5% инкрементальная маржа = 100 × 2000 × 0,2 = 40 000 ₽, а затраты на кэшбэк = 300 × 2000 × 0,05 = 30 000 ₽. Плюс постоянные затраты на интеграцию — и эффект легко уходит в минус, хотя тест «зелёный».

Шаг 4. Что уточнить перед расчётом.

• Равны ли группы по размеру. Если нет — сравнивать абсолютные 1000 и 1100 нельзя, нужно считать разницу конверсий и умножать на базу: (CR_B − CR_A) × N_B.
• Горизонт. Разовый всплеск или устойчивый эффект? Кэшбэк часто просто сдвигает покупку во времени: человек купил бы через неделю, но купил сейчас. Проверяется тем, сохраняется ли разрыв между группами через 2–3 периода.
• LTV, а не разовая покупка. Если привлечённые кэшбэком возвращаются, эффект больше разовой маржи; если это охотники за скидками — они уйдут вместе с промо.
• Защитные метрики: средний чек (не упал ли), доля возвратов, каннибализация других категорий и промо-механик.
• Доверительный интервал эффекта. 100 покупателей — точечная оценка; для решения о раскатке нужен интервал, чтобы понимать худший сценарий окупаемости.

Вывод: считаем unit-экономику на инкрементальных покупателях, затраты — на всех получателях кэшбэка. Раскатываем, если LTV инкрементальных превышает CAC с запасом, покрывающим неопределённость оценки.

Это задача Gaps & Islands. Решение:

WITH ranked AS (
  SELECT
    Department, FIO, Date, Status,
    ROW_NUMBER() OVER (PARTITION BY FIO ORDER BY Date) AS rn_all,
    ROW_NUMBER() OVER (PARTITION BY FIO, Status ORDER BY Date) AS rn_status
  FROM visits
),
islands AS (
  SELECT
    Department, FIO, Status,
    MIN(Date) AS DateFrom,
    MAX(Date) AS DateTo,
    rn_all - rn_status AS grp
  FROM ranked
  GROUP BY Department, FIO, Status, rn_all - rn_status
)
SELECT Department, FIO, DateFrom, DateTo, Status
FROM islands
ORDER BY FIO, DateFrom;

Идея: Разница между двумя нумерациями (rn_all - rn_status) остаётся постоянной для последовательных строк с одинаковым статусом, но меняется при смене статуса. Это позволяет группировать «острова» непрерывного статуса.

Альтернативный простой вариант — через LEAD:

SELECT
  FIO,
  Date AS DateFrom,
  LEAD(Date) OVER (PARTITION BY FIO ORDER BY Date) AS DateTo,
  Status
FROM visits;

def threshold_filter(bench: int, sales: list) -> list:
    failed_products = []

    for sale_group in sales:
        for item in sale_group:
            gmv = item['quantity'] * item['price']
            if gmv < bench:
                failed_products.append(item['product_id'])

    return failed_products

# Пример
sales = [
    [{"product_id": 1, "quantity": 2, "price": 100}],
    [{"product_id": 2, "quantity": 3, "price": 100}],
    [{"product_id": 3, "quantity": 1, "price": 50}]
]
print(threshold_filter(150, sales))  # [3]

Важно: вложенный массив — список списков, поэтому нужен двойной цикл. Распространённая ошибка — обращаться как i[0] вместо итерации по элементам.

Опция 1 (детерминированная):

• 100 / 25 = 4 показа на каждые 100 товаров

Опция 2 (вероятностная):

• Математическое ожидание: 100 × 0.04 = 4 показа (в среднем)
• Вероятность ровно 1 показа — биномиальное распределение:

P(X = 1) = C(100, 1) × 0.04¹ × 0.96⁹⁹

P(X = 1) = 100 × 0.04 × 0.96⁹⁹ ≈ 100 × 0.04 × 0.0169 ≈ 0.0703 (≈ 7%)

Также можно записать: вероятность = (99/100) × 0.96⁹⁹ + (1/100) — но формально это не совсем корректно, правильнее через биномиальное распределение.

Риски и контрмеры:

1. Снижение CR в переход на карточку товара — дизайн подсветки может отвлекать от основных товаров. Контрмера: A/B тест, следить за CR в карточку всех товаров.

2. Снижение среднего чека / гросс-прибыли — пользователи переключаются на скидочные товары. Контрмера: мониторить средний чек и маржинальность.

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

4. Каннибализация основного ассортимента — пользователи перестают покупать товары без скидки.

Предложения по усилению эффекта:

• Комбинировать скидочные товары с рекомендациями похожих товаров без скидки
• Пуш-уведомления о попадании любимого товара в акцию
• Геймификация и система лояльности

Диагностика:

1. Проверить конверсию воронки: клик на баннер → просмотр рецепта → добавление ингредиентов в корзину → покупка
2. Где обрыв? Пользователи смотрят рецепт, но не добавляют товары?

Возможные причины:

• Нет кнопки «Добавить все ингредиенты в корзину» — слишком много шагов
• Ингредиентов нет в наличии
• Рецепты нерелевантны текущему поиску
• Каннибализация: пользователь уходит в рецепты вместо покупки того, что искал

Рекомендации:

• Добавить кнопку «Купить все ингредиенты» на странице рецепта
• Показывать рецепты на основе того, что уже в корзине (дополнительные товары)
• Персонализировать рецепты под историю покупок
• Замерить отдельно: покупатели рецептов покупают больше товаров? Если да — проблема в цене/марже

Подход: A/B тест

Метрики:

• Целевые: время в пути, длина маршрута, доля пользователей, следовавших маршруту до конца
• Защитные: количество перестроений маршрута, удовлетворённость пользователей (рейтинг), crash rate
• Информационные: среднее количество манёвров, доля маршрутов через платные дороги

Дизайн:

• Сплит по пользователям (не по сессиям — избежать перетекания)
• Учесть географию (разные регионы — разные карты)
• Достаточная длительность для разных сценариев (будни/выходные)

Анализ:

• Сравнить среднее время в пути (t-test)
• Контролировать SRM
• Сегментация: город vs. межгород, утро/вечер, короткие/длинные маршруты

Анализ:

1. Текущие данные: какой % пользователей конвертируется в платных за 1 месяц? Какой % завершает настройку?

2. Сегментация: кто жалуется? Если это крупные клиенты с долгим onboarding — возможно стоит. Если мелкие — это может быть предлог не платить.

3. Риски продления до 3 месяцев:

   • Снижение выручки: 2 дополнительных месяца бесплатно
   • Пользователи могут пользоваться бесплатно и уходить
   • Размытие urgency — нет мотивации настраивать быстро

4. Альтернативы:

   • Улучшить onboarding (мастера настройки, шаблоны)
   • Персональный менеджер для крупных клиентов
   • Гибкий trial: продлить на 2 недели по запросу
   • Ограниченный функционал в free, полный — в trial (freemium)

5. Как проверить: A/B тест с разной длительностью trial. Метрика: конверсия в платную подписку и LTV за 6 месяцев.

Рекомендации:

1. Проверить достоверность:

   • Нет ли SRM (Sample Ratio Mismatch)?
   • Достаточно ли наблюдений для MDE основной метрики?
   • Не слишком ли короткий тест?

2. Анализ прокси-метрики:

   • Насколько она коррелирует с основной?
   • Возможно, эффект проявится позже (lag effect)

3. Сегментный анализ:

   • Есть ли сегменты, где основная метрика выросла?
   • Новые vs. старые пользователи

4. Решение:

   • Если прокси-метрика значимо коррелирует с основной и нет негативного влияния на защитные метрики — можно раскатать с мониторингом
   • Если нет — продлить тест или отказаться от изменения
   • Не принимать решение только по прокси-метрике

Используем подход «от противного» — считаем вероятность того, что все числа разные, и вычитаем из 1.

• Всего исходов: 6 × 6 × 6 = 216
• Все три разные: 6 × 5 × 4 = 120

P(хотя бы 2 одинаковых) = 1 − 120/216 = 1 − 5/9 = 4/9 ≈ 0.444

Это аналог задачи о дне рождения (birthday problem) — проще считать дополнение к «все различны».

Распределение скошено влево (отрицательная асимметрия, left-skewed).

Когда медиана > среднего, это означает, что длинный хвост распределения тянется влево (в сторону меньших значений). Среднее «утягивается» за выбросами в левом хвосте.

Мнемоника:

• Медиана > Среднего → Left-skewed (левый хвост длиннее)
• Медиана < Среднего → Right-skewed (правый хвост длиннее)
• Медиана ≈ Среднего → Симметричное распределение

Длительность уменьшится, так как скорость набора выборок станет выше.

Формула размера выборки: n = (Z_α + Z_β)² × 2σ² / δ²

Размер выборки зависит от α, β, σ², δ (MDE) — но не от трафика. Трафик влияет только на то, за сколько дней мы наберём нужный размер выборки.

Если трафик × 2 → длительность теста ≈ / 2 (при прочих равных).

Важно: нельзя останавливать тест раньше, чем набран минимальный размер выборки, даже если p-value уже низкий (проблема peeking).

UNION — объединяет результаты двух SELECT-запросов и автоматически удаляет дубликаты.

Важные отличия:

• UNION — удаляет дубликаты (выполняет сортировку / хеширование для дедупликации)
• UNION ALL — оставляет все строки, включая дубликаты (быстрее, так как нет дедупликации)

Требования:

• Оба запроса должны возвращать одинаковое количество столбцов
• Типы данных соответствующих столбцов должны быть совместимы

UNION ALL предпочтительнее, если дубликаты невозможны или допустимы — он работает быстрее.

Rolling Retention считает пользователя вернувшимся, если он вернулся в любой из последующих месяцев.

Считаем от майской когорты (100к):

Минимальный RR:

• Если пользователи июня и июля полностью пересекаются (все 20к июня вошли в 30к июля)
• Вернулось: max(20к, 30к) = 30к
• Min RR = 30к / 100к = 30%

Максимальный RR:

• Если пользователи июня и июля не пересекаются вообще
• Вернулось: 20к + 30к = 50к
• Max RR = 50к / 100к = 50%

Ответ: RR ∈ [30%, 50%]

Нет, отличия нельзя считать статистически значимыми.

p-value = 0.07 > α = 0.05 → мы не отвергаем нулевую гипотезу.

Это означает: наблюдаемая разница между группами могла получиться случайно с вероятностью 7%, что выше допустимого порога в 5%.

Важно:

• p-value ≠ вероятность того, что нулевая гипотеза верна
• p-value — это вероятность получить такой же или более экстремальный результат при условии, что H0 верна
• p = 0.07 не означает «почти значимо» — порог α выбирается до начала теста и не меняется

WITH data AS (
  SELECT
    actor_login,
    created_at,
    LAG(created_at) OVER (
      PARTITION BY actor_login ORDER BY created_at
    ) AS prev_time,
    CASE
      WHEN DATEDIFF('minute', 
        LAG(created_at) OVER (PARTITION BY actor_login ORDER BY created_at),
        created_at
      ) >= 30
      OR LAG(created_at) OVER (PARTITION BY actor_login ORDER BY created_at) IS NULL
      THEN 1
      ELSE 0
    END AS session_flag
  FROM github.events
  WHERE
    created_at BETWEEN '2025-09-01' AND '2025-10-01'
    AND repo_name = 'n8n-io/n8n'
)
SELECT SUM(session_flag) AS total_sessions
FROM data;

Идея: помечаем флагом 1 каждое событие, если пауза от предыдущего ≥ 30 минут (или это первое событие). Сумма флагов = количество сессий (визитов). Используем LAG для доступа к предыдущему времени в окне по пользователю.

import pandas as pd

df['item_sum'] = df['amount'] * df['price']

result = df.groupby('store').agg(
    total_sales=('item_sum', 'sum'),
    avg_price=('price', 'mean'),
    unique_items=('item', 'nunique')
).reset_index()

print(result)

Используем groupby + agg с именованными агрегациями (named aggregation) — это более читаемый синтаксис, чем передача словаря. Сначала создаём столбец item_sum (выручка по позиции), затем агрегируем по магазинам.

import pandas as pd

df['item_sum'] = df['amount'] * df['price']

# Считаем сумму заказа (группируем по клиенту, дате и магазину)
order_totals = (
    df.groupby(['customer', 'event_dt', 'store'])
    .agg(order_sum=('item_sum', 'sum'))
    .reset_index()
)

# Средний чек на клиента
avg_check = (
    order_totals.groupby('customer')
    .agg(avg_check=('order_sum', 'mean'))
    .reset_index()
    .sort_values('avg_check', ascending=False)
)

print(avg_check.head(5))

Важно: «чек» = один заказ (уникальная комбинация клиент + дата + магазин). Сначала считаем сумму каждого заказа, потом среднее по клиенту.

WITH data AS (
  SELECT
    YEAR(s.date) AS yr,
    c.country_name,
    SUM(s.income) AS country_income
  FROM sales s
  LEFT JOIN country c ON s.city = c.city
  WHERE DATE_TRUNC('month', s.date) IN ('2022-10-01', '2023-10-01')
  GROUP BY yr, c.country_name
)
SELECT
  country_name,
  MAX(CASE WHEN yr = 2022 THEN country_income END) AS income_22,
  MAX(CASE WHEN yr = 2023 THEN country_income END) AS income_23,
  (MAX(CASE WHEN yr = 2023 THEN country_income END)
   - MAX(CASE WHEN yr = 2022 THEN country_income END))
  / NULLIF(MAX(CASE WHEN yr = 2022 THEN country_income END), 0)
  * 100 AS delta_pct
FROM data
GROUP BY country_name;

Используем условную агрегацию (MAX(CASE WHEN ...)) для pivot из строк в столбцы. NULLIF защищает от деления на ноль.

WITH cohorts AS (
  SELECT
    user_id,
    MIN(DATE_TRUNC('week', ts)) AS install_week
  FROM event_log
  WHERE event_name = 'Install'
  GROUP BY user_id
),
diff AS (
  SELECT
    ev.user_id,
    c.install_week,
    DATE_TRUNC('week', ev.ts) AS consultation_week,
    DATEDIFF('week', c.install_week, DATE_TRUNC('week', ev.ts)) AS week_diff
  FROM cohorts c
  LEFT JOIN event_log ev
    ON ev.user_id = c.user_id
    AND ev.event_name = 'Consultation'
),
cohort_size AS (
  SELECT install_week, COUNT(DISTINCT user_id) AS size
  FROM cohorts
  GROUP BY install_week
)
SELECT
  d.install_week,
  d.week_diff,
  cs.size AS cohort_size,
  COUNT(DISTINCT d.user_id) AS consultation_users
FROM diff d
JOIN cohort_size cs ON d.install_week = cs.install_week
GROUP BY d.install_week, d.week_diff, cs.size
ORDER BY d.install_week, d.week_diff;

Три CTE: когорты (неделя первого Install), интервалы (разница в неделях до Consultation), размер когорт. Финальный SELECT объединяет всё.

Декомпозиция: GMV = Количество заказов × Средний чек DAU ↑ + GMV ↓ → значит CR в покупку ↓ или средний чек ↓ (или оба)

Возможные причины:

Трафик:

• Нерелевантный трафик из рекламы (много новых пользователей, которые не покупают)
• Боты / фродовый трафик

Конверсия (CR):

• Техническая ошибка на каком-то шаге воронки
• Ошибка интеграций (платёжный шлюз, авторизация)
• Плохой релиз (UI/UX регрессия)

Средний чек:

• Ушли акции/скидки → пользователи покупают меньше
• Проблема с рекомендатором → меньше допродаж
• Перетекание пользователей в более дешёвые категории
• Сезонность

Проверить: технические метрики (error rate, время загрузки), источники трафика, воронку конверсии по шагам.

Первым делом проверить технику:

• Нет SRM (соотношение групп правильное)
• Ивенты в обеих группах доходят корректно
• Ранжирование одинаковое
• Других изменений, кроме UI, нет

Продуктовые причины падения:

1. Парадокс выбора: появление шильдика создаёт «лучших» и «худших» врачей. Пользователи хотят к «лучшему», но у него нет свободных слотов → уходят.

2. Нерелевантное распределение метки: если шильдик получили не те врачи, пользователи теряют доверие к выдаче.

3. Эффект сравнения: пользователи дольше выбирают, сравнивая «с шильдиком» vs. «без», и откладывают запись.

4. Дефицит у «лучших»: все хотят к врачам с меткой → мест нет → пользователь уходит совсем, а не записывается к другому.

SELECT e.name
FROM employer e
LEFT JOIN vacancy v ON e.employer_id = v.employer_id
GROUP BY e.name
HAVING COUNT(CASE WHEN v.active = TRUE THEN 1 END) <= 5;

Важно использовать LEFT JOIN, чтобы включить работодателей с 0 вакансий. HAVING COUNTIF(active) <= 5 (ClickHouse-синтаксис) или COUNT(CASE WHEN ...) в стандартном SQL.

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

SELECT e.name
FROM employer e
WHERE (
  SELECT COUNT(*)
  FROM vacancy v
  WHERE v.employer_id = e.employer_id AND v.active = TRUE
) <= 5;

WITH base AS (
  SELECT
    s.user_id,
    s.search_number,
    s.vacancy_position,
    ROW_NUMBER() OVER (
      PARTITION BY s.user_id, s.search_number
      ORDER BY c.ts
    ) AS click_number
  FROM search s
  INNER JOIN clicks c
    ON s.user_id = c.user_id
    AND s.search_number = c.search_number
    AND s.vacancy_id = c.vacancy_id
)
SELECT
  user_id,
  search_number,
  AVG(vacancy_position) AS avg_position
FROM base
WHERE click_number <= 3
GROUP BY user_id, search_number
HAVING COUNT(*) = 3;

JOIN search с clicks по трём ключам. ROW_NUMBER() нумерует клики по времени внутри каждого поиска. Берём первые 3, фильтруем поиски с < 3 кликами через HAVING COUNT(*) = 3.

# Итеративный подход
def factorial(n: int) -> int:
    if n < 0:
        raise ValueError('n должно быть >= 0')
    result = 1
    for i in range(1, n + 1):
        result *= i
    return result

# Рекурсивный подход
def factorial_rec(n: int) -> int:
    if n < 0:
        raise ValueError('n должно быть >= 0')
    if n <= 1:
        return 1
    return n * factorial_rec(n - 1)

# Встроенный
from math import factorial

print(factorial(5))  # 120
print(factorial(0))  # 1

Итеративный вариант предпочтительнее — нет риска переполнения стека при больших n. В Python есть math.factorial(), но на собеседовании обычно просят написать вручную.

a = [3, 1, 2]

b = a[::-1]   # Создаёт НОВЫЙ перевёрнутый список
# a = [3, 1, 2]  — не изменился
# b = [2, 1, 3]  — новый объект

a.reverse()   # Переворачивает список IN-PLACE
# a = [2, 1, 3]  — изменился
# Возвращает None

Ключевые отличия:

• a[::-1] — создаёт новый список, a не меняется. Возвращает новый список.
• a.reverse() — изменяет a на месте (in-place). Возвращает None.
• a[::-1] использует больше памяти (O(n) — копия), reverse() — O(1).

Также есть reversed(a) — возвращает итератор (ленивый, не копирует).

Когда что использовать:

• list — изменяемая коллекция с порядком (массив данных, стек)
• tuple — неизменяемые данные (координаты, ключи словаря, возврат нескольких значений)
• set — уникальные элементы, быстрый поиск O(1), операции пересечения/объединения

Проблемы метрики «среднее откликов»:

1. Чувствительна к выбросам: одна вакансия с 10000 откликов сильно сдвигает среднее.
2. Не учитывает качество откликов — много нерелевантных откликов ≠ хорошо.
3. Не учитывает тип вакансий — массовые vs. экспертные позиции несопоставимы.
4. Среднее скрывает распределение — 50% вакансий могут иметь 0 откликов.

Улучшения:

• Использовать медиану вместо среднего (устойчива к выбросам)
• Сегментировать по типу вакансии (категория, уровень, регион)
• Считать долю вакансий с хотя бы N откликами (>= 1, >= 5)

Альтернативные метрики:

• CR отклик → приглашение (качество откликов)
• Время до первого отклика (скорость)
• Доля закрытых вакансий (финальный результат)
• Время до найма (time to hire)

P(X = 0) = 0

Для непрерывного распределения вероятность попадания в любую конкретную точку равна нулю.

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

P(X = a) = 0 для любого a, но P(a ≤ X ≤ b) > 0 при a < b.

Это следствие того, что вероятность для непрерывного распределения — это интеграл от плотности, а интеграл по точке (интервалу нулевой длины) равен нулю.

Типичный стек в крупном e-commerce (на примере Детского мира):

Хранение и обработка:

• Hive + Hadoop — хранение больших объёмов данных
• ClickHouse — быстрые аналитические запросы
• PySpark — обработка данных на кластере

Сбор данных:

• Snowplow — сбор событий (event tracking)
• Data Hub — каталог данных (data discovery)

Оркестрация:

• Airflow — планирование и мониторинг ETL-пайплайнов

Визуализация:

• Superset — дашборды и BI

Эксперименты:

• Sigma или собственная AB-платформа

Особенности e-commerce: наличие офлайн-тестов (в магазинах), маркетплейс-модель, мультиканальность (онлайн + офлайн).

Подход:

1. Внутри площадки:

• Считаем общее количество объявлений с квартирами
• Определяем риелторов через:
  • Метки на объявлениях (статус «агентство»)
  • Количество объявлений с одного аккаунта (> N → агент)
  • Анализ текста описания (LLM/NLP для выявления агентского стиля)

2. Для конкурентов:

• Парсинг данных с других площадок
• Применяем аналогичную логику определения риелторов

3. Дедупликация:

• Мэтчинг объявлений между площадками по: имени пользователя, адресу, стоимости, площади, описанию
• Убираем дубликаты

4. Итог:

• Доля квартир с риелторами = квартиры_с_риелторами / все_квартиры
• Количество уникальных риелторов = уникальные аккаунты с метками

Проблема: нет контрольной группы, эффект акции смешан с индексацией цен.

Подход — Difference-in-Differences (DiD):

Используем другие города как контроль:

• Казань: CR упал на 5%
• Другие города (без акции): CR упал на 10%

Инкрементальный эффект акции: 10% − 5% = +5% (акция компенсировала часть падения)

Расчёт привлечённых клиентов:

• Прогноз без акции и без индексации: 10000 клиентов
• Коэффициент падения от индексации: −10% → 9000
• Фактическое количество: 9999
• Аплифт от акции: 9999 − 9000 = 999 клиентов

Сегментация по флагам:

• Перешли по рекламе + купили с промокодом → точно привлечённые
• Перешли по рекламе + купили без промокода → частично
• Не видели рекламу + использовали промокод → органическое распространение

Дизайн A/B теста:

Группы:

• A (контроль): не видят программу лояльности (но уровни ведём внутренне)
• B (тест): видят программу и плюшки
• Начальные уровни рассчитаны на основе исторических данных

Метрики:

• Целевые: выручка на магазин, количество заказов
• Вторичные: средний чек, количество поднятий уровня
• Защитные: качество товаров (возвраты), скорость доставки

Сложности:

• Network effects: продавцы B получают преимущество в ранжировании → это влияет на продавцов A
• Длительность: эффект лояльности проявляется не сразу
• Сплит: по продавцам, не по пользователям

Решение network effects:

• Можно сплитить по регионам или категориям
• Switchback design (попеременное включение)
• Или сравнивать когорты (до/после) с DiD

Метрики:

Целевые:

• Доля нажатий на первые N карточек товара
• CR в карточку товара в целом

Защитные:

• CR в покупку
• Скорость загрузки страницы
• Доля пустых выдач

Информационные:

• Средний чек
• Gross / Net revenue
• Количество заказов

Платформа: определить веб / приложение (или оба).

Длительность:

1. Определить текущий CR и желаемый MDE (минимальный детектируемый эффект)
2. Рассчитать размер выборки: n = (Z_α + Z_β)² × 2p(1−p) / δ²
3. Длительность = n / (дневной трафик × доля в тесте)
4. Минимум 1-2 полных недели (учёт сезонности будни/выходные)

Проверки: SRM, отсутствие пересечений между группами, z-test / t-test для оценки разницы.

WITH data AS (
  SELECT
    id,
    skill,
    salary,
    SUM(salary) OVER (ORDER BY skill DESC, salary) AS cum_sum
  FROM employee
)
SELECT id, skill, salary
FROM data
WHERE cum_sum <= 500000;

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

WITH data AS (
  SELECT
    salary,
    ROW_NUMBER() OVER (ORDER BY salary, id) AS rn
  FROM employee
),
rows AS (
  SELECT COUNT(*) AS cnt FROM employee
)
SELECT AVG(d.salary) AS median_salary
FROM data d
CROSS JOIN rows r
WHERE
  -- нечётное количество: средний элемент
  (r.cnt % 2 = 1 AND d.rn = (r.cnt + 1) / 2)
  OR
  -- чётное количество: два центральных
  (r.cnt % 2 = 0 AND d.rn IN (r.cnt / 2, r.cnt / 2 + 1));

Пример:

• [1, 2, 3, 4, 5] → rn=3 → медиана = 3
• [1, 2, 3, 4] → rn=2,3 → медиана = (2+3)/2 = 2.5

import pandas as pd

# Фильтруем записи до нужной даты
df['update_date'] = pd.to_datetime(df['update_date'])
df_filtered = df[df['update_date'] <= '2025-06-01']

# Находим последнюю дату обновления для каждого товара
last_dates = (
    df_filtered.groupby('item_id')['update_date']
    .max()
    .reset_index()
)

# Джойним обратно для получения актуальных строк
result = pd.merge(
    df_filtered,
    last_dates,
    on=['item_id', 'update_date'],
    how='inner'
)

print(result[['item_id', 'name', 'price', 'update_date']])

Альтернативный подход через sort_values + drop_duplicates:

result = (
    df_filtered
    .sort_values('update_date')
    .drop_duplicates('item_id', keep='last')
)

WITH sample AS (
  SELECT * FROM (VALUES
    ('Анна', 90), ('Борис', 90), ('Вера', 85), ('Глеб', 80)
  ) AS t(name, score)
)
SELECT
  name,
  score,
  ROW_NUMBER() OVER (ORDER BY score DESC) AS row_num,
  RANK()       OVER (ORDER BY score DESC) AS rnk,
  DENSE_RANK() OVER (ORDER BY score DESC) AS dense_rnk
FROM sample;

Результат:

• ROW_NUMBER — уникальный номер для каждой строки (порядок дубликатов недетерминирован)
• RANK — одинаковый ранг дубликатам, пропускает следующие (1, 1, 3, 4)
• DENSE_RANK — одинаковый ранг, не пропускает (1, 1, 2, 3)

-- PERCENTILE_CONT: интерполирует между значениями
SELECT
  PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY salary) AS median_cont
FROM employees;

-- PERCENTILE_DISC: берёт ближайшее реальное значение
SELECT
  PERCENTILE_DISC(0.5) WITHIN GROUP (ORDER BY salary) AS median_disc
FROM employees;

Отличия:

• PERCENTILE_CONT(0.5) — непрерывная медиана. Если количество строк чётное, интерполирует между двумя центральными значениями. Результат может не существовать в данных.
• PERCENTILE_DISC(0.5) — дискретная медиана. Возвращает реальное значение из данных (ближайшее к позиции 50%).

Пример: [10, 20, 30, 40]

• CONT: (20 + 30) / 2 = 25
• DISC: 20 (или 30, зависит от реализации)

Gaps & Islands — классическая задача SQL: найти непрерывные последовательности (islands) и пропуски (gaps) в данных.

WITH numbered AS (
  SELECT
    user_id,
    activity_date,
    activity_date - INTERVAL '1 day' * ROW_NUMBER() OVER (
      PARTITION BY user_id ORDER BY activity_date
    ) AS grp
  FROM user_activity
)
SELECT
  user_id,
  MIN(activity_date) AS island_start,
  MAX(activity_date) AS island_end,
  COUNT(*) AS consecutive_days
FROM numbered
GROUP BY user_id, grp
ORDER BY user_id, island_start;

Идея: вычитаем из даты её порядковый номер. Для последовательных дат (01, 02, 03) разница будет одинаковой (01−1, 02−2, 03−3 = одна и та же дата). Это позволяет группировать «острова».

SCD Type 2 — подход к хранению истории изменений в аналитических хранилищах. Каждая строка имеет:

• valid_from — дата начала действия
• valid_to — дата окончания (NULL или '9999-12-31' для актуальной)
• is_current — флаг актуальности

Запрос актуального состояния:

SELECT *
FROM dim_customer
WHERE is_current = TRUE;
-- или
WHERE valid_to IS NULL;
-- или
WHERE valid_to = '9999-12-31';

Запрос состояния на дату:

SELECT *
FROM dim_customer
WHERE '2024-06-15' BETWEEN valid_from AND COALESCE(valid_to, '9999-12-31');

Типы SCD:

• Type 1: перезапись (нет истории)
• Type 2: новая строка с версионностью (полная история)
• Type 3: дополнительный столбец (previous_value)

LATERAL JOIN позволяет подзапросу ссылаться на столбцы из предыдущих таблиц в FROM.

-- Топ-3 заказа для каждого клиента
SELECT c.name, o.order_date, o.amount
FROM customers c
CROSS JOIN LATERAL (
  SELECT order_date, amount
  FROM orders
  WHERE customer_id = c.id  -- ссылка на внешнюю таблицу!
  ORDER BY amount DESC
  LIMIT 3
) o;

Отличие от обычного JOIN:

• Обычный JOIN: оба источника независимы, фильтрация через ON
• LATERAL: правая часть может ссылаться на левую (как коррелированный подзапрос, но в FROM)

Когда полезен:

• Топ-N для каждой группы (без оконных функций)
• Раскрытие массивов / JSON
• Вызов табличных функций с параметрами из другой таблицы

В SQL Server аналог — CROSS APPLY / OUTER APPLY.

WITH RECURSIVE date_spine AS (
  -- Базовый случай
  SELECT DATE '2025-01-01' AS dt
  UNION ALL
  -- Рекурсивный шаг
  SELECT dt + INTERVAL '1 day'
  FROM date_spine
  WHERE dt < DATE '2025-01-31'
)
SELECT dt FROM date_spine;

Результат: 31 строка с датами от 2025-01-01 до 2025-01-31.

Зачем нужен date spine:

• LEFT JOIN с данными по дням — показать дни без событий (пропуски)
• Заполнение пробелов в временных рядах
• Генерация календаря для отчётов

Альтернатива без рекурсии (PostgreSQL):

SELECT generate_series(
  '2025-01-01'::date,
  '2025-01-31'::date,
  '1 day'::interval
)::date AS dt;

-- Через условную агрегацию (универсально)
SELECT
  month,
  SUM(CASE WHEN product = 'A' THEN revenue ELSE 0 END) AS product_a,
  SUM(CASE WHEN product = 'B' THEN revenue ELSE 0 END) AS product_b,
  SUM(CASE WHEN product = 'C' THEN revenue ELSE 0 END) AS product_c
FROM sales
GROUP BY month
ORDER BY month;

Unpivot (обратная операция):

SELECT month, 'A' AS product, product_a AS revenue FROM pivoted
UNION ALL
SELECT month, 'B', product_b FROM pivoted
UNION ALL
SELECT month, 'C', product_c FROM pivoted;

Варианты в разных СУБД:

• PostgreSQL: crosstab() из tablefunc
• SQL Server: PIVOT / UNPIVOT операторы
• ClickHouse: условная агрегация или arrayJoin

-- Вариант 1: CASE WHEN (работает везде)
SELECT
  department,
  COUNT(CASE WHEN status = 'active' THEN 1 END) AS active_count,
  AVG(CASE WHEN status = 'active' THEN salary END) AS active_avg_salary
FROM employees
GROUP BY department;

-- Вариант 2: FILTER (PostgreSQL, ClickHouse)
SELECT
  department,
  COUNT(*) FILTER (WHERE status = 'active') AS active_count,
  AVG(salary) FILTER (WHERE status = 'active') AS active_avg_salary
FROM employees
GROUP BY department;

Разница:

• CASE WHEN — стандартный SQL, работает во всех СУБД
• FILTER (WHERE) — более читаемый синтаксис, поддерживается в PostgreSQL 9.4+, ClickHouse (countIf, sumIf)
• Семантически эквивалентны, но FILTER может быть чуть эффективнее (оптимизатор знает, что это фильтрация)

ClickHouse-вариант: countIf(status = 'active'), avgIf(salary, status = 'active')

-- IN: проверяет вхождение значения в список
SELECT * FROM orders
WHERE customer_id IN (SELECT id FROM vip_customers);

-- EXISTS: проверяет существование хотя бы одной строки
SELECT * FROM orders o
WHERE EXISTS (
  SELECT 1 FROM vip_customers v WHERE v.id = o.customer_id
);

Ключевые различия:

Правило:

• Малый подзапрос → IN
• NOT IN с возможными NULL → всегда NOT EXISTS
• Современные оптимизаторы часто делают одно и то же

WITH RECURSIVE date_spine AS (
  SELECT MIN(order_date) AS dt FROM orders
  UNION ALL
  SELECT dt + INTERVAL '1 day'
  FROM date_spine
  WHERE dt < (SELECT MAX(order_date) FROM orders)
),
daily_sales AS (
  SELECT
    order_date,
    SUM(amount) AS total_sales
  FROM orders
  GROUP BY order_date
)
SELECT
  ds.dt AS date,
  COALESCE(s.total_sales, 0) AS sales
FROM date_spine ds
LEFT JOIN daily_sales s ON ds.dt = s.order_date
ORDER BY ds.dt;

Date spine генерирует все даты в диапазоне. LEFT JOIN с данными продаж показывает 0 для дней без транзакций. Это критично для:

• Графиков без пропусков
• Корректного расчёта скользящих средних
• Обнаружения аномалий (дни без продаж)

import pandas as pd

df1 = pd.DataFrame({'key': [1, 2, 3], 'val_a': ['a', 'b', 'c']})
df2 = pd.DataFrame({'key': [2, 3, 4], 'val_b': ['x', 'y', 'z']})

# inner — только совпадающие ключи (пересечение)
pd.merge(df1, df2, on='key', how='inner')   # key: 2, 3

# left — все из левой + совпадения из правой
pd.merge(df1, df2, on='key', how='left')    # key: 1, 2, 3

# right — все из правой + совпадения из левой
pd.merge(df1, df2, on='key', how='right')   # key: 2, 3, 4

# outer — все из обеих (объединение)
pd.merge(df1, df2, on='key', how='outer')   # key: 1, 2, 3, 4

# cross — декартово произведение (каждый с каждым)
pd.merge(df1, df2, how='cross')             # 3 × 3 = 9 строк

Когда использовать:

• inner — нужны только записи с совпадениями в обеих таблицах
• left — сохранить все записи основной таблицы, дополнив данными
• outer — полная картина, включая записи без пары
• cross — генерация комбинаций (например, все пары товар × магазин)

import pandas as pd

df = pd.DataFrame({
    'group': ['A', 'A', 'B', 'B'],
    'value': [10, 20, 30, 40]
})

# transform — возвращает Series того же размера, что и исходный df
df['group_mean'] = df.groupby('group')['value'].transform('mean')
# [15, 15, 35, 35] — каждой строке приписано среднее её группы

# apply — возвращает результат произвольной формы
result = df.groupby('group')['value'].apply(list)
# A: [10, 20], B: [30, 40]

Ключевые различия:

Используй transform для: нормализации, z-score, заполнения пропусков средним по группе, процента от группы. Используй apply для: сложных функций, возвращающих несколько столбцов или агрегат.

def repeat(n: int):
    """Декоратор с аргументом — повторяет функцию n раз."""
    def decorator(func):
        def wrapper(*args, **kwargs):
            return [func(*args, **kwargs) for _ in range(n)]
        return wrapper
    return decorator

@repeat(3)
def greet(name):
    return f'Привет, {name}!'

print(greet('Мир'))
# ['Привет, Мир!', 'Привет, Мир!', 'Привет, Мир!']

Как работает:

1. repeat(3) — вызывается с аргументом, возвращает decorator
2. decorator(greet) — оборачивает функцию, возвращает wrapper
3. wrapper(*args) — вызывает оригинальную функцию N раз

Три уровня вложенности нужны, потому что:

• Внешняя функция принимает параметры декоратора
• Средняя принимает декорируемую функцию
• Внутренняя принимает аргументы вызова

# Фильтрация: только чётные квадраты
squares = [x**2 for x in range(10) if x % 2 == 0]
# [0, 4, 16, 36, 64]

# Тернарный оператор: чёт/нечёт
labels = ['чёт' if x % 2 == 0 else 'нечёт' for x in range(5)]
# ['чёт', 'нечёт', 'чёт', 'нечёт', 'чёт']

# Вложенные циклы (flatten)
matrix = [[1, 2], [3, 4], [5, 6]]
flat = [x for row in matrix for x in row]
# [1, 2, 3, 4, 5, 6]

# Комбинация: фильтрация + преобразование
data = [{'name': 'Анна', 'age': 25}, {'name': 'Борис', 'age': 17}]
adults = [d['name'].upper() for d in data if d['age'] >= 18]
# ['АННА']

Правило читаемости: если comprehension не помещается в одну строку или имеет > 2 условий — лучше обычный цикл.

from datetime import datetime, timedelta

# Парсинг строки
dt = datetime.strptime('2025-03-15 14:30:00', '%Y-%m-%d %H:%M:%S')

# Форматирование обратно в строку
dt.strftime('%d.%m.%Y')  # '15.03.2025'

# Разница между датами
dt1 = datetime(2025, 3, 1)
dt2 = datetime(2025, 3, 15)
delta = dt2 - dt1  # timedelta(days=14)
print(delta.days)  # 14

# Добавление интервала
next_week = dt1 + timedelta(days=7)   # 2025-03-08
hour_ago = dt - timedelta(hours=1)    # 2025-03-15 13:30:00

# В Pandas
import pandas as pd
df['date'] = pd.to_datetime(df['date_str'])
df['month'] = df['date'].dt.month
df['weekday'] = df['date'].dt.day_name()
df['days_ago'] = (pd.Timestamp.now() - df['date']).dt.days

import pandas as pd

# Подход 1: чтение чанками
chunk_size = 100_000
results = []

for chunk in pd.read_csv('large_file.csv', chunksize=chunk_size):
    # Обрабатываем каждый чанк отдельно
    filtered = chunk[chunk['status'] == 'active']
    agg = filtered.groupby('category')['revenue'].sum()
    results.append(agg)

# Объединяем результаты
final = pd.concat(results).groupby(level=0).sum()

# Подход 2: указать типы и нужные колонки для экономии памяти
df = pd.read_csv('large_file.csv',
    usecols=['id', 'revenue', 'status'],  # только нужные колонки
    dtype={'id': 'int32', 'status': 'category'},  # оптимальные типы
    parse_dates=['date']  # парсинг дат
)

# Подход 3: Polars (быстрее Pandas для больших файлов)
import polars as pl
df = pl.scan_csv('large_file.csv').filter(
    pl.col('status') == 'active'
).collect()

Совет: category dtype для строковых колонок с малым числом уникальных значений экономит 90%+ памяти.

import pandas as pd

df = pd.DataFrame({
    'city': ['М', 'М', 'СПб', 'СПб'],
    'product': ['A', 'B', 'A', 'B'],
    'sales': [100, 200, 150, 250]
})

# pivot_table — работает с DataFrame
pd.pivot_table(df, values='sales', index='city',
               columns='product', aggfunc='sum')

# crosstab — работает с отдельными Series/массивами
pd.crosstab(df['city'], df['product'], values=df['sales'],
            aggfunc='sum')

Когда что:

• crosstab — быстрые таблицы сопряжённости, частотные таблицы
• pivot_table — когда данные уже в DataFrame и нужна агрегация по значениям

import pandas as pd
import numpy as np

df = pd.DataFrame({
    'value': [1, np.nan, 3, np.nan, 5],
    'group': ['A', 'A', 'B', 'B', 'B']
})

# 1. Заполнить константой
df['value'].fillna(0)

# 2. Заполнить средним / медианой
df['value'].fillna(df['value'].mean())
df['value'].fillna(df['value'].median())

# 3. Заполнить средним по группе
df['value'] = df.groupby('group')['value'].transform(
    lambda x: x.fillna(x.mean())
)

# 4. Forward fill / backward fill (временные ряды)
df['value'].ffill()   # предыдущим значением
df['value'].bfill()   # следующим значением

# 5. Интерполяция
df['value'].interpolate(method='linear')

# 6. Удаление строк с пропусками
df.dropna(subset=['value'])

Выбор стратегии: ffill/bfill — для временных рядов; среднее по группе — для категориальных данных; удаление — если пропусков < 5% и они случайны (MCAR).

from functools import reduce

numbers = [1, 2, 3, 4, 5]

# lambda — анонимная функция
square = lambda x: x ** 2

# map — применяет функцию к каждому элементу
list(map(lambda x: x ** 2, numbers))    # [1, 4, 9, 16, 25]
# Эквивалент: [x ** 2 for x in numbers]

# filter — оставляет элементы, для которых функция True
list(filter(lambda x: x > 3, numbers))  # [4, 5]
# Эквивалент: [x for x in numbers if x > 3]

# reduce — последовательно применяет функцию к парам
reduce(lambda a, b: a + b, numbers)     # 15 (сумма)
reduce(lambda a, b: a * b, numbers)     # 120 (произведение)

List comprehension vs map/filter:

• Comprehension — более Pythonic и читаемый
• map/filter — бывают удобнее с готовыми функциями (map(str, numbers))
• reduce — нет прямого аналога в comprehension; для суммы/произведения лучше sum()/math.prod()

name = 'Анна'
score = 95.678
count = 1234567

# Базовая подстановка
f'{name} набрала {score} баллов'

# Округление
f'{score:.2f}'         # '95.68'
f'{score:.0f}'         # '96'

# Разделители тысяч
f'{count:,}'           # '1,234,567'
f'{count:_}'           # '1_234_567'

# Процент
rate = 0.8567
f'{rate:.1%}'          # '85.7%'

# Выравнивание (ширина 20 символов)
f'{name:<20}'         # 'Анна                '  (влево)
f'{name:>20}'         # '                Анна'  (вправо)
f'{name:^20}'         # '        Анна        '  (по центру)

# Отладочный вывод (Python 3.8+)
x = 42
f'{x = }'             # 'x = 42'
f'{len(name) = }'     # 'len(name) = 4'

Центральная предельная теорема (ЦПТ):

При достаточно большом размере выборки (n → ∞), распределение выборочного среднего стремится к нормальному, независимо от распределения исходной генеральной совокупности.

X̄ ~ N(μ, σ²/n), где μ и σ² — параметры генеральной совокупности.

Почему это важно:

1. A/B тесты: даже если метрика (выручка, конверсия) распределена ненормально, среднее по большой выборке будет ~ нормальным → можно применять t-test.

2. Доверительные интервалы: формула X̄ ± Z × σ/√n работает благодаря ЦПТ.

3. Практический порог: обычно n ≥ 30 достаточно для «нормальности» среднего. Для сильно скошенных распределений может потребоваться n ≥ 100+.

4. Ограничения: ЦПТ требует конечной дисперсии. Для распределений с «тяжёлыми хвостами» (Cauchy) не работает.

Корректная интерпретация: 95% доверительный интервал [a, b] означает: если мы повторим эксперимент много раз и построим ДИ каждый раз, то 95% таких интервалов будут содержать истинное значение параметра.

Распространённые ОШИБКИ:

❌ «Вероятность 95%, что истинное значение лежит в [a, b]» → Истинное значение — фиксированное число, а не случайная величина. Оно либо в интервале, либо нет.

❌ «95% данных попадают в этот интервал» → ДИ — про параметр (среднее), а не про отдельные наблюдения.

❌ «Если расширить ДИ, увеличится точность» → Расширение увеличивает уверенность (confidence), но снижает точность (precision).

Формула: X̄ ± Z_α/2 × σ/√n

• Увеличить n → сузить ДИ (точнее)
• Увеличить уровень доверия → расширить ДИ (надёжнее, но менее точно)

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

Три главных заблуждения:

1. ❌ p-value = вероятность того, что H0 верна ✅ p-value — вероятность данных при H0, а не вероятность H0 при данных. Это P(data | H0), а не P(H0 | data).

2. ❌ p = 0.03 значит, что эффект есть с вероятностью 97% ✅ p-value ничего не говорит о вероятности альтернативной гипотезы.

3. ❌ p = 0.049 (значимо) и p = 0.051 (незначимо) — принципиально разные результаты ✅ Порог α произволен. Разница между 0.049 и 0.051 ничтожна. Важен размер эффекта и доверительный интервал.

Что делать вместо бинарного «значимо/незначимо»:

• Смотреть на доверительный интервал для размера эффекта
• Учитывать практическую значимость (MDE)
• Отчитываться о p-value как числе, не только как да/нет

Ошибка I рода (α — False Positive): Отвергли H0, когда она верна. Решили, что эффект есть, хотя его нет.

Пример: A/B тест показал значимый рост конверсии, мы раскатали изменение, но на самом деле роста не было — результат случайный.

Ошибка II рода (β — False Negative): Не отвергли H0, когда она ложна. Не заметили реальный эффект.

Пример: Новая фича реально повышает конверсию на 2%, но тест не набрал достаточно данных и показал p > 0.05. Мы отклонили хорошую идею.

Связь:

• α обычно = 0.05 (5% ложных срабатываний)
• β обычно = 0.20 → мощность = 1 − β = 0.80 (80% шанс найти реальный эффект)
• Уменьшение α → увеличение β (и наоборот)
• Увеличение выборки → уменьшение обеих ошибок

Закон больших чисел (ЗБЧ): При увеличении числа наблюдений выборочное среднее сходится к математическому ожиданию генеральной совокупности.

X̄_n → μ при n → ∞

Отличие от ЦПТ:

Пример: Бросаем монетку.

• ЗБЧ: после 10000 бросков доля орлов ≈ 0.5
• ЦПТ: если повторить серию из 100 бросков много раз, среднее количество орлов ~ N(50, 25)

Практическое следствие для аналитика: чем больше выборка, тем точнее наша оценка среднего. Но ЗБЧ не говорит, с какой скоростью идёт сходимость (это даёт ЦПТ через σ/√n).

Частотный (frequentist):

• Параметр — фиксированное число
• Вероятность — частота событий при многократном повторении
• Инструменты: p-value, доверительные интервалы, t-test
• «Данные случайны, параметр фиксирован»

Байесовский (Bayesian):

• Параметр — случайная величина с распределением
• Вероятность — степень уверенности
• Инструменты: prior + likelihood → posterior, credible intervals
• «Данные фиксированы, параметр случаен»

Когда что:

Примеры ложных корреляций:

1. Продажи мороженого и утопления: оба растут летом. Причина — скрытая переменная (confounding variable): температура воздуха.

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

3. Потребление сыра на душу населения и количество смертей от запутывания в простынях: spurious correlation — случайное совпадение трендов при большом количестве переменных.

Почему возникают:

• Confounding (скрытая переменная) — Z влияет и на X, и на Y
• Reverse causation — Y → X, а не X → Y
• Spurious — случайное совпадение при множественных сравнениях
• Selection bias — выборка не репрезентативна

Как установить причинность: рандомизированный контролируемый эксперимент (A/B тест).

Нормальное распределение N(μ, σ²):

Свойства:

• Симметрично относительно μ (среднее = медиана = мода)
• Колоколообразная форма (bell curve)
• Полностью определяется двумя параметрами: μ (среднее) и σ (стд. отклонение)
• Сумма нормальных величин — тоже нормальная
• Хвосты уходят в бесконечность, но быстро убывают

Правило 68-95-99.7 (эмпирическое правило):

• 68% данных в пределах μ ± 1σ
• 95% данных в пределах μ ± 2σ
• 99.7% данных в пределах μ ± 3σ

Примеры в аналитике:

• Рост людей ~ N(170, 10²) → 95% людей ростом 150-190 см
• Среднее время на сайте (после логарифмирования)
• Ошибки измерений

Когда НЕ нормальное: выручка (right-skewed), время между событиями (экспоненциальное), количество событий (Пуассон).

1. IQR-метод (межквартильный размах):

Q1 = df['value'].quantile(0.25)
Q3 = df['value'].quantile(0.75)
IQR = Q3 - Q1

lower = Q1 - 1.5 * IQR
upper = Q3 + 1.5 * IQR

outliers = df[(df['value'] < lower) | (df['value'] > upper)]

2. Z-score (стандартное отклонение):

mean = df['value'].mean()
std = df['value'].std()
df['z_score'] = (df['value'] - mean) / std

outliers = df[df['z_score'].abs() > 3]  # > 3σ

3. Перцентильный метод:

lower = df['value'].quantile(0.01)  # 1-й перцентиль
upper = df['value'].quantile(0.99)  # 99-й перцентиль

Когда какой:

• IQR — устойчив к выбросам (робастный), хорош для скошенных данных
• Z-score — предполагает нормальность, чувствителен к самим выбросам
• Перцентили — просто, контролируемый порог, часто используется в A/B тестах

Bootstrap — метод статистики, основанный на многократной ресемплинге с возвращением из имеющейся выборки.

Алгоритм:

1. Из выборки размера n берём n элементов с возвращением (некоторые повторятся, некоторые не войдут)
2. Считаем нужную статистику (среднее, медиану, разницу средних)
3. Повторяем 1000-10000 раз
4. Получаем распределение статистики → строим ДИ

import numpy as np

def bootstrap_ci(data, n_bootstrap=10000, ci=95):
    stats = []
    for _ in range(n_bootstrap):
        sample = np.random.choice(data, size=len(data), replace=True)
        stats.append(np.mean(sample))
    lower = np.percentile(stats, (100 - ci) / 2)
    upper = np.percentile(stats, 100 - (100 - ci) / 2)
    return lower, upper

Когда использовать:

• Распределение неизвестно или ненормальное
• Маленькая выборка
• Сложные статистики (медиана, отношение метрик)
• Нет аналитической формулы для ДИ

CUPED (Controlled-experiment Using Pre-Experiment Data) — метод снижения дисперсии в A/B тестах за счёт использования данных до эксперимента.

Идея: если мы знаем поведение пользователя ДО теста, мы можем «вычесть» его индивидуальные особенности и оставить только эффект изменения.

Формула: Ŷ_cuped = Y − θ × (X − X̄)

где:

• Y — метрика во время эксперимента
• X — та же метрика до эксперимента (ковариата)
• θ = Cov(X, Y) / Var(X)

Зачем:

• Снижает дисперсию → уменьшает необходимый размер выборки
• Тест может длиться короче (или детектировать меньший эффект)
• Типичное снижение дисперсии: 30-50%

Требования:

• Ковариата должна коррелировать с метрикой
• Ковариата НЕ должна зависеть от эксперимента (берётся ДО)
• Не меняет E[Y], только уменьшает Var[Y]

AA-тест (bucket-тест) — эксперимент, где обе группы получают одинаковый опыт (без изменений). Цель — проверить корректность системы сплитования.

Зачем нужен:

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

2. Проверка метрик: убедиться, что при отсутствии изменений метрики не показывают статистически значимой разницы.

3. Калибровка: оценить уровень «шума» в метриках — если AA-тест показывает разницу, что-то сломано.

Что проверяем:

• Соотношение размеров групп (SRM — Sample Ratio Mismatch)
• p-value по ключевым метрикам (должен быть > 0.05)
• Распределение ковариат (возраст, платформа) одинаковое в группах

Красный флаг: если в AA-тестах часто (> 5% случаев) получаем p < 0.05, сплитование сломано.

Частота: запускать AA-тест при настройке новой AB-платформы и периодически для мониторинга.

SRM (Sample Ratio Mismatch) — ситуация, когда фактическое соотношение пользователей в группах A/B теста не совпадает с ожидаемым (например, 50/50).

Диагностика:

from scipy.stats import binomtest

n_control = 10200
n_treatment = 9800
n_total = n_control + n_treatment

# Проверяем, что доля контроля ≈ 0.5
result = binomtest(n_control, n_total, p=0.5)
print(f'p-value: {result.pvalue:.4f}')
# Если p < 0.001 — SRM!

Причины SRM:

• Баг в системе рандомизации
• Разная скорость загрузки страниц → пользователи уходят до трекинга
• Боты распределены неравномерно
• Перетекание между группами (один пользователь в разных группах)
• Фильтрация данных после сплита (разная логика для групп)

Что делать:

• Не интерпретировать результаты теста — они невалидны
• Найти и устранить причину
• Перезапустить тест
• НИКОГДА не «подгонять» результат под SRM

MDE — минимальный эффект, который тест способен обнаружить при заданных α, β и размере выборки.

Формула размера выборки (на каждую группу):

n = (Z_α/2 + Z_β)² × 2σ² / δ²

где:

• Z_α/2 = 1.96 (при α = 0.05)
• Z_β = 0.84 (при β = 0.20, мощность 80%)
• σ² — дисперсия метрики
• δ — абсолютный MDE

Пример расчёта:

from scipy.stats import norm
import numpy as np

def sample_size(baseline, mde_relative, alpha=0.05, power=0.80):
    """Для конверсии (бинарная метрика)."""
    p = baseline
    delta = baseline * mde_relative
    z_alpha = norm.ppf(1 - alpha / 2)  # 1.96
    z_beta = norm.ppf(power)            # 0.84
    n = (z_alpha + z_beta)**2 * 2 * p * (1 - p) / delta**2
    return int(np.ceil(n))

# Конверсия 5%, хотим детектировать рост на 10% (до 5.5%)
print(sample_size(0.05, 0.10))  # ~31234 на группу

Длительность теста = n × 2 / дневной трафик

Проблема: если тестируем 20 метрик при α = 0.05, ожидаем ~1 ложноположительный результат даже без реального эффекта.

P(хотя бы 1 ложное срабатывание) = 1 − (1 − 0.05)²⁰ ≈ 64%

Методы коррекции:

1. Бонферрони: α_adj = α / m (m — количество сравнений)

   • 20 метрик: α_adj = 0.05 / 20 = 0.0025
   • Плюс: простой, консервативный
   • Минус: слишком строгий при большом m

2. Holm-Bonferroni: step-down процедура

   • Менее консервативный, чем Бонферрони
   • Сортируем p-value, сравниваем с α/(m−k+1)

3. FDR (Benjamini-Hochberg): контролирует долю ложных среди всех отвергнутых

   • Менее строгий, больше мощности
   • Подходит для exploratory analysis

4. Разделение метрик:

   • 1-2 основные (primary) — полная коррекция
   • Защитные (guardrail) — без коррекции, но только для мониторинга
   • Информационные — для анализа, без принятия решений

Алгоритм определения длительности:

1. Определить метрики и baseline (текущее значение)
2. Определить MDE — минимальный эффект, который хотим поймать
3. Рассчитать размер выборки: n = f(α, β, σ², MDE)
4. Длительность = n × 2 / дневной трафик

Факторы, влияющие на длительность:

Дополнительные ограничения:

• Минимум 1-2 полных недели (сезонность будни/выходные)
• Novelty/primacy эффекты — первые 1-2 недели результат может быть нерепрезентативен
• Праздники и акции — исключить или увеличить длительность
• Нельзя останавливать досрочно при peeking (если не используется sequential testing)

Guardrail metrics — защитные метрики, которые не должны значимо ухудшиться при раскатке изменения. Мы не оптимизируем их, а мониторим.

Примеры для e-commerce:

Техническике:

• Скорость загрузки страницы (Core Web Vitals)
• Error rate (500-ки, JS-ошибки)
• Crash rate (мобильные приложения)

Пользовательские:

• Bounce rate
• Количество жалоб в поддержку
• Доля возвратов
• Churn rate

Бизнесовые:

• Средний чек (если оптимизируем конверсию)
• Конверсия (если оптимизируем средний чек)
• Revenue per user (общая выручка)

Как использовать:

• Гвардрейлы не участвуют в принятии решения о раскатке (если основная метрика выросла)
• Но если гвардрейл значимо упал — стоп, разбираемся
• Не применяем коррекцию множественного тестирования к гвардрейлам

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

Как работает:

1. Делим пользователей по важному признаку (платформа, страна, сегмент)
2. Внутри каждой страты рандомизируем 50/50
3. Гарантируем одинаковое распределение признака в группах

Зачем:

• Уменьшает дисперсию → уменьшает необходимый размер выборки
• Гарантирует баланс по ключевым признакам
• Особенно полезно при малом трафике

Пример: Платформа (iOS/Android) сильно влияет на конверсию. Без стратификации: может случайно попасть 60% iOS в контроль. Со стратификацией: ровно 50/50 внутри каждой платформы.

Когда полезна:

• Есть признак с сильным влиянием на метрику
• Малый трафик (< 10000 в группе)
• Высокая гетерогенность аудитории

Когда не нужна:

• Большой трафик (рандомизация и так сбалансирует)
• Нет явных сегментов с разным поведением

Novelty effect (эффект новизны): Пользователи активнее взаимодействуют с новым вариантом просто потому, что он новый. Метрика B завышена в начале теста.

Пример: Новая кнопка яркого цвета → больше кликов в первые дни, потом привыкают.

Primacy effect (эффект привычки): Пользователи продолжают вести себя по-старому, игнорируя изменения. Метрика B занижена в начале.

Пример: Переместили навигацию → пользователи не замечают, ходят по старым путям.

Как бороться:

1. Достаточная длительность — минимум 2-3 недели, чтобы эффекты «устаканились».

2. Анализ по когортам:

   • Новые пользователи (не видели старый вариант) — нет primacy/novelty
   • Старые пользователи — подвержены эффектам
   • Если метрика разная для когорт — эффект присутствует

3. Динамика по дням: построить график метрики по дням теста. Если тренд виден — эффект не «устоялся».

4. Тестировать только на новых пользователях (если возможно).

AA-тест — эксперимент без изменений: обе группы видят одинаковый вариант.

Цель: убедиться, что инфраструктура A/B тестирования работает корректно.

Что проверяем:

1. SRM (Sample Ratio Mismatch):

   • Соотношение групп = ожидаемому (50/50)?
   • χ²-тест или binomial test

2. Баланс ковариат:

   • Возраст, платформа, регион — одинаково распределены?

3. Метрики:

   • p-value по основным метрикам > 0.05?
   • Если часто p < 0.05 — сплитование сломано

4. Историческая частота:

   • Запускаем 100 AA-тестов → ожидаем ~5% ложных срабатываний
   • Если > 10% — проблема

Когда запускать:

• При настройке новой AB-платформы
• После изменений в логике рандомизации
• Регулярно (раз в квартал) для мониторинга

Фреймворк анализа падения DAU:

1. Определить масштаб:

• Когда именно началось падение? (день, час)
• Все платформы или одна (web/iOS/Android)?
• Все регионы или один?

2. Внешние факторы:

• Сезонность (праздники, каникулы)
• Действия конкурентов
• Изменения в App Store / Google Play (обновление рейтинга)

3. Технические проблемы:

• Аварии серверов, деплои, увеличение латенси
• Баги в трекинге (данные не доходят)
• CDN/DNS проблемы

4. Продуктовые изменения:

• Новые релизы (регрессия UX)
• Изменения в онбординге
• A/B тесты с негативным эффектом

5. Маркетинг:

• Остановка рекламных кампаний
• Изменение каналов привлечения
• Пуш-уведомления (отключили/поменяли)

6. Декомпозиция DAU: DAU = Новые + Вернувшиеся + Удержанные

• Какая составляющая упала?
• Если новые → проблема привлечения
• Если удержанные → проблема продукта

Иерархия метрик для рекомендаций:

North Star (бизнес-цель):

• Revenue per user (выручка на пользователя)

Целевые (primary):

• CR просмотр рекомендации → клик на товар
• CR клик → добавление в корзину
• CR корзина → покупка
• Доля выручки от рекомендованных товаров

Качество рекомендаций:

• CTR блока рекомендаций
• Разнообразие (% уникальных категорий в рекомендациях)
• Покрытие каталога (% товаров, которые попадают в рекомендации)
• Средняя позиция клика (ближе к 1 — лучше)

Защитные (guardrails):

• Общая конверсия сайта (не упала ли?)
• Bounce rate главной страницы
• Скорость загрузки (рекомендации не замедляют страницу?)
• Доля возвратов рекомендованных товаров

Долгосрочные:

• 7-day / 30-day retention
• LTV пользователей, кликавших на рекомендации

North Star Metric (NSM) — единственная метрика, которая лучше всего отражает ценность, которую продукт даёт пользователям, и коррелирует с долгосрочным ростом бизнеса.

Критерии хорошей NSM:

1. Отражает ценность для пользователя (не только для бизнеса)
2. Является leading indicator (предсказывает будущий рост)
3. Все команды могут на неё влиять
4. Понятна всей компании

Примеры:

Антипаттерны:

• Revenue как NSM (lagging, не отражает ценность для пользователя)
• Vanity metrics (регистрации без активации)
• Несколько NSM (теряется фокус)

Как выбрать:

1. Определить ключевое действие, показывающее, что пользователь получил ценность
2. Проверить корреляцию с retention и revenue
3. Убедиться, что метрика растёт при росте бизнеса

Фреймворк анализа воронки:

1. Определить шаги воронки: Главная → Каталог → Карточка товара → Корзина → Оформление → Оплата → Подтверждение

2. Найти проблемный шаг:

• Построить конверсию каждого шага: сейчас vs. неделю/месяц назад
• Где наибольшее абсолютное падение?
• Учесть сезонность (сравнивать с аналогичным периодом)

3. Сегментировать проблемный шаг:

• По платформе (web/iOS/Android)
• По устройству (desktop/mobile)
• По источнику трафика
• По сегменту пользователей (новые/старые)
• По категории товаров

4. Искать причину:

• Технические: ошибки, увеличение времени загрузки, баги
• Продуктовые: изменения UI, A/B тесты
• Внешние: конкуренты, сезонность, цены

5. Дополнительные инструменты:

• Session replay (Hotjar, FullStory)
• Heatmaps (клики, скролл)
• Error logs

Правило: начинать с самого широкого среза, сужать к конкретному сегменту + шагу.

Виды Retention:

1. Classic (N-day) Retention: вернулся именно в день N

   • Day 1, Day 7, Day 30
   • Самый строгий, может быть «шумным»

2. Rolling Retention: вернулся в день N или позже

   • Всегда ≥ Classic Retention
   • Показывает «живых» пользователей

3. Bracket Retention: вернулся в интервале [N, M]

   • Week 1 (день 1-7), Week 2 (день 8-14)
   • Сглаживает шум Classic Retention

Построение:

WITH cohorts AS (
  SELECT user_id,
    DATE_TRUNC('week', MIN(first_event)) AS cohort
  FROM events GROUP BY user_id
),
activity AS (
  SELECT DISTINCT user_id,
    DATE_TRUNC('week', event_date) AS active_week
  FROM events
)
SELECT
  c.cohort,
  COUNT(DISTINCT c.user_id) AS cohort_size,
  COUNT(DISTINCT CASE WHEN a.active_week = c.cohort + INTERVAL '1 week'
    THEN a.user_id END) AS retained_w1
FROM cohorts c
LEFT JOIN activity a ON c.user_id = a.user_id
GROUP BY c.cohort;

Benchmarks: Day 1: 25-40%, Day 7: 10-20%, Day 30: 5-10% (зависит от продукта).

Ключевые метрики unit-экономики:

LTV (Lifetime Value):

• LTV = ARPU × Lifetime
• Или: LTV = ARPU / Churn Rate
• Или: LTV = (Средний чек × Частота покупок × Маржа) / Churn Rate

CAC (Customer Acquisition Cost):

• CAC = Маркетинговые расходы / Количество привлечённых клиентов

Прибыльность:

• LTV > CAC → продукт прибылен
• LTV / CAC ≥ 3 → хороший показатель (правило SaaS)
• Payback period = CAC / (ARPU × Маржа) — за сколько месяцев окупается привлечение

Пример:

• CAC = 500 руб. (реклама)
• ARPU = 200 руб./мес.
• Маржа = 30%
• Churn = 10%/мес.
• LTV = 200 × 0.3 / 0.1 = 600 руб.
• LTV/CAC = 600/500 = 1.2 — на грани
• Payback = 500 / (200 × 0.3) ≈ 8.3 мес.

Рычаги улучшения: снизить CAC, увеличить ARPU, снизить churn, повысить маржу.

Каннибализация — когда новая фича «забирает» трафик/конверсии у существующих разделов, а общий результат не растёт.

Признаки каннибализации:

1. Метрика новой фичи растёт, но общая (revenue, orders) — нет
2. Трафик в смежных разделах падает пропорционально росту нового
3. Те же пользователи, те же товары — просто другой путь

Как проверить:

1. A/B тест — золотой стандарт. Сравнить суммарные метрики (не только фичевые).

2. Анализ перетекания:

   • Откуда приходят пользователи в «Популярное»?
   • Покупали бы они эти товары без раздела?
   • Пересечение товаров: «Популярное» vs. поиск/каталог

3. Инкрементальность:

   • Новые покупатели, которых раньше не было?
   • Новые товары в корзине (а не замена старых)?

4. Net Uplift:

   • Рост «Популярное» − Падение других разделов = Net Uplift
   • Если Net Uplift ≈ 0 → каннибализация
   • Если Net Uplift > 0 → реальный рост

RICE = Reach × Impact × Confidence / Effort

Пример:

Решение: фильтры → пуши → профиль.

Ограничения RICE:

• Субъективность Impact и Confidence
• Не учитывает зависимости между фичами
• Не учитывает стратегическую важность

Методы разделения сезонности и тренда:

1. Визуальный анализ:

• Построить график метрики за 2+ года
• Если паттерн повторяется в те же месяцы — сезонность

2. Year-over-Year (YoY) сравнение:

• Метрика этого месяца vs. того же месяца прошлого года
• Если YoY рост стабилен → тренд
• Если YoY рост только в определённые месяцы → сезонность

3. Декомпозиция временного ряда:

from statsmodels.tsa.seasonal import seasonal_decompose

result = seasonal_decompose(df['metric'], period=12)
result.plot()  # Показывает: тренд + сезонность + остаток

4. Скользящее среднее:

• MA(12) для месячных данных сглаживает сезонность
• Если MA растёт → есть тренд

5. Контрольная группа:

• Сравнить с конкурентами / рынком
• Если у всех рост — сезонность рынка
• Если только у нас — наш тренд

Практический совет: всегда отчитываться и YoY, и MoM. YoY убирает сезонность, MoM показывает динамику.

Фреймворк Go/No-Go:

1. Оценить значимость:

• Основная метрика: насколько значим рост? p-value, ДИ, размер эффекта
• Защитная метрика: насколько значимо падение? Может быть шумом

2. Оценить масштаб:

• Рост основной: +5% конверсии = X руб./мес.
• Падение защитной: −2% retention = Y руб./мес.
• X > Y? → может быть Go

3. Проверить причинно-следственную связь:

• Падение защитной связано с изменением или случайно?
• Есть ли логическое объяснение?
• Сегментный анализ: во всех сегментах или в одном?

4. Варианты решений:

• Go — если защитная упала незначимо и объяснимо
• No-Go — если защитная критична (revenue, churn)
• Partial rollout — раскатать на 10-20%, мониторить защитную
• Iterate — доработать фичу, чтобы устранить негативный эффект

5. Документировать:

• Записать решение, обоснование, ответственного
• Установить мониторинг после раскатки

Data Lineage — отслеживание пути данных от источника до конечного отчёта/дашборда: откуда пришли данные, как трансформировались, где используются.

Зачем аналитику:

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

2. Impact analysis: перед изменением таблицы — понять, какие отчёты/дашборды пострадают.

3. Дебаг: метрика в отчёте отличается от метрики в другом отчёте — lineage показывает, что у них разные источники или разная логика агрегации.

4. Compliance: регуляторные требования (GDPR) — где хранятся персональные данные.

Инструменты:

• dbt (встроенный lineage graph)
• Apache Atlas
• DataHub (LinkedIn)
• Monte Carlo (data observability)
• Встроенные средства Airflow (task dependencies)

Уровни: Column-level lineage (самый детальный) → Table-level → Pipeline-level.

Data Warehouse (DWH) — централизованное хранилище всех структурированных данных компании.

Data Mart — подмножество DWH, оптимизированное для конкретного отдела/задачи.

Типичная архитектура:

Источники → ETL → DWH (raw/staging) → DWH (core) → Data Marts → Дашборды

Примеры витрин:

• dm_orders — агрегированные заказы для продуктовой команды
• dm_marketing — данные по каналам привлечения
• dm_finance — выручка, расходы, P&L

Зачем витрины:

• Быстрый доступ (предагрегированные данные)
• Понятная модель для бизнес-пользователей
• Контроль доступа (не все видят сырые данные)

Группы метрик e-commerce:

Привлечение:

• CAC (Customer Acquisition Cost)
• CPC, CPA, ROAS (рекламные)
• Органический трафик, SEO-позиции

Активация:

• CR регистрация → первая покупка
• Time to first purchase
• Доля активированных (совершили целевое действие)

Конверсия (воронка):

• CR каталог → карточка → корзина → заказ → оплата
• Cart abandonment rate
• Средний чек (AOV)

Удержание:

• Retention (Day 7, 30, 90)
• Repeat purchase rate
• Churn rate
• NPS / CSAT

Монетизация:

• GMV (Gross Merchandise Value)
• Revenue, ARPU, ARPPU
• LTV
• Take rate (для маркетплейсов)

Операционные:

• Время доставки
• Доля возвратов
• NPS доставки
• Наличие товаров (in-stock rate)

North Star (зависит от стадии):

• Рост: количество заказов
• Зрелость: GMV или repeat purchase rate

Ключевые soft-skills аналитика:

1. Storytelling с данными:

   • Начинай с вывода, не с методологии
   • «Выручка упала на 15% из-за X» > «Я проанализировал 5 таблиц...»
   • Один график лучше десяти

2. Умение задавать вопросы:

   • «Зачем нужен этот отчёт?» > «Какие поля нужны?»
   • Понимать контекст задачи, не только техническую спецификацию

3. Управление ожиданиями:

   • Оценка сроков: всегда × 1.5
   • Промежуточные результаты лучше, чем долгое молчание
   • Говорить «нет» или «нужно больше времени»

4. Работа со стейкхолдерами:

   • Разный уровень детализации для CEO, PM, разработчика
   • CEO: «Что делать?» PM: «Почему так?» Dev: «Как воспроизвести?»

5. Структура презентации результатов:

   • Контекст → Проблема → Анализ → Выводы → Рекомендации
   • Дашборд: ключевая метрика сверху, детали ниже
   • Всегда: «So what?» — что делать с этими данными?

ETL (Extract → Transform → Load):

• Данные трансформируются ДО загрузки в хранилище
• Трансформация на промежуточном сервере
• Классический подход (Informatica, SSIS)

ELT (Extract → Load → Transform):

• Данные загружаются в хранилище «как есть», трансформируются ТАМ
• Трансформация силами хранилища (SQL)
• Современный подход (dbt + BigQuery/Snowflake)

Когда ETL: legacy-системы, строгие требования к качеству данных до загрузки, ограниченный бюджет на хранилище.

Когда ELT: облачные хранилища (BigQuery, Snowflake), нужна гибкость, dbt-workflow.

Основные проверки качества данных:

1. Полнота (Completeness):

• Доля NULL в ключевых полях < порога
• Количество строк в пределах ожидаемого диапазона
• Все ожидаемые даты/партиции присутствуют

2. Уникальность (Uniqueness):

• Primary key действительно уникален
• Нет дубликатов по бизнес-ключу

3. Свежесть (Freshness):

• MAX(updated_at) не старше N часов
• Данные за сегодня уже загружены

4. Валидность (Validity):

• Значения в допустимых диапазонах (цена > 0, возраст 0-120)
• Enum-поля содержат только допустимые значения
• Форматы дат, email, телефонов

5. Консистентность (Consistency):

• Сумма по детализации = итогу в агрегате
• Foreign keys существуют в справочниках
• Метрики между таблицами сходятся

Инструменты:

• dbt tests (unique, not_null, accepted_values, relationships)
• Great Expectations
• Soda
• Monte Carlo (anomaly detection)

Практика: критичные проверки блокируют пайплайн, некритичные — алертят в Slack.

Принципы хорошего дашборда:

1. Один дашборд — одна задача:

• Мониторинг (ежедневный взгляд на здоровье продукта)
• Анализ (drill-down в конкретную проблему)
• Отчётность (еженедельный/месячный отчёт руководству)

2. Иерархия информации:

• Сверху: ключевые метрики (KPI) с динамикой
• Середина: графики трендов и разбивки
• Низ: детальные таблицы

3. Принцип 5 секунд:

• За 5 секунд должно быть понятно: «всё хорошо» или «есть проблема»
• Цветовая индикация: зелёный/жёлтый/красный

Антипаттерны:

• ❌ 50 графиков на одном экране
• ❌ Дашборд, который никто не смотрит
• ❌ Только абсолютные числа без контекста (без сравнения)
• ❌ Круговые диаграммы с 15 сегментами
• ❌ 3D-графики

Чеклист:

• Есть заголовок и описание
• Указан период данных и время обновления
• Ключевые метрики видны без скролла
• Есть фильтры (период, сегмент)
• Графики подписаны (оси, легенды)

Работа с разными стейкхолдерами:

С Product Manager:

• Помогай формулировать гипотезы на данных
• Предлагай метрики, а не просто считай запрошенные
• Предупреждай о подводных камнях AB-тестов
• Ошибка: делать всё, что просят, без вопроса «зачем?»

С разработчиками:

• Чётко формулируй требования к данным (какие ивенты нужны, какие поля)
• Помогай с ТЗ на аналитические ивенты
• Ошибка: «мне нужны данные» без спецификации

С руководством:

• Выводы, не процесс: «Нужно делать X, потому что Y»
• Один слайд > 10 таблиц
• Риски и неопределённость — честно
• Ошибка: 40-слайдовая презентация с подробным SQL

Типичные ошибки аналитика:

1. Отвечать на запрос, не поняв настоящую задачу
2. Перфекционизм: 2 недели на отчёт, который нужен был вчера
3. Не уточнять deadline и приоритет
4. Не документировать решения и предпосылки
5. Молчать, если задача невыполнима или бессмысленна

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

Примеры:

1. Недокументированные пайплайны: никто не знает, что делает скрипт 3-летней давности, но от него зависят 5 дашбордов.

2. Дубликаты метрик: 3 таблицы считают revenue по-разному. Какая правильная?

3. Сломанные тесты: проверки качества отключены, потому что «часто падали».

4. Legacy-код: SQL-запросы на 500 строк без комментариев.

5. Прямые запросы к production DB: аналитики ходят в прод вместо хранилища.

Способы борьбы:

• Документация: каждая таблица/метрика — описание + владелец
• Data contracts: соглашение с разработчиками о формате данных
• Мониторинг: алерты на аномалии, freshness checks
• Рефакторинг: выделять время (20%) на улучшение инфраструктуры
• Code review: для SQL/dbt моделей так же, как для кода
• Deprecation: явно помечать устаревшие таблицы и удалять через N месяцев

Зачем документировать:

• Новый аналитик должен за день понять, как устроена система
• При инциденте быстро найти владельца и логику расчёта
• Избежать «bus factor = 1» (один человек знает всё)

Что документировать:

1. Таблицы/модели:

   • Описание: что хранит, зачем, кто владелец
   • Описание полей: тип, значения, бизнес-смысл
   • Связи: откуда данные, куда используются

2. Пайплайны:

   • DAG: визуальная схема зависимостей
   • Расписание: когда запускается
   • SLA: когда данные должны быть готовы

3. Метрики:

   • Определение: точная формула
   • Источник: из какой таблицы
   • Ограничения: что не учитывает

Инструменты:

• dbt docs — автогенерация документации из YAML-описаний
• DataHub / Amundsen — каталог данных с lineage
• Notion / Confluence — для бизнес-контекста
• README в репозитории — для технических деталей

Правило: документация рядом с кодом (dbt YAML, SQL-комментарии) > отдельный документ (быстро устаревает).

Шаги проектирования A/B теста:

1. Определить метрику успеха:

• Первичная: CTR (клики по рекомендациям), конверсия в покупку
• Guardrail: GMV, retention, DAU — убедиться, что не роняем

2. Сегментация и рандомизация:

• Единица рандомизации: user_id (не сессия — избегаем перекрёстного загрязнения)
• Стратифицированная выборка по активности пользователей

3. Размер выборки:

• Через калькулятор мощности: MDE = 5%, α = 0.05, power = 0.8
• Минимум 2 недели для учёта недельной сезонности

4. Критерии остановки:

• Досрочная остановка только при guardrail-нарушении (SRM или значимое падение GMV)
• Не пикать p-value каждый день — нужен sequential testing или фиксированный срок

5. Анализ после теста:

• Проверка SRM (Sample Ratio Mismatch) перед интерпретацией
• t-test или bootstrap для метрики
• Анализ по сегментам (новые vs. старые пользователи)

Фреймворк диагностики:

1. Проверить данные, не бизнес:

• Нет ли проблем в пайплайне сбора данных? (задержки, потеря событий)
• Корректно ли работает трекинг?

2. Декомпозиция метрики:

• DAU = новые + вернувшиеся + реактивированные
• Что именно упало? Новые пользователи или удержание?

3. Сегментация:

• По платформе (iOS / Android / web)
• По географии, каналу привлечения, версии приложения
• Позволяет локализовать источник

4. Внешние факторы:

• Был ли релиз? Изменения в пуш-уведомлениях? Маркетинговые кампании?
• Праздники, сезонность?

5. Гипотезы по приоритету:

1. Технический сбой (быстро проверяется)
2. Деградация UX после релиза
3. Изменение в привлечении (снизился бюджет / ухудшились объявления)
4. Органическое снижение (тренд)

Метрики поиска по уровням:

Релевантность (offline):

• nDCG (Normalized Discounted Cumulative Gain) — взвешенная точность ранжирования
• Precision@K — доля релевантных результатов в топ-K

Поведение пользователей (online):

• CTR по позиции — кликабельность каждого места выдачи
• Click-through rate на запрос — доля запросов, где хотя бы один результат кликнули
• Zero-result rate — доля запросов без результатов
• Abandoned search rate — открыл поиск, ввёл запрос, но ушёл без клика

Бизнес-метрики:

• Конверсия: поиск → покупка
• GMV через поиск / Total GMV
• Средний чек через поисковый канал

Как собирать:

• Логировать event: search_query, search_result_shown, search_result_click, add_to_cart_from_search
• Ключ: связать запрос → клик → покупку через session_id

Проблема: промокоды могут быть инкрементальными (привлекают новых / удерживают уходящих) или каннибализирующими (дают скидку тем, кто купил бы и так).

Подход 1 — Анализ без эксперимента:

• Сегментировать пользователей по первому типу покупки (с промо / без)
• Сравнить LTV-кривые (retention × средний чек) по когортам
• Слабость: selection bias — промо могли получить изначально более ценные сегменты

Подход 2 — A/B тест (предпочтительный):

• Случайно разделить аудиторию: получают промо (B) vs. не получают (A)
• Единица рандомизации: user_id
• Метрики: LTV за 30/60/90 дней, retention, GMV, частота покупок
• Длительность: минимум 4-8 недель для LTV-сигнала

Дополнительный анализ:

• Сегментировать по «ценности» пользователя до промо — каннибализация выше среди лояльных
• Incremental Revenue = Revenue(B) - Revenue(A) — окупает ли скидку?

Фреймворк ICE-score с данными:

ICE = Impact × Confidence × Ease (каждый 1–10)

Impact (влияние):

• Оценить по историческим данным: сколько пользователей затрагивает фича?
• Если есть похожие прецеденты — смотри на delta-метрику из тех A/B тестов
• Если нет — экспертная оценка + сравнение с бенчмарками

Confidence (уверенность):

• Есть ли данные, что пользователи испытывают эту боль? (опросы, heat maps, funnel drops)
• Качество гипотезы: основана на данных или на мнении?

Ease (сложность):

• Оценка от разработки (story points или T-shirt size)

Процесс:

1. Собрать ICE-таблицу вместе с командой
2. Нормировать оценки (избежать «всё 10»)
3. Отсортировать по ICE-score
4. Проверить: нет ли зависимостей между фичами?
5. Топ-3 взять в спринт

Дополнительно: учитывать strategic alignment — даже низко-оценённая фича может быть важна для OKR.

SELECT u.id, u.name
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE o.id IS NULL;

Альтернатива через NOT EXISTS:

SELECT id, name
FROM users u
WHERE NOT EXISTS (
  SELECT 1 FROM orders o WHERE o.user_id = u.id
);

LEFT JOIN + IS NULL и NOT EXISTS эквивалентны по результату, но оптимизатор может выбирать разные планы. На больших таблицах NOT EXISTS часто работает быстрее.

SELECT
  category,
  revenue,
  ROUND(revenue * 100.0 / SUM(revenue) OVER (), 2) AS pct
FROM sales
ORDER BY revenue DESC;

SUM(revenue) OVER () — оконная функция без секции PARTITION: суммирует по всем строкам. Результат можно также получить через CTE с предварительным подсчётом итога, но оконная функция короче.

SELECT category, name, revenue
FROM (
  SELECT
    category, name, revenue,
    ROW_NUMBER() OVER (PARTITION BY category ORDER BY revenue DESC) AS rn
  FROM products
) ranked
WHERE rn <= 3;

ROW_NUMBER() даёт уникальный номер внутри каждой группы. Если нужно учесть ничьи (вернуть всех с одинаковой выручкой), используй RANK() или DENSE_RANK().

SELECT
  sale_date,
  amount,
  SUM(amount) OVER (ORDER BY sale_date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS running_total
FROM daily_sales
ORDER BY sale_date;

ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW — явное указание рамки окна (по умолчанию для ORDER BY то же самое, но явность помогает избежать ошибок).

SELECT
  dt,
  value,
  value - LAG(value) OVER (ORDER BY dt) AS delta
FROM metrics
ORDER BY dt;

LAG(value) возвращает значение из предыдущей строки в заданном порядке. Для первой строки возвращает NULL — разность тоже NULL, что корректно.

SELECT e.name AS employee, e.salary, m.name AS manager, m.salary AS manager_salary
FROM employees e
JOIN employees m ON e.manager_id = m.id
WHERE e.salary > m.salary;

Self-join: таблица джойнится сама с собой — e (сотрудник) и m (менеджер). Условие соединения — e.manager_id = m.id.

SELECT email, COUNT(*) AS cnt
FROM emails
GROUP BY email
HAVING COUNT(*) > 1
ORDER BY cnt DESC;

Чтобы удалить дубликаты, оставив только первую запись:

DELETE FROM emails
WHERE id NOT IN (
  SELECT MIN(id) FROM emails GROUP BY email
);

SELECT AVG(amount) AS median
FROM (
  SELECT amount,
    ROW_NUMBER() OVER (ORDER BY amount) AS rn,
    COUNT(*) OVER () AS total
  FROM salaries
) t
WHERE rn IN (FLOOR((total + 1) / 2.0), CEIL((total + 1) / 2.0));

Логика: для нечётного total оба FLOOR/CEIL дают одно и то же — средний элемент. Для чётного — два средних; AVG от них и есть медиана. PERCENTILE_CONT(0.5) — встроенный вариант в PostgreSQL.

WITH deduped AS (
  SELECT DISTINCT user_id, login_date FROM logins
),
grouped AS (
  SELECT
    user_id,
    login_date,
    login_date - ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date)::int * INTERVAL '1 day' AS grp
  FROM deduped
),
streaks AS (
  SELECT user_id, COUNT(*) AS streak_len
  FROM grouped
  GROUP BY user_id, grp
)
SELECT user_id, MAX(streak_len) AS max_streak
FROM streaks
GROUP BY user_id
HAVING MAX(streak_len) >= 7;

Трюк: если вычесть порядковый номер строки из даты, все даты одной непрерывной серии получат одинаковую «группу». Затем группируем и считаем длину.

SELECT MAX(salary) AS second_highest
FROM employees
WHERE salary < (SELECT MAX(salary) FROM employees);

Через OFFSET:

SELECT DISTINCT salary
FROM employees
ORDER BY salary DESC
LIMIT 1 OFFSET 1;

Через DENSE_RANK:

SELECT salary
FROM (
  SELECT salary, DENSE_RANK() OVER (ORDER BY salary DESC) AS rnk
  FROM employees
) t
WHERE rnk = 2
LIMIT 1;

Первый вариант возвращает NULL автоматически (MAX пустого множества). OFFSET-вариант не вернёт строку, если второй зарплаты нет — нужна обёртка.

def fizzbuzz(n: int) -> list[str]:
    result = []
    for i in range(1, n + 1):
        if i % 15 == 0:
            result.append("FizzBuzz")
        elif i % 3 == 0:
            result.append("Fizz")
        elif i % 5 == 0:
            result.append("Buzz")
        else:
            result.append(str(i))
    return result

Компактный вариант:

def fizzbuzz(n):
    return [
        "FizzBuzz" if i % 15 == 0 else
        "Fizz" if i % 3 == 0 else
        "Buzz" if i % 5 == 0 else str(i)
        for i in range(1, n + 1)
    ]

Важно проверять делимость на 15 первым — иначе "FizzBuzz" не попадёт.

from collections import Counter

def are_anagrams(s1: str, s2: str) -> bool:
    clean = lambda s: s.lower().replace(" ", "")
    return Counter(clean(s1)) == Counter(clean(s2))

Альтернатива через sorted:

def are_anagrams(s1: str, s2: str) -> bool:
    clean = lambda s: sorted(s.lower().replace(" ", ""))
    return clean(s1) == clean(s2)

Counter — O(n), sorted — O(n log n). Для интервью оба варианта приемлемы, но упомяни разницу в сложности.

def fib():
    a, b = 0, 1
    while True:
        yield a
        a, b = b, a + b

# Использование:
gen = fib()
print([next(gen) for _ in range(10)])  # [0, 1, 1, 2, 3, 5, 8, 13, 21, 34]

yield превращает функцию в генератор — значения вычисляются лениво, не хранятся в памяти. a, b = b, a + b — атомарное присваивание, временная переменная не нужна.

def two_sum(nums: list[int], target: int) -> tuple[int, int]:
    seen = {}  # value -> index
    for i, num in enumerate(nums):
        complement = target - num
        if complement in seen:
            return (seen[complement], i)
        seen[num] = i
    raise ValueError("No solution")

Сложность: O(n) по времени и памяти. Наивный вариант с двумя циклами — O(n²). За один проход сохраняем «нужный» дополняющий элемент и сразу проверяем, встречали ли мы его раньше.

def flatten(lst):
    result = []
    for item in lst:
        if isinstance(item, list):
            result.extend(flatten(item))
        else:
            result.append(item)
    return result

Через генератор:

def flatten(lst):
    for item in lst:
        if isinstance(item, list):
            yield from flatten(item)
        else:
            yield item

print(list(flatten([1, [2, [3, 4]], 5])))  # [1, 2, 3, 4, 5]

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

def length_of_longest_substring(s: str) -> int:
    char_index = {}  # char -> last seen index
    max_len = 0
    left = 0
    for right, char in enumerate(s):
        if char in char_index and char_index[char] >= left:
            left = char_index[char] + 1
        char_index[char] = right
        max_len = max(max_len, right - left + 1)
    return max_len

Паттерн sliding window: left — левая граница окна без дублей. При встрече повтора сдвигаем left вправо. Сложность O(n).

from functools import wraps

def memoize(func):
    cache = {}
    @wraps(func)
    def wrapper(*args):
        if args not in cache:
            cache[args] = func(*args)
        return cache[args]
    return wrapper

@memoize
def fib(n):
    if n < 2:
        return n
    return fib(n - 1) + fib(n - 2)

print(fib(50))  # быстро

@wraps(func) сохраняет __name__ и __doc__ оборачиваемой функции. В стандартной библиотеке есть functools.lru_cache — более полная реализация с ограничением размера кэша.

def count_occurrences(data, target):
    if data == target:
        return 1
    count = 0
    if isinstance(data, dict):
        for v in data.values():
            count += count_occurrences(v, target)
    elif isinstance(data, (list, tuple)):
        for item in data:
            count += count_occurrences(item, target)
    return count

# Пример:
print(count_occurrences({"a": [1, 2, 1], "b": {"c": 1}}, 1))  # 3

from collections import OrderedDict

class LRUCache:
    def __init__(self, capacity: int):
        self.capacity = capacity
        self.cache = OrderedDict()

    def get(self, key: int) -> int:
        if key not in self.cache:
            return -1
        self.cache.move_to_end(key)  # отмечаем как недавно использованный
        return self.cache[key]

    def put(self, key: int, value: int) -> None:
        if key in self.cache:
            self.cache.move_to_end(key)
        self.cache[key] = value
        if len(self.cache) > self.capacity:
            self.cache.popitem(last=False)  # удаляем самый старый

Сложность: O(1) для обоих методов. OrderedDict хранит порядок вставки; move_to_end + popitem(last=False) — ключ к эффективности. Без OrderedDict нужен двусвязный список + хэш-таблица.

from collections import defaultdict

def group_anagrams(words: list[str]) -> list[list[str]]:
    groups = defaultdict(list)
    for word in words:
        key = tuple(sorted(word))
        groups[key].append(word)
    return list(groups.values())

# Пример:
print(group_anagrams(["eat","tea","tan","ate","nat","bat"]))
# [["eat","tea","ate"], ["tan","nat"], ["bat"]]

Сложность: O(n · k log k), где k — длина слова. Ключ — отсортированный кортеж символов: у всех анаграмм он одинаков.

p-value — это вероятность получить наблюдаемый результат (или более экстремальный), при условии что нулевая гипотеза H₀ верна.

Корректная интерпретация: Малый p-value (< α) означает, что данные маловероятны при H₀ — повод отвергнуть H₀.

Распространённые ошибки:

1. «p-value — это вероятность того, что H₀ верна» — неверно. Это вероятность данных при H₀, не вероятность H₀.
2. «p < 0.05 значит эффект большой» — неверно. При большой выборке даже ничтожный эффект даёт p < 0.05.
3. «p > 0.05 значит H₀ верна» — неверно. Мы просто не нашли достаточно доказательств против неё.

Практически: всегда смотри на размер эффекта вместе с p-value.

Среднее чувствительно к выбросам, медиана — устойчива к ним.

Медиана предпочтительнее:

• Доходы пользователей: несколько очень богатых завышают среднее (медиана зарплат по стране, LTV)
• Время ответа сервера: один тормозящий запрос искажает среднее → используют p95/p99
• Любые метрики с тяжёлым хвостом

Среднее предпочтительнее:

• Оптимизация по сумме: если нужно суммировать (GMV = n × avg_check), среднее напрямую связано с итогом
• Симметричные распределения без выбросов: нормально распределённые данные
• При агрегации метрик: avg легко считается инкрементально, медиана — нет

Практический совет: смотреть на оба показателя и распределение целиком.

Ошибка I рода (α, ложноположительная): Отвергаем H₀, когда она на самом деле верна. → В A/B тесте: объявляем фичу эффективной, хотя разницы нет. → Контролируется уровнем значимости α (обычно 0.05).

Ошибка II рода (β, ложноотрицательная): Не отвергаем H₀, когда она ложна. → В A/B тесте: не замечаем реального улучшения от фичи. → Контролируется мощностью теста (1 − β), обычно задают 0.8.

Компромисс: Снижая α (меньше ложных срабатываний), мы повышаем β (чаще пропускаем эффект). Увеличение размера выборки снижает обе ошибки одновременно.

Мнемоника: I рода — «казнить невиновного», II рода — «отпустить виновного».

ЦПТ: При достаточно большом n выборочное среднее из независимых одинаково распределённых случайных величин (с конечной дисперсией) стремится к нормальному распределению, независимо от формы исходного распределения.

Формально: $\bar{X}_n \xrightarrow{d} N(\mu, \sigma^2/n)$

Почему важна:

1. В A/B тестах метрики редко нормально распределены (выручка, время на сайте — скошенные). ЦПТ позволяет применять t-тест к средним даже для таких данных.
2. Чем больше выборка, тем лучше приближение — обычно n > 30 считается достаточным для грубых расчётов.
3. Доверительные интервалы и p-values в t-тесте основаны на нормальности средних.

Ограничения: не работает для тяжёлых хвостов (Коши), очень маленьких выборок.

Теорема Байеса: $P(A|B) = \frac{P(B|A) \cdot P(A)}{P(B)}$

Обозначения:

• P(D) = 0.001 — prior (болезнь)
• P(+|D) = 0.99 — чувствительность (1 - ложноотриц.)
• P(+|¬D) = 0.05 — ложноположительный

P(+) = P(+|D)·P(D) + P(+|¬D)·P(¬D) = 0.99×0.001 + 0.05×0.999 = 0.000990 + 0.04995 ≈ 0.05094

P(D|+) = 0.000990 / 0.05094 ≈ 1.9%

Вывод: несмотря на точный тест, при редкой болезни большинство положительных результатов — ложные. Это «парадокс базовой частоты» (base rate fallacy).

Bootstrap — метод оценки распределения статистики путём многократной (1000–10000 раз) ресэмплинг-выборки с возвращением из имеющихся данных.

Алгоритм:

1. Из выборки размера n случайно взять n наблюдений с повторением.
2. Посчитать нужную статистику (медиана, корреляция, …).
3. Повторить 10 000 раз → получить эмпирическое распределение.
4. 95% доверительный интервал: перцентили 2.5% и 97.5%.

Преимущества:

• Не требует предположений о форме распределения
• Работает для любой статистики (медиана, R², …)
• Особенно полезен при малых выборках

Ограничения: вычислительно дорогой; не работает для зависимых данных (временные ряды — нужен block bootstrap).

Проблема: при одновременной проверке k гипотез вероятность хотя бы одного ложноположительного результата резко растёт. При 20 тестах с α=0.05 вероятность хотя бы одной ошибки I рода ≈ 64%.

Поправка Бонферрони: α_adjusted = α / k Контролирует FWER (Family-Wise Error Rate) — вероятность хотя бы одной ошибки. Консервативна — при большом k мощность падает.

FDR (False Discovery Rate), поправка Бенджамини-Хохберга: Контролирует долю ложных отклонений среди всех отклонённых H₀. Менее строга, больше мощность — подходит для исследовательского анализа и омиксных данных.

Практика:

• В A/B тестах с несколькими метриками → FDR или Bonferroni для первичной метрики
• В геномике / многомерных анализах → Benjamini-Hochberg стандарт

Визуальные методы:

• Q-Q plot (Quantile-Quantile): сравнивает квантили выборки с теоретическими квантилями нормального распределения. При нормальности точки лежат на диагонали.
• Гистограмма / KDE: симметрична, колоколообразная форма.

Статистические тесты:

• Shapiro-Wilk (n < 5000): H₀ — данные нормально распределены. p > 0.05 → не отвергаем нормальность. Один из мощнейших.
• Kolmogorov-Smirnov: сравнивает эмпирическое распределение с теоретическим. Менее мощный, чем Shapiro-Wilk.
• D'Agostino-Pearson: тест на асимметрию и эксцесс.

Практически: При большом n (> 1000) тесты почти всегда найдут отклонение — из-за ЦПТ это часто не важно. Важнее Q-Q plot и понимание, зачем нужна нормальность.

ANOVA (Analysis of Variance) проверяет, различаются ли средние трёх и более групп.

H₀: μ₁ = μ₂ = … = μk (все средние равны) H₁: хотя бы одна пара различается

Ключевая идея: Сравнивает дисперсию между группами (Between-group) с дисперсией внутри групп (Within-group). F-статистика = MS_between / MS_within. Если F велико → группы отличаются.

Vs. t-тест:

• t-тест: только 2 группы
• ANOVA: 3+ группы без раздувания α (несколько t-тестов надо корректировать Бонферрони)
• ANOVA говорит «есть различие», но не «где именно» → post-hoc тесты (Tukey, Bonferroni)

Применение в аналитике:

• Сравнение нескольких вариантов (A/B/C/D тест)
• Влияние географии/платформы на метрику
• Но при нарушении предположений (гомоскедастичность, нормальность) → Kruskal-Wallis (непараметрический аналог)

Корректная интерпретация: Если повторять эксперимент бесконечно и каждый раз строить 95% ДИ, то 95% из этих интервалов будут содержать истинный параметр.

Ошибочные интерпретации:

• «Вероятность 95%, что истинное значение внутри интервала» — неверно (в частотной статистике истинный параметр фиксирован, не случаен)
• «95% данных лежат в этом интервале» — неверно (это перцентильный диапазон данных, не ДИ)

Практически: Ширина ДИ показывает точность оценки:

• Узкий ДИ → много данных, высокая точность
• Широкий ДИ → мало данных, неопределённость

Для интерпретации результатов A/B теста: если ДИ для разности эффектов не включает 0 — результат значим. Ширина ДИ говорит об экономической значимости эффекта.

MDE (Minimum Detectable Effect) — наименьший эффект, который тест способен обнаружить с заданной мощностью.

Задают исходя из бизнес-значимости: «нам не интересен эффект меньше +1% конверсии».

Зависит от:

• Размера выборки (n ↑ → MDE ↓)
• Уровня значимости α (строже α → MDE ↑)
• Мощности теста (1−β) (выше мощность → MDE ↓, нужно больше данных)
• Baseline метрики и её дисперсии

Формула (приближённо для двух групп): $n = \frac{(z_{\alpha/2} + z_\beta)^2 \cdot 2\sigma^2}{\delta^2}$

Где δ — MDE, σ² — дисперсия метрики.

Практика: использовать калькулятор размера выборки. Стандарт: α=0.05, мощность=0.8.

Единица рандомизации — объект, по которому разделяют контрольную и тестовую группы.

Основные варианты:

1. user_id — наиболее распространён. Один пользователь всегда в одной группе. Нет загрязнения между сессиями.
2. session_id — один пользователь может попасть в обе группы. Нарушает независимость наблюдений (SUTVA). Использовать с осторожностью.
3. cookie — промежуточный вариант; теряется при смене браузера/устройства.
4. географический кластер / магазин — для экспериментов с сетевыми эффектами или физических точек.

Принципы выбора:

• Единица должна быть стабильной на протяжении теста
• Нет «перетекания» между группами (SUTVA)
• Как можно ниже уровень агрегации — больше статистической мощности

Проблема: исследователь регулярно смотрит на p-value в процессе теста и останавливает его, как только p < 0.05. Это резко завышает реальный уровень ошибки I рода.

Почему: при каждом промежуточном взгляде мы проводим дополнительный статистический тест. При достаточном числе «взглядов» p-value обязательно упадёт ниже α случайно.

Симуляция: если смотреть каждый день в течение 20 дней, вероятность хотя бы раз увидеть p < 0.05 у нулевого эффекта ≈ 30-40% (вместо 5%).

Решения:

1. Фиксированный срок — определить n заранее, смотреть результат один раз
2. Sequential testing (mSPRT) — методы, корректно управляющие ошибкой при раннем останове
3. Bayesian подход — можно останавливать при достаточной вероятности эффекта
4. Always-valid p-values (Optimizely, Eppo) — промышленные решения

SRM (Sample Ratio Mismatch) — несоответствие фактического соотношения пользователей в группах ожидаемому.

Пример: ожидали 50/50, получили 48/52.

Обнаружение: тест χ² (chi-squared) на соответствие долей:

• H₀: соотношение соответствует ожидаемому
• p < 0.01 → SRM есть, результаты теста ненадёжны

Причины:

1. Ошибки в логировании (один вариант теряет события)
2. Redirect-тест: бот-трафик отфильтровывается иначе для разных вариантов
3. Кэширование на стороне клиента
4. Ошибка в рандомизаторе (hash collision)
5. Сбой в доставке фичи

Важно: при обнаружении SRM → не интерпретировать результаты теста. Сначала разобраться с источником смещения.

Эффект новизны — пользователи взаимодействуют с новым вариантом активнее просто потому, что он новый, а не потому что он лучше. Через какое-то время поведение нормализуется.

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

Признаки: значимое улучшение в первые дни, затем сходится к нулю.

Как бороться:

1. Сегментация: смотреть отдельно на новых пользователей (не подвержены novelty) и на вернувшихся
2. Увеличить срок теста — запустить на 3–4 недели, смотреть на поведение в конце периода
3. Cohort analysis: анализировать поведение пользователей по дням после попадания в тест
4. Holdout groups: долгосрочные тесты с длинным горизонтом

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

Зачем нужны: Оптимизируя одну метрику (CTR на рекомендации), можно ненароком ухудшить другую (время сессии, retention). Guardrails — страховочная сетка.

Типичные guardrail-метрики:

• Revenue / GMV (не роняем выручку)
• DAU / Retention (не теряем пользователей)
• Latency (не ухудшаем скорость)
• Crash rate / Error rate (не ломаем стабильность)
• Customer support tickets

Логика принятия решений:

• Первичная метрика ↑, guardrails в норме → запускаем
• Первичная ↑, но guardrail ↓ → нужен дополнительный анализ
• Guardrail существенно ухудшился → не запускаем, даже если первичная выросла

Частотный (frequentist):

• Понятие: p-value, доверительный интервал
• Интерпретация: «вероятность данных при H₀»
• Нельзя остановить тест досрочно без коррекции (peeking problem)

• Широко принят, легко объяснить

• Интуитивно сложен для нестатистиков («что значит p=0.03?»)

Байесовский:

• Понятие: posterior probability, доверительная область (credible interval)
• Интерпретация: «вероятность, что вариант B лучше, составляет 97%»

• Понятен стейкхолдерам
• Можно останавливать при достижении нужной вероятности
• Естественно включает prior-знания

• Чувствителен к выбору prior; при неинформативном prior может требовать больше данных
• Вычислительно дороже

На практике: многие крупные компании (Booking, Netflix) используют байесовский подход для интерпретируемости.