Какие были доступы для просмотра данных в аналитике на проекте
Что проверяют
Работали ли вы с данными за пределами интерфейса и понимаете ли, как на проекте устроено разграничение доступа. Заодно проверяют зрелость: тестировщик, который хвастается админскими правами на продовую аналитику, настораживает. Следом обычно просят рассказать, что именно вы с этим доступом проверяли.
Как отвечать
Опишите реальную картину своего проекта по уровням, инструменты называйте свои:
- продуктовая аналитика: AppMetrica, Яндекс Метрика, Google Analytics 4, Amplitude. Обычно доступ на чтение отчётов и режим отладки событий, например DebugView в GA4;
- BI и дашборды: Metabase, Superset, DataLens, Power BI. Роль просмотра, иногда право собирать свои запросы и графики;
- хранилище: доступ только на чтение к реплике или DWH (ClickHouse, PostgreSQL) для SQL-запросов, часто только к тестовому контуру или обезличенным данным;
- сырые события: чтение топика Kafka или логов, куда падает трекинг, прокси вроде Charles или Proxyman, чтобы видеть отправку событий с клиента.
Затем расскажите, как доступ выдавался и ограничивался: заявка через тикет, роль по принципу минимальных привилегий, разные права на прод и тест, маскирование персональных данных. И главное, что вы с этим делали: сверяли события с трекинг-планом (имена, параметры, момент отправки), сравнивали цифру на дашборде с SQL по исходной таблице, ловили дубли событий после ретраев.
Если доступа к аналитике не было, так и скажите и объясните, как проверяли события без него: через прокси, логи клиента, в паре с аналитиком, который смотрел отчёт. Честный ответ с рабочим обходным путём выглядит лучше придуманного админского доступа.
Где спотыкаются
Говорят «был полный доступ ко всему». Для интервьюера это сигнал, что вы не думали о безопасности данных.
Приводят придуманные метрики вроде «точность отчётов выросла на 20%» и не могут объяснить, как это посчитали.
Рассказывают, как выгружали реальные данные пользователей в баг-репорт или общий чат. Правильно прикладывать обезличенный пример или идентификатор записи.