Docs

Amplitude React Native Offline Mode Tracking

Amplitude's React Native SDK now queues events offline by default. Learn what to track to spot late, duplicated or shifted data after upgrading.

Analytics

Mobile users lose signal constantly: in lifts, on trains, in patchy rural coverage. Until recently, an analytics SDK that hit its maximum retries while a device was offline would simply drop the event. That meant your funnels quietly under-counted exactly the sessions where connectivity was worst.

Amplitude changed that on 25 June 2026. From @amplitude/analytics-react-native v1.6.0, offline mode is on by default. The SDK detects network changes, persists events locally instead of discarding them after max retries, and flushes the queue as soon as the device reconnects. It survives app restarts, needs no configuration, and is available on all plans and server zones.

That is good news for data completeness, but it changes what your dashboards show. Without a plan, you can misread the results: a sudden bump in events after upgrading is not necessarily growth, and late-arriving events can land in a different day, session or cohort than the one where the user actually acted.

Why This Matters

Events that used to vanish now arrive minutes, hours or days late. If your team reads daily active users, conversion rates or session counts straight from a chart, the historical baseline you compare against was built on the old, lossy behaviour. Upgrading creates a step change that looks like a real product shift but is really a measurement shift.

Data Points to Track

Add these as event properties, or compute them in your warehouse, so you can separate real behaviour from delivery lag:

  • sdk_version: the installed @amplitude/analytics-react-native version, so you can compare pre and post v1.6.0 cohorts
  • client_event_time: when the action happened on the device
  • server_received_time: when Amplitude ingested it, giving you delivery delay per event
  • delivery_delay_seconds: the gap between the two, bucketed (under 1 minute, under 1 hour, over 1 day)
  • was_queued_offline: a boolean you set from your own connectivity listener
  • app_version and platform: to see whether the effect differs on iOS and Android
  • session_id: to check whether queued events still attach to the correct session
  • network_type_at_event: wifi, cellular or none

Setup Steps

  1. Record your current SDK version and pin a date for the upgrade, so you have a clean before-and-after boundary.
  2. Chart your baseline event volume, DAU and key conversion rates for the four weeks before the upgrade.
  3. Upgrade to @amplitude/analytics-react-native v1.6.0 or later. No configuration is needed because offline mode is on by default.
  4. Add a small connectivity listener to your app that sets was_queued_offline on events fired while the device has no network.
  5. Build a chart of delivery_delay_seconds by bucket, split by platform and app version.
  6. Build a comparison of event volume per active user before and after the upgrade, filtered to the new SDK version.
  7. Test manually: switch to airplane mode, perform three tracked actions, force-quit the app, relaunch online, and confirm all three events arrive with correct client_event_time values.

Actionable Insights

Check the delay distribution first. If most queued events arrive within minutes, your daily numbers barely move. If a meaningful share arrive after a day, expect day-boundary shifts and revisit any report that closes at midnight.

Expect a one-off uplift. Events per user will likely rise on upgraded versions. Annotate the release on your charts so nobody celebrates a recovery that is really measurement catching up.

Watch for duplicates. Persisted events resent after a crash or restart are a classic source of double counting. Compare event counts against a server-side source of truth, such as completed orders in your database.

Compare regions and networks. Markets with weaker connectivity should show the biggest gains in completeness. That tells you where your old funnel data was least trustworthy, and where product decisions may have been skewed.

Use timestamps, not arrival order. Analyse by client_event_time wherever possible, and treat recent hours as provisional until late events have landed.

Expert help

Need help tracking this in your app?

Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.

Talk to an expert