This guide describes a scenario where both the WiFi and Location SDKs are integrated into a mobile app to maximize the impact of Cloud4Wi location services combined with seamless WiFi connectivity
Mobile app onboarding
The diagram below shows a sample onboarding flow for initializing both the Location SDK (for off-site location tracking) and the WiFi SDK (for WiFi connectivity and indoor location tracking) during the first-time app onboarding.
(click to enlarge)
Step 1 - Identify the user
App users must be initialized with an identity in order to start collecting personal data about them over time. The strategy the app uses to identify a user is completely up to the app developer, for example with a registration form, with SSO with social accounts, and might require demographic and contact data or be completely anonymous as well.
The main requirement to start collecting data about a user is to make sure that the user is associated with a unique and permanent identifier across its lifecycle, so all location data can be tracked and associated with the same user over time.
Depending on the region where you operate, it is very likely that you have to comply with data protection and privacy regulations that impose gathering customer acknowledgment and/or consent to collect and use their personal data for specific purposes.
In order to track data about the user in the Cloud4Wi platform, you also have to initialize a Customer object. You can postpone this action until step 3, as described below. In this way, in case the user does not grant legal consent to use the location data AND will not enroll in the WiFi service, you can skip completely the initialization of the Customer in Cloud4Wi.
Step 2 - Collect location services permissions
Step 2a - Inform the user
Before prompting the user to provide permission to access location data, it is a best practice to inform the user about the purpose and benefit obtained by granting such permission. Apple might even require to have such visual informative content before asking for location permission in order to approve the publication of the app.
If the user has granted legal consent related to the use of location data, you can initialize the Location SDK to track the user's location (iOS, Android). If the user has not granted legal consent related to the use of location data, you can skip this step completely.
Step 2b - The OS prompts the location permission dialog
The UX for this step varies for each OS and OS version (in the case of Android).
In most recent mobile OSs, at first, the OS prompts only options to track the user location when the app is open. In a second step, you can prompt the request to provide consent to track the location all the time (background).
Step 3 - Invite the user to enroll in the WiFi service
As a next step, you should inform the user about the benefit of enrolling in the secure and automatic WiFi service.
If the user opts for enrolling in the WiFi service, you can now initialize the Customer object in Cloud4Wi and then trigger the installation of the WiFi profile.
Even if the user does not enroll in the WiFi service, but previously granted the legal consent required for you to initialize the Location SDK and track the user location, at this step you still need to initialize a Customer object in Cloud4wi in order to properly collect the location history and interaction moments.
We recommend using always the Create Customer method (iOS, Android) and to set an external user identifier ("extId") as thededuplicateAttribute in the initialization of the customer object in order to ensure that even if a user uninstalls and re-installs the app or uses the app on multiple devices, all the location data collected by Cloud4Wi refers to the same user.
In the alternative, you can use the simplified method Setup Customer (iOS, Android) to create an "empty" customer object that has at least a customer ID assigned.