Using triggers
This article is about action triggers avaliable in the proxi.cloud platform and how to use them correctly. There is an explanation how each trigger works and what are the the differences in implementation depending on the mobile operating system. Next section describes what are triggers and how to use them in a campaign. Alternatively click below to jump to a particular trigger:
What are triggers?
Simplest explanation is that triggers are what causes the action (e.g. push message) to occur. The platform allows to define any number of triggers of (currently) four types which in turn can make a certain certain event happen. For example we can set up that the app user sees a message (action) when they enter a particular WiFi network (trigger). Each trigger (geofence, beacon, WiFi, userg segment) works in a different way but using them in a scenario looks the same regardless of type.
Usage in the platform
After making sure that the app is configured in the panel and SDK is in place we can go to “Triggers” section and add any number of triggers.
The following sections explain how each trigger works and once we add the desired triggers we can create “campaigns” that link the trigger with an action. Simply go to “Campaigns” and create a new campaign where you can set the target app and which of the triggers should cause an action. It can be a single trigger or an entire group of triggers. Below example shows how to trigger the example action on any geofence or beacon defined in the project.
Geofence
Geofence is a trigger that bases on the phone’s location services. It is defined by a point on the map and a radius forming a circle around the location. This creates a virtual perimeter that triggers whenever user croses its border. The size of a geofence can be selected freely from tens of kilometers (e.g. city wide geofence) to tens of meters (e.g. single store locations).
Android & IOS
On both Android and IOS, the action is triggered almost immediately after crossing the virtual border of a geofence. For detection purposes the phone is using best avaliable location in the system even if the app registering the geofence is in the background. This location reading is usually it is not based on GPS as it would drain the battery too much unless another service (e.g. car navigation app) is actively using this module. Normally network based location is enough to trigger a geofence
Protip!
The smaller the geofence the lower possibility of detecting it in the background. For example phone running network based rough location in the background will not detect an extremly small 5m geofence. Usually IOS devices are “better” at detecting small geofences.
WiFi
WiFi is a trigger that bases on the existing WiFi infrastructure and takes advantage of the fact that most places of interest have some sort of WiFi network avaliable. The idea is simple: entering the range of a particular network triggers action. To define a WiFi trigger only it’s broadcasted name (i.e. SSID) is neccessary. For better accuracy and future uses network’s MAC address can be entered but currently the trigger works on SSID alone.
Android
The action is triggered when a network of given SSID can be detected by the phone. According to Google developer guidelines, when in background, an app cannnot initiate scan more often than 4 times per hour but it can use scan results present within system (e.g. the user decided to search for WiFi in phone’s settings). When in foreground, scans can occur very often. The phone does not have to be connected to the network. Being in range is sufficient to trigger the action
IOS
IOS is more restrictive in terms of accessing WiFi information by any app. Therefore only connected networks can trigger events. This means that unlike in Android phone has to be connected to the network defined as trigger for the action rather than just being in range. Moreover, action triggers when transition between cellular connection (or disconnected at all) to WiFi connection occurs.
Protip!
Due to system limitations, switching between connected WiFi networks will not trigger a WiFi event on IOS!
Beacon
Beacon is a simple bluetooth device emitting a signal recognisible by modern smartphones (and other bluetooth devices). It has an unique id consisting of three numbers: UUID, Major and Minor. The first number usually identifies the vendor or the owner of the beacon the other two particular group and unique number of the beacon. It can be explained by imagining a large store chain with beacons on every shopping trolley. UUID would be the store chain name, Major would be the identinty number of a particular store and Minor would be the number of a particular trolley. Once this numbers are entered in the panel - the beacon can be used to trigger proximity actions. Considering that transmission power of a beacon can be regulated - it can be used to localise a user with high precision even indoors.
Protip!
The phone needs to have both Bluetooth and Location services enabled for beacon detection to work.
Android
Operating system checks reguraily for bluetooth beacons and action is triggered as soon as the desired beacon is detected. SDK performs scans every 10 minutes by default but the parameters can be changed. Further information about fine tunning beacon scans in Android can be found here.
IOS
IOS handles beacon detection similar to geofencing. The action is triggered as soon as the phone detects entering a beacon range.
User segment
Unlike the above three triggers “user segment” is not related to the physical presence in a particular place. This trigger works in a different way. The action is triggered simply upon establishing if the user belongs to a segment defined in the proximiy panel. User segments can be built from three sources:
- Include all users of the app - this enables targeting all users of a particular app and broadcast a wide message.
- Imported directly from a file containing a list of advertising IDs (GAID or IDFA) that belong to the segment
- Sourced from an existing campaign - all users who triggered a campaign will be put in the segment. In all cases belonging to a segment would trigger an action if there is one defined in the panel.
Protip!
Sending message to all users using segments is not the same as Cloud Messaging! This means that it will definetly reach the intended user group but there is no guarantee that it will be instant. Usually propagation of such message lasts between 2-4 hours. If you want your segment message to fire at a particular time use the “deliver at time” option in campaign settings.
Android
The SDK checks for pending segment trigger message reguralily (at least every 4 hours) but it also checks for messages when:
- Location changes
- App hosting the SDK is opened
- Beacon or WiFi scan occurs This guratantees fast delivery of segmented messaging.
IOS
IOS is more restrictive regarding delivery of segment messages. It can only deliver such action when
- Location changes significantly
- App hosting the SDK is opened In practice it means that user segment message takes a bit longer to be delivered but it will also reach it’s destination without a problem.