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