SDK и техническая интеграция: как не сломать мобильную аналитику

TL;DR

• SDK - это кодовая библиотека внутри приложения. Через нее MMP или аналитическая система получает install, first open, in-app events и user identifiers.
• Ошибка в SDK-интеграции не всегда видна пользователю. Она может тихо ломать атрибуцию, revenue, retention и рекламную оптимизацию.
• Маркетолог не обязан писать код, но обязан поставить event specification, acceptance criteria и QA-процесс.
• Главные риски: дубли событий, неверная валюта, отсутствие customer_user_id, потерянный revenue, события из staging в production, crash из-за SDK conflict.
• SDK-интеграция считается завершенной только после тестов на реальных устройствах и сверки с backend/CRM.

1. Что такое SDK

SDK, Software Development Kit, - это набор библиотек, методов и настроек, который разработчики добавляют в мобильное приложение. Для маркетинга SDK нужен, чтобы приложение могло отправлять события во внешние системы: MMP, продуктовую аналитику, push-платформу, crash monitoring, A/B testing, payments.

В mobile app нет простого аналога “вставить GTM snippet на сайт и готово”. Нужно выпускать новую версию приложения, проходить review, ждать обновления пользователей и поддерживать версии SDK.

Чем больше SDK в приложении, тем выше риск конфликтов, веса, privacy-вопросов и сложного debugging. Поэтому зрелая команда не ставит SDK “на всякий случай”.

2. Что должно быть в event specification

Перед разработкой нужен документ, похожий на dataLayer spec для web.

Минимальная таблица:

Поле	Пример	Зачем
Event name	af_purchase / purchase	Единый язык для MMP, BI, рекламы
Trigger	Успешная оплата, не клик по кнопке	Чтобы событие отражало факт
Parameters	value, currency, order_id, product_id	Для ROAS, LTV, товарной аналитики
User ID	customer_user_id	Связь с CRM/backend
Dedup ID	transaction_id / event_id	Защита от повторной отправки
Platform	iOS, Android	Проверка различий
Environment	dev, staging, prod	Не смешивать тест и реальные данные
Owner	Analytics / product / backend	Кто отвечает за качество

Плохая спецификация звучит так: “отправьте покупку”. Хорошая: “после подтверждения backend payment отправить purchase один раз на transaction_id, с value без скидочных бонусов или с ними по правилу X, currency KZT, user ID, product category и payment method”.

3. Инициализация SDK

SDK должен стартовать в правильный момент. Слишком рано - можно нарушить consent или отправить лишние данные. Слишком поздно - можно потерять attribution data при first open.

Вопросы для QA:

• SDK стартует на первом открытии?
• SDK учитывает ATT/consent?
• dev key / app token правильный для iOS и Android?
• staging app не отправляет события в production workspace?
• SDK не инициализируется дважды?
• user ID выставляется после login/registration?
• события до login связываются с пользователем после login, если это нужно?

4. In-app events: что считать

Не нужно отправлять каждое касание экрана. Mobile event taxonomy должна быть компактной и полезной.

Уровень	Примеры	Для чего
Acquisition	install, first_open	Понять качество источника
Activation	sign_up, kyc_started, first_search, first_lesson_started	Понять, дошел ли пользователь до ценности
Monetization	add_to_cart, purchase, subscription_started, refund	ROAS, LTV, оптимизация кампаний
Retention	session_start, push_open, repeat_purchase	Когорты и возвращаемость
Risk	payment_failed, crash_after_login	Потери денег и UX

Маркетинговые платформы часто просят стандартные event names. Продуктовая аналитика может хотеть более детальную taxonomy. Лучше заранее решить, какие события являются canonical, а какие только продуктовые.

5. Revenue events

Revenue - самое частое место ошибок.

Проверьте:

• отправляется ли сумма после успешной оплаты, а не после клика “оплатить”;
• включает ли сумма скидку, бонусы, доставку, налоги;
• какая валюта отправляется;
• не отправляется ли revenue дважды после retry;
• есть ли transaction_id;
• как обрабатываются refunds;
• как подписки отправляют renewals и cancellations.

Пример:

Если revenue нет или он кривой, MMP покажет CPI и CPA, но не даст нормальный ROAS.

6. Тестирование

SDK QA нельзя делать только “по логам разработчика”.

Минимальный набор устройств:

• iPhone с ATT allowed;
• iPhone с ATT denied;
• Android с advertising ID available;
• Android с limited ads personalization;
• старый Android, если он важен для рынка;
• staging build;
• production build после релиза.

7. Release process

Web-тег можно откатить за минуту. Mobile SDK-интеграцию откатить сложнее: нужно собрать новую версию, пройти review и дождаться обновления пользователей.

Поэтому релизный процесс должен включать:

Этап	Проверка
Development	SDK keys, event names, parameters
QA build	Test devices, sandbox dashboard
Staging	Realistic flows, backend connection
Release candidate	No debug events, correct environment
Store release	Post-release smoke test
24-48h monitoring	Event volume, crashes, attribution anomalies

Не выпускайте крупное приложение в пятницу вечером, если в этот же релиз вошли SDK, платежи и push.

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

Многие локальные компании заказывают приложение у подрядчика и принимают работу по принципу “открывается, кнопки работают”. Для маркетинга этого недостаточно.

Типовые проблемы:

• подрядчик поставил SDK, но не настроил in-app events;
• события называются по-разному на iOS и Android;
• сумма покупки уходит в USD вместо KZT;
• Android старых версий падает из-за SDK conflict;
• production и staging отправляют данные в один app ID;
• customer_user_id не передается, поэтому CRM и MMP не склеиваются.

В договор с подрядчиком стоит добавлять acceptance criteria по аналитике: список событий, параметры, тестовые сценарии, доступы, документация, post-release support.

9. Чеклист приемки SDK

• SDK установлен на iOS и Android актуальной поддерживаемой версией.
• SDK keys/app tokens соответствуют нужным приложениям.
• First open виден в MMP.
• ATT/consent flow проверен.
• customer_user_id передается после регистрации/login.
• Основные in-app events приходят с параметрами.
• Purchase содержит transaction_id, value, currency.
• Дубликаты событий не появляются после retry, app restart, poor network.
• Staging не пишет в production.
• События сверены с backend для тестовых пользователей.
• Crash rate не вырос после релиза.

10. Видео

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

Маркетологу не нужно писать SDK-код, но нужно принимать результат как инженерный контракт. Пока вы не увидели тестовую регистрацию, покупку и revenue в MMP и backend, интеграция не закончена.

Sources / Notes

• AppsFlyer Dev Hub: AppsFlyer SDK integration overview
• AppsFlyer Dev Hub: In-app events
• Adjust Help Center: SDK integration
• Adjust Developer Docs: Track events
• Google Play SDK Index: Make informed SDK decisions