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 React Native SDK
npm install @respectlytics/react-native
# or
yarn add @respectlytics/react-nativeJavaScript-only — no native modules, no auto-linking, no New Architecture migration concerns. Bundle size: ~14KB minified+gzipped. Works in any Expo project (managed or bare) without expo prebuild.
▸Initialize Respectlytics in React Native
// App.tsx (or App.js)
import { useEffect } from 'react';
import Respectlytics from '@respectlytics/react-native';
export default function App() {
useEffect(() => {
Respectlytics.configure({ appKey: '<YOUR_APP_KEY>' });
}, []);
return <YourApp />;
}Initialize once in your top-level component. No native config; no Info.plist or AndroidManifest changes. The SDK is Hermes- and JSC-compatible.
▸Track the event in React Native
import Respectlytics from '@respectlytics/react-native';
export async function submitSearch(query) {
Respectlytics.track('search_query');
const results = await api.search(query);
if (results.length === 0) {
Respectlytics.track('search_zero_results');
}
return results;
}Don't fire on every keystroke (autocomplete) — only on submission. Per-keystroke firing inflates the rate dramatically and isn't actionable.
✦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.
The React Native SDK is JavaScript-only — no Objective-C/Swift bridging on iOS, no Java/Kotlin bridging on Android. Side effects: no react-native link, no auto-linking, no New Architecture migration concerns, no platform-channel exception surfaces. Trade-off: no access to platform-only metadata (which we don't want to collect anyway).
Works in Expo managed workflow without expo prebuild. No config plugin is required. EAS Build users: nothing to configure. This is the smoothest integration path on RN — most analytics SDKs require ejecting from managed.
⇋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.