MOVE Services
The MOVE SDK offers various features that recognise when, where and how users are moving through their days. This allows app developers to e.g. establish context-based communication (e.g. location-based marketing), to raise awareness about movement patterns, or to offer assistance when needed.
Timeline
One of our key features is a user timeline about when, where and how users move through their days. The timeline can be more or less detailed, depending on the features active in the MOVE configuration.
All of this is running in the background using OS-specific functions, to ensure that the battery footprint is as low as possible. Of course, the more features you activate, the more battery will be required to run MOVE.
Please note that the following timeline components are prioritised in how they are registered into the timeline: CAR trips are registered in the timeline before PUBLIC TRANSPORT and WALKING. So while a CAR trip may be there merely a few minutes after you finished your trip, you may have to wait a bit for other timeline items. We do this to ensure that (a) the timeline never changes retrospectively, (b) the timeline looks clean and compact (e.g. a 2 hours walk should be a 2 hours walk in the timeline, rather than numerous 5-15 minute walk segments), and (c) we only transfer the minimum amount of data in the minimum frequency needed to provide quality of service.
CAR trips
Even in the background, MOVE will wake up on a location change and check whether the user is moving at a considerable speed. For CAR trips, this is a linear speed of 20 km/h for at least 2 minutes or more. As soon as a trip is detected, MOVE will record GPS points of the trip and only stop when the user stops moving.
Please note that real world data impurities may lead MOVE into thinking it is a trip, while it actually isn’t (e.g. GPS jumps), and vice versa (e.g. initial linear speed is too slow because car takes multiple turns in pedestrian zone). But overall, trip detection works in most situations and bad results may indicate other problems (e.g. wrong setup, bad battery settings kill app on Android phones).
In addition to merely collecting GPS points, MOVE may score DFD, DBE and Speed during the trip.
Speed
GPS positions during a trip are matched to the closest street. At this point, we can compare the actual speed with the legally allowed speed for that street segment according to our source data in Open Street Map (OSM). Please note that the coverage of OSM-data may vary between countries, although we found OSM to be one of the most up-to-date sources for map data.
DFD - Distraction-Free Driving
Phone usage is currently the most frequent and fatal cause of car accidents around the globe. Therefore, MOVE recognises any type of phone usage during a car trip: each event of voice or swipe-and-type is indicated in the trip details. The technology of detecting DFD events is very different between Android and iOS; we took great care, however, that the events are detected with largely similar fidelity.
MOVE also offers a standard DFD score for each CAR trip, which basically scores the minutes used vs overall minutes of the trip into a score value of 0-100. However, based on the phone usage events, you may also implement a different scoring algorithm. Please note that events of hands-free phone usage generate different DFD events; yet, since both cause mental distraction, we recommend that both are scored negatively.
DBE - Driving Behavior Events
MOVE platform profiles driving behavior for acceleration, braking and cornering from sensor data recorded during a trip. We are particularly proud about our algorithms for normalising the direction of driving, which works even without user interaction. The algorithm recovers if the phone is relocated during phone usage. However, it is impossible to detect DBE if the phone is unstable and e.g. slides in the storage console with every turn, or the driver put the phone in the shirt pocket. Also for iOS, DBE and DFD cannot be detected at the same time.
BDD - Bluetooth Device Discovery
If you're aiming to identify specific vehicles, one method to do this is by assigning a specific Bluetooth device that can be used when in proximity, for example a car's hands-free kit.
MOVE supports two types of such devices:
Bluetooth audio devices
Bluetooth beacons that support the iBeacon protocol
A host application can register a collection of Bluetooth devices (multiple devices are supported) with the SDK. The SDK will scan for all registered devices during a trip and will add discovered devices to the trip's metadata.
CYCLING
MOVE detects CYCLING like CAR trips, although CYCLING trips can be slower at about 12 km/h. Later, we distinguish between CAR and CYCLING based on speed and movement. Configuring CYCLING has a couple of impacts on MOVE:
Due to the reduced initial speed from 20 km/h to 12 km/h, MOVE is recording trips more often. This increases the likelihood of a fake trip in the timeline (i.e. a trip which actually was no real trip but due to GPS inaccuracies it seems like a trip).
Since MOVE is awake and recording trips more often, you may see an increase in battery usage.
We usually detect CYCLING trips in a city quite well, but there are various contexts that may make it hard for us: e.g. cycling up a steep hill may be too slow and classified as WALKING; mountain biking may be not detected at all or classified as UNKNOWN; fast e-bikes may be confused with CAR.
Mode of Transport
MOVE needs to deal with messy data, with regards to both, technical noise in the data (e.g. GPS accuracy is low) as well as unexpected user behavior (e.g. a car trip following exactly a tram line). We use machine learning algorithms and huge training data sets to classify trip data in the MOVE backend to the correct mode of transport:
FAKETRIPs are recognised based on speed and GPS validations (e.g. GPS jumps around a location rather than following a route)
if the movement patterns of the majority of the trip time points to walking/running, we re-classify the trip as WALKING
slow maximum speed plus movement patterns for cycling and walking may indicate CYCLING
GPS positions close to a train, tram or metro track indicate a PUBLICTRANSPORT (rather than CAR)
trips that are for the most part too far away from a public road will be classified as UNKNOWN (this includes e.g. skiing, boat trips, drone flights)
If you know from user interaction that we classified a specific trip to the wrong mode of transport, you are invited to report this back to us through the API. This may also change the data provided for the timeline item (e.g. if you re-classify from PUBLICTRANSPORT to CAR within 2 weeks after the trip occurred, you receive the DBE, DFD and Speed scores).
PUBLIC TRANSPORT
While we can detect some PUBLICTRANSPORT trips based on GPS, it is insufficient for a full coverage. There are multiple reasons for this: metro lines by definition have no GPS underground, even trains sometimes have bad GPS reception (perhaps of the overhead contact lines for electric power), and in a city the high frequency of stops at stations may confuse the MOVE trip detection. For this reason, we also developed a second detection mechanism for PUBLICTRANSPORT which is based on the stations and how quickly you move between public transport stations. Overall, our detection of rail-based public transit is more than 85% (according to our manual tests in central Europe). However, we cannot at this point distinguish public buses or taxi from CAR merely based on GPS and other phone sensors. Depending on the user app, you may want to use bluetooth or any other available context signals to ensure the user is actually using her car.
WALKING
Last in line for timeline items, we evaluate all times outside of a trip as to whether or not they were walking/running. You can also walk in a train, and sometimes cycling seems like walking from a sensor movement perspective, so therefore it is important to evaluate WALKING timeline items as last in line.
Sensor-based movement evaluation is performed in quite different ways by operating systems and manufacturers. So therefore, a Samsung with Android 10 could yield quite different results compared to a Pixel with Android 13 and compared to iOS 15. We took great efforts to ensure that those differences are reduced to a minimum (counting timeline minutes). So that apps, which award points for each walking minute, can be fair across platforms/manufacturers/OS versions. Part of this implies that WALKING items should be at least 3 minutes long; shorter walks (such as switching rooms indoors) are ignored by MOVE.
Points of Interest
MOVE offers to register geographical locations that will trigger an immediate event notification (called point of interest, POI). For example, you can register all airports and train stations, tag them accordingly, and whenever a user enters an airport or train station send a dedicated message to the user. Because the message is suited to the user context at that time, you can create significant touch points.
POIs can be triggered on-enter or on-exit, and they can be triggered outside or within a trip. Please note that the OS functions provided by Android and iOS are not fully reliable. So some events may be triggered a bit late or may be inaccurate. But we measured in our tests that those events are about 85% reliable (see also the section on PUBLICTRANSPORT).
Uploading your POIs and definition of the webhook for the event notification is done in the MOVE dashboard.
Assistance
This set of services is particularly targeted at organisations that offer (human) assistance in emergency situations. Users can either call for help manually (i.e. bCall = breakdown call, road-side assistance), or when phone sensors indicate an accident, help is sent automatically to the location of the accident.
If your organisation seeks support for providing emergency response services, please get in touch.
Assistance Call
The manual assistance call can be manually triggered by a user and merely sends the current GPS location plus metadata to the MOVE backend. The MOVE backend then forwards to e.g. a call robot or a 24/7 on-duty human phone service to send help if needed. For this, the MOVE backend needs “receivers” (= web hooks) to be defined in the MOVE dashboard.
Automated Impact Detection
We automatically detect high impacts on the smartphone sensors. An impact of more than 3.5g during a trip will trigger recording of a potential accident, and apply a series of filters (based on GPS and sensors) in a period of 60 seconds. Only if none of the filters has triggered after that evaluation time, the impact will be forwarded to the receiver (as defined in the MOVE backend).
Note that for every recorded impact we calculate the acceleration severity index (ASI). The ASI is an internationally acknowledged method for calculating the risk of bodily injury in car accidents. It is most notably based on the impact strength (measured in g) and the impact angle. This can be the last filter before forwarding the impact to a human-operated call-center to consider sending an ambulance to the location: only impacts with an ASI > x are forwarded to the receiver. We recommend using an ASI > 0.5 for FNOL (first notification of loss, data available in backend for e.g. insurance report) and ASI > 1.0 for human assistance in case of car accident.
Setup of assistance services
The following steps are required to setup your assistance services:
Configure "assistance call" and/or "AID" in the MOVE configuration
Activate them in the setup of the mobile frontend as well
Validate that you receive assistance requests in the MOVE dashboard
Specify the target for real-time events in MOVE Dashboard > Configuration > Receiver/Assistance. Make sure to specify the ASI threshold as to your required level of sensitivity - we recommend an ASI of 1.0, but if you like to receive more events set the ASI lower, e.g. to 0.5
Battery vs. background services
In order to provide quality service, we need to make sure that MOVE is initialized in the background all the time, all permissions are granted, and - on Android - the battery settings allow operations in the background. In other words, to provide quality service we need the cooperation of the user. We aim to achieve this with transparency and data minimalism on the one hand, and foremost with our focus on battery optimization.
The more MOVE is active (in the background or foreground), the higher the battery consumption. Therefore, MOVE has various OS-specific mechanisms that allow the app to sleep without any battery consumption (e.g. when the smartphone is idle at home or at any fixed location), yet wake up whenever MOVE needs to work (e.g. when the user moves to a different location or in a POI).
It is a tough balance to make sure that the app is awake as much as needed to provide quality of service, yet asleep as much as possible to ensure low battery impact. You can help to improve this balance to your advantage by only activating the MOVE features in the MOVE configuration that you really need.
Last updated