“If Stripe is for payments and Twilio is for communications, Radar is for location.” #TheNextGeo
Most apps that we use on a regular basis use location in one form or the other – weather, mobility, social media, camera, photos, web browser, bank, news and even the App store itself uses access to location services. While requesting access to location services might be universal, not every app developer is interested in writing their own code to handle geofences, places and everything else that we have come to expect with location services. If Stripe is for payments and Twilio is for communications, which product/API serves the needs of developers when it comes to location?
Q: Location isn’t something new to you or to Coby, your co-founder at Radar. Both of you guys worked for Foursquare earlier in your careers. However, what motivated you to start Radar – a startup that focuses on making location easier for developers?
A: In our previous roles, Coby and I saw firsthand how hard it was to build location context and tracking. For similar problems like analytics, payments, and communications, there are great platform solutions like Amplitude, Stripe, and Twilio, respectively. Why not location?We started Radar to fill this gap in the market and to help engineers, product managers, and growth marketers build the next wave of location-aware product and service experiences.
Q: “If Stripe is for payments and Twilio is for communications, Radar is for location.” – that is a catchy phrase. Radar’s core offering i.e. geofences, places and insights are aimed at making it easier for developers to integrate location-based contextual awareness to their apps. But then again, geofences are available natively in both iOS and Android. How is Radar’s geofencing offering different? Also what exactly are “insights”?
A: Radar is a great alternative to native Android geofencing and iOS geofencing. Radar supports unlimited geofences (iOS limits you to 20 geofences, Android limits you to 100 geofences), polygon geofences (iOS and Android only support circular geofences), and stop detection (Android supports geofence dwell, but iOS does not).
Q: In addition to geofencing, Radar supports other context types, including Places (place, category, and chain detection) and Insights (home, work, and travelling detection).
A: On the client, Radar can be integrated with just a few lines of code, making it easier to use than native iOS and Android geofencing. And unlike native iOS and Android geofencing Radar is a full-stack solution with an API, a dashboard, webhooks, and server-side integrations with top mobile analytics and marketing platforms like Urban Airship, Braze, Mixpanel, mParticle, and Segment.
Q: One of the things that caught my attention was that Radar supports building-level accuracy. Does that mean that you have your own indoor positioning solution or is it more of an extension to the iOS and Android positioning API’s?
A: Under the hood, Radar leverages native iOS and Android location services. However, the SDK abstracts away implementation challenges and cross-platform differences.
Radar is typically accurate down to 30 meters. We do not yet support indoor positioning per se, but Radar is a great software-based alternative to beacons and other hardware-based solutions. Hardware-based solutions are complicated and costly to deploy, and we believe that the accuracy of software-only solutions will match the accuracy of beacons in the next few years.
Q: Radar uses Facebook Places to determine if the user is at a particular place. What made you decide to go with Facebook Places instead of Foursquare or some other database?
A: Facebook Places is the same place database that powers Facebook and Instagram, with over 140M places worldwide. As far as crowdsourced, social place databases go, Facebook is unmatched.
However, Radar is an open, flexible platform, and we don’t require customers to use a specific place database. If customers have their own first-party place data, they can create custom geofences instead. And we may integrate with other place databases in the future.
Q: Could you tell us more about the tech stack at Radar? What technologies do you use? What programming languages do you guys use?
Radar is installed on tens of millions of devices and processing billions of locations per week. We’re biased, but we think we’re solving some of the most interesting engineering challenges out there. If this sounds interesting to you, we’re always hiring great engineers.
Q: Radar’s business model revolves around enterprise customers using your API for building location-based contextual awareness into their apps and NOT on saving user’s data to sell ads. However, in the era of numerous privacy-related controversies and GDPR – privacy is still a major concern. How do you handle the location data that the users share with you?
A: Unlike other companies in the location space, Radar is not an ad tech company, we do not resell data, and we do not play pricing games to incentivize data sharing. Customers do not need to send us any personally identifiable information about end users, only a stable unique ID for each end user. Radar is GDPR-compliant, and we take privacy and security very seriously.
Q: Where do you see Radar in 3 years from now? What products are in the pipeline?
A: We’ve historically styled ourselves as a developer tool. While we’ll continue to build features for developers, we’ll be building more features for product managers and growth marketers over the next few years.
Q: As a startup founder, I am sure that there are many things that you must have learnt along the way. What was the most interesting feedback that you received so far?
A: Talk to your customers! Questions and ideas from customers inspire us to build new features and make our product better every day.
Q: You are based in New York, how’s the startup scene there? Is it easy to hire people and get investments? Are there any accelerator programs/venture capitals that focus on geo companies?
A: New York has an amazing startup scene. It’s large enough to be significant and small enough to be navigable, with a tremendous amount of talent and capital.
We’re lucky to have raised capital from Expa, a startup studio from Garrett Camp (founder of Uber) and Naveen Selvadurai (co-founder of Foursquare), and we’re lucky to have spent a year working out of Work-Bench, an NYC-based enterprise investor and co-working space. Both Expa and Work-Bench understand the value of enterprise SaaS and data, especially geo data.
In April 2018, TechCrunch named Radar a top 12 up-and-coming enterprise startup in NYC. NYC will be our home for the foreseeable future. We wouldn’t want to be anywhere else.
Q: Okay, this is a tricky one – on a scale of 1 to 10 (10 being the highest), how geoawesome do you feel today 😉
Q: Any closing remarks for anyone looking to start their own geo startup?
A: If you are building anything that touches consumers, make sure they benefit from your platform in some way. For example, Radar helps developers build amazing contextual product experiences for end users. Between GDPR and crackdowns from Apple and Google, the days of collecting location data without end-user benefit or consent are quickly coming to an end. And that’s a very good thing.
Q: If you would like to reach you, what would be the best way to do so?
The Next Geo is supported by Geovation:
Learn more about Geovation and how they can help turn your idea into reality at geovation.uk
About The Next Geo
The Next Geo is all about discovering the people and companies that are changing the geospatial industry – unearthing their stories, discovering their products, understanding their business models and celebrating their success! You can read more about the series and the vision behind it here.
We know it takes a village, and so we are thrilled to have your feedback, suggestions, and any leads you think should be featured on The Next Geo! Share with us, and we’ll share it with the world! You can reach us at email@example.com or via social media 🙂
You got a warrant, officer? SC sides with location data privacy
In a major win for privacy advocates, the United States Supreme Court has ruled that police cannot ask cellular service carriers to provide a crime suspect’s phone location records without a court-approved warrant.
The decision last weekend reversed the previous conflicting rulings by two lower courts in the closely-watched Carpenter v. United States. The case goes all the way back to 2011, wherein the police pulled four months’ worth of location data – 12,898 different locations in total – to convict Timothy Carpenter in several armed robberies.
Though not as accurate as GPS, mobile carriers can always tell a user’s approximate location based on the cellphone towers they are catching a signal from. The US police routinely use this information to convict criminals. However, in its latest ruling, the Supreme Court has explicitly stated that asking for access to this data without a warrant violates the Constitution’s Fourth Amendment right which safeguards people against unreasonable searches and seizures.
Chief Justice John Roberts wrote in his ruling, “We decline to grant the state unrestricted access to a wireless carrier’s database of physical location information. In light of the deeply revealing nature of [cell-site location information], its depth, breadth, and comprehensive reach, and the inescapable and automatic nature of its collection, the fact that such information is gathered by a third party does not make it any less deserving of Fourth Amendment protection. The Government’s acquisition of the cell-site records here was a search under that Amendment.”
This means, now instead of using a suspect’s location data to tie them to a case, police will first need to find a ‘probable cause’ or evidence for their culpability – and then seek a warrant for their coordinates if they feel that would make their case stronger.
Carpenter was sentenced to serve more than 100 years in prison based on his convictions.