Все вопросы

Порядок выполнения 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 проверяет разницу средних между группами.

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;

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

SELECT DISTINCT user_id
FROM watch_content
WHERE video_id = 1
  AND user_id IN (SELECT user_id FROM watch_content WHERE video_id = 3)
  AND user_id NOT IN (SELECT user_id FROM watch_content WHERE video_id = 2);

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

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 месяца.

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

Тест показал, что доля в B выше — но нужно оценить прибыльность.

CAC (Cost of Acquisition):

• Все затраты на кэшбэк + интеграция с банком (% от продаж)
• CAC = Все затраты / (1100 − 1000) = Затраты / 100 привлечённых

Инкрементальные пользователи:

• Из 300 воспользовавшихся кэшбэком не все пришли благодаря ему
• Доля тех, кто пришёл благодаря кэшбэку: (1100 − 1000) / 300 ≈ 33%

LTV:

• Выручка от привлечённых кэшбэком пользователей за N месяцев
• LTV > CAC → программа выгодна

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

Это задача 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) используют байесовский подход для интерпретируемости.

CUPED — метод снижения дисперсии метрики за счёт использования ковариаты (чаще всего — предтестовых данных пользователя).

Идея: Большая часть вариации метрики объясняется постоянными свойствами пользователя. Если вычесть предсказуемую часть, остаток (residual) будет иметь меньшую дисперсию → тест мощнее.

Формула: $Y_{cuped} = Y - \theta \cdot X$

Где X — предтестовое значение той же метрики, θ = Cov(X,Y)/Var(X).

Результат: при высокой корреляции X и Y дисперсия уменьшается на (1 − ρ²) × 100%. При ρ=0.7 → экономия ~51% объёма выборки.

Требования:

• X должна быть собрана до рандомизации
• X независима от назначения в группу

Применение: Microsoft (изобрели метод), Booking.com, Netflix используют по умолчанию.

Проблема: При сетевых эффектах действия пользователя влияют на других пользователей. Контрольная и тестовая группы «заражают» друг друга → нарушается условие независимости (SUTVA).

Пример: тест фичи «Отправить приглашение другу». Пользователь из группы B приглашает друга из группы A → группа A «загрязнена».

Методы:

1. Cluster randomization (географические кластеры): разделить не пользователей, а города/регионы. Дороже (нужно больше кластеров), снижает мощность.
2. Graph-based clustering: разбить социальный граф на плотные сообщества, тестировать целые сообщества.
3. Ego-network experiments (LinkedIn): рандомизация по «эго-сетям» пользователей.
4. Two-sided marketplace experiments: тестировать отдельно supply и demand.

Компании: LinkedIn, Facebook, Airbnb публикуют кейсы своих подходов.

Проблема: малый baseline → нужна огромная выборка для заданного MDE.

При baseline=0.5%, MDE=10% (т.е. 0.55%), α=0.05, мощность=0.8 → нужно ~1.6 млн пользователей на группу.

Подходы:

1. Суррогатные метрики (proxy metrics): использовать более частое событие на воронке (клик, добавление в корзину), которое коррелирует с покупкой. Экономит выборку, но нужно валидировать суррогат.

2. Увеличить MDE: протестировать более сильное изменение (не +10%, а +25%). Минус — нет информации о малых эффектах.

3. Байесовский подход: более эффективен при малых выборках за счёт prior-а.

4. Sequential design / SPRT: останавливать тест при накоплении доказательств (экономит время).

5. Сегментация: тестировать только на аудитории с высоким conversion propensity (например, пользователи, добавившие в корзину).

Шаг 1 — Проверить данные:

• Нет ли пропусков в логах или сбоя трекинга оплаты
• Сравнить событие «страница открыта» с «оплата нажата» — где именно отвал

Шаг 2 — Разбить по сегментам:

• Устройство: мобайл vs. десктоп (мобильная верстка сломана?)
• Платёжная система: одна из систем (карта, SberPay) упала
• Браузер/ОС: обновление приложения с багом
• Тип пользователя: новые vs. старые

Шаг 3 — Внешние изменения:

• Был ли деплой в эти дни? Изменения в форме оплаты?
• Выросли ли ошибки от платёжного провайдера?

Шаг 4 — Качественные сигналы:

• Записи сессий (Hotjar, Fullstory): куда кликают перед уходом
• Тикеты в поддержку: жалобы на ошибки при оплате

Вывод и действие: определить сегмент → откатить деплой / исправить ошибку / заэскалировать в команду платёжного шлюза.

Почему DAU стабилен при падении Ret? Скорее всего, вырос поток новых пользователей — они компенсируют отток. Важно разделить потоки.

Декомпозиция:

• Ret падает только у новых? Проверить вернувшихся и реактивированных отдельно
• В каком канале привлечения упал Ret? (платный трафик, органика, рефералы)
• Новая когорта хуже по качеству (боты, нерелевантная аудитория)?

Анализ онбординга:

• Построить воронку онбординга: регистрация → первое ключевое действие → возврат
• Где падает воронка по сравнению с прошлыми когортами?

Гипотезы:

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

Рекомендации: сравнить cohort-based воронку новых когорт с когортами 2–3 месяца назад.

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

Кандидаты для стриминга:

1. Часы просмотра на пользователя в месяц — отражает вовлечённость, предсказывает удержание
2. % активных пользователей, просмотревших >X часов — качественный порог активности
3. Monthly Active Subscribers — бизнесовая метрика, но не отражает ценность
4. Завершённые просмотры — качество: досмотрел ли пользователь

Рекомендация: Часы просмотра / активный пользователь — хорошо предсказывает отток (меньше смотришь → уходишь) и рост (больше контента → больше смотришь → выше готовность платить). Netflix использует близкую метрику.

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

• Ведущий индикатор (не запаздывает)
• Понятен всей команде
• Действенный (на него можно влиять)

Шаг 1 — Понять охват:

• Сколько пользователей видят эту фичу в месяц? (n_eligible)
• Какой baseline конверсии был? (r_baseline)

Шаг 2 — Инкрементальные покупки:

• Инкрементальные покупки = n_eligible × r_baseline × 0.03
• Пример: 1 млн пользователей, baseline 20%, MDE +3% → +0.6% абс. → 6 000 доп. покупок/мес

Шаг 3 — Средний чек и маржа:

• Инкрементальный GMV = 6 000 × avg_check
• Инкрементальная маржа = 6 000 × avg_check × margin%

Шаг 4 — Аннуализация и LTV-эффект:

• Месячный эффект × 12 — консервативная оценка
• Если повторные покупки повышают Retention → дополнительный LTV-эффект

Шаг 5 — Доверительный интервал:

• Построить CI вокруг оценки (из ДИ A/B теста для конверсии)

Почему среднее в норме при жалобах:

1. Хвост распределения: медленно только у части (p95 или p99 высокий). Среднее не показывает выбросы.
2. Сегмент пользователей: медленно только на старых устройствах / слабом интернете / конкретной платформе
3. Проблема в конкретном регионе: CDN упал в Сибири
4. Ошибка метрики: не учитываются тайм-ауты или failed-запросы

Что проверить:

• Построить перцентили: p50, p75, p95, p99 по скорости
• Сегментировать: ОС, версия, география, тип соединения
• Посмотреть на error rate: ошибки ≠ медленные ответы в обычных метриках
• Проверить инфраструктурный мониторинг: CDN, mobile backend

Вывод: использовать перцентильные метрики (p95 latency) вместо среднего для мониторинга пользовательского опыта.

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

Гипотезы:

1. Артефакт данных: ошибка в логировании для этой когорты
2. Изменение в продукте: в момент привлечения этой когорты запустили фичу, которая улучшила онбординг
3. Качество аудитории: когорта из другого канала (органика vs. платный), другая демография
4. Специальная акция: промокод или бонус при регистрации создал «искусственный» Retention
5. Сезонность: привлекали в период высокого product-market fit (праздники, новый контент)

Действия:

1. Проверить данные: нет ли дублей, проблем с трекингом
2. Посмотреть каналы и источники трафика когорты
3. Восстановить таймлайн: что менялось в продукте и маркетинге в тот период
4. Если изменение в продукте — запустить A/B тест, чтобы проверить гипотезу

Диагноз: каннибализация. Пользователи переключились с каталога на персональные рекомендации — рекомендации «съели» часть трафика каталога.

Ключевые вопросы:

1. Изменился ли общий объём потребления контента (суммарные просмотры), или просто перераспределился?
2. Одинакова ли ценность контента через каталог и через рекомендации? (CTR → покупка, LTV)
3. Есть ли долгосрочный эффект: рекомендации могут снижать разнообразие потребления (filter bubble)

Анализ:

• Считать net-суммарный CTR + downstream метрики (retention, revenue per user)
• Сравнить качество просмотров: завершение, оценки, покупки

Принятие решения:

• Если суммарная вовлечённость и бизнес-метрики выросли → запускать
• Если перераспределение с каннибализацией ключевого KPI команды контента → обсуждать компромисс на уровне продуктового комитета

Вывод: без анализа сквозных метрик выводы преждевременны.