thank you

📌 Question:
Hello,
We are using the Facebook Graph API (v22.0) to retrieve spend and install data at the ad set level, but we have noticed a slight discrepancy between the numbers obtained from the API and those shown in Facebook Ads Manager.
📌 Details:
- API Endpoint: /insights
- Query Parameters:
- level: "adset"
- action_attribution_windows: ["1d_click", "7d_click", "skan_click"]
- time_range: { since: yesterday, until: yesterday }
- time_zone: 9 (Asia/Tokyo, matching our Ads Account settings)
- Issue:
- The mobile_app_install count returned by the API does not exactly match the installs displayed in Ads Manager.
- The difference is usually ±1 install per ad set but sometimes varies more.
- We have ensured that we are summing all mobile_app_install values returned by the API.
📌 Our Hypotheses & Questions:
1. Does Ads Manager use a different data aggregation method compared to the API?
2. Could Facebook's statistical modeling (e.g., estimated installs) be affecting the reported numbers?
3. Are there any additional attribution windows or conversion events that Ads Manager includes but are missing from the API response?
4. Is there a recommended method to ensure that the install count from the API matches exactly with Ads Manager?
Any insights or suggestions from the community or Facebook engineers would be greatly appreciated.
Thank you in advance!

I want to get the PAGE_ACCESS_TOKEN but it's be disable

How can i delete this my your alerts in support inbox?I already delete this post but still there. Actually i just have 2 violation the other 2 is the Facebook message that saying we're sorry we got this wrong. We reviewed your post again and it does follow our community standards.

We are in the process of requesting advanced permissions for an application on Meta Developers. This process requires a detailed review by Meta, where we must submit instructions and a screencast, following the official documentation’s criteria, demonstrating step by step how to test the application and the use case for each requested permission.
So far, we have received 17 rejections, all for two main reasons:
Inconsistent requests from reviewers – Although we strictly follow all of Meta’s documented guidelines and requirements, each review introduces a new request from a reviewer that is not described in the documentation. After making adjustments, the next review is assigned to a different reviewer, who adds yet another request, creating an endless cycle of new demands. Test user issue – The test user creation functionality within the Meta Developers platform is not working, which is a Meta platform issue. Reviewers themselves suggested using an existing user linked to our application, but when they attempt to log in, a verification code is required and sent to our phone, even though we have disabled 2FA, preventing them from completing the verification. Meta’s Contradictions and Inconsistencies Regarding the Test User Issue In section 2 of the item "We were unable to verify the permissions requested while testing your app" on the Application Verification Details page, Meta requests: "Create a test user and verify that you can use it to recreate the experience exactly as it is depicted in the screencast."
However:
As stated, test user creation has been temporarily disabled by Meta (source). Contradictorily, in "Step 4: Complete App Verification", Meta states: "We will test your app using our own test accounts. Do not include your personal Meta Technologies app account's credentials." We have attempted both approaches multiple times:
When we do not provide our own test user, clearly following one part of Meta’s documentation, our submission gets rejected, claiming that a test user is needed to verify functionalities and the use case demonstrated in the screencast. When we do provide a test user, Meta reviewers cannot log in because the app still requests a mobile verification code, even though 2FA is disabled on our account. Alternative Attempts and Current Roadblock To bypass this issue, we attempted to provide a workaround, which involved:
Setting up a recovery email on our account. Granting the reviewer access to this email. Instructing them to use the "Forgotten password?" and "Try another way" options during login. However, even with this approach, the login process still requires confirmation via SMS, making it impossible for reviewers to access the account.