Инструментация и качество данных: вопросы для собеседования (часть 4)
Трекинг событий, naming conventions, data contracts, валидация данных — от качества инструментации зависит качество всей аналитики. На собеседовании спрашивают, как спроектировать систему событий для нового фичи, что делать при расхождении данных между системами и как обнаружить проблемы с логированием.
Вопросы 16–20 из 20
16Вы хотите добавить новое свойство `promo_code` в событие `checkout_started`. Какой подход лучше с точки зрения качества данных и совместимости?
AПереименовать событие в `checkout_started_v2` и сразу удалить старое из схемы, чтобы избежать двух версий в отчётах
BУдалить из события устаревшие свойства одновременно с добавлением `promo_code`, чтобы держать схему компактной
CДобавить `promo_code` как необязательное свойство, обновить таксономию событий и валидаторы, сохранив обратную совместимость
DДобавить `promo_code` как обязательное свойство сразу для всех клиентов, чтобы старые сборки приложения не отправляли событие без него
Ответ: Безопасная эволюция схемы — это добавление необязательных свойств и обновление таксономии событий с сохранением обратной совместимости.
При расширении схемы событий важно не сломать данные, которые уже идут со старых клиентов. Новое поле добавляют как необязательное (`optional`): новые сборки шлют его, старые продолжают слать событие без него — обратная совместимость сохраняется. Резкое переименование или удаление старого события создаёт пробел в исторических метриках. Удаление устаревших свойств одновременно с добавлением нового — отдельная задача, её делают через депрекацию. Обязательное поле для всех ломает сборки, которые ещё не обновились.
Подробный разбор → 17Вы хотите убрать дубликаты для события `purchase_succeeded`. Какой ключ дедупликации наиболее безопасен, чтобы не «съесть» реальные повторные покупки одного пользователя?
AИспользовать `dedup_key=user_id` совместно с `event_name`, чтобы оставить у каждого пользователя только одну покупку и убрать повторные.
BИспользовать `dedup_key=order_id` (или `transaction_id`), а для повторных доставок одного события дополнительно `event_id` как защиту.
CИспользовать `dedup_key=event_time` совместно с `user_id`, потому что одинаковое время события почти наверняка означает дубликат записи.
DИспользовать `dedup_key=amount_minor` совместно с `user_id`, потому что одинаковая сумма платежа с большой вероятностью означает дубликат.
Ответ: Дедупликация должна опираться на идентификатор транзакции (`order_id`), а не на время или пользователя.
Пользователь может совершать несколько покупок, поэтому `user_id` не подходит как ключ дедупликации. Время устройства может быть неточным, а разные покупки могут происходить близко по времени. Сумма также не уникальна и приведёт к потере валидных событий. `order_id` или `transaction_id` отражают уникальность покупки, а `event_id` помогает удалять повторные доставки одного и того же события в пайплайне сбора логов.
Подробный разбор → 18После релиза Android `app_version='5.2'` `DAU` по событию `app_open` упал на 30%. При этом по той же версии объём `screen_view` и `purchase_succeeded` почти не изменился. Какое объяснение наиболее вероятно и что делать?
AСезонная просадка после релиза: `DAU` по `app_open` восстановится через пару недель без вмешательства команды
BЧасть пользователей перешла на использование виджетов вместо открытия приложения, поэтому переписываем сценарий запуска
CСнижение `app_open` объясняется ростом числа push-уведомлений: пользователи реагируют на них без открытия приложения
DСкорее всего сломалось инструментирование `app_open` в `5.2`: сверить схему событий, проверить отправку и добавить алерты по версии
Ответ: Если падает один `event`, а соседние события стабильны, это часто баг логирования, а не реальное изменение поведения пользователей.
Когда метрика по одному событию резко падает, а смежные события (`screen_view`, `purchase_succeeded`) на той же версии не меняются, это типичный признак поломки инструментирования, а не реального изменения поведения пользователей. Если бы пользователи перестали открывать приложение, упали бы и просмотры экранов, и покупки. Поэтому первый шаг — проверить отправку события `app_open` в новой сборке, сравнить со схемой и поднять алерт по версии. Гипотезы про виджеты или push-эффект интересны, но для них нет подтверждающих изменений в смежных метриках.
Подробный разбор → 19Вы настраиваете мониторинг качества данных для платёжного флоу. Какой набор проверок согласованности наиболее практичен и устойчив к сезонности?
AДоля `payment_succeeded` к `checkout_started` строго фиксирована на 2% каждые сутки и блокирует пайплайн при любом отклонении
BВ событии `payment_succeeded` заполнены ключевые поля `order_id` и `amount`, и за сутки на один `order_id` не более одного успеха
CМежду `checkout_started` и `payment_succeeded` нет задержек и переупорядочивания, иначе событие считается потерянным навсегда
DДоля `payment_failed` обнулена в сводке каждый отчётный день, иначе строки `payment_failed` считаем плохими и блокируем выгрузку
Ответ: Хорошие проверки согласованности проверяют структуру и логическую целостность событий, а не «идеальные» бизнес-отношения.
Хорошие проверки согласованности — это инварианты схемы, которые редко ломаются по бизнес-причинам: непустые ключевые поля, уникальность по `order_id`, ссылочная целостность. Жёсткая фиксированная конверсия (2%) или нулевая доля ошибок будут срабатывать на сезонности и инцидентах провайдеров, давая ложные алерты. Требование «нет задержек» нереалистично для мобильных событий: офлайн-буфер и переотправка — норма. Поэтому самый практичный набор — заполненность ключей и уникальность успешного события на заказ за сутки.
Подробный разбор → 20После релиза iOS конверсия из `add_to_cart` в `purchase_succeeded` резко упала, но вы не уверены — это продуктовый эффект или поломка логирования. Какое действие наиболее корректно?
AСчитать падение реальным снижением спроса и срочно корректировать ассортимент и ценовую политику для восстановления конверсии
BВременно переключить дашборд на метрику `add_to_cart`, чтобы убрать просадку из отчётности до следующего ревью команды
CУвеличить маркетинговый бюджет и запустить акцию: рост трафика компенсирует падение конверсии и стабилизирует воронку покупок
DПроверить изменения схемы событий и инструментирования: не пропал ли `order_id`, не вырос ли null rate, сверить с источником истины
Ответ: При резком сдвиге воронки сначала проверяют `data quality`: схему, поля, объёмы и соответствие источнику истины.
При резкой просадке конверсии после релиза первая гипотеза — поломка логирования, а не падение спроса. Сверяем схему событий и инструментирование: появились ли новые null-значения в ключевых полях, изменилось ли имя события, не пропали ли свойства вроде `order_id`. Сравниваем количество `purchase_succeeded` с источником истины — таблицей заказов в платёжной системе. Решения уровня «корректировать ассортимент» или «вкачать маркетинг» без проверки данных — потенциально дорогая ошибка. Прятать просадку из дашборда — антипаттерн отчётности, который не решает проблему.
Подробный разбор → Другие темы: Продуктовая аналитика