Skip to main content

FAQs

Testing#

How should I test Radar battery drain?#

To test battery drain attributable to Radar background tracking in your iOS or Android app, you must isolate battery drain attributable Radar's usage of location services.

This means that you must control for confounding variables:

  • In the context of your app, you must control for battery drain attributable to other code and other SDKs running in your app, having the app foregrounded, and notifications.
  • In the context of your device, you must control for battery drain attributable to other apps, the OS, and your device state, including having the screen turned on.

Often, having the screen turned on and the app foregrounded are bigger sources of battery drain than usage of location services.

To isolate battery drain attributable Radar's usage of location services in your app, there are two ways to test:

  1. Install two builds of your app, one with Radar running background tracking and one without. Use your phone for a period of time, ideally a full day, and avoid opening either app (to avoid the confounding variables described above). At the end of the period, compare battery blame for each app on the Battery screen in the device settings.
  2. Install the Radar Waypoint app, a sample app that does nothing but run Radar. Use your phone for a period of time, ideally a full day, and avoid opening the app (to avoid the confounding variables described above). At the end of the period, inspect battery blame for the app on the Battery screen in the device settings.

Note that the Battery screen on iOS and Android shows battery drain attributable to each app not as an absolute percentage, but as a percentage of the absolute battery drain in the battery session.

For example, if the iOS Battery screen shows 2% battery blame attributable to your app and shows that your phone has drained 50% of its battery in the battery session, the absolute percentage attributable to your app is actually 2% * 50% = 1%.

When using the efficient and responsive tracking presets, the SDK will wake up while the user is moving (usually every few minutes), then shut down when the user stops. To save battery, the SDK will not wake up when stopped. For most users, background tracking with these presets uses only 1-2% battery per day (measured in absolute percentage).

See the SDK documentation and Navigating location services tradeoffs between accuracy, frequency, and battery efficiency for more information.

Can I test Radar side-by-side with another location SDK?#

Many developers switch to Radar from other location SDKs. You can test Radar side-by-side with another location SDK, but keep in mind that there may be side effects on iOS.

On iOS, significant location change events, CLRegion events, and CLVisit events may be sent to all CLLocationManager instances in the app. This may cause the Radar SDK to receive client-side location updates triggered by other SDKs even if you have not called Radar.trackOnce() or Radar.startTracking().

On Android, this is not an issue.

Product#

Is Radar still able to track location in the background if the app is killed?#

Yes, if background location permissions have been granted.

On iOS, if the app is killed (e.g., swiped up from the App Switcher), the SDK is able to wake up and start collecting locations again if it receives certain types of location updates from the OS. These services can be activated on iOS by enabling the location updates background mode and using at least one of following tracking options:

  • syncGeofences
  • useStoppedGeofence
  • useMovingGeofence
  • useSignificantLocationChanges
  • useVisits

On Android, Radar will continue to receive location updates if the app is swiped out of the Recent Apps list. Radar will not receive location updates if the phone manufacturer aggressively kills background services or the user presses Force stop.

If a user backgrounds my app, do I need to request background location permissions to access location?#

With just foreground location permissions, you can leverage the background location indicator on iOS or a foreground service on Android to continue to receive location updates in the background. These are activated via the showBlueBar tracking option on iOS or the foregroundService tracking option on Android. iOS devices will display a blue location icon when activated, and Android devices will display a persistent notification. Use of these visual indicators is common for operational use cases such as fleet tracking and delivery.

What are the different event listeners and how should I use them?#

Each listener can support different use cases and exposes different data to take actions. The client location listener (onClientLocationUpdated on Android, didUpdateClientLocation on iOS) is fired whenever the Radar SDK receives a location update from the device. It can be used to collect a stream of location updates before they hit Radar servers. The location updated listener (onLocationUpdated on Android, didUpdateLocation on iOS) delivers location updates processed by Radar servers and will return refreshed user context. This listener can be used to deliver in-app experiences based on user context, including when Radar.trackOnce() is called on application launch. The Radar events listener (didReceiveEvents on Android and iOS) can be used to listen for Radar events and trigger workflows.

What is the latency of Radar APIs?#

Radar APIs have a p50 latency of 50ms and a p90 of 150ms. The /route/matrix API increases in latency as additional origin or destination points are added, or as the distance between points increases.

How often are usage statistics recalculated?#

Usage statistics are recalculated nightly and reflect the total Monthly Tracked Users (MTUs) and API requests made in the month. Usage statistics can be found on the Home page of the Radar dashboard.

Privacy#

What data does the Radar SDK collect?#

The Radar SDK collects location data (latitude, longitude), device IDs, IP addresses, and device info by default. We also collect any other user IDs (e.g., user IDs) or metadata that you choose to send us. Radar does not collect personally identifiable information like name or email by default.

For more information, see our privacy policy, our commitment to privacy, and our location data privacy checklist.

What are privacy best practices for Radar?#

  • Do not send any PII, like names, email addresses, or publicly available IDs, to the Radar SDK or API.
  • Minimize the data you collect with Radar, turning on only the context types relevant to your use case (store visits for shopping apps, airport visits for travel apps, and so on).
  • Clearly explain to end users what data will be collected and how it will be used in your apps, in permissions prompts, and in your privacy policy.

For more information, see our location data privacy checklist.

What are location permission prompt best practices?#

The best location permission prompts are:

  • Transparent: The prompt explains what data will be collected from the end user and how it will be used, with a link to your privacy policy.
  • Valuable: The prompt explains why the user should grant location permissions, like enabling a location-based feature or unlocking an offer.
  • Timely: The prompt is shown when the user is engaged, like in an onboarding, when accessing a location-based feature, or after a transaction. Background permission prompts are shown after and incremental to foreground permission prompts.

Opt-in rates vary from app to app, but apps that follow best practices can expect 70-80% of users to grant location permissions, with 40-50% of users granting background ("always") location permissions on iOS.

For more information, see our location data privacy checklist.

What is Radar's data retention policy?#

By default, users and events are retained for 1 year, trips are retained for 90 days, and location updates are retained for 7 days.

Radar supports custom data retention settings. Admins can adjust these settings in the Radar dashboard under the Privacy section. Data retention settings are customizable per project.

Is Radar CCPA-compliant and GDPR-compliant?#

Yes, Radar is CCPA-compliant and GDPR-compliant. For more information, see our commitment to privacy.

For data deletion requests, you can delete a user manually from the user detail page in the dashboard or delete a user programmatically using the API. Deletions are immediate.

For data access requests, you can export a user and all of their events and locations manually from the user detail page in the dashboard.

If you need assistance, you can also forward requests to your customer success manager.

Security#

How do Radar account roles work?#

  • Read accounts can read user, geofence, and event data.
  • Write accounts can also create, update, and delete user, geofence, and event data.
  • Admin accounts can also invite new accounts and update project settings, including API keys and integrations.
  • Owner accounts can also edit account roles and project access.

Use the appropriate role (owner, admin, write, or read) for each co-worker's account. See Radar security best practices. By default, an organization can have a maximum of 100 accounts. Contact your customer success manager if you need more.

How do data access controls work?#

In addition to the account roles above, owners can also control:

  • Project access: Access to specific projects in an organization
  • Environment access: Access to test or live data across projects in an organization
  • Data access: Access to specific data and pages across projects in an organization
    • User locations: Access to data on the user details page (map and location information) and access to the user locations page
    • Trip locations: Access to data on the trip details page (map and location information) and access to the trip tracking dashboard
    • Geofence tags: Access to geofences with specific tags. An empty list gives access to all geofences. To access a Geofence, both the tag and externalId access controls must be satisfied.
    • Geofence externalIds: Access to geofences with specific externalIds. An empty list gives access to all geofences. To access a Geofence, both the tag and externalId access controls must be satisfied.

Does Radar have a bug bounty or responsible disclosure program?#

Yes. For more information, see the Vulnerability Disclosure Policy.

What are security best practices for Radar?#

Account management#

  • Use a strong password (at least 10 characters, at least 1 lowercase letter, at least 1 uppercase letter, at least 1 number, and at least 1 symbol).
  • Use a password manager like 1Password or LastPass to generate and store passwords, and use a different password for each website.
  • Use app- or SMS-based multi-factor authentication (MFA). Enable MFA on the Account page.
  • Do not share your account with co-workers.
  • Use the appropriate role (owner, admin, write, or read) for each co-worker's account.
  • When a co-worker is terminated, delete their account.
  • Use single sign-on (SSO) if supported by your organization.
  • Use a password protected lock screen on employee workstations set to a short timeout, e.g., 5 minutes.

Authentication#

  • Use Test keys for development and Live keys for production.
  • Use Publishable keys, which are restricted in scope in client-side code. Never use Secret keys, which can read or write any data.

Website Restrictions#

Additionally, you can restrict which websites can use your publishable API keys. You can add or modify available domains on the settings page. Multiple domains are supported with the selectable input field.

Examples of valid rules:

  • A host with a single domain: example.com
  • A host with sub domains: sub.example.com or sub1.sub2.example.com
  • A domain and all its subdomain(s), using a wildcard (*) asterisk: example.com and *.example.com
  • A host with a non-standard port: example.com:8000
  • Using localhost with port: localhost:8080

Mobile Restrictions#

Furthermore, you can also restrict which mobile app can use your publishable key via the RadarSDK. You can add or modify bundle IDs and package names on the settings page. Multiple bundle IDs and package names are supported with the selectable input field. Bundle IDs and package names cannot have wildcards (*) and are case insensitive.

Data management#

  • Encrypt data stored outside of Radar (e.g., data sent to integrations or sent to webhooks and stored in a data warehouse).
  • Do not send any PII, like names, email addresses, or publicly available IDs, to the Radar SDK or API. See also Radar privacy best practices.

Does Radar support audit logs?#

Yes, Radar supports audit logs for enterprise customers. Audit logs include all requests made from the dashboard with the account, project, environment, IP address, and timestamp of each request. The 100 most recent audit logs can be viewed from the dashboard, and the most recent 100,000 audit logs can be exported to CSV. Contact your customer success manager if you need older audit logs.

How do I set up single sign-on (SSO) in Radar?#

Radar supports single sign-on (SSO) via SAML, LDAP, Open ID, and other identity providers.

SSO is an enterprise-only feature. Contact your customer success manager to enable this feature.

SAML#

To set up your SAML identity provider, reach out to your customer success manager who will provide the assertion consumer service URL and application callback URL. They will need the following information in return:

Is Radar SOC 2 type II-certified?#

Yes, Radar is SOC 2 type II-certified. For more information, please ask your account executive for a copy of our attestation report.

Is the Radar SDK secure?#

Yes. The Radar SDK calls the Radar API over HTTPS using TLS version 1.2 or higher, so all data is encrypted in transit. API calls are authenticated using your Publishable keys, which are restricted in scope.

Location permissions#

How do I get statistics for location permissions?#

Statistics for location permissions are available for customers who have installed SDK 3.1 or later.

What do the states in the location permissions graph represent?#

On iOS, the SDK checks authorizationStatus on CLLocationManager to determine authorization status:

  • Granted Background: authorizationStatus is .authorizedAlways, meaning that the user has granted background location permissions.
  • Granted Foreground: authorizationStatus is .authorizedWhenInUse, meaning that the user has granted foreground location permissions.
  • Denied: authorizationStatus is .denied or .restricted, meaning that the user has denied location permissions.
  • Not Determined: authorizationStatus is .notDetermined, meaning that the user has not yet been prompted for location permissions.

On Android, the SDK checks the ACCESS_FINE_LOCATION and ACCESS_BACKGROUND_LOCATION permissions to determine authorization status:

  • Granted Background: The ACCESS_BACKGROUND_LOCATION permission is granted, meaning that the user has granted background location permissions.
  • Granted Foreground: The ACCESS_FINE_LOCATION permission is granted, meaning that the user has granted foreground location permissions.
  • Denied: The ACCESS_FINE_LOCATION permission is denied and shouldShowRequestPermissionRationale() returns false, meaning that the user has denied location permissions and checked "Never ask again."
  • Not Determined: None of the above criteria are true, meaning that the user has not yet been prompted for location permissions.

What is a tracked user?#

A tracked user is a unique user that sends one or more location events to Radar in a given time period.

What is a unique user? When does Radar create a new user record?#

The Radar SDK collects IDs for each user and device, including:

  • installId: a GUID automatically generated on fresh install
  • deviceId: IDFV on iOS, Android ID on Android, or a GUID on web
  • userId: set by calling Radar.setUserId(), also called External ID in the dashboard

Each user record is also assigned a unique _id, also called Radar ID in the dashboard.

For usage tracking and security reasons, Radar maintains a separate user record for each unique combination of these IDs.

Although calling Radar.setUserId() for the first time will assign a userId to an existing user record (e.g., on login or when a device is first identified), changing the userId for an already identified user (e.g., to set a different userId or to clear the userId on logout) will create a new user record.

A unique user record created or updated in a given time period is counted as a tracked user in that time period.

What is an active user?#

An active user is a unique user that has an app session in a given time period.

What qualifies as an app session?#

An app session is a period of user activity in your app. A new app session is started whenever the app is opened, assuming at least 5 minutes have elapsed since the last app session started.

Why are counts of active users different from counts of tracked users?#

Depending on your Radar SDK implementation, a user may have an app session without sending a location event to Radar. Conversely, a user may send a location event to Radar in the background (assuming they have granted background location permissions) without opening the app.