Fire the call when the user submits a search — Enter key, Search button, suggestion tap. Don't pass the query string, the result count, or any normalized form of the query.
▸Install the Kotlin (Android) SDK
// build.gradle.kts (app module)
dependencies {
implementation("com.respectlytics:respectlytics-kotlin:3.0.0")
}Pure Kotlin coroutines implementation. No Java dependencies, no Google Play Services dependencies. ~300KB DEX overhead — compare to roughly 3.8MB for Firebase Analytics (a measurable cold-start improvement on lower-end devices).
▸Initialize Respectlytics in Kotlin (Android)
import com.respectlytics.android.Respectlytics
class MyApplication : Application() {
override fun onCreate() {
super.onCreate()
Respectlytics.configure(this, appKey = "<YOUR_APP_KEY>")
}
}Initialize once in Application.onCreate. No additional permissions in the manifest — INTERNET is sufficient. The SDK does not request AD_ID, does not query AdvertisingIdClient, and does not declare ACCESS_NETWORK_STATE.
▸Track the event in Kotlin (Android)
import com.respectlytics.android.Respectlytics
class SearchViewModel(private val api: SearchApi) : ViewModel() {
fun submit(query: String) = viewModelScope.launch {
Respectlytics.track("search_query")
val results = api.search(query)
if (results.isEmpty()) {
Respectlytics.track("search_zero_results")
}
}
}Voice and typed search are different events — search_query_typed vs search_query_voice if you support both.
✦Privacy & implementation notes
Search queries are some of the most sensitive content in your app — users type personal questions, medical concerns, addresses, names. The European Court of Justice has ruled IP + search-query combinations are personal data in multiple cases. Respectlytics's API rejects free-text payloads at the boundary; the query never gets that far.
Your search backend stores queries for ranking and quality work — that's its job, with proper retention and access controls. Mirroring those queries into analytics gives you a second store with weaker controls and no clear purpose. Respectlytics's role is the product-engagement layer above search, not the search-content layer itself.
Many teams discover the com.google.android.gms.permission.AD_ID permission in their merged manifest only after Google Play flags them — usually because a transitive dependency dragged it in. Respectlytics's Kotlin SDK has no Google Play Services dependency at all, so it cannot contribute to that merge.
The SDK is implemented as pure Kotlin coroutines with no Java sources, no RxJava, and no platform channels. Events are queued in a Channel<Event> buffered to a small ring (RAM-only), drained by a coroutine that flushes every 30 seconds or on backgrounding. There is no SharedPreferences usage.
⇋How this compares to other analytics SDKs
| Search event | Firebase Analytics | Mixpanel | Respectlytics |
|---|---|---|---|
| Query string stored | Common (free-text param) | Common | Forbidden (PII) |
| Result count as parameter | Recommended | Recommended | Out of scope |
| Per-user search history | Yes | Yes | Out of scope |
| Search → result-clicked funnel | Per-user | Per-user | Session-scoped |
| Zero-result rate | Per-user from query property | Per-user | Use distinct event_name |
❓Frequently asked questions
How do we know what users search for if we don't store queries?
Your search backend (Algolia, Elastic, your own) already has the query data with appropriate retention and access controls. That's where query analytics lives. Respectlytics is for the product surface — "is search getting used and is it converting?" — not the content of queries.
What about zero-result queries?
Distinct event name: search_zero_results. Fire it instead of (or in addition to) search_query when the result set is empty. The rate of zero-result over total search is a UX-quality signal you can read directly.
Can we still measure search-driven conversion?
Yes, per-session. A session with search_query followed by product_viewed (or whatever your conversion event is) is a converting session. The funnel auto-discovery surfaces this without manual config.
What about voice search vs typed search?
Distinct event names: search_query_typed, search_query_voice. Their completion rates and result-click patterns differ enough to be worth splitting.