Skip to content
Grona Developers
The mobile SDKs are available on request. Email support@grona.ai to get access.

Consent and data minimisation

The SDK has three consent states, and it starts in the most restrictive one that still lets your app work. This page explains what the SDK keeps, sends and deletes in each state, and why some data stays on the device after a refusal. Read it with your privacy team before you connect your consent prompt to the SDK.

Your app owns the consent prompt and stores the answer. The SDK does not remember consent between launches: it starts in UNKNOWN every time. So pass the stored answer with the consent call on each launch, and again whenever the shopper changes it.

The three states

Section titled “The three states”
State Events Personalisation
UNKNOWN (the default) Kept in memory only, at most 500, oldest dropped. Nothing is written to disk and nothing is sent Campaigns render
GRANTED Written to the on-disk queue and sent Campaigns render
DENIED The in-memory buffer is dropped, the disk queue and preview pins are deleted, and nothing new is collected Campaigns render; evaluation stays on the device

In every state, campaigns are decided on the device from the signed configuration, so the shopper’s experience does not depend on consent. Consent controls what is recorded and sent, not what renders.

The configuration download carries no identifiers in any state.

Section titled “Events before consent”

While consent is UNKNOWN, events wait in memory. When the shopper grants consent, the SDK drops that pre-consent buffer by default and sends only events recorded from then on.

You can turn on the pre-consent events option to send the buffered events once consent is granted instead. It is off by default. Turn it on only if your counsel confirms that your consent text covers events recorded before the shopper answered.

Events dropped before consent or under DENIED take no sequence number, so they do not show up as gaps.

What DENIED deletes, what it keeps, and why

Section titled “What DENIED deletes, what it keeps, and why”

When the shopper refuses, the SDK deletes:

  • the in-memory event buffer;
  • the on-disk event queue;
  • preview pins.

It keeps, on the device only:

  • the install id;
  • the configuration state: the cached signed configuration, and the record of the highest configuration version accepted.

Nothing sends either of them under DENIED. They stay because deleting them would make things worse, not better. A new install id would reassign the shopper to new arms in every install-based campaign. Losing the version record would weaken the protection that stops an attacker replaying an older configuration, for example one with a campaign that has since been killed.

Preview pairing also needs the install id, so the SDK refuses to pair a preview link while consent is DENIED.

Minimisation in every state

Section titled “Minimisation in every state”

Whatever the consent state, the SDK limits what an event can carry:

  • Product ids and prices appear only for products a Grona campaign showed or added in the session. Other product views and basket changes are counted without them.
  • Purchases carry the order total, the applied treatments and only those session products, never the full basket.
  • Exception: on keyed placements such as cart_line, campaign events carry the line’s product id as their key, in every arm. So while a cart_line campaign is live, the product ids of the cart lines bound to it leave the device.
  • Events never carry search text, names, phone numbers or email addresses, and the customer id is your opaque internal id.
  • The SDK never reads the advertising identifier or other device identifiers.
  • The on-disk queue holds at most 1,000 events or 7 days.

See Events and exposure for the full rules, and Data, privacy and security for Grona’s approach across products.

Next steps

Section titled “Next steps”