Инструментация и качество данных: вопросы для собеседования (часть 2)
Трекинг событий, naming conventions, data contracts, валидация данных — от качества инструментации зависит качество всей аналитики. На собеседовании спрашивают, как спроектировать систему событий для нового фичи, что делать при расхождении данных между системами и как обнаружить проблемы с логированием.
Вопросы 6–10 из 20
6Вы проектируете `event taxonomy` для регистрации. Какой вариант `instrumentation` лучше всего подходит, чтобы считать конверсию в успешную регистрацию и понимать, через какой способ вошли?
AЛогировать `signup_completed` с `properties={'method': 'email', 'platform': 'ios'}` и отдельно `signup_failed` с причиной ошибки.
BЛогировать только `button_click` по кнопке «Зарегистрироваться» без `properties`.
CЛогировать отдельные события `signup_completed_email` и `signup_completed_phone` разными именами.
DЛогировать только серверные `logging`-сообщения без идентификатора пользователя.
Ответ: Хорошая `event taxonomy` фиксирует смысловой `event` и ключевые `properties`, а ошибки лучше отделять отдельным событием.
Событие `signup_completed` отражает факт успешного результата и удобно для воронки. Свойства вроде метода и платформы помогают сегментировать, не раздувая набор имён событий. Отдельный `signup_failed` позволяет анализировать причины падения конверсии без смешивания успеха и ошибок в одном событии. `button_click` без контекста не даёт уверенности, что регистрация завершилась.
7На iOS свойство товара приходит как `productId`, а на Android как `product_id`. В отчётах часть событий не джойнится. Что правильнее сделать для `data quality`?
AОставить как есть и в каждом запросе писать два варианта поля.
BСчитать метрики по iOS и Android всегда отдельно, чтобы не смешивать.
CПереименовать поле только на iOS без обновления `event taxonomy`, чтобы быстро починить.
DЗафиксировать единый стандарт в `event taxonomy` (например, `product_id`) и привести `instrumentation` или ETL-нормализацию к нему.
Ответ: Единая `event taxonomy` и нормализация свойств между платформами уменьшают ошибки `logging` и упрощают аналитику.
Когда названия и типы `properties` расходятся, появляются скрытые дыры: отчёты не совпадают, джойны ломаются, проверки не срабатывают. Лучший путь — договориться о контракте и привести реализацию на всех платформах к нему, либо сделать явное преобразование в пайплайне. Важно также добавить валидации на схему, чтобы такие расхождения ловились автоматически. Это снижает ручную работу аналитиков и повышает доверие к данным.
8Как лучше организовать `event taxonomy` для ошибок оплаты, чтобы аналитика могла быстро находить причины падения конверсии и не путать успех с ошибкой?
AЛогировать только системные `logging`-сообщения на устройстве без событий.
BДелать разные имена событий под каждую ошибку, например `payment_error_timeout`, `payment_error_3ds`.
CЛогировать `payment_succeeded` для успеха и `payment_failed` для ошибки с `properties={'stage': '3ds', 'error_code': 'timeout', 'provider': 'bank'}`.
DНе логировать ошибки, чтобы не «загрязнять» данные.
Ответ: Разделение успеха и ошибки на разные `event` и явные `properties` делает `data quality` и диагностику лучше.
Если смешивать успех и ошибки в одном событии или раздувать имена под каждую причину, отчёты становятся нестабильными и трудно валидируемыми. Отдельные `payment_succeeded` и `payment_failed` упрощают воронки и дают ясные точки для `invariants`. Свойства `stage` и `error_code` позволяют агрегировать причины и не терять детализацию. Это снижает время диагностики и делает `instrumentation` предсказуемой.
9Вы включили семплирование 10% для высокочастотного события `scroll` (в `instrumentation` оно отправляется не всегда). Как сделать так, чтобы аналитика и `data quality` не пострадали?
AНичего не делать: семплирование не влияет на выводы, потому что выборка большая.
BЛогировать `sample_rate` в `properties` и использовать веса при расчётах, а критичные для `user journey` события не семплировать.
CУбрать `sample_rate`, чтобы не путать аналитиков, и считать как обычные события.
DСемплировать только «плохих» пользователей, чтобы быстрее находить проблемы.
Ответ: При семплировании важно фиксировать `sample_rate` и не семплировать события, которые являются основой воронок и инвариантов.
Без знания `sample_rate` вы не сможете корректно восстанавливать оценки и сравнивать периоды. Для событий поведения вроде `scroll` семплирование может быть нормальным, но для событий успеха и шагов `user journey` оно ломает конверсии и `invariants`. Поэтому обычно разделяют: высокочастотные события можно семплировать, а ключевые — нет. Явная фиксация семплирования делает расчёты воспроизводимыми и защищает `data quality`.
10После обновления SDK вы видите, что сумма по `purchase_succeeded` выросла почти в 2 раза, но платежный провайдер этого не подтверждает. Что наиболее вероятно и какое действие по `data quality` самое уместное?
AПользователи стали покупать чаще, оставляем как есть.
BНужно подождать неделю: метрики «усреднятся» и проблема исчезнет.
CНужно удалить все события с одинаковым `event_time`, это точно дубликаты.
DВероятна повторная отправка событий (`at-least-once`); нужен уникальный `event_id` или `dedup_key` и дедупликация в пайплайне.
Ответ: Дубликаты часто возникают из-за повторной отправки при сетевых ретраях, поэтому нужен механизм дедупликации через `event_id` или `dedup_key`.
Если источник истины (провайдер) не подтверждает рост, это сильный сигнал, что проблема в `instrumentation` или обработке событий. Удаление по `event_time` опасно: реальные покупки могут происходить близко по времени, а часы на устройстве могут быть неточными. Правильнее закладывать дедуп на уровне идентификаторов события и транзакции. Затем инварианты по уникальности `order_id` помогут автоматически ловить повторения.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в TelegramДругие темы: Продуктовая аналитика