facebook / facebook/facebook-ios-sdk
Docs and dashboard contradict each other in different places regarding automatic logging of events
- Dominant language
- Swift
- Stars
- 8.1k
- Forks
- 3.7k
- PR merge metrics
- No merged PRs in 30d
Description
### Checklist before submitting a bug report
- [x] I've updated to the latest released version of the SDK
- [x] I've searched for existing [GitHub issues](https://github.com/facebook/facebook-ios-sdk/issues)
- [x] I've looked for existing answers on [Stack Overflow](https://facebook.stackoverflow.com), the [Facebook Developer Community Forum](https://developers.facebook.com/community/) and the [Facebook Developers Group](https://www.facebook.com/groups/fbdevelopers)
- [x] I've read the [Code of Conduct](https://github.com/facebook/facebook-ios-sdk/blob/main/CODE_OF_CONDUCT.md)
- [x] This issue is not security related and can safely be disclosed publicly on GitHub
### Xcode version
26.5
### Facebook iOS SDK version
18.0.3
### Dependency Manager
SPM
### SDK Framework
Core
### Goals
I'd like to accurately track LTV events back to Facebook using our payment provider. We then have to disable automatic logging of those events by the Facebook SDK though. Because the dashboard tells us that
> Source: https://developers.facebook.com/apps/***/settings/basic
> Log in-app events automatically (recommended)
> Turning this toggle on automatically logs in-app events, including purchases, subscriptions, and start trial events that are processed through the App Store. When this toggle is turned on, you should stop manually logging these events to avoid duplicate reporting.
So the other way around must also be the case, and we should thus disable this toggle. For iOS and Android we have the following switches:
> Source: https://developers.facebook.com/apps/***/settings/basic/
> (iOS) Log in-app events automatically (recommended)
> (Android) Log In-App Purchases Automatically (Recommended)
> (Android) Log In-App Subscriptions Automatically (Recommended)
> Source: https://developers.facebook.com/apps/***/analytics/settings/
> (iOS) iOS: Log in-app events automatically (Recommended)
> (Android) Android: Log in-app purchases automatically (Recommended)
> (both platforms ?) Automatic event logging for the Facebook SDK
> Source: https://developers.facebook.com/quickstarts/***/?platform=ios
> (iOS) Log in-app purchase events automatically on iOS (recommended)
> ^--- toggling this switch throws a 404 error btw
> Source: https://developers.facebook.com/quickstarts/***/?platform=android
> (Android) Log in-app purchase events automatically on Android (recommended)
To make it even more interesting, there's also a toggle on the "Datasets" settings in the Facebook events manager:
> Source: https://eventsmanager.facebook.com/events_manager2/list/app/***/settings?act=***
> (both platforms ?) Automatic event logging for the Facebook SDK
In the docs and dashboard it says that the toggle takes precedence over the code. But then there's this (yet unreleased) commit: https://github.com/facebook/facebook-ios-sdk/commit/f0cf21cde152b35151f7341f28311a127546e2e4 , saying:
> Add _isAutoLogAppEventsExplicitlySet flag so the developer's explicit
setter call takes priority over server config.
So right now, I'm very very confused. Why are the toggles scattered all over the place? Which takes precedence over the other? When does the code take precedence? There's this community question that's never been answered, asking the same: https://developers.facebook.com/community/threads/348457771184349/
But most importantly: how do I specifically disable **Purchase** events without disabling other events (like App Install and App Launch). It _seems_ to be possible on Android (not sure as it's very amibigous). It also seems like it was possible on iOS _at some point_ (because it's still present in the apparently outdated quickstart).
Could you please enlighten me about this matter?
### Expected results
n/a
### Actual results
n/a
### Steps to reproduce
_No response_
### Code samples & details
```swift
```
Contributor guide
Assessment
This issue has not been assessed yet.