С какими аналитическими инструментами работали в iOS проектах

Что проверяют

Работали ли вы с продуктовой частью, а не только с экранами. Аналитика это чужой код внутри вашего приложения, требования приватности и вечная проблема качества событий. Спрашивают, видите ли вы всю цепочку от постановки гипотезы до цифры в отчёте.

Как отвечать

Перечисляйте инструменты по назначению, а не вперемешку:

• продуктовые события и воронки: Firebase Analytics, Amplitude, AppMetrica, Mixpanel;
• сбои и ошибки: Crashlytics, Sentry, отчёты в организаторе Xcode;
• производительность приложения: MetricKit с данными о запуске, зависаниях и расходе энергии, плюс показатели в консоли разработчика.

Дальше про встраивание. Сильный ответ звучит так: в приложении есть свой протокол отправки события, а конкретные наборы разработчика спрятаны за его реализациями. Тогда смена поставщика не превращается в правку всего проекта, а в отладочной сборке события выводятся в журнал или в отдельный экран проверки. Схема событий фиксируется заранее: имя, обязательные параметры, единый стиль именования. Добавьте про приватность: запрос разрешения на отслеживание, декларация собираемых данных, отказ от персональных сведений в параметрах.

Где спотыкаются

Зовут набор разработчика прямо из экранов. Через полгода смена поставщика превращается в правку сотни файлов, а имена событий расползаются так, что воронку уже не собрать.

Вторая ошибка: не проверять события. Аналитика не падает от опечатки в имени, она молча шлёт мусор, и это выясняется через месяц, когда данные понадобились для решения.

Третья: рассказ про инструмент, который поставщик давно свернул, или заученная цифра роста конверсии. Спросят, как считали и с чем сравнивали, и окажется, что замера не было вовсе.