Tell users who controls their data
Identify your organisation and explain the purposes for using UserGist in your app or portal. UserGist generally processes customer end-user information on your instructions; linking to the UserGist Privacy Policy does not replace your own notice or the required customer DPA.
Explain any account linkage, targeting, public publishing, support handling, integrations, international transfers, retention, and rights contact that applies to your implementation. Do not call a persistent anonymous identifier “fully anonymous” when it can distinguish or be linked to a person.
Disclose what your integration actually sends
- Anonymous app-scoped IDs and any identified user IDs, aliases, or properties your app supplies.
- Tracked events and app/device/OS/language information; avoid sending sensitive page names or properties without a clear need.
- Feedback ratings, survey answers and progress, free text, and the app context associated with a response.
- For mobile push, device tokens, selected channels/preferences, notification content, and delivery/open/action callbacks you forward.
- For portals, email verification, authored requests/comments, votes/follows, public content visibility, and private support messages and uploads where enabled.
- Offline queues and stored identity/consent state on the device. Describe real platform persistence rather than promising universal encryption.
Apply real choices and withdrawal
Use the host app’s existing consent/lawful-basis decision before enabling optional processing. Pass the actual choices to setConsent rather than copying an example that grants every purpose. Keep analytics, feedback, survey, and push decisions separate where supported.
On web, initialisation remains inactive until participation is explicitly activated. Identified participation requires a server-minted token; anonymous participation requires its explicit opt-in configuration and start method. Reset identity correctly on logout and account switching.
When push is withdrawn, follow the SDK’s documented disable/token-revocation flow and reconcile device permission. Withdrawing optional purposes and clearing local state do not erase existing server records. Provide a separate way to request deletion.
App Store and Google Play disclosures
Complete App Store privacy labels and Google Play Data safety using the data your shipped app and its configured SDKs actually collect, link, share, and retain. SDK presence alone does not determine every answer. Check platform definitions of tracking, sharing, collection, encryption, and deletion against the release configuration.
Review Apple privacy-manifest and required-reason API requirements for the distributed SDK package and host app, including UserDefaults and other covered APIs. A manifest in a demo app is not evidence that every distributed SDK contains the required resource. Review tracking permission requirements separately; routine push permission is not App Tracking Transparency consent.
If your app supports account creation, review the platform-specific account-deletion requirements and provide the necessary in-app and web paths. An API available only to your internal administrators does not itself satisfy every app-store user-facing requirement.
Public portals and support
Provide a collection notice before someone supplies their email or content. Explain that public requests and comments can be viewed by others and indexed, and that support conversations are handled by your authorised team. Do not bundle feedback participation with promotional email or analytics consent.
In Customer Portal settings, expand the app’s Portal appearance and provide the organisation’s legal name, HTTPS Privacy Policy URL, and privacy contact email together. They appear before sign-in/submission and in the portal footer. The platform also links to UserGist’s legal information; that link does not replace your own notice. Confirm how portal email identities map to app subjects before promising that one app-user deletion removes every portal/support record.
Before shipping your integration
- Execute the DPA and required transfer documents, review the provider register, and confirm locations and retention that meet your obligations.
- Test anonymous and identified users, account changes, consent refusal/withdrawal, offline queues, and access/deletion for the release you ship.
- Validate mobile push using real APNs/FCM configuration and physical-device testing for your own app. Do not infer delivery from a successful API request.
- Verify public/private content and downstream integrations. Keep notices and store disclosures current as features change.
You can save or print this document using your browser’s print menu. Keep the version and draft status with any copy.