YouTube API Derived Metrics and Data Storage: What Changed on 1 June 2026
Two separate things landed on the same date, and almost every guide written before mid-2026 now describes a rulebook that no longer matches YouTube’s own documents. One change narrowly relaxes a long-standing prohibition. The other quietly changes how your daily quota is counted. Neither is optional reading if your product touches YouTube analytics.
Read this before you build anything on it: the new derived-metrics allowance is not a general loosening of the rules. YouTube documents it as applying only to developers who are already audited, who have an analytics use case, who explicitly applied through the quota extension request form, and who accepted an amendment to the Developer Policies. If you are none of those things, the original prohibition still applies to you in full.
The rule that has always been there
YouTube’s Developer Policies have long carried a blunt restriction: API clients must not replace API data with similar, independently calculated data, and must not use API data to create new or derived data or metrics. A companion clause prohibits aggregating API data to gain insight into YouTube’s usage, revenue or business.
In practice that is the clause that kills a large share of analytics products at audit time. A dashboard that takes subscriber counts and view counts and presents an “engagement score” or an “estimated earnings” figure is, on the plain reading of that clause, creating derived data. Teams build the feature first, discover the clause during a compliance audit, and then have to decide whether to strip the feature or fight for it.
What actually changed
A narrow exception
YouTube now permits six specific categories of additional metric — but only under an amendment you have to opt into, and each category carries its own explicit prohibitions.
Longer storage, undefined
The revision history states that accepted use cases may store some statistical data beyond 30 days. The linked policy page does not yet spell out how long, or which fields.
Granular quota buckets
Separately, the Data API began charging search.list and videos.insert to their own quota buckets instead of the single shared pool.
Nothing was repealed
The general prohibition on derived data is untouched. The new policy sits on top of it as a conditional exception, not a replacement.
The six permitted categories — and the limit inside each one
This is the part most summaries get wrong. Each permitted category is published together with a prohibition that is easy to trip over, and the prohibitions are where products actually fail.
| Permitted category | The limit published alongside it |
|---|---|
| Custom channel scores and ratios | Must add unique analytical value, not simply redisplay raw API data under a new name, and must not misrepresent the definition or provenance of API data |
| Financial performance projections | Must be presented clearly as third-party estimates, with a prominent disclaimer that the figures are not approved by Google |
| Content categorisation and tagging | Must be additive and distinct from YouTube’s own video categories, and must not replace or override a published YouTube category |
| Viewer sentiment analysis | Aggregate sentiment is allowed; inferring or estimating sensitive protected attributes is prohibited |
| Gamification and leaderboards | Allowed, but not in a framing that fosters harassment or brigading between channels |
| Brand suitability and safety scoring | Pre-campaign planning is allowed; validated brand-safety claims about specific ad impressions or platform-wide verification are not |
Running underneath all six is a single requirement that is trivial to state and surprisingly expensive to retrofit: your product must visibly distinguish your calculated metrics from metrics sourced from API data. That is a UI, export, API-response and documentation change, not a footnote.
The gate you have to pass to use any of it
Be an audited developer already
The policy is scoped to audited developers. If you have never been through a YouTube API compliance audit, this exception is not available to you yet — the audit comes first.
Have an analytics use case
The allowance is tied to analytics and creator-tool use cases. A general-purpose integration that happens to compute a score does not automatically qualify.
Apply explicitly through the quota extension request form
Permission is not implied by having passed an audit previously. It is requested, and the request identifies which additional metrics you intend to create.
Accept the amendment to the Developer Policies
The additional metrics are conditional on accepting an amendment. Using them without that acceptance leaves you on the original prohibition.
Rebuild the product so the distinction is visible
Every surface that shows a calculated metric has to make clear it is yours and not YouTube’s. YouTube states that violating these policies may result in quota reduction or termination of API access.
The storage rules nobody re-reads until the audit
The derived-metrics change touches storage, so it is worth restating what the baseline actually says, because the version repeated in developer forums is not the version in the policy.
The 30-day rule
Authorized data outside the exemption list, and non-authorized data, may be stored no longer than 30 calendar days. After that you must delete or refresh it.
What is exempt
Analytics API data, Reporting API data, and statistics such as view counts. Even then, authorisation must still be re-checked every 30 days.
What is not exempt
There is no published exemption for resource identifiers. The widely repeated claim that video and channel IDs sit outside the 30-day rule does not appear in the policy text.
On revocation
When a user revokes consent, all authorized data accessed or stored under that consent must be deleted — and your privacy policy has to describe that path.
The quota change riding alongside it
Independently of the policy amendment, the Data API moved to a granular quota model on the same date. Instead of one shared daily pool, search.list and videos.insert are charged to their own respective buckets, with all other methods continuing against the existing pool. The published default allocation is now stated as 100 search.list calls, 100 videos.insert calls, and 10,000 units per day combined for everything else.
If your capacity planning is based on a flat “10,000 units a day” figure taken from an older article, your search-heavy or upload-heavy product is being budgeted against a number that no longer describes how it is billed. That is also the point at which teams start submitting quota extension requests — which routes them straight back into the audit process covered in our YouTube Data API quota increase and compliance audit guide.
Where projects stall on this
- Shipping a score, index or estimate first and discovering the derived-data prohibition during an audit, when the feature is already in customer contracts
- Assuming the June 2026 allowance applies automatically because the product does analytics — it is opt-in, and unrequested use is still a violation
- Presenting an earnings estimate without the required third-party-estimate framing and disclaimer
- Building brand-safety verification claims that cross from planning into impression-level validation
- Retaining a long-lived corpus of API data on the assumption that IDs, or cached responses, are exempt from the 30-day rule
- Having no working delete-on-revoke path, and a privacy policy that does not describe one
- Capacity planning against a flat daily unit figure that pre-dates the granular quota split
- Re-badging a YouTube metric under a friendlier product name, which the policy treats as misrepresenting its provenance
- Submitting a quota extension request that describes the product as it is marketed rather than as the policy language requires it to be described
What Google has not published
Do not let anyone quote you a number on these
- How long “beyond 30 days” actually is. The revision history announces the extended storage allowance; the linked policy document does not currently state a duration, a field list or a retention cap.
- Any turnaround time for the application. There is no published decision timeline for a derived-metrics request.
- Any approval or rejection rate for the amendment, the audit, or quota extensions.
- An AI or machine-learning training clause. Neither the API Services Terms of Service nor the Developer Policies contain one. Articles claiming YouTube added an API-side AI-training prohibition are not supported by those documents — what constrains model building is the ownership clause, the derived-data prohibition and the 30-day storage rule, which is a different argument and needs to be made accurately.
- A definitive reading of whether your specific metric qualifies. The categories are described in general terms; the mapping from your feature to a category is a judgement you have to make and defend.
There is also an unresolved inconsistency worth knowing about rather than papering over: the quota and compliance audits page carries an auto-generated summary stating a flat 10,000 units per day, while the body of the same page states the post-June split. The body text is the accurate statement. If you are reconciling a policy question against a summary box, you may be reconciling against a stale figure.
What this means in practice
A feature that was quietly non-compliant, discovered at audit time with revenue already attached to it
Mapping each computed metric to a permitted category, rebuilding the provenance distinction, and rewriting the request in policy language
An analytics product whose calculated metrics sit inside a documented allowance instead of outside a documented prohibition
The genuinely difficult part of this is not the reading. It is the reconciliation: deciding which of your existing metrics survive as-is, which need reframing, which have to be rebuilt so the provenance distinction is visible everywhere, and how the quota extension request should describe all of that so it matches both your product and the policy. Get that mapping wrong and the request is answered on the version of your product you described, not the one you shipped.
That reconciliation work — auditing what you compute today against the six categories, preparing the storage and deletion story, and assembling the extension request — is what we handle as part of YouTube API approval and verification support. If the authentication model is also still open, our comparison of YouTube API key versus OAuth 2.0 is the right place to settle that first.
Policy summary compiled from YouTube’s published API Services Terms of Service, Developer Policies, revision histories and quota guidance as available on 30 July 2026. YouTube updates these documents without notice — always confirm against the current official pages before making an engineering or contractual decision. This is approval and compliance support, not affiliation with or endorsement by YouTube or Google, and no specific outcome or timeline can be guaranteed.