Пост Firebase в WebView: какие события собирать, чтобы не сломать арбитражную аналитику

Firebase в WebView: какие события собирать, чтобы не сломать арбитражную аналитику В WebView аналитика ломается не из-за Firebase, а из-за хаотичной схемы событий. Если сразу не развести web-сигналы и app-сигналы, вы увидите красивый, но бесполезный график: установка есть, а где отвалился трафик — неясно. Что важно: собирайте только те точки, которые помогают управлять воронкой. Минимум: first_open, view_item, lead_start, lead_submit, purchase/dep, plus кастомные шаги для формы, оплаты и ошибок. Для арбитража полезнее не “все клики подряд”, а 2–3 ключевых этапа в каждом экране. На практике: передавайте в event_params source, campaign, adset, creative и placement, но не тащите в аналитику мусорный кликстрим. Иначе в отчетах будет много строк, а решений — мало. Для WebView отдельно помечайте переходы между страницей, формой и внешним SDK-экраном, чтобы видеть, где именно падает конверсия. Еще один момент — дедупликация. Если WebView перезагружается или пользователь возвращается назад, одно и то же событие может улететь повторно. Ставьте session_id, stable user_id и защиту от дублей на стороне приложения или бэка. Это спасает от ложного роста CR и неправильных выводов по крео. Соберите сначала каркас событий, потом уже расширяйте его под конкретный оффер. В арбитраже аналитика ценна не количеством метрик, а тем, насколько быстро она отвечает на вопрос: где теряется деньги.