В таблицу кликов поступает 2 миллиарда событий в день, и продукту нужны пользовательские сессии с разрывом после 30 минут бездействия, чтобы решить, сократил ли новый онбординг медианное время до активации хотя бы на 10 процентов. Как построить SQL-выгрузку за последние 90 дней?

Я выделю сессии в SQL с помощью детерминированной последовательности оконных вычислений, а затем агрегирую данные на уровне полученных сессий. - Применю LAG по каждому пользователю с сортировкой по event_ts и event_id и отмечу начало новой сессии, если предыдущего события нет или разрыв превышает 30 минут. - Накопительной суммой этого маркера в том же разделе создам стабильный номер сессии, сохранив event_id как критерий порядка для одинаковых временных меток. - Сгруппирую данные по user_id и номеру сессии и верну начало, конец, число событий и время первой активации. - Отфильтрую event_date до оконных вычислений, чтобы прочитать только 90 партиций, а затем сравню медианную длительность до активации между старым и новым вариантами онбординга.

Хранилище принимает 800 миллионов мобильных событий в день, а сетевые повторы дублируют около 0,7 процента из них до подготовки ежедневного отчёта о покупках к 09:00. Как дедуплицировать события в SQL, чтобы финансовая команда доверяла числу заказов?

Я выберу одну каноническую строку для каждого события до любых объединений и агрегаций покупок. - Применю ROW_NUMBER с разделением по event_id и сортировкой по убыванию source_updated_at, затем ingestion_ts, после чего оставлю строку с номером 1. - Если у старых клиентов нет event_id, построю документированный отпечаток из user_id, event_name, client_ts, order_id и хеша payload, а долю коллизий покажу отдельно. - Ограничу сканирование датой отчёта и трёхдневным окном повторов, но добавлю плановый пересчёт за семь дней для опоздавших событий. - Сверю уникальные order_id и сумму выручки с таблицей платежей и заблокирую отчёт на 09:00, если любое расхождение превысит 0,1 процента.

У подписочного продукта 20 миллионов регистраций за 18 месяцев, и growth-команда остановит каналы с удержанием четвёртой недели ниже 18 процентов. Как написать SQL для когорт по месяцу регистрации с удержанием с 1-й по 12-ю неделю по каналу привлечения?

Я один раз зафиксирую когорту и знаменатель каждого пользователя, а затем соединю активность с явной сеткой недель. - До объединения с 6 миллиардами строк активности назначу каждому пользователю самую раннюю валидную дату регистрации, месяц когорты и канал привлечения. - Сведу активность к уникальным парам user_id и activity_date, затем рассчитаю week_number от даты регистрации и оставлю недели с 1-й по 12-ю. - Соединю каждую когорту и канал со справочником недель от 1 до 12, чтобы недели с нулём удержанных пользователей не исчезали. - Разделю число уникальных активных пользователей на исходный размер когорты, исключу из таблицы решений когорты с незавершённой четвёртой неделей и выведу каналы ниже порога 18 процентов.

Интернет-магазин записывает 600 миллионов событий в день, и checkout-команде нужно измерить пользователей, которые выполнили view_item, add_to_cart, begin_checkout и purchase в таком порядке за 24 часа, прежде чем решать о раскатке. Как запросить эту упорядоченную воронку, не учитывая события в неверном порядке?

Я привяжу каждый шаг воронки к самому раннему подходящему событию после предыдущего шага на заданном уровне попытки. - Начну с одного view_item на пользователя и попытку оформления, сохранив item_id, вариант и временную метку как строку знаменателя. - Для каждого следующего шага возьму минимальную временную метку позже предыдущего шага и не позднее 24 часов после исходного просмотра, используя order_id или attempt_id для защиты от склейки разных покупок. - Соединю последовательные шаги через LEFT JOIN, чтобы пользователи, покинувшие воронку, остались в знаменателе, и засчитаю этап только при наличии всех предыдущих временных меток. - Верну конверсию этапов и потери между шагами по устройству и варианту, а в таблице раскатки отмечу варианты с ростом конверсии в покупку хотя бы на 2 процента.

У вас есть 400 миллионов исторических транзакций и таблица клиентского риска, где уровень меняется со временем, а кредитному отделу нужно пометить каждую транзакцию уровнем на момент покупки для установки лимитов на следующий квартал. Как реализовать point-in-time join в SQL?

Я соединю каждую транзакцию с единственной версией уровня риска, интервал действия которой содержит время покупки. - Представлю историю уровней с включительной границей valid_from и исключительной valid_to, используя далёкую будущую дату только для текущей версии. - Соединю по customer_id при условии valid_from не позже purchased_at и purchased_at раньше valid_to либо применю нативный ASOF join хранилища с той же семантикой. - Проверю отсутствие пересекающихся интервалов, использую version_id как детерминированный критерий выбора и направлю транзакции без соответствия в явный уровень unknown. - Ограничу транзакции планируемым кварталом, заранее отфильтрую версии уровней, пересекающие этот период, и выведу долю дефолтов и объём риска по историческому уровню для установки лимитов.

Маркетплейс хранит 1,2 миллиарда ежедневных снимков запасов, и операционной команде нужны все пары продавец и SKU как минимум с 14 последовательными днями отсутствия товара, чтобы решить, какие объявления скрыть. Как решить эту задачу gaps-and-islands в SQL, отличая пропущенные снимки от реального отсутствия товара?

Я построю полный дневной ряд, явно выделю пробелы в данных и сформирую острова только из подтверждённых дней без товара. - Соединю диапазоны активности продавца и SKU с календарём за 60-дневное окно, затем добавлю снимки через LEFT JOIN, чтобы отсутствующая строка означала unknown, а не нулевой запас. - С помощью LAG внутри каждого seller_id и sku_id отмечу границу острова при смене статуса, если предыдущая календарная дата не была вчерашней или статус любого дня равен unknown. - Накопительной суммой маркера границы назначу island_id, затем сгруппирую подтверждённые острова без товара и получу start_date, end_date и day_count. - Верну острова с day_count не меньше 14 для скрытия объявлений, а неизвестные интервалы длиннее двух дней отправлю в отдельную очередь качества данных.

Таблица задержек содержит 12 миллиардов строк в месяц и 500 групп по стране и устройству, но гейт релиза должен получить p50, p95 и p99 за 10 минут и блокирует любую группу с p95 выше 2,5 секунды. Когда в SQL использовать точные, а когда приближённые перцентили?

Для широкого сканирования перед гейтом я использую приближённые перцентили, а точные рассчитаю только для групп около границы 2,5 секунды. - Точный PERCENTILE_CONT требует большой сортировки внутри каждой группы и даёт интерполированные квантили для финальных аудируемых чисел, но вряд ли уложится в 10 минут на 12 миллиардах строк. - APPROX_PERCENTILE или APPROX_QUANTILES использует скетчи с ограниченной памятью и должен вернуть p50, p95 и p99 для всех 500 групп в пределах SLA дашборда. - Ежемесячно откалибрую приближение относительно точного результата на репрезентативных партициях и зафиксирую абсолютную ошибку p95, которая должна оставаться ниже 50 миллисекунд. - Точно пересчитаю p95 для групп с приближённым результатом от 2,4 до 2,6 секунды и заблокирую релиз только по этой точной пограничной таблице.

Мерчандайзингу нужны пять лучших товаров по чистой выручке внутри каждой из 120 категорий по 250 миллионам строк заказов, причём для решения об ассортименте нужно включить все товары, разделившие пятое место. Как написать SQL и явно задать поведение при равенстве?

Я сначала агрегирую данные до одной строки на категорию и товар, а затем применю DENSE_RANK внутри каждой категории. - До оконной функции просуммирую выручку строк за вычетом возвратов на уровне category_id и product_id, округлив выручку до бухгалтерских центов. - Рассчитаю DENSE_RANK с разделением по category_id и сортировкой по убыванию net_revenue, затем оставлю ранги с 1-го по 5-й. - Не возьму ROW_NUMBER, потому что он произвольно отбросит товары, разделившие пятое место, и не возьму RANK, потому что пропуски рангов могут вернуть меньше пяти разных уровней выручки. - Верну ранг, чистую выручку и долю выручки категории и предупрежу мерчандайзинг, что при равенстве на пятом месте категория может содержать больше пяти товаров.

У B2B-компании есть иерархия из 8 миллионов аккаунтов с parent_account_id и годовой регулярной выручкой, а отделу продаж нужна ARR, свёрнутая на каждого предка, плюс список структур глубже восьми уровней перед изменением территорий. Как запросить это рекурсивным SQL?

Я построю рекурсивным CTE замыкание предок-потомок, а затем агрегирую ARR потомков по каждому предку. - Начну с каждого аккаунта как одновременно предка и потомка на глубине 0, затем рекурсивно пойду по parent_account_id, сохраняя ancestor_id, descendant_id, depth и путь из посещённых id. - Остановлю ветвь при повторе id или достижении глубины 50, а циклы и отсутствующих родителей выведу отдельно вместо молчаливого удаления. - Просуммирую ARR каждого потомка один раз по ancestor_id из замыкания и рассчитаю максимальную глубину, не добавляя выручку родителя повторно на промежуточных уровнях. - Материализую проверенное замыкание инкрементально для 8 миллионов узлов, затем передам свёрнутую ARR и предков с максимальной глубиной выше восьми для изменения территорий.

Еженедельный запрос атрибуции сканирует 15 ТБ кликов, объединяет заказы и историю кампаний, выполняется 70 минут и стоит 180 долларов, но маркетингу нужен результат быстрее 10 минут до перераспределения 5 миллионов долларов бюджета. Как оптимизировать аналитический SQL без изменения результата?

Я использую профиль запроса, чтобы сначала сократить объём чтения и пересылки данных, а не увеличивать размер хранилища. - Проверю прочитанные байты, кардинальность объединений, сброс на диск и длительность этапов, затем перенесу фильтры event_date и периода действия кампании в самое раннее чтение кликов, сохранив отсечение партиций. - Сведу клики до нужного уровня user, session и campaign до объединения с заказами, а небольшие измерения кампаний добавлю только после сокращения данных, чтобы избежать размножения строк и сетевой пересылки. - Кластеризую или отсортирую крупный промежуточный набор по event_date и user_id и инкрементально материализую дневные входные данные атрибуции, если одни и те же 15 ТБ истории перечитываются каждую неделю. - Сравню число строк, идентификаторы атрибутированных заказов и контрольные суммы выручки с исходным запросом и приму переписывание только при времени меньше 10 минут и полном совпадении бизнес-итогов.

У маркетплейса бытовых услуг 500 000 посетителей в неделю, 40 000 завершённых заказов и недельный GMV $8 млн. Какую north star метрику вы выберете?

Я выберу число успешно завершённых заказов за неделю, потому что оно фиксирует ценность, полученную и клиентами, и исполнителями. - Учитываю заказ один раз после проведения оплаты, если в течение 7 дней не было отмены или возврата; текущая база равна 40 000. - Раскладываю метрику как 500 000 подходящих посетителей, умноженные на 12% создания заявки, 80% мэтчинга и 83% завершения, что даёт около 39 840 заказов. - Ограничиваю долю споров за 7 дней уровнем ниже 3%, требую медианный заработок исполнителя не менее $24 в час и p90 времени до мэтча менее 48 часов. - Публикую показатель по городам и категориям услуг и отмечаю сегмент, который даёт более 20% роста при падении доли повторных заказов больше чем на 2 процентных пункта.

У подписочного продукта 100 000 платных мест и $2 млн MRR, который нужно увеличить на 20% за 6 месяцев. Постройте дерево метрик.

Я поставлю в корень конечный MRR и свяжу все ветки тождествами, которые сходятся к цели $2,4 млн. - Ветка запаса начинается с $2 млн, равных 100 000 платных мест, умноженным на $20 фактического MRR на место, и заканчивается целью $2,4 млн. - Месячный мост равен начальному MRR плюс $50 000 нового и $30 000 расширения, минус $20 000 сокращения и $25 000 оттока, что сейчас даёт чистый прирост $35 000. - Привлечение отвечает за ветку нового MRR в $50 000 как 1 000 новых аккаунтов, умноженные на $50 MRR первого месяца, с объёмом триалов и платной конверсией ниже по дереву. - Удержание отвечает за валовый отток MRR в 1,25%, а расширение за ветку $30 000; текущие потоки добавят за 6 месяцев только $210 000, оставив разрыв $190 000.

Продукт для совместной работы в вебе и на мобильных устройствах отчитывается о 1,2 млн MAU, но содержательно редактируют контент только 430 000 пользователей. Сформулируйте точный контракт активного пользователя.

Я определю MAU как число уникальных канонических пользователей-людей, которые за календарный месяц по UTC создали хотя бы 1 сохранённое изменение контента. - Засчитываются ровно 3 успешных события: document_created, edit_committed и comment_posted; входы, просмотры, открытия уведомлений и неудачные записи не считаются. - Окно длится с 00:00 UTC 1-го числа включительно до 00:00 UTC 1-го числа следующего месяца, использует время события и закрывается после допуска в 48 часов на опоздавшие данные. - Разрешение идентичности считает 1 канонического пользователя на вебе и мобильном устройстве, исключает анонимную активность до привязки, а также сотрудников, тестовые, бот- и заблокированные аккаунты. - Старый показатель 1,2 млн я переименую в посещавшие MAU, пересчитаю оба определения за 12 месяцев и приму 430 000 за управляемую базу нового контракта.

Обучающее приложение получает 2 млн новых регистраций в месяц, а growth-команда хочет напоминаниями поднять активацию с 32% до 40%. Определите KPI и guardrail-метрики.

Я буду оптимизировать качественную активацию за 7 дней, а не клики по напоминаниям или число начатых уроков. - Регистрация активируется только после завершения 3 уроков хотя бы в 2 разных дня за первые 168 часов; рост с 32% до 40% означает ещё 160 000 активированных пользователей в месячной когорте. - В знаменателе оставляю подходящие новые аккаунты людей, назначенные в группу до первого напоминания, а сегменты по каналам показываю только при объёме не менее 10 000 регистраций. - Требую, чтобы 30-дневное удержание активированных пользователей снизилось не более чем на 1 процентный пункт, а доля отключивших push выросла не более чем на 0,5 пункта. - Ограничиваю жалобы на напоминания уровнем 2 на 10 000 отправок, а переменную стоимость доставки уровнем $0,30 на дополнительного активированного пользователя.

На рынке A было 9 000 подходящих сессий оформления заказа и 1 800 покупок, а на рынке B было 1 000 сессий и 400 покупок. Как агрегировать месячную конверсию оформления заказа?

Общая конверсия равна отношению суммы покупок к сумме подходящих сессий, то есть 2 200, делённым на 10 000, или 22%. - Рынок A конвертирует 20%, а рынок B 40%; их невзвешенное среднее 30% завышает результат на 10 пунктов. - Взвешивание конверсии каждого рынка по её знаменателю даёт 90% умножить на 20% плюс 10% умножить на 40%, что сходится к 22%. - Если доли рынков изменятся до 50% на каждый при прежних ставках, сырая конверсия вырастет до 30%, поэтому я также публикую ряд со стандартизированным исходным миксом 90/10. - Контракт учитывает не более 1 покупки на подходящую сессию оформления и показывает числитель 2 200 и знаменатель 10 000 рядом с каждым отношением.

В кредитной воронке 100 000 посетителей, 60 000 начатых заявок, 30 000 завершённых заявок, прошедших eligibility, 12 000 одобрений и 8 000 выданных кредитов. Growth-команда показывает конверсию 8%, а риск-команда 26,7%. Как определить воронку?

Обе ставки верны для разных вопросов, поэтому я назову каждый переход и его подходящий знаменатель вместо одной неоднозначной конверсии. - Конверсия посетителя в старт равна 60 000, делённым на 100 000, или 60%, а конверсия старта в подходящую завершённую заявку равна 30 000, делённым на 60 000, или 50%. - Одобрение андеррайтинга равно 12 000, делённым на 30 000 подходящих завершённых заявок, или 40%; неподходящие и незавершённые заявки в этот знаменатель не входят. - Конверсия от подходящей заявки до выдачи равна 8 000, делённым на 30 000, или 26,7%, и раскладывается на 40% одобрения и 66,7% выдачи после одобрения; сквозная конверсия равна 8%. - Фиксирую eligibility на момент отправки заявки, объединяю повторные заявки одного человека за 30 дней и показываю все 5 объёмов этапов рядом с условными ставками.

Маркетплейс доставки еды выполняет 50 000 заказов в неделю со средним чеком $32, take rate 22%, сбором с клиента $2,20, стоимостью курьера $5,50, платёжной комиссией 2,9%, поддержкой и возвратами $0,80 и промо $1,50. Как выглядит юнит-экономика?

Маржинальная прибыль составляет всего около $0,51 на заказ, поэтому внешне здоровый take rate 22% почти не оставляет места для дополнительных скидок. - Переменная выручка равна $7,04 комиссии плюс $2,20 сбора с клиента, итого $9,24 на заказ. - Переменные затраты равны $5,50 плюс $0,93 за обработку платежа, $0,80 на поддержку и возвраты и $1,50 на промо, итого около $8,73. - Маржинальная прибыль равна $0,51 на заказ, 1,6% GMV или примерно $25 600 на 50 000 недельных заказов до постоянных затрат. - Увеличение промо с $1,50 до $3,00 делает вклад отрицательным примерно на $0,99 за заказ, поэтому для оправдания потребуется не менее $1,50 измеренной будущей маржи когорты.

Поисковая команда хочет использовать CTR как прокси 28-дневной повторной покупки, потому что эксперименты идут 2 недели, а корреляция на уровне пользователей равна 0,65. Как проверить прокси по 24 прошлым экспериментам?

Я проверю CTR на уровне эффектов экспериментов, потому что корреляция 0,65 между пользователями не доказывает, что изменение кликов меняет повторные покупки. - Для всех 24 зрелых тестов оцениваю эффекты на обе метрики на единице рандомизации и строю взвешенную по точности связь с leave-one-experiment-out валидацией. - Потребую совпадения направления хотя бы в 20 из 24 тестов, out-of-sample R-squared выше 0,50 и калибровочный наклон от 0,8 до 1,2. - Проверяю, что рост CTR на 1 пункт систематически не повышает возврат к поиску за 5 секунд больше чем на 0,3 пункта, иначе оптимизация создаёт низкокачественные клики. - Наблюдаю за прокси ещё на 6 экспериментах, дошедших до 28-го дня, и перестаю его использовать после 2 разворотов направления или выхода квартальной калибровки за диапазон 0,8-1,2.

У маркетплейса бытовых услуг 90 000 запрошенных часов работы и 100 000 доступных часов исполнителей в неделю, но исполняется только 72% заявок, а утилизация исполнителей равна 55%. Какую метрику баланса вы построите?

Я использую покрытие сбалансированной ликвидностью: долю подходящих заявок в локальных ячейках, где отношение запрошенных часов к доступным часам исполнителей лежит от 0,8 до 1,0. - Считаю нагрузку по городу, категории услуги и дню с учётом ожидаемой длительности заказа; глобальное отношение 90 000 к 100 000, или 0,9, скрывает локальный дефицит и простой. - Нагрузку ниже 0,6 считаю избытком предложения, а выше 1,2 дефицитом, при этом ячейки с менее чем 100 недельными заявками объединяю в более крупный регион. - Если сейчас только 58% заявок попадают в диапазон 0,8-1,0, ставлю цель 75% вместо максимизации только числа исполнителей или объёма заявок. - Подтверждаю границы ростом исполнения выше 80%, утилизацией исполнителей от 55% до 70% и медианным временем первого ответа менее 4 часов.

Недельное число оплаченных заказов равно 1,02 млн при плане 1,08 млн, а квартальный рост замедлился с 8% до 2%. Вся постановка: почему замедляется рост? Превратите её в ограниченный анализ.

Я ограничу вопрос объяснением недельного отставания на 60 000 заказов за последние 13 недель от плана, построенного на предыдущих 13 неделях, для 5 зрелых рынков. - Определяю оплаченные заказы как подходящих посетителей, умноженных на конверсию в покупателя и число заказов на покупателя, и свожу компоненты от факта 1,02 млн к плану 1,08 млн. - Распределяю разрыв 60 000 между этими 3 компонентами через log-change или декомпозицию Шепли, затем разделяю новых и вернувшихся покупателей, чтобы не назвать микс привлечения удержанием. - Разрезаю разрыв по топ-5 рынкам, топ-5 каналам, платформе и возрасту когорты, но углубляюсь только в сегмент, объясняющий не менее 5 000 заказов или 10% отставания. - Отдаю диагностику за 5 рабочих дней, сравниваю с теми же 13 неделями прошлого года для контроля сезонности, а причинные выводы оставляю следующим тестам по 2 крупнейшим факторам.

Вопросы на собеседовании: Аналитик данных

100 реальных вопросов с образцовыми ответами и пояснениями для уровня Senior.

Смотреть пример резюме: Аналитик данных →

Тренировка флешкарточками

Интервальное повторение · Hunter Pass

Вопросы

activationsqlonboarding

Я выделю сессии в SQL с помощью детерминированной последовательности оконных вычислений, а затем агрегирую данные на уровне полученных сессий.

Применю LAG по каждому пользователю с сортировкой по event_ts и event_id и отмечу начало новой сессии, если предыдущего события нет или разрыв превышает 30 минут.
Накопительной суммой этого маркера в том же разделе создам стабильный номер сессии, сохранив event_id как критерий порядка для одинаковых временных меток.
Сгруппирую данные по user_id и номеру сессии и верну начало, конец, число событий и время первой активации.
Отфильтрую event_date до оконных вычислений, чтобы прочитать только 90 партиций, а затем сравню медианную длительность до активации между старым и новым вариантами онбординга.

Зачем это спрашивают: Интервьюер проверяет, умеет ли кандидат превратить оконные функции в детерминированный масштабируемый набор сессий, связанный с продуктовым порогом.

sqlwarehousequeries

Я выберу одну каноническую строку для каждого события до любых объединений и агрегаций покупок.

Применю ROW_NUMBER с разделением по event_id и сортировкой по убыванию source_updated_at, затем ingestion_ts, после чего оставлю строку с номером 1.
Если у старых клиентов нет event_id, построю документированный отпечаток из user_id, event_name, client_ts, order_id и хеша payload, а долю коллизий покажу отдельно.
Ограничу сканирование датой отчёта и трёхдневным окном повторов, но добавлю плановый пересчёт за семь дней для опоздавших событий.
Сверю уникальные order_id и сумму выручки с таблицей платежей и заблокирую отчёт на 09:00, если любое расхождение превысит 0,1 процента.

Зачем это спрашивают: Сильный ответ задаёт детерминированный выбор записи, учитывает несовершенные ключи и опоздавшие данные и проверяет финансовый результат, а не ограничивается DISTINCT.

retentioncohortssql

Я один раз зафиксирую когорту и знаменатель каждого пользователя, а затем соединю активность с явной сеткой недель.

До объединения с 6 миллиардами строк активности назначу каждому пользователю самую раннюю валидную дату регистрации, месяц когорты и канал привлечения.
Сведу активность к уникальным парам user_id и activity_date, затем рассчитаю week_number от даты регистрации и оставлю недели с 1-й по 12-ю.
Соединю каждую когорту и канал со справочником недель от 1 до 12, чтобы недели с нулём удержанных пользователей не исчезали.
Разделю число уникальных активных пользователей на исходный размер когорты, исключу из таблицы решений когорты с незавершённой четвёртой неделей и выведу каналы ниже порога 18 процентов.

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

funnelqueries

Я привяжу каждый шаг воронки к самому раннему подходящему событию после предыдущего шага на заданном уровне попытки.

Начну с одного view_item на пользователя и попытку оформления, сохранив item_id, вариант и временную метку как строку знаменателя.
Для каждого следующего шага возьму минимальную временную метку позже предыдущего шага и не позднее 24 часов после исходного просмотра, используя order_id или attempt_id для защиты от склейки разных покупок.
Соединю последовательные шаги через LEFT JOIN, чтобы пользователи, покинувшие воронку, остались в знаменателе, и засчитаю этап только при наличии всех предыдущих временных меток.
Верну конверсию этапов и потери между шагами по устройству и варианту, а в таблице раскатки отмечу варианты с ростом конверсии в покупку хотя бы на 2 процента.

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

sqltransactionsjoins

Я соединю каждую транзакцию с единственной версией уровня риска, интервал действия которой содержит время покупки.

Представлю историю уровней с включительной границей valid_from и исключительной valid_to, используя далёкую будущую дату только для текущей версии.
Соединю по customer_id при условии valid_from не позже purchased_at и purchased_at раньше valid_to либо применю нативный ASOF join хранилища с той же семантикой.
Проверю отсутствие пересекающихся интервалов, использую version_id как детерминированный критерий выбора и направлю транзакции без соответствия в явный уровень unknown.
Ограничу транзакции планируемым кварталом, заранее отфильтрую версии уровней, пересекающие этот период, и выведу долю дефолтов и объём риска по историческому уровню для установки лимитов.

Зачем это спрашивают: Сильный ответ предотвращает утечку будущей информации и доказывает, что каждый факт получает не более одной исторически корректной строки измерения.

sqlsnapshot

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

Соединю диапазоны активности продавца и SKU с календарём за 60-дневное окно, затем добавлю снимки через LEFT JOIN, чтобы отсутствующая строка означала unknown, а не нулевой запас.
С помощью LAG внутри каждого seller_id и sku_id отмечу границу острова при смене статуса, если предыдущая календарная дата не была вчерашней или статус любого дня равен unknown.
Накопительной суммой маркера границы назначу island_id, затем сгруппирую подтверждённые острова без товара и получу start_date, end_date и day_count.
Верну острова с day_count не меньше 14 для скрытия объявлений, а неизвестные интервалы длиннее двух дней отправлю в отдельную очередь качества данных.

Зачем это спрашивают: Интервьюер проверяет, умеет ли кандидат применять gaps-and-islands, не превращая отсутствие телеметрии в ложное бизнес-состояние.

percentilessqllatency

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

Точный PERCENTILE_CONT требует большой сортировки внутри каждой группы и даёт интерполированные квантили для финальных аудируемых чисел, но вряд ли уложится в 10 минут на 12 миллиардах строк.
APPROX_PERCENTILE или APPROX_QUANTILES использует скетчи с ограниченной памятью и должен вернуть p50, p95 и p99 для всех 500 групп в пределах SLA дашборда.
Ежемесячно откалибрую приближение относительно точного результата на репрезентативных партициях и зафиксирую абсолютную ошибку p95, которая должна оставаться ниже 50 миллисекунд.
Точно пересчитаю p95 для групп с приближённым результатом от 2,4 до 2,6 секунды и заблокирую релиз только по этой точной пограничной таблице.

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

sql

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

До оконной функции просуммирую выручку строк за вычетом возвратов на уровне category_id и product_id, округлив выручку до бухгалтерских центов.
Рассчитаю DENSE_RANK с разделением по category_id и сортировкой по убыванию net_revenue, затем оставлю ранги с 1-го по 5-й.
Не возьму ROW_NUMBER, потому что он произвольно отбросит товары, разделившие пятое место, и не возьму RANK, потому что пропуски рангов могут вернуть меньше пяти разных уровней выручки.
Верну ранг, чистую выручку и долю выручки категории и предупрежу мерчандайзинг, что при равенстве на пятом месте категория может содержать больше пяти товаров.

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

sqlqueriesrecursion

Я построю рекурсивным CTE замыкание предок-потомок, а затем агрегирую ARR потомков по каждому предку.

Начну с каждого аккаунта как одновременно предка и потомка на глубине 0, затем рекурсивно пойду по parent_account_id, сохраняя ancestor_id, descendant_id, depth и путь из посещённых id.
Остановлю ветвь при повторе id или достижении глубины 50, а циклы и отсутствующих родителей выведу отдельно вместо молчаливого удаления.
Просуммирую ARR каждого потомка один раз по ancestor_id из замыкания и рассчитаю максимальную глубину, не добавляя выручку родителя повторно на промежуточных уровнях.
Материализую проверенное замыкание инкрементально для 8 миллионов узлов, затем передам свёрнутую ARR и предков с максимальной глубиной выше восьми для изменения территорий.

Зачем это спрашивают: Сильный ответ использует рекурсивный SQL с правильной гранулярностью свёртки, защитой от циклов, ограничением глубины и результатом, связанным с решением по иерархии.

sqlqueriesjoins

Я использую профиль запроса, чтобы сначала сократить объём чтения и пересылки данных, а не увеличивать размер хранилища.

Проверю прочитанные байты, кардинальность объединений, сброс на диск и длительность этапов, затем перенесу фильтры event_date и периода действия кампании в самое раннее чтение кликов, сохранив отсечение партиций.
Сведу клики до нужного уровня user, session и campaign до объединения с заказами, а небольшие измерения кампаний добавлю только после сокращения данных, чтобы избежать размножения строк и сетевой пересылки.
Кластеризую или отсортирую крупный промежуточный набор по event_date и user_id и инкрементально материализую дневные входные данные атрибуции, если одни и те же 15 ТБ истории перечитываются каждую неделю.
Сравню число строк, идентификаторы атрибутированных заказов и контрольные суммы выручки с исходным запросом и приму переписывание только при времени меньше 10 минут и полном совпадении бизнес-итогов.

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

north-starmonitoring

Я выберу число успешно завершённых заказов за неделю, потому что оно фиксирует ценность, полученную и клиентами, и исполнителями.

Учитываю заказ один раз после проведения оплаты, если в течение 7 дней не было отмены или возврата; текущая база равна 40 000.
Раскладываю метрику как 500 000 подходящих посетителей, умноженные на 12% создания заявки, 80% мэтчинга и 83% завершения, что даёт около 39 840 заказов.
Ограничиваю долю споров за 7 дней уровнем ниже 3%, требую медианный заработок исполнителя не менее $24 в час и p90 времени до мэтча менее 48 часов.
Публикую показатель по городам и категориям услуг и отмечаю сегмент, который даёт более 20% роста при падении доли повторных заказов больше чем на 2 процентных пункта.

Зачем это спрашивают: Сильный ответ определяет созданную маркетплейсом ценность, даёт арифметическое разложение и не позволяет низкокачественному объёму выглядеть ростом.

metric-treesmonitoring

Я поставлю в корень конечный MRR и свяжу все ветки тождествами, которые сходятся к цели $2,4 млн.

Ветка запаса начинается с $2 млн, равных 100 000 платных мест, умноженным на $20 фактического MRR на место, и заканчивается целью $2,4 млн.
Месячный мост равен начальному MRR плюс $50 000 нового и $30 000 расширения, минус $20 000 сокращения и $25 000 оттока, что сейчас даёт чистый прирост $35 000.
Привлечение отвечает за ветку нового MRR в $50 000 как 1 000 новых аккаунтов, умноженные на $50 MRR первого месяца, с объёмом триалов и платной конверсией ниже по дереву.
Удержание отвечает за валовый отток MRR в 1,25%, а расширение за ветку $30 000; текущие потоки добавят за 6 месяцев только $210 000, оставив разрыв $190 000.

Зачем это спрашивают: Интервьюер проверяет, сходится ли дерево математически, можно ли закрепить его ветки за конкретными действиями и показывает ли оно разрыв до цели.

active-usersdecision-making

Я определю MAU как число уникальных канонических пользователей-людей, которые за календарный месяц по UTC создали хотя бы 1 сохранённое изменение контента.

Засчитываются ровно 3 успешных события: document_created, edit_committed и comment_posted; входы, просмотры, открытия уведомлений и неудачные записи не считаются.
Окно длится с 00:00 UTC 1-го числа включительно до 00:00 UTC 1-го числа следующего месяца, использует время события и закрывается после допуска в 48 часов на опоздавшие данные.
Разрешение идентичности считает 1 канонического пользователя на вебе и мобильном устройстве, исключает анонимную активность до привязки, а также сотрудников, тестовые, бот- и заблокированные аккаунты.
Старый показатель 1,2 млн я переименую в посещавшие MAU, пересчитаю оба определения за 12 месяцев и приму 430 000 за управляемую базу нового контракта.

Зачем это спрашивают: Сильный ответ убирает неоднозначность поведения, идентичности, времени и eligibility, а не просто выбирает более строгое прилагательное к слову активный.

activationguardrails

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

Регистрация активируется только после завершения 3 уроков хотя бы в 2 разных дня за первые 168 часов; рост с 32% до 40% означает ещё 160 000 активированных пользователей в месячной когорте.
В знаменателе оставляю подходящие новые аккаунты людей, назначенные в группу до первого напоминания, а сегменты по каналам показываю только при объёме не менее 10 000 регистраций.
Требую, чтобы 30-дневное удержание активированных пользователей снизилось не более чем на 1 процентный пункт, а доля отключивших push выросла не более чем на 0,5 пункта.
Ограничиваю жалобы на напоминания уровнем 2 на 10 000 отправок, а переменную стоимость доставки уровнем $0,30 на дополнительного активированного пользователя.

Зачем это спрашивают: Интервьюер ждёт KPI роста, привязанный к ценности, с точным контрактом и числовыми пределами для качества, вреда пользователю и стоимости.

aggregationsessions

Общая конверсия равна отношению суммы покупок к сумме подходящих сессий, то есть 2 200, делённым на 10 000, или 22%.

Рынок A конвертирует 20%, а рынок B 40%; их невзвешенное среднее 30% завышает результат на 10 пунктов.
Взвешивание конверсии каждого рынка по её знаменателю даёт 90% умножить на 20% плюс 10% умножить на 40%, что сходится к 22%.
Если доли рынков изменятся до 50% на каждый при прежних ставках, сырая конверсия вырастет до 30%, поэтому я также публикую ряд со стандартизированным исходным миксом 90/10.
Контракт учитывает не более 1 покупки на подходящую сессию оформления и показывает числитель 2 200 и знаменатель 10 000 рядом с каждым отношением.

Зачем это спрашивают: Сильный ответ считает отношение сумм, выявляет эффект микса и фиксирует гранулярность подсчёта вместо усреднения процентов.

funnel

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

Конверсия посетителя в старт равна 60 000, делённым на 100 000, или 60%, а конверсия старта в подходящую завершённую заявку равна 30 000, делённым на 60 000, или 50%.
Одобрение андеррайтинга равно 12 000, делённым на 30 000 подходящих завершённых заявок, или 40%; неподходящие и незавершённые заявки в этот знаменатель не входят.
Конверсия от подходящей заявки до выдачи равна 8 000, делённым на 30 000, или 26,7%, и раскладывается на 40% одобрения и 66,7% выдачи после одобрения; сквозная конверсия равна 8%.
Фиксирую eligibility на момент отправки заявки, объединяю повторные заявки одного человека за 30 дней и показываю все 5 объёмов этапов рядом с условными ставками.

Зачем это спрашивают: Интервьюер оценивает, умеет ли кандидат разделять знаменатели привлечения, eligibility, андеррайтинга и выдачи, не скрывая объёмы.

concurrency

Маржинальная прибыль составляет всего около $0,51 на заказ, поэтому внешне здоровый take rate 22% почти не оставляет места для дополнительных скидок.

Переменная выручка равна $7,04 комиссии плюс $2,20 сбора с клиента, итого $9,24 на заказ.
Переменные затраты равны $5,50 плюс $0,93 за обработку платежа, $0,80 на поддержку и возвраты и $1,50 на промо, итого около $8,73.
Маржинальная прибыль равна $0,51 на заказ, 1,6% GMV или примерно $25 600 на 50 000 недельных заказов до постоянных затрат.
Увеличение промо с $1,50 до $3,00 делает вклад отрицательным примерно на $0,99 за заказ, поэтому для оправдания потребуется не менее $1,50 измеренной будущей маржи когорты.

Зачем это спрашивают: Сильный ответ восстанавливает маржинальную прибыль из проверяемых компонентов выручки и переменных затрат и оценивает предлагаемый экономический рычаг.

experimentsproxyvalidation

Я проверю CTR на уровне эффектов экспериментов, потому что корреляция 0,65 между пользователями не доказывает, что изменение кликов меняет повторные покупки.

Для всех 24 зрелых тестов оцениваю эффекты на обе метрики на единице рандомизации и строю взвешенную по точности связь с leave-one-experiment-out валидацией.
Потребую совпадения направления хотя бы в 20 из 24 тестов, out-of-sample R-squared выше 0,50 и калибровочный наклон от 0,8 до 1,2.
Проверяю, что рост CTR на 1 пункт систематически не повышает возврат к поиску за 5 секунд больше чем на 0,3 пункта, иначе оптимизация создаёт низкокачественные клики.
Наблюдаю за прокси ещё на 6 экспериментах, дошедших до 28-го дня, и перестаю его использовать после 2 разворотов направления или выхода квартальной калибровки за диапазон 0,8-1,2.

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

monitoring

Я использую покрытие сбалансированной ликвидностью: долю подходящих заявок в локальных ячейках, где отношение запрошенных часов к доступным часам исполнителей лежит от 0,8 до 1,0.

Считаю нагрузку по городу, категории услуги и дню с учётом ожидаемой длительности заказа; глобальное отношение 90 000 к 100 000, или 0,9, скрывает локальный дефицит и простой.
Нагрузку ниже 0,6 считаю избытком предложения, а выше 1,2 дефицитом, при этом ячейки с менее чем 100 недельными заявками объединяю в более крупный регион.
Если сейчас только 58% заявок попадают в диапазон 0,8-1,0, ставлю цель 75% вместо максимизации только числа исполнителей или объёма заявок.
Подтверждаю границы ростом исполнения выше 80%, утилизацией исполнителей от 55% до 70% и медианным временем первого ответа менее 4 часов.

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

Я ограничу вопрос объяснением недельного отставания на 60 000 заказов за последние 13 недель от плана, построенного на предыдущих 13 неделях, для 5 зрелых рынков.

Определяю оплаченные заказы как подходящих посетителей, умноженных на конверсию в покупателя и число заказов на покупателя, и свожу компоненты от факта 1,02 млн к плану 1,08 млн.
Распределяю разрыв 60 000 между этими 3 компонентами через log-change или декомпозицию Шепли, затем разделяю новых и вернувшихся покупателей, чтобы не назвать микс привлечения удержанием.
Разрезаю разрыв по топ-5 рынкам, топ-5 каналам, платформе и возрасту когорты, но углубляюсь только в сегмент, объясняющий не менее 5 000 заказов или 10% отставания.
Отдаю диагностику за 5 рабочих дней, сравниваю с теми же 13 неделями прошлого года для контроля сезонности, а причинные выводы оставляю следующим тестам по 2 крупнейшим факторам.

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

Закрытые вопросы

21
В эксперименте с оформлением заказа базовая конверсия равна 12%, а прирост на 0,8 процентного пункта составляет минимальный эффект стоимостью $120 000 в год. Как рассчитать выборку и длительность при двустороннем alpha 5%, мощности 80% и 15 000 подходящих пользователей в день?
experimentsconversion
22
Тест цены поднял конверсию с 18,00% до 18,18%, а 95% доверительный интервал прироста составляет от 0,05 до 0,31 процентного пункта, но финансисты требуют минимум 0,30 пункта для покрытия внедрения за $250 000. Что вы рекомендуете?
confidence-intervalspricing
23
Эксперимент с номинальным распределением 50/50 назначил 100 000 пользователей, но в тесте записано 54 000, а в контроле 46 000. Метрика теста выросла на 4%. Как вы анализируете результат и принимаете решение?
experimentsmonitoring
24
До запуска команда зарегистрировала завершение оформления заказа как основную метрику, две защитные метрики с границами допустимого ухудшения и 24 вторичные метрики. Основная метрика выросла на 1,4% при p = 0,03, а одна вторичная получила p = 0,02. Как вы принимаете решение?
guardrailsmonitoring
25
В тесте подписки на 80 000 пользователей средняя выручка на пользователя выросла на 6%, но один тестовый аккаунт принёс $180 000, а без него оценка меняется на минус 1%. Что вы сообщаете и какое решение принимаете?
estimation
26
Новая домашняя лента увеличивает число сессий на 12% в первую неделю, на 6% во вторую и на 3% в четвёртую, а удержание 30-го дня ещё не созрело. Как отделить эффект новизны от устойчивой ценности?
retentionsessions
27
Функцию совместной работы тестируют на 120 000 пользователей в 6 000 рабочих пространствах, в среднем по 20 участников, но участники теста могут приглашать пользователей контроля и влиять на них. Как спроектировать тест при внутрикластерной корреляции 0,08?
correlationdesign
28
Нужно протестировать новый алгоритм диспетчеризации в восьми городах, где вариант одного водителя меняет ожидание других. Как вы спроектируете switchback и какое решение примете при росте завершённых поездок на 2,4% и ухудшении p90 подачи на 0,7 минуты при защитном лимите 0,5 минуты?
designguardrails
29
В эксперименте 200 000 существующих пользователей, а версия основной метрики за период до теста коррелирует с результатом на 0,65. Как CUPED изменит точность и что нужно проверить перед использованием положительного результата?
variance-reductionexperimentsmonitoring
30
Требование закона вынуждает 1 июля запустить новый комплаенс-флоу сразу во всех восьми рынках ЕС без контрольной группы. У вас есть 12 недель до и после запуска и 14 незатронутых рынков. Как оценить причинный эффект на активацию?
causaldesignestimation
31
В аналитической команде из 60 человек есть 400 моделей dbt и семь определений bookings в Looker. Как вы построите семантический слой метрик?
monitoringbidbt
32
Дашборд из 25 виджетов сканирует таблицу фактов на два миллиарда строк, а в 9 утра его открывают 400 пользователей; p95 загрузки должен быть ниже пяти секунд. Какую архитектуру запросов вы выберете?
queriesmodelingarchitecture
33
Таблица фактов продаж на восемь миллиардов строк питает ежедневный дашборд по странам и категориям, но возвраты для чистой выручки приходят с задержкой до 30 дней. Вы выберете агрегатную таблицу или материализованное представление?
materialized-viewsaggregation
34
У дашборда продаж в Tableau 200 пользователей, 120 миллионов позиций заказов, SLA свежести 30 минут и цель интерактивности две секунды. Вы выберете live-подключение или extract?
bi
35
Как обеспечить row-level security для 8 000 пользователей BI, 30 000 клиентских аккаунтов и четырёх миллионов прав пользователь-аккаунт, не замедлив каждый дашборд?
36
Спроектируйте звездообразную схему для коммерции с 500 миллионами позиций заказов в год, частичными возвратами, разделёнными отправками и несколькими попытками оплаты.
schemamodelingdesign
37
Вы получаете 150 миллионов продуктовых событий в день и должны считать DAU, воронки и сессии. Какую гранулярность вы выберете для базового факта и почему?
funnelactive-userssessions
38
Сегмент клиента и территория продаж меняются со временем, но финансы должны отчитываться по 80 миллионам строк счетов с атрибутами, действовавшими при выставлении счёта. Как вы смоделируете это через SCD Type 2?
39
Кредитор обрабатывает 2 млн заявок в год и должен видеть дневные остатки воронки и время от подачи до одобрения и выдачи. Вы используете периодический или накапливающий снимок?
snapshotconcurrencyci-cd
40
Спроектируйте self-service дашборд руководства по заказам и марже со свежестью 15 минут, p95 ниже трёх секунд в 9 утра и drill-down от региона до аккаунта и заказа.
cssdesign
41
Общая конверсия выросла с 7,8% до 8,75%, хотя на мобильных устройствах она упала с 6,0% до 5,8%, а на десктопе с 12,0% до 11,7%; как проверить, что это парадокс Симпсона?
paradoxes
42
У пользователей, открывающих рекомендации не менее 3 раз в неделю, удержание через 8 недель составляет 68% против 42% у остальных; как определить, вызывают ли рекомендации разрыв в 26 пунктов?
retention
43
В дневных данных за 18 месяцев регрессия связывает каждый дополнительный $1 расходов на кампанию с $2,40 выручки, но расходы растут в выходные и праздники; как оценить конфаундинг?
44
A/B-тест на 120 000 пользователей показал относительный прирост +2,1% и 95% доверительный интервал от -0,4% до +4,6%, а для запуска требуется не менее +1,5%; какой вывод вы сделаете?
ab-testingconfidence-intervals
45
На 1 800 заказах медианное время доставки снизилось с 42 до 39 минут, но 99-й перцентиль равен 310 минутам; как применить бутстрап к этой ненормальной метрике?
percentilesmonitoring
46
У вас есть 3 года недельных заказов, повторяющийся декабрьский всплеск на 30% и задача спрогнозировать следующие 13 недель при росте расходов на кампанию на 15%; каков ваш план анализа?
47
У подписочного продукта только 6 месяцев истории, 45% клиентов пришли за последние 60 дней, а бизнес просит отток за 180 дней; как учесть цензурирование?
churnsoft-skills
48
Месячный отток вырос с 4,8% до 6,1% за 3 месяца; как разложить этот бизнес-вопрос на проверяемые аналитические вопросы?
churn
49
После добавления тарифа за $19 ниже премиального тарифа за $39 общее число регистраций выросло на 24%, а старты премиума упали на 18%; как оценить каннибализацию и чистую ценность?
pricingestimation
50
В новой стране 25 миллионов взрослых, опрос 1 200 человек показывает потребность у 14%, а платный пилот на 800 посетителях конвертирует 3,5%; как оценить расширение с учётом неопределённости?
51
В 08:30 выяснилось, что KPI по вчерашним заказам на дашборде руководства завышен на 12% из-за 84 000 строк, продублированных при повторной обработке, а встреча CEO начнётся через 90 минут. Что вы сделаете сейчас и как докажете надёжность нового числа?
52
За 3 часа до заседания совета директоров CFO обнаруживает, что месячная выручка в аналитическом отчёте ниже главной бухгалтерской книги на 4,6%, или $3,2 млн. Как вы поступите с отчётом и сверите расхождение?
soft-skills
53
Дашборд продаж с SLA свежести 30 минут внезапно отстаёт на 9 часов, им пользуются 700 сотрудников, а ежедневная встреча по прогнозу начнётся через 40 минут. Опишите немедленные действия и проверку восстановления.
54
Дневная метрика заказов меняется на 6,8% каждую полночь, потому что события сгруппированы по UTC, а не по локальной дате каждого рынка в 14 странах, и завтрашний отчёт нужно выпустить через 2 часа. Что вы исправите и пересчитаете?
monitoring
55
Возвраты поступали с опозданием до 18 дней, поэтому чистая выручка прошлого месяца завышена на 2,7%, или $740 000, а финансовая команда требует пересчёт до звонка по финансовым результатам через 6 часов. Как вы его проведёте?
56
BI-выгрузка раскрыла 420 строк с конфиденциальными данными клиентов, а журналы аудита показывают, что за последние 36 часов файл скачали 17 сотрудников. Каковы ваши первые действия, оценка влияния и доказательство локализации?
57
Релиз источника переименовал checkout_status, что создало 38% NULL за 6 часов и снизило отчётную конверсию оформления заказа на 11 процентных пунктов. Продуктовый разбор начнётся через 45 минут. Как вы отреагируете?
58
Исправляющий пересчёт за 6 месяцев остановился на 61%, поэтому дашборд руководства смешивает исправленные и повреждённые месяцы и показывает скачок KPI на 3,4%. Что вы сделаете перед возобновлением?
backfill
59
В течение 2 часов дашборд продаж EMEA периодически показывал срез APAC, потому что в ключе общего кеша не было фильтра региона, а в журнале записаны 63 просмотра руководителями. Как вы локализуете и расследуете инцидент?
incidentscaching
60
Дашборд показывает $48,27 млн, а сумма его CSV-выгрузки из 18 400 строк равна $49,01 млн, расхождение составляет 1,53%, и финансовой команде нужен единый ответ через 60 минут. Вы находите $620 000 тестовых заказов и ещё $120 000 из-за охвата и округления строк. Что вы опубликуете?
61
Продуктовая команда показывает 1,2 млн MAU, а управляемый клиентский дашборд показывает 780 000, при этом до отправки материалов совету директоров осталось 3 часа. Что вы публикуете и как разрешаете спор?
active-users
62
Продажи считают квартальную выручку равной $84 млн, Финансы показывают $71 млн, а бонусы руководителей закрываются завтра. Как разрешить спор о валовой и чистой выручке?
63
Коммерческий дашборд показывает 2,46 млн заказов за июнь, но в платёжной системе есть 1,82 млн оплаченных order_id. От этого числа сегодня зависит решение о промоакции. Что вы делаете?
system-design
64
Маркетинговая атрибуция присваивает 52% конверсий платному поиску, 38% платным соцсетям, 27% email и 18% прямому каналу, всего 135%, а CMO хочет завтра перераспределить $4 млн. Как вы поступите?
soft-skills
65
Customer Success показывает месячный отток клиентов 4,8%, Финансы показывают 6,0%, хотя обе команды используют одни и те же 12 000 отмен. Какое число вы возьмёте в план продлений?
churnresilience
66
Продуктовая команда считает 4,08 млн апрельских заказов по календарному месяцу UTC, а Финансы считают 3,92 млн в фискальном апреле по календарю 4-4-5, который закрылся 28 апреля. Что попадёт в квартальный обзор?
67
Дашборд маркетплейса показывает месячный GMV $96 млн, но $14 млн приходится на отменённые заказы или неудачные платежи, а Финансы ожидают $82 млн. Какой показатель вы сохраняете?
68
Продуктовая команда показывает MRR $14,8 млн, Финансы показывают $13,9 млн, а разница возникла из-за валютных курсов и времени вступления апгрейдов в силу в 22 валютах. Что вы сообщите на закрытии месяца?
69
Поддержка показывает медианное время первого ответа 2,1 часа по 80 000 обращений, а Customer Success показывает 11,4 часа, при этом договоры предусматривают штрафы после 8 часов. Поддержка останавливает часы вне смен и считает ответы бота, а Customer Success считает полное время до первого ответа человека. Какой показатель станет официальным?
70
Руководство хочет изменить определение недельно активной команды с любого входа на минимум 3 совместных действия, но у текущей метрики есть 18 месяцев истории, текущее значение 640 000 и цель 750 000 к концу года. Как мигрировать контракт?
monitoring
71
Команда запланировала 14-дневный A/B-тест чекаута на 60 000 пользователей, но проверила результаты 12 раз и остановила тест на 4-й день при 18 000 пользователей, когда рост достиг 3,2% при p = 0,041. Вице-президент уже одобрил запуск. Что вы исправите немедленно?
72
Редизайн ленты поднял число сессий на 14% на 1-й неделе и на 7% на 2-й, поэтому продуктовая команда начала полную раскатку на основе раннего среднего роста 10,5%; к 6-й неделе эффект стал отрицательным 1%. Как вы исправите решение?
sessions
73
На слайде для руководства сказано, что редизайн поднял конверсию с 14,0% до 20,4%, но в enterprise-сегменте она упала с 30% до 28%, в SMB с 10% до 9%, а доля enterprise-трафика выросла с 20% до 60%. Что вы скажете руководству?
74
Опрос 2 000 клиентов показывает, что 62% хотят новый процесс, и руководство готово вложить $2 млн в разработку; 70% респондентов относятся к enterprise, хотя в клиентской базе их 15%, при поддержке 75% в enterprise и 32% в SMB. Что вы исправите?
75
В эксперименте с уведомлением на 100 000 пользователей аналитик исключает 30 000 участников тестовой группы и 20 000 участников контрольной, которые не открыли приложение после распределения; среди оставшихся покупают 12% против 10%, а по всем назначенным пользователям показатели равны 8,4% против 8,2%. Команда хочет запустить изменение. Как вы ответите?
experiments
76
В тесте показаны 30 итоговых метрик: зарегистрированная основная метрика снизилась на 0,4% при p = 0,62, но одна незарегистрированная метрика шеринга выросла на 6% при p = 0,03, и в мемо запуск назван победой. Что вы измените?
experimentsmonitoring
77
Тест на 12 000 пользователей оценивает рост конверсии в 1,0 процентного пункта при p = 0,57 и 95% доверительном интервале от минус 2,5 до плюс 4,5 пункта; команда говорит, что эффекта нет, и хочет раскатить уже разработанную функцию. Что вы решите?
confidence-intervalsestimation
78
Поисковый эксперимент распределяет 40 000 пользователей, но анализ считает 3,2 млн поисков независимыми строками и сообщает рост 1,8% при p = 0,004. Пересчёт на уровне пользователя даёт 95% интервал от -0,6% до +4,2%, для запуска требуется не менее +2,5%, а CMO хочет продолжить. Что вы сделаете?
experiments
79
Операционная команда выбрала 20 худших регионов после 8-недельного падения до 72 заказов в день; после обучения показатель вырос до 88, и команда заявила рост 22%. Рандомизированная очередь ожидания из 20 регионов за тот же период выросла с 73 до 87, а для раскатки требуется 10 дополнительных заказов в день. Как вы исправите вывод?
design
80
В обзоре здоровья клиентов опрашивают только 18 000 аккаунтов, которые остались активными из исходной когорты 30 000, и сообщают об удовлетворённости 84% через 12 месяцев; 12 000 ушедших аккаунтов исключены, а руководство использует результат для продления программы customer success за $3 млн. Что вы сделаете?
churncohorts
81
COO просит за 4 часа решить, одобрять ли экстренную доставку за $3 млн, потому что fill rate упал с 96% до 89% в 12 складах, но один склад с 8% заказов сегодня не загрузился. Что вы предоставите?
warehouse
82
Презентацию для совета директоров нужно сдать через 3 часа, но в хранилище отсутствует источник, на который приходится 8% квартальных заказов. Как вы представите показатель?
warehouse
83
Запуск продукта назначен через 12 часов, но таблица качества платежей для порога ошибок 1,0% отстаёт на 2 дня. Что вы рекомендуете?
84
CFO требует через 6 часов один прогноз годовой выручки для бюджета, хотя текущие модели дают диапазон от $116 млн до $141 млн. Что вы предоставите?
85
VP просит убрать сегмент, охватывающий 14% клиентских аккаунтов, потому что его удержание упало на 11 процентных пунктов и скрывает рост остальных сегментов на 3%. Что вы сделаете?
retention
86
Маркетинг тратит $4,2 млн в квартал и требует за 3 часа причинную оценку ROI по наблюдательным данным атрибуции; дашборд показывает ROAS 3,1x. Как вы ответите?
causal
87
Команде коммуникаций за 24 часа нужно публичное число клиентов, и она хочет заявить 2 млн, но разные правила идентификации дают от 1,84 млн до 2,07 млн. Какое число вы одобрите?
estimation
88
Регулятор требует отчёт по транзакциям через 36 часов, но итог хранилища равен $138,6 млн против $141,0 млн в бухгалтерском реестре, то есть расхождение составляет 1,7%. Что вы подадите?
transactionswarehousereact
89
Руководство предлагает сократить 15% операционной команды из 240 человек, потому что дашборд ставит их на последние места по продуктивности, но в поток данных не попало 22% выполненной работы. Как вы ответите?
90
Due diligence по покупке компании завершается через 48 часов, при этом цель сделки заявляет выручку $62 млн, её главная книга показывает $57 млн, а CRM показывает $65 млн. Что вы советуете команде сделки?
91
За 2 часа до встречи с руководством junior показывает рост жалоб с 0,2% до 0,6% как утроение на графике, чья ось Y начинается с 0,18%; размеры выборок равны 22 000 и 1 900 пользователей. Как исправить представление для решения и помочь junior, не забирая работу?
92
Junior распределяет бюджет кампании $5 млн по таблице с 6 ручными фильтрами, а повторный запуск меняет итоги каналов на 3,2%; рекомендация нужна завтра к 10:00. Что вы сделаете?
spreadsheetsspread
93
Middle-аналитик сообщает на квартальном обзоре, что выручка выросла на 18%, со $100 млн до $118 млн, но цены поднялись на 12%, а число клиентов снизилось на 4%. Как исправить вывод и превратить ситуацию в менторский кейс?
mentoring
94
Junior построил дашборд из 47 графиков для 12 руководителей к 09:00 завтра, хотя на встрече нужно принять решения только по трём бизнес-вопросам. Как спасти поставку и помочь ему вырасти?
95
У клиентов, которые сами подключают консультации, 90-дневное удержание равно 68% против 42% у остальных, но до подключения первые уже были активнее в 2,3 раза; аналитик пишет в презентации для VP, что консультации повышают удержание на 26 пунктов. Что вы сделаете?
retentiondecision-making
96
Middle-аналитик обещал за пять дней диагностировать отток, но к пятому дню не подготовил результат, расширив четыре гипотезы до 34 сегментных разрезов, а решение руководства назначено на завтра. Как вы поступите?
churnpromisessoft-skills
97
Аналитик хочет получить повышение до senior за шесть месяцев, а три команды сейчас регистрируют 18 споров о метрике конверсии за квартал и тратят шесть часов в неделю на сверку. Какой проект с владением вы ему дадите?
ownershipmonitoring
98
Два аналитика публикуют потребность поддержки на третий квартал в 120 и 165 FTE для прогнозных 4,2 млн обращений за 30 минут до закрытия операционного плана. Как разрешить ситуацию без поиска виноватого?
99
В 14:00 перед сроком регионального отчёта в 16:00 junior обнаруживает, что у 9% заказов нет региона, присваивает им крупнейший регион и не упоминает пробел в примечаниях. Как вы отреагируете?
estimation
100
Ваша команда рекомендовала новый онбординг, но после запуска на 10% аудитории активация падает с 35,0% до 33,2%, а обращения в поддержку растут на 18%. Что вы сделаете с запуском и командой?
activationonboarding

Вопросы

11У маркетплейса бытовых услуг 500 000 посетителей в неделю, 40 000 завершённых заказов и недельный GMV $8 млн. Какую north star метрику вы выберете?

12У подписочного продукта 100 000 платных мест и $2 млн MRR, который нужно увеличить на 20% за 6 месяцев. Постройте дерево метрик.

14Обучающее приложение получает 2 млн новых регистраций в месяц, а growth-команда хочет напоминаниями поднять активацию с 32% до 40%. Определите KPI и guardrail-метрики.

Закрытые вопросы