Google Play Data safety

This page helps your app team fill in Google Play’s Data safety form for the Grona SDK. Play’s form covers user data that libraries and SDKs in your app transmit off the device, so Grona’s data belongs in your answers. The page lists what the SDK sends, when and why, mapped to Play’s data types, and names the questions that need a judgement call from your team.

Caution

The final answers are yours. Google holds the developer responsible for complete and accurate declarations, including data that SDKs in the app send, and your answers also depend on how you configure Grona, what your consent text says and your contract with Grona. Review them with your privacy counsel.

When the SDK sends anything

Play counts data as collected when it is transmitted off the device. The Grona SDK sends events only when both of these hold:

• You set an eventsUrl in your options. Without one, the SDK sends no events and keeps no queue.
• The shopper’s consent is GRANTED. Under UNKNOWN events stay in memory and none are sent. Under DENIED nothing is collected. See Consent.

If you turn on sendPreConsentEvents, events buffered under UNKNOWN are sent once consent is granted, so your consent text must cover them.

Consent gating does not remove the entries from your form. Once any shopper can grant consent, the data is collected and must be declared.

Three other requests leave the device:

• The configuration fetch carries no identifiers in any consent state. It is not user data.
• Preview pairing sends a pairing code and the install id when a tester opens a preview link. It is refused under DENIED. The code is a single-use tester secret that expires in minutes, not end-user data.
• Image downloads fetch component images from the image hosts in your signed configuration. They carry no Grona identifiers, but the image host sees the device’s IP address.

Data types

With consent granted and an events endpoint set, the SDK sends the following. For every row: collected yes, encrypted in transit yes, and not ephemeral. Play counts data as ephemeral only when it is held in memory no longer than it takes to serve a request; Grona stores events and uses them for per-shopper analysis.

Play category and data type	What Grona sends	Notes
Device or other IDs	The SDK’s install id and session id, random UUIDs the SDK generates	Pseudonymous ids that can be re-associated with a user still count. Never the advertising ID, OAID, ANDROID_ID or App Set ID, which the SDK does not read.
Personal info: User IDs	The customer id you pass to Grona.identify	Only if your app calls identify. Must be your opaque internal id.
App activity: App interactions	Campaign events: eligible, visible, served, exposure, taps on Grona content, dismissals. Product views, cart adds and cart removals	Product ids and prices only for products a Grona campaign showed or added in the session. Other products are counted without id or price. Exception: on keyed placements such as cart_line, campaign events carry the line’s product id as their key, in every arm.
Financial info: Purchase history	The checkout total, and the purchase event: order id, order total, currency, the Grona treatments, and the products in the order that a Grona campaign showed or added	Never the full basket. Cart line product ids can still travel as campaign event keys, see App interactions.
App info and performance: Diagnostics	Batch metadata: SDK version, app version, platform and Android API level	A conservative choice. It is not clear that Play requires an entry for this metadata.

The SDK does not send:

• Location, contacts, messages, photos, files or any other device content.
• Names, email addresses or phone numbers.
• Search text or browsing history.
• The shopper’s profile from Grona.setProfile, which stays on the device.
• The full basket from Grona.setBasket, which stays on the device. Only the product ids of cart lines bound to a keyed placement such as cart_line leave it, as campaign event keys.

Grant fetching runs through your own GronaGrantSource and your own backend. Declare that data flow as part of your app, as you would any call to your own servers.

IP addresses

Play asks you to declare Approximate location when IP addresses are used to infer location. Every request reaches Grona’s servers from the device’s IP address. Grona truncates IP addresses when it receives them and does not derive location from them, so the SDK adds no location entry to your answers.

Purposes

Choose the purposes that match how your company uses Grona. These are the usual candidates:

Purpose	Applies to	Why
Analytics	All rows	Grona measures campaigns: who was eligible, who saw what and what they did next.
Personalization	All rows except diagnostics	Campaigns target shoppers by audience and assign them to variants.
App functionality	Install id, customer id, diagnostics	Customer ids gate offers and grants. Install and customer ids keep variant assignment stable.
Advertising or marketing	All rows except diagnostics	A judgement call, see below.

Advertising or marketing. Grona banners and offers promote your own products to targeted shoppers and measure their exposure. A plain reading of Play’s definition suggests declaring this purpose. The counter-argument is that slots which only recommend products are Personalization alone. Decide with your counsel. If you drop it, drop it on your App Store answers too, so both stores tell the same story.

Sharing

Play does not count a transfer to a service provider as sharing when the provider processes data on your behalf and on your instructions. “Shared: No” holds for Grona only while Grona processes your data solely on your instructions, which depends on your contract with Grona. Confirm it with your counsel.

Your own use can change this answer. If your app forwards Grona ids or events to advertising platforms, that is your app’s data flow and must be declared as such.

Optional or required

Play lets you mark collection as optional only when every user, in every region, can opt in, opt out or skip it. The SDK sends no events until your app passes GronaConsent.GRANTED. If your consent prompt is shown to every shopper everywhere and declining is possible, the Grona data can be declared optional. If your prompt is shown only in some regions, the answer is required.

Security practices

• Encrypted in transit: yes. The SDK uses https only and refuses http even when your app allows cleartext traffic. Play asks this once for the whole app, so your answer must hold for your other traffic too.
• Deletion. See below.

Deletion

Grona.reset() alone does not answer Play’s deletion question. It clears the device, but Play asks whether users can request deletion of data you collected.

• On the device. Grona.reset() clears the event queue, the customer id, the profile, grants, the basket snapshot and preview pins, and issues a new install id. Call it from your account deletion or erasure flow. See Identify shoppers.
• Already sent. Give users a way to request deletion, for example through your existing account deletion flow, and pass the request on to Grona with the customer id or install id. Contact Grona support to set up how requests reach Grona.

Common mistakes

• Passing an email, phone number or hashed email as the customer id. That changes your answers on both stores and breaks Grona’s identity rules.
• Answering “optional” when your consent prompt is shown only in some regions.
• Treating reset() as your deletion mechanism.
• Assuming consent gating removes the entries from the form.

Next steps

• Read Consent and data minimisation.
• Read Data privacy and security.