Skip to main content

Testing

Use this guide to troubleshoot issues with location tracking and event generation.

Device is not showing up in the dashboard#

A device will show up in the Radar dashboard once a successful track API call has been sent to the server. The Radar SDK collects location updates and then sends them to the server via the track API.

Common issues#

  • Location permissions have not been granted.
  • The Radar SDK has not been properly initialized.
  • Radar tracking methods have not been implemented correctly.

Troubleshooting steps#

  1. Verify location permissions have been granted.
  2. Verify that initializing the SDK uses the correct publishable key and happens during application launch. This initialization should happen in the onCreate() method of the Application class on Android and the didFinishLaunchingWithOptions() method of the AppDelegate on iOS.
  3. Call Radar.trackOnce() on application launch and log the status in the callback. Refer to the iOS and Android implementations to understand the status values returned.
  4. Call Radar.setLogLevel() with a value of debug and monitor for errors in the logs. Refer to the debug logging sections of iOS and Android for more detail.

A successful Radar API request log looks like the following:

2022-11-08 11:33:01.784759-0500 RadarImplementation[6947:250060] 📍 Radar API response | method = POST; url = https://api.radar.io/v1/track; statusCode = 200;

Once a successful API call is made, there will be a corresponding user on the Users page in the dashboard.

Verify that Radar is registering users on the Users page:

Users Page

Events are not firing when the app is backgrounded#

As the Radar SDK collects location updates and sends them to the server, it will generate events based on location context (e.g., the device moves into or out of a geofence or starts a trip). Generated events will appear on the Events page in the dashboard if location updates are triggering events as expected. If the device's last location is in a geofence or a place, that information will be displayed on the details page for that user.

Common issues#

  • Background location permissions have not been granted.
  • Radar events are not enabled on the Settings page in the dashboard.
  • Radar tracking methods have not been implemented correctly.
  • The test device has issues collecting location updates (e.g., location sensors are not working in the simulator).
  • Flawed testing based on the tracking options applied (e.g., geofence stop detection is on, but the device is not dwelling long enough to detect a stop).

Troubleshooting steps#

  1. Verify that initializing the SDK uses the correct publishable key and happens during application launch. This initialization should happen in the onCreate() method of the Application class on Android and the didFinishLaunchingWithOptions() method of the AppDelegate on iOS. On iOS, verify that the Location updates background mode has been enabled if using the responsive or continuous presets.
  2. Confirm that events are enabled for the context type you are testing on the Settings page.
  3. Confirm that you are calling Radar.startTracking().
  4. Determine the behavior needed to trigger location updates based on the tracking options in use and verify that they appear in the Radar dashboard. For example, if the device is stopped in responsive mode, move over 200 meters to trigger a location update. Location updates can be verified on the Users page in the dashboard or on the User Activity page.
  5. If location updates are still not appearing, call Radar.setLogLevel() with a value of debug and monitor for errors in the logs. Refer to the debug logging sections of iOS and Android for more detail.

Verify that events are firing on the Events page:

Recent Events

Verify a device's current geofences on the User details page:

User Details

Note: a device needs to exit a geofence before generating a subsequent entry event, so ensure that the device has been detected outside of the geofence prior to testing another entry.

Event listeners are not delivering#

Common issues#

  • Radar event listeners are not implemented correctly.
  • Radar events are not generating from location updates.

Troubleshooting steps#

  1. Verify the RadarDelegate on iOS and RadarReceiver on Android are implemented correctly. For cross-platform frameworks such as React Native and Capacitor, ensure that the listeners are set up outside of the view lifecycle. Verify that you are using the correct native SDK version via the Users page in the dashboard.
  2. Verify that expected events are firing when testing the listeners.
  3. Understand the behavior of each of the listeners. The client location listener (onClientLocationUpdated on Android, didUpdateClientLocation on iOS) is triggered whenever the Radar SDK receives an update from the device. The location updated listener (onLocationUpdated on Android, didUpdateLocation on iOS) delivers location updates processed by Radar servers and will return refreshed user context. The Radar events listener (didReceiveEvents on Android and iOS) will only fire if events are triggered from location updates.
  4. Implement the error listener methods (onError on Android, didFail on iOS) to determine if errors are firing. Review the error messages returned to diagnose the root cause.

Troubleshooting other behavior#

Multiple Radar users have the same user ID or device ID#

Learn more about when Radar creates new user records here.

Rate limit errors are occurring when tracking location#

Radar has device specific rate limits per second, hour and day for the track API endpoint, which sends location updates to Radar. To mitigate rate limits, adjust tracking options to collect locations less frequently. If you hit the per hour or day limits while testing, reinstalling the application with the Radar SDK will reset the rate limits.

Simulator#

The simulator is the easiest way to generate location updates to test and visualize entry and exit events at will. Gone are the days of needing to drive around or download spoofing apps to try out location-enabled features. The simulator acts as a playground to experiment with our API without any code!

How it works#

  1. Click around the map to generate locations and events. The activity feed is populated in real-time to mirror how our APIs would surface locations and events in your app. The data generated flows through to your enabled integrations in the corresponding environment. The locations and events generated abide by your project's settings and will persist across the dashboard. To avoid any production side effects, use the test environment with the default user provided (simulated-user-id).

  2. Simulate a target user. To simulate a given user, click into that specific user on the users page and hit the "Simulate" button. You can also set custom user metadata, app-specific information that downstream systems can act upon, such as whether a user has been activated or membership in a target cohort.

  3. Simulate a trip. There are 3 fields necessary to simulate a trip: externalId, destinationGeofenceTag, and destinationGeofenceExternalId. You can enter them manually or select a geofence on the map and click "Set as trip destination" to autofill these values. Then, click "Start Trip" to officially kick off and activate the trip! As you click around, you'll notice events such as user.approaching_trip_destination and user.arrived_at_trip_destination.

Simulator.gif

User Activity#

The User Activity page is the most straightforward way to debug a user's recent locations and events. Navigate to the Users page and select View within the desired user row. Then, click View Activity. Filter the user's recent activity down to the minute to investigate why events did or did not fire, and understand confidence levels for events in real-world scenarios.

How it works#

  1. See a unified view of locations, events, and geofences. The User Activity map displays a user's recent locations and events alongside geofences to pin down exactly when entries and exits occurred.

  2. Focus on an individual location or event. Hover over a row in the Activity Feed to center the map view around those coordinates and to display the accuracy bubble for that location or event. An Event's confidence level is a function of the accuracy of the location and the geometry of the geofence. The smaller the geofence and the less accurate the location, the lower the confidence.

  3. Filter to a specific time period. Move the bounds of the slider to isolate a range of time for investigation. The slider supports granularity down to the minute.

UserActivity.gif

Location sources#

  • FOREGROUND_LOCATION: location update triggered by Radar.trackOnce
  • BACKGROUND_LOCATION: location updated triggered by Radar.startTracking
  • GEOFENCE_ENTER: location update triggered by a client-side geofence entry, either nearby geofences synced from the server or a "bubble" geofence around the device's current location
  • GEOFENCE_EXIT: location updated triggered by client-side geofence exit, either nearby geofences synced from the server or a "bubble" geofence around the device's current location
  • BEACON_ENTER: location update triggered by a client-side beacon entry
  • BEACON_EXIT: location update triggered by a client-side beacon exit
  • VISIT_ARRIVAL (iOS only): location update triggered by an arrival from the iOS visit monitoring service
  • VISIT_DEPARTURE (iOS only): location update triggered by a departure from the iOS visit monitoring service
  • MANUAL_LOCATION: location update triggered by Radar.trackOnce passing in a location not collected by the Radar SDK
  • MOCK_LOCATION: location update triggered by Radar.mockTracking