Brand Verification vs App Verification: Google's Two-Track System Explained

Google reviews your OAuth app twice, on two tracks that share a console page and almost nothing else. Brand verification is an automated identity check that finishes in minutes. App verification, which Google's own docs call sensitive scope verification, is a human review that takes weeks. The automated one gates the human one, so doing them in the wrong order costs you the difference.

We just took Savra through the first track and prepped the second, and the console's current layout matches none of the older guides. This is the map I wish I'd had.

Where did the OAuth consent screen settings go?

The configuration that used to live under "APIs & Services → OAuth consent screen" now lives under Google Auth Platform in the Cloud console's left menu. The old path redirects. The new section has six pages, and each owns a distinct piece of the verification story.

The Verification Center shows two statuses side by side, Branding and Data access. That pairing is the whole system in one screen.

What does brand verification actually check?

Track one is Google confirming your app is who it says it is. The check is automated and brand-level: your app name, logo, support email, homepage, and privacy and terms URLs get compared for consistency, and your authorized domain must be verified in Google Search Console by an account that holds Owner or Editor on the same Cloud project.

Note what the automated check does not do: it does not read your privacy policy's contents. We ran brand verification while our marketing site was mid-migration, and it passed on identity consistency alone. The human track is the one that reads your pages.

Two mechanics trip people here. The check produces a result you still have to publish; verified-but-unpublished branding blocks the next track exactly like unverified branding. And the Search Console verification must belong to a project Owner or Editor, so a domain verified years ago by an agency account or a departed teammate counts for nothing until someone on the project re-verifies it.

Do this track first, always. It costs minutes, it unlocks the submission form for the slow track, and on the Google Ads side the Basic Access application form says a brand-verified project gets expedited review. One automated check speeds up two separate bureaucracies.

What does app (scope) verification check?

Track two is a person at Google deciding whether your app's use of user data matches what you disclose. It applies the moment you request any sensitive scope. For Savra that is three: Search Console reporting, Analytics reporting, and Ads.

The reviewer works from four artifacts you submit:

The scope list. Declared on the Data Access page, and it must match what your app requests in the real world, across every flow on the OAuth client. Our client serves two flows: sign-in with Google, which requests openid, email, and profile, and the data connection, which requests the three sensitive scopes plus openid and email. The declaration is the union of both. Miss a scope your app requests, or declare one it never requests, and the reviewer sees a mismatch against the consent screens in your own demo video.

Per-scope justifications. One short paragraph each: which feature uses the scope, and why no narrower scope works. Ads has a built-in answer, because the Ads API exposes a single scope with no read-only variant, so the justification writes itself: one scope exists, we use it for reporting only, and any future write feature would ship behind explicit per-action confirmation.

The demo video. An unlisted YouTube link showing the OAuth grant flow end to end in English, the consent screen with your app's name, the browser URL bar showing your client ID, and then each sensitive scope's data appearing in your product. If your client also powers sign-in with Google, the video must show that flow too. Most rejections cite this artifact: a scope requested and never demonstrated, or a client ID cropped out of frame.

Your live privacy policy. Hosted on the authorized domain, linked from your homepage, disclosing how the app accesses, uses, stores, and shares Google user data, and carrying the Limited Use disclosure required by the Google API Services User Data Policy. The human reviewer reads it. Ours names the exact scopes and states in one sentence that Google data is used on a read-only basis, so the policy and the application make the same promise in the same words.

While this review is pending or unsubmitted, your consent screen shows an unverified-app warning and sensitive-scope grants cap at roughly 100 users. Existing grants keep working either way.

What order should a small team run this in?

The dependency chain settles the schedule for you.

1. Verify the domain in Search Console with a project Owner or Editor account.
2. Complete the Branding page and run brand verification. Minutes.
3. Publish the verified branding. The scope submission stays locked without this.
4. Set the Audience page to External and In production. Verification cannot complete from Testing.
5. Reconcile the Data Access scope list against every flow your client runs.
6. Write the per-scope justifications and record the demo video against your live product.
7. Submit in the Verification Center, then answer the Trust and Safety thread fast; a stalled thread stalls the review.

The two tracks reward the same underlying discipline. Your app name, your consent screen, your privacy policy, your scope list, and your video all describe one product, in agreement, with no claim your product cannot demonstrate. Reviewers on both tracks are checking for coherence, and coherence is cheap to manufacture up front and expensive to retrofit under review.

FAQ

Is brand verification the same as app verification?
No. Brand verification is an automated identity check and completes in minutes. App verification is a human review of sensitive-scope usage and takes days to weeks. Published brand verification is the entry ticket to the app review.

Can I skip the app review if my scopes are basic?
If your app requests only non-sensitive scopes like openid, email, and profile, yes. The human review triggers on sensitive and restricted scopes.

Do Analytics, Search Console, or Ads scopes require a security assessment?
No. Those are sensitive, and the annual CASA security assessment applies only to restricted scopes such as full Gmail or Drive access.

What blocks the scope submission most often?
Unpublished branding, a Testing publishing status, a scope list that disagrees with what the app requests, and a missing demo video. All four are visible on the submission form before you file, so a careful read of that page is a free pre-review.