Location-based games and VPC
Location-based games are typically not playable unless they can access the user’s geolocation. Under COPPA and GDPR-K, you cannot access a child user’s geolocation data without verified parental consent (VPC).
“COPPA covers the collection of geolocation information ‘sufficient’ to identify street name and name of city or town. One example where COPPA would be triggered is where an app takes the user’s longitude and latitude coordinates and translates them to a precise location on a map.”FTC
Even if your game does not store the geolocation data it collects – for example, it may process the data in real-time only – you are still required to have verifiable parental consent (VPC) if you want to collect geolocation data from kids:
“COPPA covers the collection of geolocation information, not just its use or disclosure.”FTC
Previously, this requirement for VPC has led some AR game developers to exclude kids completely. Others avoid the requirement by focusing on games that don’t need geolocation. Kids Web Services (KWS) removes these restrictions.
KWS offers a VPC flow that allows the inclusion of kids in AR experiences by facilitating a COPPA-compliant process to obtain parental consent. This guide explains how you can utilise KWS to best effect when building AR location-based games.
1. Set up a KWS App
For instructions, see Create your KWS app.
If you don’t already have access to a KWS environment; ask for a free sandbox.
2. Set up permissions and permissions copy
- When you have set up your app, liaise with your Implementation Manager to set up any permissions that your app requires, besides the geolocation permission.
- Define the copy that describes the permissions to parents in emails and in the Parent Portal. How permissions are described to the parent is key to ensuring compliance and maximising conversion. When the set-up process is complete, your Implementation Manager will add the permissions to your KWS App.
For instructions, see Set up app permissions.
3. Set up the user access flow
This is the recommended flow that you can build using KWS:
To set up this flow:
- Age gate
At sign-up, identify which of your users are kids. To do this, pass the user’s date of birth and their country to the child-age endpoint. This endpoint returns a flag that signals if the user is defined as a child based on their age and country (i.e. ‘isMinor’ = true).
- Kid registration
Now that you know which users are kids, direct them to a sign-up flow that is powered by KWS. Use the pre-built single sign-on (SSO) view that you can trigger from within your app using the Authorization code flow.
To define how your SSO view should function, see Set up the multi-app SSO. Make sure the geolocation permission is requested as part of the sign-up flow.
The SSO view is pre-built to collect the following information from the kid during sign up:
Kid’s username and password – both are used for authentication.
Kid’s display name – this is an anonymous display name that is visible to other users within your app. Random display names can be auto-generated by the KWS SSO. You can turn this feature off if you don’t require it within your app. For more information, see Set up display names.
Parent’s email address – KWS uses this to contact the parent whenever consent is required.
- Request parent permission
When the registration process is complete, KWS automatically sends an email to the parent, letting them know that their child signed up to your app and that they require further permissions before using any location-based features. The parent may then choose to grant permission and go through the Parent identity verification process to verify their identity in accordance with data privacy laws.
- Check if permission is granted
Use the Get User Profile API endpoint to periodically check what permissions the parent has granted to the user. As soon as the geolocation permission is granted, allow the child to access location-based features.
Avoid completely blocking kids from accessing features that do not require the geolocation permission while they are waiting for their parent to grant them access. You can achieve this by building into your experience a limited gameplay feature or an interactive tutorial. We call this ‘progressive permissioning’ and it’s a great way to maximise engagement and conversion even when you have to obtain VPC before enabling full gameplay.
This also avoids frustrating kids – it’s not uncommon for them to ‘cheat the system’ by restarting the sign-up process and providing a false age.
In addition, giving the kid a glimpse of the experience increases the likelihood of them ‘nagging’ their parents for access to the features that lie behind permissions. This in itself drastically increases the conversion rate; i.e. the likelihood of parents granting that permission.
You’ve done it! Your app should now be accessible to the ever growing community of kid-gamers.