1. Home
  2. Use Cases
  3. Set up push notifications

Set up push notifications

Push notifications collect personal information, so providing them as a feature to kids requires a lot of care. This use case describes how to set up the following flow, managed by KWS, that provides direct notice to parents for compliant push notifications:

About KidSafe push notifications

Push notifications can be tricky to implement when building apps that are targeted at kids. This is because signing users up to receive push notifications often involves the collection of personal information: 

“The information you collect from the child’s device used to send push notifications is online contact information – it permits you to contact the user outside the confines of your app – and is therefore personal information under the [COPPA] Rule.”

FTC

You should only send push notifications to kids if their parent or guardian has consented to  this… but what does this really mean?

Because most vendors collect personal information in order to send push notifications, the FTC requires you to seek verifiable parental consent (VPC) when sending them to kids:

“…provide parents with direct notice and obtain verifiable parental consent prior to sending push notifications to the child.”

FTC

Obtaining VPC creates an extra hurdle which can significantly reduce your conversion rates. However, there is a way to implement push notifications using a much leaner ‘opt-out’ consent flow:

“You may be able to rely on the “multiple-contact” exception to verifiable parental consent, for which you must also collect a parent’s online contact information and provide parents with direct notice of your information practices and an opportunity to opt-out. Importantly, in order to fit within this exception, your push notifications must be reasonably related to the content of your app.”

FTC

KWS offers such a flow, which you can use in conjunction with the right push notification provider. The parent is given notice (via email) that their child wants to receive push notifications. The parent may opt their child out if they wish. If they take no action, their child remains subscribed to your push notification service. 

This KWS-powered flow ensures a good balance between compliance, frictionless UX and higher conversion rates.

For more information about opt-in, opt-out, and verified parental consent, see Parental consent and verification.

Choose a push notification service

The first step is to choose the right push notification provider. The FTC explains that, to utilise the ‘multiple contact exception’ rule, your push notification provider must not collect any other personal information:

“If you want to combine this online contact information with other personal information collected from the child, you cannot rely on this exception and must provide parents with direct notice and obtain verifiable parental consent prior to sending push notifications to the child.”

Always aim to minimise the data that you and your third parties collect from kids. For an app targeted at kids, make sure you choose a push notification provider that:

  • does not automatically collect personal information from the device, unless the user opts in to push notifications.
  • does not share personal data across apps.
  • does not collect a persistent device identifier that can identify the user across apps.
  • does not automatically combine push notification identifier with other data. If they do, this will require verifiable parental consent.
  • supports opt-out of push notifications for users via an API, so that you can stop sending push notifications to users whose parents opt them out.

One effective way to find out what information your provider collects is to check their API documentation. Our safe social engagement platform, PopJam, uses Firebase. Below is the analysis we carried out to reach this choice:

Requirement
No auto-collection of personal information from the deviceCompliant if: Developer prevents Firebase auto-initialization.
Actual practice: Firebase generates an instance ID, which the Firebase Cloud Messaging (FCM) SDK uses to generate a registration token on app start. Firebase sends it to the backend automatically. This is not ideal. 
Further action required: To comply with COPPA, the developers need to prevent this auto-initialisation, which is supported.
No data shared across appsCompliant if: Developer sets up only one app for one project ID on Firebase.
Actual practice: Instance IDs are common to a project ID on Firebase. As long as each app is a separate project on Firebase, no data is shared across apps.
Support for user-specific opt-out APICompliant if: Developer deletes the instance ID when KWS notifies the developer that the user should not be sent any more push notifications.
Actual practice: There doesn’t seem to be specific documentation around how the developer can opt out of push notifications (other than on the device). 
Further action required: The developer should utilise Firebase’s server and client-side API to delete an instance ID, which deletes all associated information with that ID.
No combining push notification identifier with other PIICompliant if: The developer does not send targeted push notifications to kids, where the targeting is based on kid’s personal information such as their birthday. This must be enforced through a contract.
Actual practice: If the intention is to send targeted push notifications based on the kid’s PII, verifiable parental consent is required.
Instance IDs are used by Firebase to combine data across Cloud Messaging and Crashlytics but they do not contain any other PII and are local to the app.
No persistent device identifierCompliant if: The instance ID is a unique identifier for an app instance. It is unique for all app installs in the world, and is regenerated is the app is reinstalled.

Set up a push notification

1. Set up a KWS App

When you’ve found a suitable provider, set up your KWS app. If you don’t already have access to a KWS environment, ask for a free sandbox

2. Determine which 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 (i.e. isMinor = true) that signals if the user is defined as a child, based on their age and location.

3. Invoke the kid-safe push notification flow

Now that you know the user is a kid, invoke the following kid-safe push notification flow for kids only. Adults can go through your own standard flow.

  1. Present the kid with a push notification subscription dialog – You may trigger this wherever you wish within your app. For example, it could automatically pop up after sign-up, or when the kid clicks a specific button.
  2. If the kid accepts the subscription, your app needs to check (using the Get User’s Application Profile endpoint) if they already have parental permission to receive push notifications.
    – If they have consent, your app can now subscribe them to your push notification service
    – If they don’t have consent, trigger a permission request using the Request Permission(s) endpoint. This endpoint sends an automated email to the parent giving them an opportunity to opt their child out.
  3. When consent is granted, you can deliver push notifications – The kid can receive push notifications as long as push notifications remain enabled on their device and their parent has not revoked the permission via the Parent Portal.

Voila!

You’ve now set up your app to adhere to “best practice” as defined under COPPA. The great advantage of utilising KWS for this is that the entire permission request flow is managed by the platform. This includes all notices to the parent and the logging of the permissions that they granted.

Updated on 24/11/2020

Was this article helpful?

Related Articles