SuperApp нельзя продвигать только по KYC: Firebase-события, value model и tROAS для роста продуктов

Dilshat Rakhimov
May 2026 · 14 min read

У банковского SuperApp есть типичная ловушка роста. Команда начинает с понятной цели: привести больше зарегистрированных пользователей, довести их до KYC и доказать, что реклама может масштабировать базу. Это нормальный первый шаг. Но если оптимизация долго живет только на sign_up, registration_complete или kyc_approved, рекламная система учится находить людей, которые дешево проходят онбординг. Она не обязана находить людей, которые потом делают переводы, открывают депозит, берут кредит или покупают услуги внутри WebView.

Для SuperApp уровня Halyk проблема особенно заметна. Внутри одного приложения живут продукты с разной экономикой: ежедневные переводы, платежи, кредитные заявки, карты, депозиты, инвестиции, страховки, билеты, коммунальные платежи, мобильная связь, eGov-like сервисы и партнерские витрины. Если все это мерить одной регистрацией, маркетинг выглядит эффективным, но продуктовые команды видят другое: пользователи пришли, KYC прошли, а оборота и маржи по продуктам не хватает.

Правильный ответ - не заменить KYC на один случайный purchase. Нужно построить систему, где KYC остается качественным входным фильтром, а оптимизация постепенно переезжает на события с value: не на сумму кредита, не на баланс депозита и не на оборот перевода, а на ожидаемую бизнес-ценность действия.

Короткий тезис

SuperApp нужно продвигать в два слоя.

Первый слой - acquisition и onboarding. Он отвечает за регистрацию, первый вход, KYC, согласия, установку платежного PIN, привязку карты, первый понятный продуктовый интерес. Здесь чаще уместны tCPA или Maximize conversions, потому что цель - дать алгоритму достаточный поток качественных пользователей.

Второй слой - product value growth. Он отвечает за деньги и поведение: переводы, платежи, покупки услуг, выдачи кредитов, пополненные депозиты, активированные продукты. Здесь уже нужен value и, когда накоплена история, tROAS или Maximize conversion value.

Ошибка - требовать от первого слоя задач второго. KYC сам по себе не объясняет рекламной системе, кто принесет маржу. Он только говорит: пользователь дошел до порога, с которого SuperApp может продавать продукты.

Что ломается, если оптимизироваться только на регистрацию и KYC

Если кампания оптимизируется на registration_complete, она минимизирует стоимость регистрации. Если оптимизируется на kyc_approved, она ищет людей, которые с высокой вероятностью пройдут проверку. Это полезно, но у такого сигнала есть четыре ограничения.

Во-первых, KYC не различает продуктовый intent. Пользователь, который прошел KYC ради бесплатного перевода, пользователь, которому нужен кредит наличными, и пользователь, который собирается открыть депозит, для рекламной системы выглядят одинаково.

Во-вторых, KYC не несет value. В Google Ads tROAS работает с ценностью конверсии: алгоритм должен понимать, сколько ценности приносит действие, а не только факт события. Если у всех KYC одинаковая ценность, система не увидит разницы между дешевым пользователем без дальнейших действий и дорогим пользователем с высокой LTV.

В-третьих, KYC слишком ранний для части продуктов. Для кредита важнее не заявка, а одобрение, выдача и ожидаемая маржа с учетом риска. Для депозита важнее не открытие формы, а funded deposit: деньги реально внесены. Для WebView-сервиса важнее не клик по витрине, а подтвержденная покупка или комиссия.

В-четвертых, SuperApp быстро превращается в политический спор между продуктами. Кредитная команда хочет отдельную оптимизацию, депозиты хотят отдельную, платежи хотят объем, marketplace хочет покупки. Если разрезать кампании по оргструктуре, каждая кампания может остаться без обучающего сигнала. Если все слить в один event без нормальной value model, алгоритм может начать покупать только тот продукт, где value формально выше, даже если он хуже по прибыли или риску.

Event taxonomy: не список экранов, а грамматика продукта

Для SuperApp события нужно проектировать не от экранов, а от бизнес-грамматики. Экранов будет много, WebView-сервисов еще больше, продуктовые команды будут менять названия, партнеры будут приходить и уходить. Стабильными должны быть смысловые этапы:

1. Кто пользователь и может ли он покупать продукт.
2. Какой продукт он изучает.
3. Какой шаг в продуктовой воронке он сделал.
4. Какую ожидаемую ценность это действие принесло.
5. Можно ли это событие отдавать в рекламную оптимизацию.

Базовый слой можно собрать так:

Слой	События	Зачем нужны
Identity	sign_up, login, kyc_start, kyc_submitted, kyc_verified, first_login_after_kyc	Отделяют новых пользователей от реальных KYC-пользователей и дают warm-up сигнал
Product discovery	view_item, select_item, product_view, product_start	Показывают, что пользователь не просто зарегистрировался, а смотрит конкретный продукт
Funnel	begin_checkout, generate_lead, application_submit, payment_start, service_order_submit	Дают средние события для продуктов с длинным циклом
Value	product_value, purchase, loan_approved_value, deposit_funded_value, transfer_success_value	Питают tROAS и Maximize conversion value
Quality	loan_rejected, deposit_closed_7d, refund, chargeback, kyc_failed	Не всегда идут в Ads, но нужны для BigQuery QA и корректировки value model

GA4 и Firebase уже имеют рекомендованные события вроде sign_up, login, generate_lead, purchase, begin_checkout, view_item и select_item. Их стоит использовать там, где смысл совпадает. Но банковский SuperApp почти всегда потребует custom events: например kyc_verified, product_value, loan_disbursed_value или deposit_funded_value.

Главное правило: event name должен быть стабильным, а детализация продукта должна жить в параметрах.

Такой контракт позволяет не плодить десятки событий для каждого SKU, но сохраняет возможность отчетности по продуктам. Отдельные события нужны не потому, что продуктовая команда хочет собственное имя в Firebase, а потому что экономика, eligibility, регуляторика или bidding goal реально отличаются.

Как считать value: не отправляйте principal как revenue

Самая опасная ошибка в банковском tROAS - отправить в value сумму кредита, баланс депозита или объем перевода. Алгоритм воспримет это как ценность конверсии. Но 1 000 000 KZT кредита - это не 1 000 000 KZT дохода банка. 1 000 000 KZT депозита - это не выручка. 100 000 KZT перевода - это не маржа.

В value нужно отправлять ожидаемую contribution value: комиссию, gross profit, ожидаемую маржу, риск-скорректированную ценность или прогнозный LTV в выбранном окне.

Продукт	Триггер события	Что класть в value	Комментарий для bidding
Регистрация / KYC	kyc_verified	Обычно 0 или небольшой proxy value	Хорошо для tCPA/warm-up, плохо как финальная цель
Перевод	transfer_success_value	Комиссия + activation proxy или retention value	Не используйте сумму перевода как revenue
Кредит	loan_approved_value или loan_disbursed_value	Вероятность выдачи × ожидаемая маржа - риск - бонус	Лучше отдельная модель и часто отдельная кампания
Депозит	deposit_funded_value	Баланс × net margin за 30/90 дней × retention probability - incentive cost	Не отправляйте весь баланс как value
WebView-сервис	purchase или service_purchase_value	Комиссия, take rate или gross margin	Если банк получает комиссию, value = комиссия, не GMV
Карта / подписка	card_activated_value, subscription_started	Прогнозная маржа или LTV	Важно вычитать cashback и welcome bonus

Минимальная формула для value model:

Для кредита:

Для депозита:

Для WebView-сервиса:

Эти формулы не обязаны быть идеальными в первый день. Они обязаны быть честнее, чем principal-as-revenue. Даже грубый margin proxy обычно лучше для tROAS, чем красивая, но ложная сумма транзакции.

Как отправлять value в Firebase

В Firebase/GA4 у события может быть параметр value, а для денежных событий вместе с ним нужно передавать currency. В Android SDK это FirebaseAnalytics.Param.VALUE и FirebaseAnalytics.Param.CURRENCY. Для ecommerce-событий вроде purchase GA4 также ожидает transaction-level value, currency и массив items, если покупка действительно похожа на покупку товара или услуги.

Для SuperApp я бы разделил события на два типа.

Первый тип - canonical value event. Это один стабильный custom event, например product_value, который подходит для большинства продуктов:

Второй тип - recommended ecommerce event, когда пользователь реально покупает услугу: мобильная связь, билет, страховка, подписка, партнерский сервис в WebView. Здесь можно использовать purchase, потому что смысл совпадает с GA4 ecommerce.

В банковском приложении value лучше считать не только на клиенте. Клиент может отправить быстрый продуктовый сигнал, но финальное value-событие должно быть подтверждено backend ledger: KYC действительно approved, кредит действительно выдан или одобрен по нужному статусу, депозит действительно funded, WebView-покупка действительно оплачена, refund не пришел.

Практическая схема:

1. App SDK логирует ранние события: sign_up, kyc_start, product_view, begin_checkout.
2. Backend создает authoritative event после подтверждения финансового статуса.
3. Value service рассчитывает expected_value по продуктовой модели.
4. Firebase/GA4 получает событие с value, currency и стабильными product params.
5. Google Ads импортирует нужные Firebase/GA4 events как conversion actions.
6. BigQuery проверяет, что value не завышен, не дублируется и не конфликтует с фактической экономикой.

Отдельно проверьте custom dimensions и metrics. Параметры вроде product_type, funnel_stage, value_model нужны для отчетности, но их нужно держать в контролируемом словаре. Если в product_id улетит свободный текст от партнеров или динамические названия WebView-услуг, отчетность быстро превратится в высокую cardinality и станет плохо управляемой.

Один purchase для всех продуктов или отдельные события?

Идея "давайте сделаем один purchase event, а продукт положим в custom variables" звучит правильно, потому что Smart Bidding любит плотный сигнал. Но для SuperApp это не всегда безопасно.

Один unified event хорош, когда:

1. У продуктов похожая аудитория.
2. Value нормализован и сравним между продуктами.
3. Бюджета и конверсий недостаточно для отдельных кампаний.
4. Creative можно разделить на ad groups, но campaign goal остается общим.
5. Вы готовы принять portfolio optimization: алгоритм сам распределяет спрос между продуктами по value.

Отдельные product-specific events лучше, когда:

1. У продукта сильно другая экономика: например кредиты против переводов.
2. У продукта другая eligibility: кредит доступен не всем KYC-пользователям.
3. Есть регуляторные ограничения или отдельный approval flow.
4. Value model не сопоставима с остальными продуктами.
5. Объема достаточно, чтобы кампания училась без голодания.

Мой default для банковского SuperApp: начинать с product_value как единого value event, но сразу закладывать параметры product_type, product_id, funnel_stage, value_model, surface. Затем отделять события и кампании только там, где это доказано экономикой и объемом.

Для Halyk-like SuperApp это обычно приводит к гибридной структуре:

1. Loans - чаще отдельная event/campaign логика, потому что риск, approval, выдача и маржа не похожи на платежи.
2. Deposits / investments - отдельная кампания только при достаточном объеме funded-событий; иначе ad group внутри unified value campaign.
3. Transfers / payments - можно держать в daily banking value campaign, потому что это частое поведение и хороший engagement signal.
4. WebView marketplace services - использовать purchase или service_purchase_value; если сервисов много, разделять ad groups по категориям, а не делать кампанию на каждую услугу.

Кампания: как перейти от KYC к tROAS

Переход к tROAS не должен быть резким. Google Ads в официальных рекомендациях для App campaigns говорит сначала проверить conversion tracking, убедиться, что Firebase/GA4 события корректно импортируются, и учитывать cold start: для tROAS нужна историческая value data. Если кампании раньше работали на tCPA, разумно собрать 3-4 недели conversion value history, а для новых app campaigns начинать с Maximize conversions или tCPA до стабильного объема.

Рабочая структура может выглядеть так.

Campaign 1: New users / KYC approved

Цель: не прибыль, а качественная база.

Событие: kyc_verified или first_login_after_kyc.

Bid strategy: tCPA или Maximize conversions.

Кому показывать: новые пользователи, lookalike/automated targeting, broad acquisition, исключение существующих KYC users там, где это возможно.

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

Campaign 2: Daily Banking Value

Цель: первые продуктовые действия после KYC.

Событие: product_value с product_type = transfer, payment, service, иногда deposit.

Bid strategy: Maximize conversion value, затем tROAS после накопления стабильной value history.

Ad groups: transfers, payments, services, deposits-lite. В каждой группе отдельные assets и deep links: перевод на карту, оплата мобильной связи, коммуналка, депозит за 2 минуты, билеты, страховка.

Зачем нужна: не дробить early product growth на слишком маленькие кампании. Daily banking дает частотный сигнал и помогает алгоритму понять, какие KYC-пользователи начинают пользоваться SuperApp как финансовым центром.

Campaign 3: Loans Value

Цель: заявки, одобрения, выдачи, но с риск-скорректированным value.

Событие: лучше loan_approved_value или loan_disbursed_value, не просто loan_application_submit. Если цикл длинный, можно использовать две цели: средняя generate_lead для объема и финальная value-конверсия для оценки качества.

Bid strategy: tROAS только после проверки value model. До этого - tCPA на qualified application или Maximize conversion value с осторожным бюджетом.

Зачем отдельная: кредитная экономика сильно отличается от платежей. Алгоритм не должен сравнивать 300 KZT комиссии за перевод с рискованной кредитной маржой, если value model еще сырая.

Campaign 4: Deposits / Savings Value

Цель: funded deposit, не просто открытый экран.

Событие: deposit_funded_value.

Value: ожидаемая net interest margin за выбранное окно, умноженная на retention probability, минус бонусы.

Структура: отдельная кампания, если есть объем funded-событий. Если объема мало, начинать как ad group внутри Daily Banking Value и анализировать post-click поведение в BigQuery.

Campaign 5: App engagement for existing KYC users

Цель: вернуть уже установивших приложение пользователей в конкретный продуктовый экран.

События: product-specific value events или purchase.

Инфраструктура: deep links, аудитории из Firebase/GA4, исключения пользователей, которые уже купили продукт, и отдельная частота коммуникации, чтобы SuperApp не превращался в push/ads spam.

Здесь важно не смешивать acquisition и re-engagement в один управленческий отчет. Новый пользователь, который только прошел KYC, и существующий KYC-пользователь, которому нужно показать кредитный оффер, требуют разных сообщений, deep links и ожиданий по CPA/ROAS.

Когда делить кампании, а когда оставлять ad groups

Разделение кампаний - это не отражение оргструктуры банка. Это решение о том, где алгоритму нужен отдельный learning pool.

Оставляйте один value campaign с product ad groups, если:

1. На уровне продукта меньше стабильных value-конверсий, чем нужно для обучения.
2. Пользователи и creative сильно пересекаются.
3. Value уже нормализован и не дает одному продукту искусственное преимущество.
4. Продуктовые команды могут смотреть разбивку через GA4/BigQuery, а не требуют отдельный campaign budget любой ценой.

Делите на отдельные кампании, если:

1. Есть достаточно конверсий и бюджета на каждую кампанию.
2. У продукта отдельная экономика и целевой ROAS.
3. Нужны разные geo, language, age eligibility, legal disclaimers или approval rules.
4. Нужны разные conversion windows: кредит может созревать дольше, чем покупка мобильной связи.
5. Вы готовы управлять learning phase и не менять tROAS каждые два дня.

На практике хороший компромисс такой:

WebView-сервисы: отдельная зона риска

В SuperApp много сервисов живет в WebView или партнерских flow. Это удобно для бизнеса, но рискованно для measurement.

Проблемы обычно такие:

1. WebView отправляет web events, native app отправляет Firebase events, backend подтверждает оплату отдельно.
2. Один и тот же order может улететь как purchase из WebView и как service_purchase_value из native/backend.
3. В value попадает GMV партнера, хотя банк зарабатывает только комиссию.
4. transaction_id нестабилен: у партнера один ID, у банка другой, у платежа третий.
5. Категории сервисов меняются быстрее, чем маркетинг успевает поддерживать campaign structure.

Решение: WebView должен передавать в native/backend не "маркетинговое событие", а order context. Финальное событие должно собираться после подтверждения платежа.

Если сервисы похожи на ecommerce, используйте purchase и items. Если это банковский продукт или заявка, используйте generate_lead, product_value или product-specific custom event. Не называйте все purchase только ради красивого отчета: событие должно описывать реальное действие.

QA: что проверить перед импортом в Google Ads

Перед тем как делать событие Primary conversion action и включать tROAS, нужно пройти технический QA.

1. value всегда numeric, не строка.
2. currency всегда передается вместе с денежным value.
3. Валюта стабильна: например KZT, а не микс KZT/USD без понятной конвертации.
4. value не равен principal, балансу или обороту, если это не реальная выручка.
5. event_id или transaction_id позволяют находить дубли.
6. WebView и backend не отправляют одно финальное действие дважды.
7. product_type берется из контролируемого словаря.
8. В события не попадают PII, ИИН, номер телефона, номер карты, номер договора или чувствительные свободные поля.
9. Событие видно в DebugView/Realtime, затем в BigQuery export.
10. Google Ads импортирует именно тот event, который должен участвовать в bidding.
11. Secondary conversions остаются для диагностики, Primary - только для целей оптимизации.
12. Отчет conv. value / cost проверен до старта tROAS.

Особенно осторожно с банковскими данными. Рекламной системе не нужен номер договора, ИИН, номер счета или raw application payload. Для оптимизации достаточно value, product category, funnel stage и разрешенных технических идентификаторов. Все остальное должно оставаться в банковском контуре и BI.

Operating cadence: как внедрять без хаоса

Неделя 1: taxonomy и словари.

Согласуйте список product_type, product_id, funnel_stage, value_model, surface. Уберите свободный текст. Определите, какие события являются analytics-only, а какие могут стать Ads conversions.

Неделя 2: Firebase events и backend ledger.

Добавьте ранние client-side события и финальные backend-confirmed события. Проверьте DebugView, BigQuery export, дубли и currency. Не включайте tROAS до проверки value.

Неделя 3: импорт в Google Ads.

Свяжите Firebase/GA4 с Google Ads, импортируйте события, настройте Primary/Secondary conversion actions. KYC оставьте как acquisition goal. product_value или product-specific value events готовьте для value bidding.

Неделя 4-6: value calibration.

Сравните отправленный value с фактической продуктовой экономикой. Проверьте, не покупает ли алгоритм только один продукт. Проверьте lag: кредиты и депозиты созревают дольше, чем платежи и сервисы.

После накопления истории: tROAS.

Стартуйте с осторожным target ROAS на базе исторического conv. value / cost, не меняйте target каждый день и не дробите кампании раньше, чем у них есть объем. Большая часть провалов tROAS в SuperApp происходит не из-за алгоритма, а из-за плохого value, дублированных событий или слишком раннего разделения кампаний.

Рекомендация в одну строку

Для SuperApp уровня Halyk я бы не выбирал между "одна кампания на все" и "отдельная кампания на каждый продукт". Я бы сделал гибрид: KYC как warm-up tCPA, единый product_value для daily banking и сервисов, отдельную loans value логику из-за риска и маржи, deposits выделять только при достаточном funded volume, а WebView-покупки отправлять как purchase с commission-based value и строгим dedup.

Это дает рекламной системе достаточно плотный сигнал для обучения и одновременно не превращает банк в черный ящик, где регистрация выглядит дешевой, а продуктовая экономика остается вне оптимизации.

Sources

• Firebase: Log events
• Firebase Android reference: FirebaseAnalytics.Param.VALUE and CURRENCY
• Firebase Android reference: recommended events including purchase, generate_lead, sign_up
• GA4 recommended events
• GA4 ecommerce measurement: purchase, value, currency, items
• Google Ads: Using Firebase and Google Ads together
• Google Ads: Set up mobile app conversion tracking
• Google Ads: App campaigns best practices
• Google Ads: Set a recommended initial Target ROAS for App campaigns