Replace Firebase Analytics: 5-field schema

Q: How do we segment events without custom properties?

By using distinct event names. Instead of `track('purchase', { product: 'gold_pack' })`, fire `track('purchase_gold_pack')`. The aggregation buckets event names automatically; no manual configuration. Keep your taxonomy short (under ~50 distinct names per matrix axis) to stay navigable.

Q: How does the API actually enforce this?

JSON validation at the API gateway. A `POST /api/v1/events/` with any field outside the 5 allowed keys returns `HTTP 400 Bad Request` with a body listing the rejected field names. Your integration test catches the regression on the first commit that adds an extra field.

▸Example Firebase Analytics call (the "before")

swift Respectlytics

import FirebaseAnalytics

// Default Firebase event with rich per-user metadata:
Analytics.logEvent("purchase", parameters: [
    "value": price,
    "currency": "USD",
    "transaction_id": UUID().uuidString,
    "user_id": userId,
])

Most analytics SDKs accept dozens of custom parameters per event. Respectlytics's API stores exactly five fields per event: event_name, session_id (rotated every two hours), timestamp, platform, and country. Extra fields are rejected with a 400. The discipline is structural — engineers can't accidentally add PII over time because the API refuses it.

☑Remove Firebase Analytics cleanly

1
Remove pod 'Firebase/Analytics' from Podfile (and any Firebase/Core pulled by it that isn't needed elsewhere)
2
Remove implementation 'com.google.firebase:firebase-analytics-ktx' from build.gradle.kts
3
Remove @react-native-firebase/analytics from package.json
4
Remove firebase_analytics: from pubspec.yaml
5
Remove FirebaseApp.configure() and Analytics.logEvent call sites — replace with Respectlytics.configure() and Respectlytics.track("event_name")
6
Delete the GoogleService-Info.plist and google-services.json if no other Firebase product remains in the app
7
Run ./gradlew :app:dependencies and confirm play-services-ads-identifier is no longer in the runtime classpath

⇋Firebase Analytics vs Respectlytics — 5-field event schema

	Firebase Analytics	Respectlytics
Stored fields per event	— see tool note above (typically dozens of params)	Exactly 5
API enforcement of schema	Lenient (extras stored)	Strict (extras rejected with 400)
Per-user state computable	Yes (people profiles, user properties)	No (use account system)
Custom event properties accepted	25–250 depending on tool	0

❓Frequently asked questions

How do we segment events without custom properties?

By using distinct event names. Instead of track('purchase', { product: 'gold_pack' }), fire track('purchase_gold_pack'). The aggregation buckets event names automatically; no manual configuration. Keep your taxonomy short (under ~50 distinct names per matrix axis) to stay navigable.

We need per-event price for revenue reporting — how does that work?

It doesn't — and that's the point. Authoritative revenue lives in your billing system (Stripe, RevenueCat, App Store Connect) with refund-aware totals and currency-conversion handling. Mirroring revenue into product analytics produces two truths that drift over time.

What if we genuinely need a sixth field for legitimate reasons?

Three options: (a) encode the variant into the event name (e.g., paywall_purchase_pro vs paywall_purchase_basic); (b) keep per-user state in your account system and don't mirror it; (c) use a different tool for the specific use case. Most product teams find (a) or (b) sufficient.

How does the API actually enforce this?

JSON validation at the API gateway. A POST /api/v1/events/ with any field outside the 5 allowed keys returns HTTP 400 Bad Request with a body listing the rejected field names. Your integration test catches the regression on the first commit that adds an extra field.

⇢Related migration guides

Replace Firebase Analytics with a strict 5-field event schema