Вопросы по теме «Инструментация и качество данных»
Трекинг событий, naming conventions, data contracts, валидация данных — от качества инструментации зависит качество всей аналитики. На собеседовании спрашивают, как спроектировать систему событий для нового фичи, что делать при расхождении данных между системами и как обнаружить проблемы с логированием.
Всего в этом разделе 20 вопросов. Каждый — с правильным ответом и кратким разбором теории. Разбито на 4 части по 5 вопросов.
Вопросы 1–5 из 20
1Вы логируете событие `experiment_exposure` для A/B тестов. Какой `invariants` наиболее полезен для контроля `data quality`?
AДля пары `user_id` + `experiment_id` не должно быть разных значений `variant`, а в событии должны быть заполнены `experiment_id` и `variant` из списка допустимых.
BРаспределение вариантов должно быть ровно 50/50 каждый день, иначе данные неверные.
C`experiment_exposure` можно не логировать, достаточно смотреть метрики результата.
DСобытие нужно отправлять как можно чаще при каждом открытии экрана, даже если вариант не меняется.
Ответ: Инварианты для `experiment_exposure` должны ловить противоречия в назначении варианта и обязательные поля, а не требовать идеальной пропорции.
Равномерность распределения может колебаться из-за сегментации и рандомизации, поэтому это плохой жёсткий инвариант. Гораздо важнее, чтобы один пользователь не попадал в разные варианты одного эксперимента, иначе нарушается корректность интерпретации. Обязательные свойства и допустимые значения позволяют быстро ловить баги в `logging`. Частые повторные экспозиции могут раздуть события и усложнить дедупликацию, поэтому их нужно контролировать.
2Вы описываете `event taxonomy` для `purchase_succeeded`. Как лучше хранить сумму покупки в `properties`, чтобы избежать проблем `data quality` при агрегациях?
AХранить `amount='1990 RUB'` строкой, чтобы сразу было красиво.
BХранить `amount_minor=1990` и `currency='RUB'` отдельным свойством.
CХранить `amount='1 990'` со пробелами и разделителями, как в UI.
DХранить только `currency`, а сумму вычислять по истории корзины.
Ответ: Для аналитики лучше хранить числовое поле и валюту отдельно, чтобы избежать парсинга и неоднозначностей в `properties`.
Строковые суммы легко ломаются из-за форматирования, пробелов и локалей, что создаёт ошибки в отчётах. Число в минимальных единицах удобно суммировать и сравнивать без плавающих ошибок, а `currency` отделяет контекст. Такой формат проще валидировать и поддерживать при изменениях. Это повышает надёжность `logging` и снижает стоимость последующей очистки данных.
3Какой санити-чек лучше всего подходит для свойства `currency` в событиях покупок с точки зрения `invariants` и `data quality`?
AПроверять, что `currency` всегда равно 'RUB', иначе это ошибка данных.
BРазрешить любые значения `currency`, чтобы `logging` никогда не ломался.
CУдалить `currency` и хранить только `amount_minor`.
DПроверять, что `currency` не пустое и входит в список допустимых кодов; алертить на новые или неожиданные значения.
Ответ: Инвариант для перечислимого поля должен проверять не пустоту и допустимый набор значений, иначе ошибки будут скрыты.
Жёстко фиксировать одну валюту нельзя, если продукт международный или планы могут измениться. Разрешать любые значения тоже опасно: опечатки и разные форматы начнут «размножаться» и ломать отчёты. Проверка допустимых кодов даёт ранний сигнал о баге `instrumentation` или о новом бизнес-кейсе, который нужно поддержать. Это простой, но очень эффективный контроль `data quality`.
4Какие `properties` полезно добавлять почти ко всем событиям, чтобы быстрее диагностировать проблемы `instrumentation` после релизов?
AДостаточно только `user_id`, остальные поля не нужны.
BДобавлять `app_version`, `platform` и `sdk_version` (или `build_number`), чтобы локализовать баги по версиям и окружению.
CУбирать `app_version`, чтобы данные были единым массивом без сегментации.
DЛогировать пароль пользователя, чтобы проще было воспроизводить ошибки.
Ответ: Поля версии и платформы в `logging` помогают быстро понять, где именно сломалась `instrumentation`.
Если метрика падает после релиза, первый вопрос: это реальное поведение или сломанные события в конкретной версии. `App_version` и `platform` позволяют сегментировать и увидеть резкие разрывы, а `sdk_version` помогает отделить баг SDK от кода приложения. Без этих полей диагностика превращается в гадание и долгие переписки. Это один из самых дешёвых способов улучшить `data quality`.
5Вы хотите логировать применение фильтров в каталоге. Какой вариант лучше для `event taxonomy` и последующей аналитики?
AСоздавать отдельные события `filter_applied_color`, `filter_applied_brand` и так далее.
BЛогировать единый `filter_applied` с `properties={'filter': 'brand', 'value': 'nike'}`.
CЛогировать событие `user_did_something` и писать всё в текстовое поле.
DЛогировать событие `filter_applied` без `properties`, а значение фильтра брать из UI-скриншота.
Ответ: Стабильные имена `event` и параметры в `properties` обычно лучше, чем динамические имена событий.
Динамические имена раздувают таксономию и усложняют запросы и мониторинг `data quality`. Единый `event` с параметрами позволяет добавлять новые фильтры без взрыва количества событий. Такой подход проще валидировать и сравнивать между платформами. Текстовые поля и скриншоты плохо подходят для надёжной аналитики и автоматических проверок.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в TelegramДругие темы: Продуктовая аналитика