In-app события: как превратить приложение в управляемую воронку

TL;DR

• In-app events - это язык, на котором приложение рассказывает бизнесу, что делает пользователь.
• Install и first open почти ничего не говорят о качестве. Нужны activation, monetization, retention и risk events.
• Событие должно иметь trigger, owner, parameters, user ID, environment и QA-критерий.
• Revenue events требуют особой дисциплины: transaction ID, currency, refunds, subscriptions, backend validation.
• Хорошая event taxonomy помогает не только отчетам, но и рекламной оптимизации, push triggers, fraud detection, продуктовым решениям и BI.

1. Что такое in-app events

In-app event - это зафиксированное действие внутри приложения: регистрация, поиск, просмотр товара, добавление в корзину, покупка, начало урока, KYC, открытие push, повторный заказ.

Если в аналитике есть только installs, команда видит вход в воронку, но не видит продукт. Это как считать людей, вошедших в магазин, и не знать, дошли ли они до кассы.

2. Tracking plan

Tracking plan - это контракт между маркетингом, продуктом, аналитикой и разработкой.

Поле	Пример
Event name	purchase
Trigger	Backend payment status changed to paid
Parameters	transaction_id, value, currency, items_count
User ID	customer_user_id
Platform	iOS, Android
Environment	dev, staging, production
Destination	Firebase, AppsFlyer, BI, CRM
Owner	Analytics / Product
QA rule	Event appears once per transaction

Без tracking plan события быстро становятся хаосом: Purchase, purchase, order_complete, payment_success, af_purchase означают одно и то же, но отчеты считают их разными событиями.

3. Какие события нужны

Не нужно трекать каждое касание. Начните с событий, которые меняют бизнес-решения.

Layer	Events	Для чего
Acquisition	install, first_open	Понять входящий поток
Registration	sign_up_started, sign_up_completed, login	Найти friction в auth
Activation	first_search, lesson_started, kyc_completed, address_added	Понять, дошел ли пользователь до пользы
Monetization	add_to_cart, begin_checkout, purchase, subscription_started	ROAS, LTV, campaign optimization
Retention	session_start, repeat_purchase, push_open, lesson_completed	Cohorts and lifecycle
Risk	payment_failed, verification_failed, app_error, refund	Потери денег и UX

Событие должно отвечать на вопрос: "Что мы изменим, если эта цифра падает?"

4. Параметры событий

Событие без параметров часто бесполезно.

Событие	Обязательные параметры
purchase	transaction_id, value, currency, items, payment_method
sign_up_completed	method, customer_user_id
search	query, results_count, category
add_to_cart	item_id, item_name, price, category
push_open	campaign_id, message_id, deep_link
kyc_completed	flow_type, result, duration_bucket

Для AppsFlyer важно помнить: revenue должен идти в правильном revenue parameter. В AppsFlyer документации af_revenue - специальный параметр, который считается revenue в dashboard и raw reports. Если currency не передана, могут применяться default settings. Поэтому revenue QA обязателен.

5. User ID

До регистрации у приложения есть anonymous/device identifiers. После регистрации появляется customer_user_id.

Правильная схема:

Ошибки:

• user ID не передается в MMP;
• iOS и Android используют разные ID;
• после logout events продолжают уходить на старого пользователя;
• один user создает несколько CRM records;
• события до registration не связываются с known user, хотя это нужно для funnel.

6. Revenue и подписки

Revenue events должны совпадать с backend.

Проверьте:

• что purchase отправляется после успешной оплаты, не после клика;
• transaction_id стабилен;
• повторная отправка не создает duplicate revenue;
• refund отправляется отдельно;
• subscription renewal не теряется;
• currency всегда KZT/USD/etc, а не пустое значение;
• скидки, бонусы и доставка считаются по понятному правилу.

Для subscription app отдельно описывайте:

Event	Смысл
trial_started	Пользователь начал trial
subscription_started	Появилась платная подписка
subscription_renewed	Renewal прошел успешно
subscription_cancelled	Пользователь отменил
billing_retry_started	Платеж не прошел, начался retry

7. QA событий

QA должен проходить на реальных устройствах.

Проверка	Что ловит
Fresh install	first_open и attribution
Sign up	user ID и registration event
Purchase	revenue, transaction ID, currency
Poor network retry	duplicates
App restart	repeated events
Staging build	environment isolation
iOS ATT denied	privacy behavior
Android 13+	permission and lifecycle differences

Событие считается готовым только когда оно видно в SDK live view, MMP, product analytics и backend сверке.

8. Локальный контекст СНГ/РК

В Казахстане часто много важных действий происходит вне приложения: звонок, WhatsApp, Kaspi payment, офисная консультация, курьер, CRM. Поэтому in-app events должны связываться с внешними ID.

Примеры:

• app lead -> CRM lead_id;
• app order -> ERP order_id;
• payment -> transaction_id;
• call request -> call_id;
• Kaspi/payment status -> backend event;
• offline pickup -> order completion.

Если приложение показывает purchase, а финансы не видят деньги, событие нельзя использовать для P&L.

9. Частые ошибки

Ошибка	Последствие
Трекают все экраны	Данные шумят, никто ими не пользуется
Не трекают failed states	Нельзя найти потери
Нет naming convention	Отчеты ломаются на разных event names
Нет owner	Никто не исправляет broken events
Нет backend validation	Revenue в аналитике расходится с кассой
Нет versioning	Релиз меняет смысл события без предупреждения

10. Практический чеклист

• Есть tracking plan для 15-30 ключевых events.
• У каждого event есть trigger, owner, parameters и destinations.
• Naming convention единый для iOS, Android, backend и BI.
• Revenue events проходят backend validation.
• customer_user_id передается после login/registration.
• Staging и production разделены.
• Есть QA-сценарии для duplicates, retries, refunds.
• В BI есть report по event health.
• Рекламные postbacks отправляют не только install, но и quality events.

11. Видео

12. Главный совет

Событие нужно не для отчета, а для решения. Если никто не может сказать, какое действие команда примет при изменении метрики, это событие не должно быть в первой версии tracking plan.

Sources / Notes

• AppsFlyer Help: In-app events overview
• AppsFlyer Dev Hub: In-app events for iOS
• Firebase: Measure ecommerce
• Google Analytics Help: Recommended events
• Firebase Android Reference: FirebaseAnalytics.Event
• Amplitude: Create a tracking plan