Meta Health & Wellness Restrictions for Apps: Why Events Disappear and What to Check

Last updated: October 27, 2026 · By Jason Garrett, Founder, Coast Studio. Not legal advice — review claims with counsel.

Short answer: Meta's health and wellness data-sharing restriction applies to apps as well as websites; the restriction attaches to the data source, and an app is a data source. If purchases have disappeared from Meta reporting, check the event's actual integration route, Meta's receipt of it, its attribution eligibility, and its optimization availability before attributing the loss to the restriction. Record the category, the affected regions, the notice, and the effective date for each source.

Meta's notice reads "websites or apps," and Events Manager lists website, app, and offline sources separately, each with its own category. The published guides we have read treat it as a website problem. (When we asked a Meta rep to confirm that apps are covered, the answer was yes.) What Meta has published about app events under the restriction is thin, so this page separates what Meta says, what we have observed in restricted app datasets, and what we think explains it.

If your website is the flagged source and the app is clean, start with the restrictions guide. This page is for app-first funnels: subscription apps, telehealth apps, language and learning apps, and any brand whose revenue event fires inside the app.

What Meta publishes

• Data sources (website, app, offline) are categorized automatically, and an advertiser cannot change an assigned category, only request a review. (About data source categories)
• Three restriction types, which can apply in combination and vary by region. Core Setup restricts custom parameters and the part of the URL after the domain. Restrictions on standard events block "specific mid and lower funnel events." Full restriction stops all events from the source. Custom events also need review and confirmation in Events Manager. That is a separate check from the source restriction, and confirming an event does not lift a restriction. (Understand data sharing restrictions)
• Campaigns are not paused by a restriction; they lose the events.

Meta publishes no list of which app events fall under "mid and lower funnel," no guidance on Aggregated Event Measurement or SKAdNetwork under a restriction, and no rule on whether a website's category reaches a linked app. Treat anything you read on those three points, including the sections below, as observation or hypothesis.

Five checks to find where the event stopped

"Our purchases disappeared from Meta" has several possible causes, and the restriction is only one of them. This is the workflow we run, in order.

1. Did the event fire inside the app? Check the SDK debug log or your measurement partner's live view. If it never fired, the restriction is not your problem yet.
2. If a measurement partner or other integration forwards it, did that route receive and forward it? Map the actual route first: direct SDK, server-side App Events, or an MMP such as AppsFlyer, Adjust, Singular, or Branch, and sometimes more than one. In the MMP, check the event mapping, the enabled sharing to Meta, the consent signals, and the integration errors. If the event is here and nowhere downstream, the problem is between the partner and Meta.
3. Did Meta receive it? Events Manager, test events or the event activity view for the app dataset. In the restricted datasets we have audited, the event still showed as received, with a restriction notice on the dataset. Record what yours shows: the notice text, the dataset ID, the platform, and which events are available for reporting and which for optimization.
4. Is it eligible for the attribution method? AppsFlyer's own documentation separates delivering an app event to Meta from that event's eligibility for Aggregated Event Measurement, and tells advertisers to check eligibility in Events Manager. (AppsFlyer, Meta Ads integration setup) A restriction, a missed AEM configuration, and an unconfirmed custom event all look the same from a dashboard.
5. Can the campaign use it for optimization? The ad set's optimization event list shows what is available for selection today. If the purchase event is absent from the list on a restricted dataset, correlate that with the restriction notice and the integration checks above before calling it the cause. An event that is available is not proof that sending its underlying data is permitted.

What we have observed in restricted app datasets

In the accounts we have audited, the web list of blocked events (Purchase, Lead, Add to Cart, Initiate Checkout, Schedule, Complete Registration) maps onto the app's purchase, subscribe, start-trial, and registration events, and install, launch, and content-view events kept firing under the middle level. That is a small sample. Treat it as the list of events to test on your own dataset after the effective date, with step 5 above as the test.

One app-first account arrived with the website domain categorized as a health and wellness condition. The founders' own read was that Meta had inferred the audience from who the app serves; Meta's review was declined without a stated reason, so the inference was never confirmed. The app dataset was not categorized at the time, and their fear was that it would be. That gap between a flagged domain and a clean app is a common state for app-first brands when they find this page.

Check the web and app sources separately

Meta categorizes the two sources separately, so a flagged domain does not automatically flag the app. We think the signals that lead to an app being categorized are the App Store and Play listing text, the app name, the SDK event names, the domain linked in the app settings, and the audience Meta infers from installs and conversions. None of that is published. We have also seen a paid web funnel that deep-links into the app lose conversions after the web source was restricted, with the app dataset still clean. We have not isolated why, so treat it as a case to check on your own account, not a rule.

What to do before the effective date

Meta schedules the restriction per data source after it notifies you, so the date on your notice is yours.

1. Request review once, after cleaning up the listing and event names. In the cases we have handled, reviews were declined more often than not. Make the one request count.
2. Separate the web and app sources where they are tangled. Distinct datasets and distinct event names, so each source can be diagnosed and reported on its own.
3. Use only events whose meaning and underlying data are permitted for your source. This is the compliant-layer work we do for web datasets: parameters stripped before they leave your server, each custom event reviewed and confirmed in Events Manager, and revenue measured in your own systems when it cannot be shared. Renaming an event, separating datasets, changing domains, or changing transport from SDK to server-side App Events does not make a restricted event eligible; the restriction is on the source and the data. The point of the layer is control over what the permitted events carry.
4. Rebuild optimization on what step 5 shows you can use. Install plus a confirmed upper-funnel event in Meta, with the purchase measured in your own analytics.
5. Decide which campaigns change on the effective date. List the ad sets that optimize on an event the notice covers; those lose that optimization event on the date, and the plan above decides what they move to.

FAQ

Does the restriction apply to the SDK and server-side App Events equally?
Yes, as far as Meta's published text goes: the restriction is applied to the data source, and both routes feed the same source.

Can I keep running app-install campaigns under a health and wellness flag?
In the datasets we have seen, install-optimized campaigns kept their signal under the middle level. Meta has published nothing on this; confirm it on your ad set's optimization list.

Will removing the website from the app settings help?
We have no case that isolates that change, so we cannot say it helps. It does not remove a category already assigned to the app.

How long is the review?
Meta publishes no turnaround, and the reports we have seen vary too widely to quote a range.

Not legal advice. Review claims with counsel.

Get an app and web event map before the date

We audit both datasets, run the five checks on your live events, and deliver three things: an event map showing which events reach Meta and which the campaigns can still use, the restriction findings verified in Events Manager, and a measurement and campaign plan for the day the restriction takes effect. Fixed fee.

Book a Consultation