The SDK typically registers an "at" visit after a user has lingered at a single location for ~5 minutes. This brief time lag is used to ensure a high degree of confidence that the user isn't simply walking or driving by.
Aside from examining dwell time (as noted above), when assessing location visits, the SDK accesses the accelerometer to perform activity detection around the time of the visit and may use the detected activity to inform the likelihood of being at the particular category of place the user is at.
The SDK uses a machine learning algorithm to determine the probability that you are actually at a particular venue that is trained against other users claiming to be at that venue, or similar venues. The at condition of an Engine Circumstance requires that Engine is confident that the user is actually there.
The near condition of a Circumstance specifies venues within approximately 150m of the current device location.
Geofencing is susceptible to a number of problems:
Streams of lat/lng signals from devices are often noisy and inaccurate. Despite having 6 decimals of precision, it's common for sequentially sampled geopoints at the exact same point to be off by 10s or 100s of meters.
Geofences themselves have to be accurate. Often times, the boundaries of places are either spatially or temporally porous (think Farmer's markets, food courts, etc.). Also personal definitions of boundaries aren't always clear. Have you ever been running late to meet someone and let them know you "were there", even though you were still barreling into the parking lot?
Geofences are generally two dimensional. The world is not.
Engine uses a machine learning model to assess the probability that you are in each place around you. Just a few of the features considered:
Popularity of places
Business operating hours
Lay of the land (relationship to street, building, and plot polygons)
Density of businesses in the surrounding area
Beacons are hardware transmitters that broadcast across very short distances. Devices that come in contact beacons can be tied to very accurate locations (provided that the hardware's location is known, and hasn't been inadvertently changed by someone unknowingly moving it). As a hardware solution, beacons only work where the actual hardware is deployed. Beacons can be expensive to deploy and maintain, and will not enable you to track devices across places like your competitors' stores or any other real estate you don't own. Engine, on the other hand, relies on machine learning models examining all available signals to the device and thus can work cheaply just about everywhere.
Engine adds approximately 1.5 megabytes to the download size of your app, depending on the architecture (see below)
Engine should not exhibit more than ~1% difference in overall power consumption.
Your Engine API key identifies your app to Factual. There are not unique
keys per user or any kind of token dance required. You can get your API key
from the Engine web UI under your profile.
In iOS, Engine requires either the authorizedWhenInUse or authorizedAlways authorizations. Obviously, Engine will only be able to perform background Circumstance detection if authorizedAlways is available.
In Android, Engine requires the _ACCESS_FINELOCATION and INTERNET permissions.
Engine keeps a small cache of Factual Global Places data onboard, in order to
service Circumstance checks without constantly making network connections back to
Factual. When user Circumstances are evaluated against places, it is against
the local cache.
Any configuration you make in the Engine web UI is committed when you click the push changes
button. Periodically, individual instances of your app will
call back to Factual to see if there are any configuration updates. Having pushed your changes, these apps will be notified that there is an update and that they should pull it immediately.
Instances of Engine in the field are configured to call back to Factual when your app is started, provided that it has been at least 24 hours since the last time the app started. This call simply checks to see if any configuration changes need to be pushed. It's possible individual devices may not receive the latest update within 24 hours, but generally, most of your active devices should be updated within that period.
Updated 2 months ago