Sentry and Google Play Public Pages: explain diagnostics and replay

Inventory what your SDK sends

Start by locating every Sentry initialization and capture path in the Android app. The base error-monitoring setup and optional products have different disclosure consequences.

• Error events: stack traces, exception messages, breadcrumbs, app version, operating-system details, device context, and timestamps can appear in diagnostic events.
• User context: a user ID, email, username, or other custom user fields are optional and depend on what your code attaches.
• Custom context and tags: teams often add account IDs, feature flags, URLs, screen names, or business metadata; these can identify a person or reveal sensitive details.
• Performance monitoring: transactions, spans, timing, network information, and route names are configuration-dependent.
• Session Replay: replay can capture additional screen and interaction information. Scrubbing and masking settings are part of the real behavior, not a reason to assume no user data is involved.
• Attachments and logs: screenshots, request bodies, console output, or locally captured files may contain more than the default event fields.

Review your beforeSend, beforeBreadcrumb, replay masking, sampling, and PII configuration alongside the event payload. A redaction hook can materially change what your app sends, but it does not change the need to check the data that survives the hook. Look at a production event in Sentry with sensitive values removed from any example you share.

The catalog table on this page is generated from Declora's Sentry Service Profile. It treats diagnostics and crash logs as likely, while performance data, user context, entered text, and Session Replay depend on configuration. Confirm the facts for your release; do not turn an optional Sentry capability into a claim just because the dependency exists.

Write the privacy policy around purposes

A useful privacy policy distinguishes diagnostics from product analytics. Explain that Sentry receives error or performance information to monitor reliability, investigate failures, protect the service, and improve app quality. If you use replay to reproduce interface problems, say so directly and describe the controls you apply to mask or redact content.

Then list the categories that users might see in those events. “Technical data” is too vague if your events include device identifiers, app version, network information, account IDs, or user-entered text. At the same time, avoid claiming that every event contains every category. Use configuration-dependent language where sampling, capture hooks, or feature flags determine collection.

Explain account linkage clearly. If you set a Sentry user ID or email, say that diagnostic events may be associated with an account so your team can investigate a report. If you only use an internal non-account identifier, describe it as an identifier that may still be linked by your systems. If you never call setUser or send contact fields, do not list email because Sentry supports the field.

Include provider and retention information that matches your contract and settings. Identify Sentry as a service provider processing data for error monitoring, point users to the provider's privacy information through your normal policy review, and state your own retention or deletion process. Do not promise immediate deletion of every backup or event unless your operational process actually does that.

Make the support page part of the debugging path

A public support page should let an unauthenticated user report a crash, login problem, or data question. Include the app name, developer identity, monitored contact, and a form or email that actually reaches your team. Tell users not to paste passwords, authentication codes, payment card numbers, or private keys into a support request.

If you ask for a diagnostic ID or event link, explain how to find it and warn that the link may expose event details. Prefer a short event ID or a server-side lookup over asking users to send a complete log. If the app automatically attaches a user identifier to Sentry events, ensure the support workflow does not disclose another user's event to the person making the request.

The privacy page can describe diagnostic reports, but it should not masquerade as a support channel. Link the support Public Page from the app and the store listing, test it while logged out, and verify that a user can reach a human or a documented response path. A working page is evidence that the contact route exists; it does not prove that the event payload is safe, so keep the two checks separate.

Align replay and redaction claims with reality

Session Replay deserves its own implementation review. Record whether it is enabled in production, which screens are eligible, which text inputs are masked, whether images or network details are blocked, and how sampling works. Test a screen containing a fake email, address, or message and inspect the resulting replay using a test account. Do not use real customer data for this test.

If replay is disabled in production but enabled in a staging build, say which environment the policy covers and prevent staging settings from shipping accidentally. If you enable it later, update the policy, Data safety answers, and any consent or notice flow your product requires. A blanket statement that Sentry never captures user content is not appropriate when your custom breadcrumbs or replay configuration can capture it.

Keep Google Play answers and pages consistent

Google Play Data safety asks about data collected and shared by your app, including relevant third-party SDK behavior. The Public Page gives users the explanation; the store form provides structured answers. Both should be based on the same confirmed inventory of Sentry events.

Check the treatment of service providers and sharing against the current Google definition and your contractual setup rather than guessing from the word “third party.” Decide separately whether events are collected, whether they are linked to a user, the purpose, and whether users can request deletion. Keep a versioned record of the Sentry configuration that informed the answers so a later SDK upgrade or replay rollout triggers a review.

Common mistakes

• Calling Sentry “anonymous” while attaching an account ID, email, or custom context.
• Ignoring breadcrumbs, tags, request data, or logs because the default exception object looks harmless.
• Describing Session Replay as active when it is disabled, or claiming it is absent when a production flag enables it.
• Promising that scrubbing removes every sensitive value without testing the actual event and replay output.
• Listing only crash logs in the policy while Google Play answers include performance or diagnostic categories.
• Making the support page require the broken app or an account the user cannot access.

Where Declora fits

Declora's App Passport turns the Sentry questions that are easy to miss — user context, entered text, performance monitoring, and Session Replay — into confirmable App Facts. It can then keep Google Play Answers, privacy and support Public Pages, and the Consistency Check aligned when your configuration changes. Review the generated reference at declora.app. Declora is not a law firm, does not provide legal advice, and cannot guarantee approval by Google or any other reviewer.

FAQ

Do I need to list email just because Sentry has a user context API?

No. Email is configuration-dependent. List it when your app actually attaches email to Sentry events or sends it through another path, and review whether your own systems can link the identifier to an account. An available SDK field is not proof that your production app uses it.

Is Sentry Session Replay automatically included in the privacy policy?

Only when you enable and ship it in the environment covered by the policy. If it is enabled, document the additional interaction or screen data, your masking and scrubbing controls, and the purpose. If it is off in production, do not describe it as active; still review feature flags and build configuration before release.

Does a Sentry event ID belong on a public support page?

You can tell users how to provide a diagnostic ID, but do not publish event links or logs publicly. Use a monitored form or private channel, warn users not to include secrets, and make sure your support process does not reveal another person's event data.

Can I call all Sentry data anonymous?

Not safely as a default. Stack traces, device context, custom tags, user IDs, emails, breadcrumbs, and replay may be linkable or contain personal information depending on your code. Review the actual payload and use precise, configuration-dependent wording.

Does Declora verify my Sentry redaction settings?

No. Declora's Service Profile suggests common facts and asks configuration questions; you confirm what your production app sends. It helps align your store answers and Public Pages, but it does not inspect your Sentry project, provide legal advice, or guarantee store approval.