User sign-up flows

There are various ways in which Kids Web Service can be integrated into an app's sign-up and authentication user flows. We've scoped out some common use cases and flows that we recommend for each. These cover most scenarios, but if you would like to implement something bespoke, we are happy to guide you as you define the flow that works for you.

Key

Terms used:

  • Legal age threshold - the age at which a user is defined as a 'kid' based on the relevant laws of their country (e.g. as defined by GDPR and COPPA)
  • Kid - a user of your app who is within the legal age threshold (as defined above)
  • Progressive permissions - find out more about these here.

Example Flow 1.0 - Standard flow (Age Gate)

Developer Requirements:

This flow illustrates a use case where the developer requires the following:

  1. Users below the legal age thresholds (kids) to supply their parent’s email address
    • These kids will gain access to the app after completing the sign up process but features that require parental consent will be disabled
    • Kids can then (progressively) request access to these features from their parents
  2. Users who are above the legal age thresholds do not provide their parent’s email address
    • These users will access to the app straight away
    • They will have access to all features that would normally be disabled for kids who are pending parental permissions

Summary:

If you’re developing an application that you know will attract a significant number of users who are both above and below the legal age thresholds we recommend this flow. This way you will avoid treating all users as kids while at the same time remaining legally compliant (hence increasing your conversion funnel).

See an example of this flow here

Example Flow 1.1 - Access gate for kids

Developer Requirements:

This flow illustrates a use case where the developer requires the following:

  1. Restrict kids who are below the legal age threshold from accessing the app until parental consent is given.
    • These kids will need to supply their parent email address during registration.
  2. Users who are above the legal age thresholds do not provide their parent’s email address
    • These users will access to the app straight away without needing to request permissions to do so.
    • They will have access to all features that would normally be disabled for kids who are pending permissions

Summary:

If you’re developing an application that absolutely requires parental consent before it can be used, we recommend this flow. Some examples of situations where this may be necessary is when your app requires PII upfront (e.g. without this PII the app would not be usable):

  • GPS/location - e.g. for an app that needs to always be location aware to fulfil it's basic function
  • Phone camera - e.g. for an app where taking photos are integral to the user experience
  • E.t.c.

Note: The best user experience is one that always allows kids to register and begin using your app without hitting an access wall (for this refer to 'Example Flow 1.0' above). Only utilise an access wall if you absolutely need to in order to avoid impeding your conversion funnel unnecessarily.

Example Flow 2.0 - Treat all users as kids

Developer Requirements:

This flow illustrates a use case where the developer requires the following:

  1. All users are treated as kids
  2. All users have to therefore provide their parent’s email address
  3. All users will gain access to the app after completing the sign up process but features that require parental consent will be disabled.
    • All users can then request access to these features from their parents once logged into the app.

Summary:

If you’re developing an app that is specifically targeted at kids and want to treat all users as kids, we recommend this flow.

Note:

  • If you expect users that are not kids to also use your app, consider implementing 'Example Flow 1.0' instead. Treating such users as kids is likely to negatively impact your conversion funnel due to the added parental consent steps (which will be irrelevant for them).
  • At registration, you may choose not to collect a date of birth since all users are treated the same regardless of age.

Example Flow 2.1 - Access gate for all users

Developer Requirements:

This flow illustrates a use case where the developer requires the following:

  1. All users are treated as kids.
  2. All users have to therefore provide their parent’s email address
  3. All users will need parental consent before they can access the app

Summary:

If you’re developing an app that is specifically targeted at kids and want to treat all users as kids while requiring parental consent before giving them access to your app - we recommend this flow.

Note:

  • If you expect users that are not kids to also use your app, consider implementing 'Example Flow 1.1' instead. Treating such users as kids is likely to negatively impact your conversion funnel due to the added parental consent steps (which will be irrelevant for them).
  • At registration, you may choose not to collect a date of birth since all users are treated the same regardless of age.

Example Flow 3.0 - Only store kids accounts in KWS

Developer Requirements:

This flow illustrates a use case where the developer requires the following:

  1. Allow KWS to handle the sign up flow for kids
  2. Handle the sign up flow for all other users using a separate system (built by the developer)

Summary:

This flow will require the most work by the developer as it will involve building custom backend code and maintaining a separate database of users.