Meta Ads Insights API: Device & Frequency Breakdowns Now Require Ad Account Opt-In
Since August 6, 2026, Meta has required certain ad accounts to opt in before the Ads Insights API will return real data for the impression_device breakdown (and any breakdown combination that includes it), the hourly stats breakdowns, and frequency_value. Accounts that haven't opted in don't get an error — the call still returns a normal success response, just with an empty result set. Dashboards quietly render zeros and nobody gets an alert.
Where teams get stuck
- Reporting pipelines built on these breakdowns silently return empty data after August 6, with no exception thrown to alert engineering
- There's no bulk toggle in Ads Manager's UI — enablement is account-by-account under Additional Breakdowns
- Agencies and SaaS platforms managing many client ad accounts have no easy way to tell which accounts were opted in and which weren't
- Confusing an opt-in gate with a metric deprecation — the breakdown itself hasn't been removed, it's just switched off by default
What actually needs to be right
- Enabling the correct breakdown per ad account — either manually in Ads Manager or programmatically via the account-level feature-settings enablement endpoint
- Detecting a silent empty-but-successful response in your own error handling, instead of treating any 200 status as proof of real data
- Applying the fix across every managed ad account, not just the one where someone happened to notice the drop first
- Keeping this separate from the underlying
ads_managementApp Review permission — the permission grant and this reporting-level opt-in are two different gates
Find every Insights call touching an affected breakdown
Audit every request using impression_device, an hourly stats breakdown, or frequency_value — including any breakdown combination where one of these is nested alongside another parameter.
Enable the breakdown at the ad account level
Turn it on manually per account in Ads Manager's reporting settings, or use the enablement endpoint if you're managing reporting programmatically across many accounts.
Audit every account you manage, not just the first one that broke
Because this is opt-in per ad account, a multi-account setup can have some accounts already enabled and others silently returning nothing — including new accounts created after August 6.
Build detection for empty-but-successful responses
Standard error handling won't catch this, because Meta returns a normal success response with an empty result — the failure only shows up if you specifically check whether the data array is unexpectedly blank.
Common ways this breaks silently
- Dashboards and BI tools built on
impression_deviceorfrequency_valuequietly showing zeros instead of real device or reach data - Agencies only discovering the gap when a client asks why device-level reporting disappeared
- New ad accounts created after August 6 inheriting the opted-out default with no prompt to enable it
- Reporting code treating a 200 response as confirmation the data is correct, when it's actually an empty result set
ads_management in the first place — getting that permission approved and getting your reporting pipeline configured correctly afterward are two separate problems. I handle both: Facebook App Review and permission approval support for the underlying access, and correct API-level configuration so reporting breakdowns don't go silently blank. For technical implementation support, see Hire Facebook API Developer.