Why does Meta web to app show clicks but no installs in AppsFlyer?

When Meta shows link clicks and AppsFlyer shows no installs, either the installs are there under a different label or the record broke at one stage between the ad and the app. AppsFlyer reports Meta web to app installs under Facebook Ads, not under metaweb_int, so the first check is whether you are reading the right label. The second is to trace a single test click through each stage until a record is missing. On iOS, one setting changes what Meta receives while AppsFlyer’s aggregated reports stay the same: with AppsFlyer’s Advanced Privacy on, postbacks for users who have not granted ATT permission carry no click ID or device identifiers. A test phone that granted permission can pass while the postbacks for everyone else lack the click ID Meta uses to identify the click.

Scope: Meta ads with the Website conversion location, measured through AppsFlyer’s Meta Web integration (metaweb_int), for an app installed from the App Store or Google Play, with trial and purchase events sent by the AppsFlyer SDK or by RevenueCat. I checked every platform statement against the vendor’s own page on 1 October 2026. Web campaigns that convert on the website itself use a different AppsFlyer guide and are outside this post. So are Meta app promotion campaigns: an event that reaches Meta there and still cannot be optimized for is covered in Why are my trial and purchase events ineligible for Meta AEM?

What can “clicks but no installs” mean?

One of three things, and each needs a different fix.

1. A labeling difference. AppsFlyer’s guide Meta Ads: Create web-based campaigns (edited 15 September 2026) says web to app installs are reported “under the Facebook Ads PID” in dashboards and raw data. In raw data, the original_url field keeps pid=metaweb_int, and postback reports show metaweb_int as the media source the postback went to.
2. Two different clicks. Meta counts the ad click. In AppsFlyer’s landing page flow, the AppsFlyer click is registered when the user taps the call to action on your page. Visitors who leave without tapping are just an impression, and that counts toward an install only if you turn on AppsFlyer’s view through attribution (window of up to 24 hours).
3. A real break. The click ID never reached the store link, the install could not be matched, or the downstream event never reached Meta.

How do you trace one test click through every stage?

I check one path end to end before reading any aggregate numbers.

Set the test up so a missing record can only mean a setup problem:

• Register the phone as a test device. AppsFlyer’s Registering test devices (edited 28 August 2026) says the reattribution window limits install attributions to one per 90 days, so repeated test installs on the same phone record nothing unless it is registered. For an iPhone that will allow tracking, AppsFlyer’s method is to register it by IDFA.
• Grant ATT permission on the test phone. Use a team member’s phone, tap Allow on your app’s ATT prompt, and accept your consent banner if the landing page shows one. Under AppsFlyer’s Apply Aggregated Advanced Privacy framework (edited 11 June 2026), web traffic to an app whose user authorized ATT gets user level attribution data for both you and the ad network, so Advanced Privacy does not limit what this test shows.
• Click the ad the way a user would. On the phone, inside Facebook or Instagram, not from a desktop preview. If the page opens in Safari, do not use Private Browsing: AppsFlyer’s 2023 bulletin on Link tracking Privacy (LTP) says iOS 17 removes fbclid in that mode.
• Write down the time of each step, so you can find the rows later.

Then walk the stages in order and stop at the first one that fails.

AppsFlyer’s Raw data reporting overview (edited 11 August 2026) lists click raw data as a Data Locker report only, so without Data Locker you check stage 2 on the links themselves. AppsFlyer’s Raw data export page (edited 13 August 2026) says web PIDs such as metaweb_int do not appear in the media source drop down; to see web postbacks you add the PID manually. RevenueCat’s AppsFlyer integration page notes that AppsFlyer’s Events view shows in app events by the user’s install date, so a purchase made today by a user who installed last week sits in last week’s range.

Which link should the Meta ad use?

AppsFlyer’s guide names the options by destination:

• Landing page: a page with OneLink Smart Script or a Smart Banner. AppsFlyer recommends this when the app is on several platforms, or when you want the page to explain the product or collect data. The Smart Banner builds only OneLink links; Smart Script can also build single platform links for other stores.
• Straight to the store: an AppsFlyer attribution link, OneLink, single platform or cross platform. AppsFlyer adds a warning: “Sometimes, the use of AF attribution links may lead to errors”. Its suggested fix is to ask Meta or use a landing page instead.

In Ads Manager, the campaign uses the Website conversion location with the same pixel ID you entered in AppsFlyer. In the Tracking section, AppsFlyer says not to choose App Events, “otherwise Meta will claim those conversions using the SRN API”. If AppsFlyer shows no clicks, impressions or cost for the web campaign at all, its guide says the link needs af_c_id and the ad account must be connected on the Facebook Ads integration.

What has to happen to fbclid?

Meta adds it and AppsFlyer carries it. Meta’s developer page ClickID and the fbp and fbc Parameters describes the click ID as a parameter Meta generates and passes with the URL when someone clicks an ad, and warns that the value is case sensitive. AppsFlyer says Meta appends fbclid to the destination URL automatically.

On a landing page, AppsFlyer’s Set up Smart Script to convert web visitors (edited 2 September 2026) says Smart Script forwards fbclid to the outgoing URL on its own from version 2.8.1. For version 2.8.0 and below, the Meta web guide says to map it by hand. To see the value in raw data, map it to one of af_sub1 to af_sub5 as well. The Meta web guide calls fbclid essential for sending in app event postbacks to Meta, which is why stage 2 in the table checks the value on both links.

Why do installs show under Facebook Ads and not metaweb_int?

By design. The Meta web guide says events go to Meta under metaweb_int but appear under Facebook Ads in the Overview and Activity dashboards and in the media_source field of raw data and API reports. To separate web from app campaigns, AppsFlyer suggests a web prefix or suffix in the campaign name; to confirm one install, read its original_url.

What does the Advanced Privacy step change, and who decides it?

AppsFlyer’s Meta web guide includes, as a setup step, “Turn off Advanced Privacy (if you are setting an iOS app integration).” Its Aggregated Advanced Privacy article explains what the setting does. With it on, partners get only aggregated campaign details for iOS 14.5 and later users who have not granted ATT permission. The user level data they do not get includes the AppsFlyer ID, customer user ID, click ID, IDFA, IDFV, user agent and IP address. The Meta web guide says Meta uses fbclid to identify the specific click, so a postback without it loses that link. The Aggregated Advanced Privacy article also says that an ad network without an Advanced Privacy integration gets no postback at all for users who did not consent, and that a partner’s toggle can only be turned off once the app level Aggregated Advanced Privacy toggle is off.

I do not treat this as a switch to flip while debugging. AppsFlyer itself says to work with your legal and other professional advisors on how Apple defines tracking before turning the framework off. Apple’s User Privacy and Data Use page says you need ATT permission to track, and that “you may not derive data from a device for the purpose of uniquely identifying it”, whatever your settings. AppsFlyer adds that even with the framework off, user level data cannot be used to uniquely identify a device. The app owner decides with privacy counsel, and the measurement plan follows that decision. The test phone above, with ATT permission granted, lets you check the setup without touching the setting.

Are the postbacks to Meta set up the way AppsFlyer documents?

The install postback is automatic; everything else is mapped by hand. From AppsFlyer’s Meta web guide:

• The integration needs the pixel ID and an access token, and the partner toggle must stay on.
• Installs are the only automatic default postback. Trial and purchase need a mapping to a Meta event or CUSTOM.
• A purchase postback must include “Values and revenue”. Any other choice makes the postback fail.
• “This partner only” sends events attributed to Meta; “All media sources, including organic” also sends events attributed to other partners and to organic. It is a postback setting: it changes what Meta receives, not whether AppsFlyer attributes an install to Meta.
• Events sent server to server to metaweb_int must carry ua and ip. The SDK adds them; your server has to.
• Postbacks for what AppsFlyer calls “re-engagement” are not supported on this integration.

On Meta’s side, the developer page Using the API says events can be verified in Events Manager within 20 minutes of sending, where the data source shows raw, matched and attributed events.

Can SKAdNetwork see these installs?

Not for an ad clicked inside the Facebook or Instagram app. Apple’s Signing and providing ads lists attributable web ads, “where the ad network presents an ad on a Safari web page”, from SKAdNetwork 4. Google’s Understanding iOS App campaign measurement and reporting describes web to app observability “only on Safari browsers” and calls Chrome and Firefox unsupported by SKAdNetwork. An ad in the Facebook or Instagram app is not on a Safari web page, and AppsFlyer’s Meta web guide does not mention SKAdNetwork. Do not expect SKAN to explain a missing install here.

What if RevenueCat sends the trial and purchase?

Then only one system should send revenue to AppsFlyer. RevenueCat’s AppsFlyer page says to “remove all client-side tracking of revenue”, because tracking purchases with the AppsFlyer SDK as well “can lead to double counting of revenue”. It also lists the $appsflyerId attribute as required, says RevenueCat only sends events to AppsFlyer when the required attributes are set, and warns that without the AppsFlyer ID some events may not be delivered, which shows up as a missing stage 5 or 6.

For purchases made on the web through Stripe, Paddle or RevenueCat Billing, RevenueCat’s web store event routing setting sends each purchase to one AppsFlyer API, Mobile S2S by default or Web S2S, and the page says “a purchase is never sent through both APIs”. If a web purchase still appears twice, look for purchase tracking still running in the app or another sender outside RevenueCat. The page also says AppsFlyer plans to retire People-Based Attribution by the end of 2026, which is a stated plan, not a change that has happened. How I compare Meta, RevenueCat and an MMP when their numbers disagree is in Meta vs RevenueCat vs Adjust: which number do you trust?

What should you not conclude from one test?

A passing test proves the path works for one user who granted ATT permission on one phone, not the match rate for everyone else. A failing test does not show which setting is at fault until you change one thing and run it again. No vendor page I checked documents a single setting as the fix for missing web to app installs, and several changes at once hide which one mattered. Record the stage, the change and the new observed result each time.

Where does the trace fit in my work?

Tracing a click like this is signal engineering: the event the ad platform optimizes on has to be the one the business counts, and it has to arrive. When a Meta web campaign looks weak and you cannot tell if measurement is the reason, I check that in the growth audit, which you can book on its own. The Google side of web to app, where click IDs and conversion uploads work differently, is in Why does Google web to app show no conversions in AppsFlyer? Why a team would send Google Search traffic to an app this way is in Do Google Search Ads work for app installs?

Sources

All checked on 1 October 2026.

• AppsFlyer: Meta Ads: Create web-based campaigns, edited 15 September 2026.
• AppsFlyer: Apply Aggregated Advanced Privacy framework, edited 11 June 2026.
• AppsFlyer: Set up Smart Script to convert web visitors, edited 2 September 2026.
• AppsFlyer: Raw data export page, edited 13 August 2026.
• AppsFlyer: Raw data reporting overview, edited 11 August 2026.
• AppsFlyer: Registering test devices, edited 28 August 2026.
• AppsFlyer: Bulletin: Link tracking Privacy (LTP) is coming with iOS17, published 21 September 2023.
• AppsFlyer: Meta Ads: Create web campaigns for website apps, edited 30 August 2026, for the website conversion case outside this post.
• Meta for Developers: ClickID and the fbp and fbc Parameters, no page date.
• Meta for Developers: Using the API, no page date.
• RevenueCat: AppsFlyer, no page date.
• Apple Developer: User Privacy and Data Use, no page date.
• Apple Developer: Signing and providing ads, no page date.
• Google Ads Help: Understanding iOS App campaign measurement and reporting, no page date.