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 Toolkit 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.

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.

See our privacy policy for more information.

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 and traveling detection 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.

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.

See the SDK documentation for more information.

What is Radar's data retention policy?

By default, Radar retains user and event data for 1 year.

Radar supports custom data retention policies for enterprise customers. Contact your customer success manager to enable this feature.

You can also delete users and events in the dashboard or in the API. See our API documentation for more information.

Is Radar GDPR-compliant?

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

Is Radar CCPA-compliant?

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

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.

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.

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.

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.

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, we will need:

Once your SAML identity provider is set up, we will provide:

  • Assertion consumer service URL
  • Application callback URL

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.