Data and privacy
Consent and erasure
Consent decides what Loop may do for a person; erasure removes them. Both are per person, and both are recorded.
Three channels
| Channel | What it gates |
|---|---|
| analytics | Events and identities: the data collection itself. |
| surface | In-app guides. A denial short-circuits every guide decision. |
| messaging | Lifecycle email. |
In consent-required mode the SDK makes no request of any kind and touches no storage until you grant one, because every call it would make carries an identifier for someone who has agreed to nothing.
Where each one is enforced
The analytics channel is enforced in the SDK, not on the server.
A denied surface channel is refused server-side: the decision engine checks it on every request. A denied analytics channel is honoured by the SDK, which drops events before they are queued, but the ingest endpoint does not consult consent, so events posted directly with a write key are accepted regardless. If your compliance posture depends on server-side enforcement of analytics consent, it is not there yet.
This is worth knowing rather than working around. Keep the record of why consent is valid on your own systems; a consent call mirrors a decision your page already made and is not independent proof that a human made it.
Erasure
A deletion request removes a person's events and identity from the stores. It is recorded, because being able to show that an erasure happened is most of what an erasure is for.
A recorded denial is currently hard to reverse.
Consent moves forward more easily than it moves back. If someone denies and then grants, check the resulting state rather than assuming the second call replaced the first.