Fire the call inside your deep-link handler — SceneDelegate.scene(_:continue:) on iOS, Intent filter receiver on Android, the equivalent React Native Linking handler, Flutter's uni_links callback. Don't pass the URL or its query parameters.
▸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';
import { Linking } from 'react-native';
import { useEffect } from 'react';
export function useDeepLinkTracking(handle) {
useEffect(() => {
Linking.getInitialURL().then(url => {
if (url) {
Respectlytics.track('deeplink_open');
handle(url);
}
});
const sub = Linking.addEventListener('url', ({ url }) => {
Respectlytics.track('deeplink_open');
handle(url);
});
return () => sub.remove();
}, [handle]);
}Covers both cold-start (getInitialURL) and warm-start (addEventListener) deep links. The URL is passed to your routing handler, not to analytics.
✦Privacy & implementation notes
A deep-link URL often contains the user's tracking ID, the campaign source, the referrer, and sometimes a session token — concatenated into a single free-form string. Respectlytics's API rejects free-form strings as event metadata. Your routing code keeps the URL; analytics gets the event name.
Install attribution and deep-link open are different signals. Install attribution requires server-side callbacks from the App Store / Play Store. Deep-link open is the in-app signal that the user navigated via a link. Don't use the open event as a proxy for install — they fire at different times for different populations.
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
| Deep-link open event | Firebase Analytics | Mixpanel | Respectlytics |
|---|---|---|---|
| Full URL stored | Often (via Dynamic Links) | Often | Rejected by API |
| UTM parameters as event properties | Yes (default for web tracking) | Yes | Rejected by API |
| Referral code as parameter | Recommended | Recommended | Use distinct event_name (top-N) or skip |
| Per-campaign attribution | Per-user | Per-user | Session-scoped, top-N campaigns only |
| Click-through rate (link → app open) | With Dynamic Links | With server-side join | Out of scope (use server-side analytics) |
❓Frequently asked questions
How do we know which campaign drove an install?
Server-side, not in product analytics. App Store Connect (Apple Search Ads) and Play Console (Play Store referrer API) deliver install attribution to your backend via server-to-server callbacks. Respectlytics is for in-app product engagement — different question, different system of record.
What about top-N campaign tracking via event names?
If you have a small set of high-volume campaigns (under 10), distinct event names work: deeplink_open_summer_sale, deeplink_open_press_pickup. The long tail bucketed as deeplink_open_other. For high-cardinality campaign ID tracking, use server-side attribution instead.
Should we distinguish Universal Links / App Links from custom schemes?
If your app supports both (which is common during a migration), use distinct event names: deeplink_open_universal, deeplink_open_custom_scheme. The rate of each tells you how successfully you've migrated traffic to the modern API.
What if the deep link triggers in-app navigation but no other events?
Common with deep links to settings or specific content. Fire deeplink_open anyway — the open itself is the signal. If the user goes on to convert in the same session, the funnel groups them together via session_id.