AppsBrief
← AppsBrief

Privacy Policy

Last updated 29 October 2026

AppsBrief (“AppsBrief”, “we”, “us”) is a reporting tool for people who publish mobile apps. You connect the analytics, advertising and distribution accounts you already own, and we send you a daily summary of what changed. This policy explains what we access, why, how long we keep it, and who else sees it. It applies to appsbrief.com and the AppsBrief service.

1. The short version

  • We request read-only access. We cannot change anything in your accounts.
  • We read aggregate reports — totals per day, and for crashes, where in your code they happen and which app versions and devices they hit. We do not receive personal data about the people who use your apps.
  • We never sell your data, and we never use it for advertising or to train AI models.
  • You can disconnect or delete everything at any time, and revoke us directly from your Google Account.

2. Information we collect

Account information. When you create an account we store your email address and the workspace name you choose. Authentication is handled by Supabase; we do not store your password.

Connection settings. For each account you connect we store non-secret configuration needed to query it — for example a Google Analytics property ID, a Google Ads customer ID, a BigQuery project and dataset name, your Play reports bucket, and the email address of the Google account that granted access. We show you that email so you can see which account each surface is reading.

Billing information. AppsBrief is free during its beta, so no payment is taken and we hold no billing information. Once paid plans start, a payment will be taken by our reseller, the merchant of record, which collects your card details and billing address under its own privacy policy; we will never see or store your card number. Before then we will name the reseller here and list exactly what it tells us about a subscription.

Credentials. OAuth refresh tokens and service-account keys are held in an encrypted secret store, separately from the rest of your record. They are used only to request the reports described below.

Reporting data from connected accounts. Aggregate metrics — for example daily ad revenue, impressions, clicks, installs, active users, sessions, spend, cost per install, and crash counts with their issue titles — together with the signals and summaries we derive from them. For your top crash issues we also read where the crash happens in the code (file, line and method, and the error type) and how its crashes split by app version, device model, Android version, free memory and whether the app was in the background. These come back as counts per issue: we never read individual crash reports' error messages, logs, custom keys, breadcrumbs or user identifiers, and device installation IDs are only counted, never retrieved.

From Google Analytics we also read your app's own events as counts: each event's name, how many times it fired and by how many people over the last 28 days and week by week, split by app version, the screen names your app reports, and the values of parameters you registered as custom dimensions (for example a failure reason). From AdMob we also read revenue and impressions per app version. We never read individual event records or user identifiers from Google Analytics.

3. Google user data: what we access and why

AppsBrief's use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. We request the minimum scopes needed for the features described on this site, and every one of them is read-only:

AdMobadmob.report
Daily ad revenue, impressions and clicks, so the brief can flag a revenue drop or a click-through rate that looks like invalid traffic, and revenue per app version, to compare releases.
Google Analytics 4analytics.readonly
Daily active users and sessions, plus your app's own events counted by name and app version (and any reason parameters you registered), so the brief can follow the actions your app exists for. Counts only, never user identifiers.
Google Adsadwords
Campaign spend, installs and cost per install. Read-only in practice: AppsBrief never creates, pauses or edits a campaign, bid or asset.
Crashlytics (via BigQuery)bigquery.readonly
Crash counts and issue titles from the Crashlytics export you already own, so a release that starts crashing shows up next to the revenue it costs you.

Specifically, we do not: request write access of any kind; read the contents of your Gmail, Drive, Calendar or Contacts; request or receive identifiers for the end users of your apps; or use Google user data for advertising, credit assessment, or lending.

Limited Use. Data obtained through Google APIs is used only to provide and improve the user-facing features described on this site. We do not transfer it except as needed to provide those features, to comply with applicable law, or as part of a merger or acquisition; we do not use it for advertising; and we do not allow humans to read it except with your explicit permission, to resolve a support issue you have raised, for security purposes, or where required by law. We do not use it to develop, improve or train generalised AI or machine-learning models.

4. Where AI is involved, and what it is given

Part of your brief is written by a large language model, which turns the metrics and signals we have already computed into readable narrative. This is the one point at which your data is processed by a third party for a purpose other than storage, so it is worth being precise about it:

  • What is sent is the assembled brief context — your workspace name, the date, the aggregate metrics for the period, and the signals we derived from them.
  • When you connect Google Analytics, a model also reads the list of your app's event names with their counts and any registered reason values, with no user identifiers, to describe your app in plain words and choose which of its numbers your brief watches. You can see what it chose on your dashboard.
  • If you add your own questions, the model is given their text and the same aggregate metrics day by day, to answer them. Each answer is stored with that day's brief. Please don't put personal information in a question.
  • Credentials are never sent. Tokens and keys stay in the secret store and are not part of the brief context.
  • The provider is contractually bound not to train models on data submitted through its API, and the content is not used to improve generalised models.
  • If this step is unavailable, the brief is still produced without it — the numbers and findings do not depend on it.

5. How we use your information

We use it to: generate and deliver your briefs; detect anomalies and draft the suggested responses; show you the current status of each connection; send you service email such as your brief and security notices; and keep the service secure and working. We do not use your data for advertising, and we do not sell or rent it.

6. Sharing and subprocessors

We do not sell your data or share it with third parties for their own purposes. We use a small number of service providers to run AppsBrief, each with access limited to what their function requires: a cloud database and authentication provider, an application hosting provider, an email delivery provider, the AI provider described in section 4, and,once paid plans start and if you subscribe, the reseller that sells the subscription as merchant of record (named in section 2 before then).We may disclose information where required by law, or to protect the rights, safety and security of AppsBrief and its users.

7. Retention and deletion

Metrics and briefs are retained while your account is open, so the service can show trends over time. You can disconnect any surface at any time, which deletes the stored credential for it and stops all further access. You can also delete a workspace, or your whole account, yourself from the dashboard under Privacy & data. Deleting a workspace revokes our Google access for every connection and deletes its connections, credentials, metrics and briefs, including the brief files on our server; deleting your account does that for every workspace you own alone and also deletes your login. We remove the data from live systems immediately and from routine backups within 30 days.

Billing records (the subscription's status and the payment notices our reseller sends us, which we store without your name, email or billing address) are deleted with the workspace, and deleting a workspace cancels its subscription. The reseller keeps its own record of each transaction under its privacy policy.

You can also revoke AppsBrief's access independently of us at myaccount.google.com/permissions. Revoking there stops access immediately, whatever else happens.

8. Security

Credentials are stored encrypted and separately from your other records. Access to each workspace's data is enforced at the database level, so one customer's records cannot be read from another's session. Traffic is encrypted in transit. No system is perfectly secure, and we do not claim otherwise — if a breach affects your data we will tell you.

9. Your rights

You may request a copy of the data we hold about you, ask us to correct it, or ask us to delete it, by emailing support@appsbrief.com. Depending on where you live you may have additional rights under laws such as the GDPR or the CCPA, including the right to object to processing and to complain to your local data protection authority. AppsBrief does not sell personal information.

10. Children

AppsBrief is a business tool and is not directed to children. We do not knowingly collect personal information from anyone under 16.

11. Changes to this policy

If we make a material change we will update the date at the top of this page and, where the change affects how we handle your data, notify you by email before it takes effect.

12. Contact

Questions about this policy or your data: support@appsbrief.com