You added the monetary scope. Your revenue numbers are still empty.
That is usually not a bug in your code. In most cases yt-analytics-monetary.readonly is doing exactly what Google documented it to do for the report you are calling — which is nothing at all.
Every tutorial about the YouTube Analytics API stops at the scope string. You paste it into your OAuth request, the consent screen accepts it, the token comes back with the scope granted — and the revenue fields are still missing or your call returns a permissions error. Nothing in the developer guides explains why, because the explanation sits in a single note on a different page.
What Google actually says about the monetary scope
The YouTube Analytics channel reports documentation carries this note, verbatim:
Read that again, because it reframes the whole problem. If your integration authenticates a normal creator and pulls channel reports, the monetary scope is not gated, throttled or pending approval. It simply has no revenue to give you on that surface. You are asking the wrong API surface, not holding the wrong permission.
This is why the problem is so expensive to diagnose in-house. Every signal your app receives says success: the scope was granted, the token is valid, the request returns HTTP 200. The failure is silent and architectural.
Four different reasons revenue is missing
Wrong report surface
You are calling channel reports. Google states revenue and ad performance metrics are not supported there, regardless of the scope you hold.
Wrong account class
Estimated revenue and ad performance reports are documented as content owner reports. A content owner is a YouTube Partner Program entity with linked channels — not the same thing as a channel owner who logged into your app.
Wrong API entirely
Actual — not estimated — revenue lives in system-managed reports. Google states that data in the system-managed reports can only be retrieved with the Reporting API, and only for content owners who already have those reports in Creator Studio.
Unapproved app
Even when the surface and the account class are right, your app has to survive Google OAuth verification before real users outside your test list can consent to these scopes at all.
Where revenue data actually lives
Google splits YouTube analytics access across two APIs and two account classes, and the revenue question lands differently in each combination.
- Channel owners retrieve reports about their own channel. Google describes this as understanding viewing statistics and trends. Revenue is not part of the channel report set.
- Content owners in the YouTube Partner Program can retrieve reports that aggregate data for all channels linked to their accounts. This is where the documented estimated revenue and ad performance reports live.
- System-managed reports are generated automatically by YouTube for content owners who already have access to the equivalent reports in Creator Studio. Google states these provide actual revenue data earned by assets and videos, and that they are retrievable only through the Reporting API.
The practical consequence: if your product promises creators a revenue dashboard and your users are individual channel owners rather than a content owner entity, no scope, no quota increase and no approval unlocks the data you promised. That is a product scoping problem, and it is far cheaper to discover before you build than after a customer asks where their earnings are.
The dependency chain most teams discover in the wrong order
Decide whose data you are actually reading. Channel owner or content owner. This single decision determines which reports exist for you, and it cannot be patched later with a permission request.
Pick the API that carries the metric you promised. Analytics API for targeted queries, Reporting API for bulk and system-managed datasets. They are not interchangeable, and only one of them carries actual revenue.
Request the narrowest scope set that supports it. Google is explicit that you must request the narrowest scopes your app needs and provide a written justification explaining why narrower scopes would not work. A scope you cannot justify is a liability in review, not a safety net.
Build the app so the reviewer can verify it. The verification requirements say the demo must show the end-to-end flow including the OAuth grant, and that the consent screen must show the same exact scopes you are requesting. An app that cannot demonstrate the monetary scope in use cannot justify holding it.
Survive review, then plan for the data rules. Access is the beginning of the obligation, not the end of it — see the retention and aggregation rules below.
Two separate Google reviews, routinely confused
Teams working on YouTube integrations often assume there is one approval. There are two, they are different submissions, and they answer different questions.
- Google OAuth app verification decides whether your app may ask real users for sensitive scopes at all. It is a Google Cloud process covering domain ownership, your privacy policy, scope justification and a demo video. We cover the mechanics of that review in our Google OAuth verification guide, and the point at which an integration crosses from a simple API key into that review in YouTube API key vs OAuth 2.0.
- The YouTube API Services compliance audit decides whether your YouTube usage complies with the Developer Policies, and it is the gate on additional quota. That is a separate submission with separate criteria, covered in YouTube Data API quota increase.
Some products need both. Passing one tells you nothing about the other, and preparing for the wrong one is a common reason a project stalls for weeks with no clear blocker.
Where these projects actually stall
- The product was scoped around revenue metrics that do not exist for the account class the users belong to.
- The scope list was copied from a sample project, so there is no defensible justification for half of it when review asks.
- The demo recording shows the dashboard working but never shows the consent screen granting the exact scopes requested.
- The privacy policy does not describe how Google user data is handled, or is not reachable where Google requires it to be.
- The team assumed one Google approval covered both OAuth verification and the YouTube compliance audit.
- Correspondence goes to a project contact address nobody monitors, and the review times out waiting on a reply.
The rules that apply after you get access
YouTube Analytics and Reporting data get an unusual carve-out from YouTube’s general 30-day storage rule — the Developer Policies permit storing this data for as long as necessary, provided the client still confirms every 30 days that it remains authorised by the user. That is a recurring engineering obligation, not a one-off setting.
Aggregation is more restrictive than most teams expect. The policies permit aggregating data only across channels under the same content owner, state that such aggregated data must only be viewable by that content owner, and prohibit combining data from different content owners. A benchmarking or league-table feature built across your customer base is not a UI decision — it collides directly with published policy, and it is the kind of feature that turns a passed audit into a failed one later.
Why this is worth getting right the first time
The scope string takes thirty seconds. Everything expensive sits around it: choosing the account class your product can actually serve, matching the API surface to the metric you sold, writing scope justifications that survive review, producing a demo a reviewer can verify, and designing storage and aggregation that will not fail a later policy check. Each of those is recoverable on its own. Discovering all five after launch, with customers waiting on a revenue dashboard that cannot legally or technically exist, is not.
If you are planning a YouTube analytics integration, or you are already holding the monetary scope and still cannot see revenue, we provide review preparation and policy-aligned guidance for exactly this path — scope selection and justification, submission preparation, and architecture review before you commit engineering time. You can see what that covers on our services page.
This article summarises publicly available Google and YouTube developer documentation as published at the time of writing, and is provided for general guidance only. Platform requirements change without notice, and review outcomes are determined solely by Google. We are an independent consultancy and are not affiliated with, endorsed by, or a partner of Google or YouTube.