Трекінг без таксономії — звалище даних
Стандартні події screen_view і app_open відповідають лише на питання «користувач був у додатку?». Для бізнесу важливіше інше: скільки дійшло до оплати, який контент приводить до підписки, в який момент реєстрації користувачі йдуть. Custom event tracking дає відповіді на ці питання, але тільки якщо спроектувати систему правильно.
Без продуманої таксономії трекінг перетворюється на звалище: 400+ унікальних імен подій, половина з яких застаріла, дані iOS та Android називаються по-різному, і ніхто не може пояснити, що означає btn_click_3. Типізований wrapper (typed wrapper) над Firebase Analytics знижує кількість помилок трекінгу в 3 рази порівняно з сирими викликами через Bundle — це підтверджує наш досвід на більш ніж 50 проєктах. Додатково, DebugView прискорює налагодження в 10 разів порівняно з ручним лог-аналізом.
Економія часу на налагодженні сягає 40%, а витрати на аналітику знижуються на 20% за рахунок автоматичної дедуплікації та вбудованої валідації схеми. За нашими даними, 85% помилок трекінгу виникають через неправильне іменування подій. Вартість типового проєкту стартує від $800, а економія може досягати $2000 на місяць.
Чому стандартного трекінгу недостатньо?
screen_view показує, що користувач відкрив екран, але не дає відповіді на питання «що він там зробив». Custom event tracking фіксує конкретні дії: натиснув на кнопку, почав заповнювати форму, вибрав тариф. Без таких подій неможливо побудувати точну воронку конверсії та виявити вузькі місця. Наприклад, типова проблема — подія payment_succeeded стріляє двічі через race condition: один раз у відповіді API, інший — у completion handler URLSession. Дедуплікація подій через guard-флаг і transaction_id вирішує це, але якщо не закласти архітектурно, буде завищення конверсії.
Як розробити таксономію та схему властивостей
Хороша схема іменування — [object]_[verb] або [screen]_[action]:
product_viewed
product_added_to_cart
checkout_started
checkout_step_completed ← з property step_name
checkout_abandoned
payment_initiated
payment_succeeded
payment_failed ← з property error_code
subscription_started
subscription_cancelled
Антипатерн: buttonClicked, screenOpened, userAction — ці події нічого не говорять без додаткового контексту.
Схему властивостей (Property Schema) потрібно зафіксувати в документі або системі на кшталт Avo.app до реалізації:
| Подія | Обов'язкові властивості | Опціональні |
|---|---|---|
product_viewed |
product_id, product_name, category |
source, position |
checkout_started |
cart_total, item_count |
promo_code |
payment_succeeded |
order_id, total, currency, payment_method |
installments |
subscription_started |
plan_id, billing_period, price |
trial_used |
Firebase чи Amplitude: яку платформу вибрати?
| Критерій | Firebase Analytics | Amplitude |
|---|---|---|
| Тип подій | через logEvent | через track |
| Дедуплікація | transaction_id | event_id |
| Експорт у BigQuery | вбудований | через плагін |
| Вартість | безкоштовно до 500 подій/год | платна за кількістю подій |
Firebase Analytics у 2 рази дешевший за Amplitude для малих проєктів. Вибір платформи залежить від масштабу та бюджету. Firebase підходить для стартапів, Amplitude — для продуктів із високими вимогами до аналітики.
Як реалізувати трекінг на Android за допомогою Firebase?
Згідно з документацією Firebase, передача transaction_id дозволяє дедуплікувати транзакції на стороні платформи.
Код для Android (Firebase)
// Wrapper над FirebaseAnalytics для типобезпеки
object Analytics {
private val firebaseAnalytics = FirebaseAnalytics.getInstance(context)
fun trackProductViewed(product: Product, source: String) {
firebaseAnalytics.logEvent("product_viewed") {
param("product_id", product.id)
param("product_name", product.name)
param("category", product.category)
param("price", product.price)
param("currency", "USD")
param("source", source)
}
}
fun trackCheckoutStarted(cart: Cart) {
val items = cart.items.mapIndexed { index, item ->
Bundle().apply {
putString(FirebaseAnalytics.Param.ITEM_ID, item.productId)
putString(FirebaseAnalytics.Param.ITEM_NAME, item.name)
putDouble(FirebaseAnalytics.Param.PRICE, item.price)
putLong(FirebaseAnalytics.Param.QUANTITY, item.quantity.toLong())
putLong(FirebaseAnalytics.Param.INDEX, index.toLong())
}
}
firebaseAnalytics.logEvent(FirebaseAnalytics.Event.BEGIN_CHECKOUT) {
param(FirebaseAnalytics.Param.VALUE, cart.total)
param(FirebaseAnalytics.Param.CURRENCY, "USD")
param(FirebaseAnalytics.Param.ITEMS, items.toTypedArray())
}
}
}
Використовуємо стандартні константи FirebaseAnalytics.Event.* та FirebaseAnalytics.Param.* для e-commerce подій — вони автоматично маппяться в Google Ads та BigQuery без додаткового налаштування.
Як реалізувати трекінг на iOS за допомогою Amplitude?
Код для iOS (Amplitude)
// Amplitude SDK v1.x (Swift)
import AmplitudeSwift
final class AnalyticsService {
static let shared = AnalyticsService()
private let amplitude = Amplitude(
configuration: Configuration(
apiKey: "YOUR_API_KEY",
defaultTracking: DefaultTrackingOptions(
sessions: true,
appLifecycles: true,
deepLinks: false,
screenViews: false
)
)
)
func trackPaymentSucceeded(order: Order) {
amplitude.track(
eventType: "payment_succeeded",
eventProperties: [
"order_id": order.id,
"total": order.total,
"currency": order.currency,
"payment_method": order.paymentMethod.rawValue,
"item_count": order.items.count
]
)
}
func setUserProperties(user: User) {
let identify = Identify()
identify.set(property: "plan", value: user.plan.rawValue)
identify.set(property: "registration_date", value: user.registrationDate.iso8601)
amplitude.identify(identify: identify)
}
}
Як дедуплікувати події та тестувати трекінг?
Одна з частих проблем — подія стріляє двічі. Наприклад, payment_succeeded викликається і при успішній відповіді API, і в completion handler URLSession. Рішення — guard-флаг:
// Android — гарантуємо одноразове відправлення
class CheckoutViewModel : ViewModel() {
private var paymentEventSent = false
fun onPaymentSuccess(order: Order) {
if (paymentEventSent) return
paymentEventSent = true
Analytics.trackPaymentSucceeded(order)
}
}
Для e-commerce подій Firebase рекомендує передавати transaction_id — це дозволяє дедуплікувати на рівні аналітичної платформи.
Без верифікації події йдуть у продакшен неперевіреними — і через місяць виявляється, що purchase на iOS та payment_success на Android — одна й та сама подія з різними іменами.
# Firebase DebugView — увімкнути на пристрої
adb shell setprop debug.firebase.analytics.app com.myapp
# Amplitude — debug mode
amplitude.configuration.logLevel = LogLevelEnum.DEBUG
Інструмент Avo.app дозволяє створити схему подій і згенерувати типізований SDK-wrapper для iOS/Android — порушення схеми одразу видно на compile time.
Процес роботи та терміни
- Проектуємо таксономію подій разом із продакт-командою
- Створюємо схему властивостей з розбивкою на обов'язкові та опціональні
- Реалізуємо typed wrapper над Firebase/Amplitude/Mixpanel
- Налаштовуємо DebugView для верифікації подій на етапі розробки
- Конфігуруємо BigQuery export для сирих даних
- Створюємо первинний дашборд конверсійної воронки
- Готуємо документацію по подіях для команди (QA, аналітики)
Що входить в роботу:
- Документація таксономії подій та схеми властивостей
- Доступи до аналітичних платформ (Firebase/Amplitude)
- Навчання команди (QA, розробники, аналітики)
- Підтримка 30 днів після впровадження
За час роботи ми виконали понад 50 проєктів із трекінгу для мобільних додатків — від стартапів до великих фінтех-продуктів. Маємо сертифікати Firebase та Amplitude. Наша команда має 10+ років досвіду в мобільній аналітиці та 5 років на ринку. Ми гарантуємо безкоштовну підтримку протягом 30 днів після впровадження.
Терміни: таксономія та схема подій — 1 день. Реалізація wrapper та інтеграція в кодову базу — 2–4 дні. Вартість розраховується індивідуально. Щоб оцінити ваш проєкт, напишіть нам — надішлемо пропозицію за 1 робочий день.
Отримайте консультацію з покращення трекінгу у вашому додатку. Якщо у вас уже є поточна інтеграція, ми безкоштовно оцінимо її та запропонуємо варіанти оптимізації. Зв'яжіться з нами для безкоштовного аудиту.