How to grant read access to Google Play install reports

From the SoleOS answers series — written about our own product space; grounded in published definitions and documented behavior, never invented numbers.

You grant read access to Google Play install reports by creating a Google Cloud service account, linking it to your Play Console account under Users and permissions, and assigning it only "View app information and download bulk reports" (financial data optional, separately toggled) — never any Release or Store presence permission. This gives an external tool or dashboard read-only access to installs, ratings, and revenue reports without letting it publish, edit listings, or manage users.

Play Console's permission model wasn't designed with "give my dashboard read access" in mind — it was designed for agencies and in-house teams with QA, marketing, and release managers who need different levels of access. That's why the setup feels heavier than, say, generating a Stripe restricted key. But once you've done it once, it's a five-minute task for every additional app under the same developer account.

Why service accounts, not your personal login

Google Play doesn't support read-only API keys the way Stripe or Bing Webmaster Tools do. Instead, access to the Play Developer Reporting API and bulk reports goes through a Google Cloud service account — a non-human identity with its own email address (something like reports-reader@your-project.iam.gserviceaccount.com) that you then invite into Play Console like a teammate.

This matters for two reasons:

• You're not sharing your own credentials. Your personal Google login keeps full admin rights; the service account gets only what you explicitly check.
• You can revoke it in one click. Remove the service account from Users and permissions, or delete the key in Google Cloud, and access stops immediately — no password reset, no 2FA fatigue.

If you're already comfortable creating service accounts for GA4 or Search Console, this will feel familiar. If not, it's worth learning once; you'll reuse the pattern.

Step-by-step: creating and scoping the service account

1. Create (or reuse) a Google Cloud project. Go to console.cloud.google.com, create a project (or use one you already have for GA4/Search Console — service accounts can be scoped independently even inside a shared project).

2. Enable the Google Play Developer Reporting API. Under APIs & Services → Library, search for it and enable it. Without this step, the service account exists but can't actually call the reporting endpoints.

3. Create the service account. IAM & Admin → Service Accounts → Create Service Account. Give it a descriptive name like play-reports-readonly so you recognize it later if you're managing several apps or several tools.

4. Generate a JSON key. Open the service account, go to Keys → Add Key → JSON. Download it and store it somewhere safe — this file is what you'll upload to whatever tool needs it. Treat it like a password: it's the credential, not just an identifier.

5. Invite the service account into Play Console. In Play Console, go to Users and permissions → Invite new users. Enter the service account's email address (the one ending in .iam.gserviceaccount.com), not your Google account.

6. Assign minimal permissions. This is the step people rush. Under account permissions, grant:

• View app information (read-only)
• View financial data — only if you actually need revenue reports, not just installs

Do not grant anything under Release management, Store presence, or Admin. A tool that only needs install and rating trends has no reason to touch your app listing or release tracks.

7. Limit to specific apps if you manage a portfolio. If you run several apps under one developer account, Play Console lets you restrict the invited account to specific apps rather than "all apps." Use this. A dashboard tracking three apps shouldn't have visibility into the other seven.

What "read access" actually gets you

Once connected, a read-only service account can typically pull:

• Install and uninstall counts by date, country, and device
• Rating and review trend data (not the ability to respond to reviews)
• Crash and ANR rates, if you've granted the relevant scope
• Financial reports, if you checked that box — gross installs revenue by product, not raw transaction-level Stripe-style detail

It cannot publish updates, change pricing, respond to users, or add/remove other team members. That asymmetry — full visibility, zero write power — is the whole point.

Common mistakes that widen the blast radius

Granting "Admin" out of impatience. If a setup wizard fails silently, the instinct is to just check every box. Don't. If a report isn't showing up, the fix is almost always a missing API enablement or an unenabled report type, not insufficient permissions.

Reusing one service account across unrelated tools. If two different dashboards both need Play data, create two service accounts. It's more setup overhead but means revoking one tool's access doesn't require touching the other's.

Forgetting the key exists after rotating tools. If you switch dashboards a year from now, go back into IAM & Admin and delete the old key. An unused JSON key with live permissions is a dangling risk with no upside.

Not restricting to specific apps. Especially relevant if you're running a multi-product portfolio — see tracking Stripe and RevenueCat together for the parallel problem on the revenue side, where scoping matters just as much.

Where this fits if you're tracking a portfolio, not one app

If you're pulling Play Console data into a spreadsheet for a single app, the steps above are the whole job. If you're managing installs and revenue across five, ten, or twenty apps, the manual version means repeating this service-account dance per app, then stitching CSVs together by hand every week.

That's the specific gap SoleOS was built to close — this post is written by SoleOS about its own connector space, so take the framing with that in mind. SoleOS connects to Google Play via the same service-account model described above (you still create the key and grant the same minimal, view-only permissions — SoleOS never asks for release or admin scopes), then normalizes install and revenue trends alongside RevenueCat, Stripe, GA4, and your other sources so you're not reconciling report formats app by app. Full scope details are on what SoleOS connects to, and the underlying formulas are documented in the metrics dictionary.

If you only publish one app and check installs once a month, none of this portfolio tooling is necessary — Play Console's own dashboard and a saved bookmark will do the job fine. The service-account setup only starts paying for itself once you're doing it more than a couple of times or need the numbers next to other products' data. You can see how the connected view looks with the live demo before deciding either way, and SoleOS pricing if you get that far.

Frequently asked questions

Does the service account need my Google Play developer account password?

No. Service accounts authenticate with their own JSON key, generated in Google Cloud, not your Play Console login. You never share your personal credentials with any third-party tool.

Can I revoke access without affecting my own Play Console login?

Yes. Removing the service account from Users and permissions, or deleting its key in Google Cloud IAM, cuts off that specific access immediately. Your own admin login and any other integrations are unaffected.

Why can't I just use an API key like I do for Bing Webmaster Tools?

Google Play's Developer Reporting API is built on Google Cloud's IAM system, which uses service accounts and OAuth-style credentials rather than simple static API keys. It's more setup upfront but gives finer-grained, per-app permission control than a single key would.

What if I only want install counts, not financial data?

Leave "View financial data" unchecked when you assign permissions. The service account will still return install, uninstall, and rating trend data — financial reports are a separate, opt-in permission specifically because revenue data is more sensitive.

Do I need a new service account for every app I publish?

No, one service account can be granted access to multiple apps under the same developer account — you just choose which specific apps to include when assigning permissions, rather than creating a new account per app.