OneSignal and Google Play Data safety: what to declare for push notifications

What push notifications require, and what they don't

Sending a push notification requires a device or push token so OneSignal's servers know where to deliver the message. That token is functionally an identifier, and it is the one fact nearly every OneSignal integration produces — which is why the Service Profile marks device identifier collection as possible rather than certain, pending confirmation of your specific setup, and treats push messaging itself as a likely purpose tied to developer communications.

What push notifications do not automatically require is a link to a specific person's identity, an email address, or a phone number. OneSignal can operate purely on anonymous device subscriptions. The moment you add features on top of that baseline — tying subscriptions to accounts, adding email or SMS channels, or sending location for geo-targeted messages — you introduce additional data types that need their own confirmation.

External IDs: the linkage question

OneSignal lets you attach an external ID to a subscription, typically your own user or account identifier, so a single person's notification preferences follow them across devices. This is the single biggest factor in whether your push setup counts as linked to the user's identity.

If you never set an external ID, OneSignal manages anonymous device subscriptions, and your user ID answer looks different than if you tie every subscription to a signed-in account. Both are legitimate configurations; they just produce different Data safety answers, and the difference is something only your own integration code can settle.

Email and SMS are separate features, not defaults

OneSignal is commonly known for push, but the same platform supports email and SMS messaging as additional channels. These are opt-in features a developer has to build into their messaging strategy — they do not activate simply because the OneSignal SDK is present for push. If your app only sends push notifications, declaring email or phone number collection because "OneSignal can do that" overstates what your app actually does.

Conversely, if you do route transactional or marketing email through OneSignal's email channel, that is Contact Info collection tied to a specific purpose, and it needs its own line in the Data safety form separate from your push declaration.

Location-based messaging is configuration-dependent, not implied

Some OneSignal implementations use location data to segment or trigger geo-targeted messages. This is a distinct feature from basic push delivery and is not implied merely by having notifications enabled. If your app sends precise or approximate location to OneSignal for this purpose, it belongs in your Data safety declaration under location; if it does not, including it anyway creates a mismatch between your declared data types and what your app can be observed doing.

The advertising identifier is the easiest thing to get wrong

Push infrastructure and advertising infrastructure are conceptually different, but some OneSignal configurations do involve the advertising identifier, particularly where segmentation ties into broader marketing tooling. The Service Profile does not assume this either way — it is explicitly configuration-dependent, and assuming a "no" because push isn't advertising, or a "yes" because the SDK vendor also does marketing products, are both guesses rather than confirmed facts about your setup.

Common mistake

The most common mistake is declaring only Device or other IDs and stopping there, without checking whether an external ID, email channel, or location feature was added later in the product's life by a different contributor. Push infrastructure tends to accumulate features gradually, and the Data safety form should reflect the app's current integration, not its original minimal setup.

The second common mistake is the reverse: declaring broad data collection "to be safe" for features that were never actually implemented. Overstating collection creates its own inconsistency, since a data safety label describing SMS messaging in an app that never sends SMS doesn't match observable behavior either.

Why apps get rejected

Google Play's review process checks Data safety accuracy against runtime behavior and the app's own privacy policy:

• Declaring "no data collected" while a push SDK visibly requests notification permission and delivers messages.
• Omitting an external ID or email channel that a security researcher or reviewer can trigger by observing network requests during testing.
• A privacy policy silent on push notifications or messaging while the Data safety form declares device identifier collection for that purpose.

Where Declora fits

Declora's OneSignal Service Profile suggests App Facts for device identifiers and developer communications automatically, then asks the four questions that determine everything else: whether you set an external ID, whether you use email or SMS channels, whether location feeds into messaging, and whether the advertising identifier is involved. Confirming these produces consistent Apple and Google Play answers and Public Pages from one set of App Facts, so adding a feature like email messaging later regenerates every declaration instead of leaving Google Play out of sync with what the app now does. Declora does not scan your code and cannot guarantee approval by Google or any other reviewer — it keeps your confirmed answers aligned across every place they appear.

FAQ

Does adding OneSignal for push automatically require declaring an advertising identifier?

No. Push delivery relies on a device or push token, not necessarily the advertising identifier. Whether the advertising identifier is involved depends on your specific configuration and any additional segmentation or marketing tooling connected to it.

Do I need to declare email collection if I only use OneSignal for push?

No. Email and SMS are separate OneSignal channels that require deliberate setup. If your integration only sends push notifications, you have not collected email through OneSignal.

What does setting an external ID change about my Data safety answer?

It ties push subscriptions to your own account identifier, which generally makes the data linked to the user's identity. Without an external ID, OneSignal manages anonymous device subscriptions, which is a different answer.

Is location data always involved in push notifications?

No. Location-based messaging is an optional feature. Basic push delivery does not require sending location data to OneSignal.

Can Declora confirm these answers automatically without my input?

No. The Service Profile suggests App Facts with a confidence level and reason, and asks the configuration-dependent questions your integration determines. You confirm them, and Declora then keeps your Apple and Google Play declarations consistent with what you confirmed. It is not legal advice and does not guarantee approval.