Replace Google Analytics for Firebase: open-source

Q: Where can we audit the source?

GitHub: `github.com/respectlytics`. Each SDK has its own repository with source, tests, CI configuration, and release tags. The server lives in a separate repo with the same conventions.

▸Example Google Analytics for Firebase call (the "before")

kotlin Respectlytics

import com.google.firebase.analytics.ktx.analytics
import com.google.firebase.ktx.Firebase

// GA4 event with user_id and freeform parameters:
Firebase.analytics.logEvent("level_up") {
    param("level", 7L)
    param("character", "Aragorn")
    param("user_id", userId)
}

Closed-source analytics SDKs require you to trust vendor claims about behaviour. Open-source SDKs let your security team verify those claims from source. For regulated industries this is often a procurement-gating requirement. Respectlytics's SDKs are MIT-licensed and fully open; the server is AGPL-3.0.

☑Remove Google Analytics for Firebase cleanly

1
Remove the Firebase Analytics dependency from your build (CocoaPods / SPM / Gradle / npm / pub)
2
Remove the GA4 property's data stream linkage from your Firebase console — the data stops flowing as soon as the SDK is removed, but the property remains until manually deleted
3
Replace Analytics.logEvent call sites with Respectlytics.track("event_name")
4
Re-audit your Info.plist and AndroidManifest.xml for IDFA / AD_ID surfaces that GA for Firebase contributed
5
Confirm play-services-ads-identifier is no longer in the Android runtime classpath

⇋Google Analytics for Firebase vs Respectlytics — open-source sdk + server

	Google Analytics for Firebase	Respectlytics
SDK source publicly available	— see tool note above	Yes (MIT)
Server source publicly available	— typically no	Yes (AGPL-3.0)
Reproducible builds from source	— varies	Yes (CI publishes from same commit)
Fork-and-modify allowed	— varies by license	Yes
Public commit history	— typically no	Yes (GitHub)

❓Frequently asked questions

Where can we audit the source?

GitHub: github.com/respectlytics. Each SDK has its own repository with source, tests, CI configuration, and release tags. The server lives in a separate repo with the same conventions.

Are the published binaries reproducible from source?

Yes — CI builds use deterministic build commands. The artifacts published to CocoaPods / SPM / Maven Central / npm / pub.dev are produced by the same pipeline that runs against each commit. Reproducible builds are a goal we test against; report any discrepancy as an issue.

Can we modify the SDK and ship our fork?

Yes — MIT permits modification and redistribution with attribution. Many enterprises fork to adjust logging, add internal tracing, or vendor the SDK into their build.

Why MIT for SDK and AGPL for server?

Standard split for source-available SaaS (GitLab, Sentry, MinIO, Plausible). MIT on the SDK maximises consumer freedom — your app picks up the dependency without obligation. AGPL on the server prevents competing closed-source SaaS forks while allowing internal self-hosting freely.

⇢Related migration guides

Replace Google Analytics for Firebase with an open-source analytics stack