Skip to content

feat: add fetchDeferredAppLink method for Facebook ad attribution#471

Open
g-apparence wants to merge 7 commits intooddbit:mainfrom
g-apparence:main
Open

feat: add fetchDeferredAppLink method for Facebook ad attribution#471
g-apparence wants to merge 7 commits intooddbit:mainfrom
g-apparence:main

Conversation

@g-apparence
Copy link
Copy Markdown

Summary

Add fetchDeferredAppLink() method to retrieve campaign attribution data from Facebook ad campaigns. This enables better event-to-campaign linking for improved attribution accuracy.

Changes

  • Add fetchDeferredAppLink() method to Dart API
  • Implement iOS handler using AppLinkUtility.fetchDeferredAppLink()
  • Implement Android handler using AppLinkData.fetchDeferredAppLinkData()
  • Fix example project AGP version (8.1.1 → 8.2.1) for Java 21 compatibility

New API

Future<Map<String, dynamic>?> fetchDeferredAppLink()

Usage

final appLink = await facebookAppEvents.fetchDeferredAppLink();
if (appLink != null) {
  final targetUrl = appLink['targetUrl'] as String?;
  final clickTime = appLink['clickTimestamp'] as String?;
  final queryParams = appLink['queryParameters'] as Map<String, String>?;
  // Use campaign data for attribution
}

Important Notes

  • Data is only returned once per app install (subsequent calls return null)
  • On iOS 14.5+, requires ATT authorization and setAdvertiserTracking(enabled: true)
  • Helps Meta link events to Facebook users for better ad attribution

chore: update iOS deployment target to 13.0
chore: update Android Gradle plugin version to 8.2.1
chore: update Podfile.lock to version 0.24.0
@michaeljajou
Copy link
Copy Markdown

So does the current version of this SDK not work for AEM? e.g., events will not be attributed for anyone who denies ATT?

@g-apparence
Copy link
Copy Markdown
Author

So does the current version of this SDK not work for AEM? e.g., events will not be attributed for anyone who denies ATT?

I think yes. At least i've never been able to make it properly work on AEM for my apps

@michaeljajou
Copy link
Copy Markdown

I think you're right, I switched from AppsFlyer to this package yesterday, and my attributions tanked.

We should get this tested and merged

@g-apparence
Copy link
Copy Markdown
Author

I am testing on my own apps. Hope this get merged

@g-apparence
Copy link
Copy Markdown
Author

g-apparence commented Jan 24, 2026

Ok I can say AEM now works
1 day after publishing my app with this fix AEM is now working on my account @michaeljajou

@g-apparence
Copy link
Copy Markdown
Author

ALso migrated to the UIScene delegate to make this work with latest flutter changes
see https://docs.flutter.dev/release/breaking-changes/uiscenedelegate#migration-guide-for-flutter-plugins

@g-apparence
Copy link
Copy Markdown
Author

I took time to investigate on how the RN plugin works
From this I migrated AEM methods to report events to meta.
I think this should fix everything for those running ads using it

@michaeljajou
Copy link
Copy Markdown

Thanks @g-apparence do you have this uploaded elsewhere, would love to use your version until this gets merged

@g-apparence
Copy link
Copy Markdown
Author

@michaeljajou it's here https://github.com/g-apparence/flutter_facebook_app_events/tree/main

But if @DennisAlund don't want to merge this I'll publish this as a copy. (Would prefer not but seems not really active here)

@DennisAlund
Copy link
Copy Markdown
Member

Sorry I missed this one and aplogies for slow replies. I see that it is not addressing any issue that has been reported.

As for your comment

But if @DennisAlund don't want to merge this I'll publish this as a copy. (Would prefer not but seems not really active here)

A good solution while waiting for the official release is that you proceed in your app development with a personal clone of the repo where your fix is implemented. Publishing to the marketplace is not necessary and will likely not be the easiest path forward for you. But I understand the frustration.

@DennisAlund
Copy link
Copy Markdown
Member

Thanks for putting the work into this @g-apparence, I appreciate you digging into the RN SDK to figure out the AEM piece.

I've had a proper look through the changes now and I think there's some good stuff in here, but the scope has grown beyond what this plugin is meant to cover. This plugin wraps the Facebook App Events SDK specifically — event logging, purchase tracking, and the analytics side of things. It's not meant to be a general-purpose Facebook SDK wrapper.

Looking at the individual pieces:

fetchDeferredAppLink() — This is part of Facebook's App Links module (facebook-applinks on Android, AppLinkUtility on iOS), which is a deep linking feature, not event tracking. I'd suggest looking at a dedicated deep linking package for Flutter, or wrapping it in a separate plugin if there's demand for it.

recordAndUpdateAEMEvent() as a public Dart API — Same thing, AEM (FBAEMKit) is a separate module in the Facebook SDK. Exposing it as a standalone method expands the surface of this plugin beyond its purpose.

setDebugEnabled() — This is a generic SDK-level setting, not specific to App Events. Handy for sure, but it belongs in a broader SDK wrapper.

What I do think makes sense is the internal AEM recording you've wired into logEvent() and logPurchase() on iOS. That's not adding new API surface — it's making existing App Events work properly for attribution under iOS 14.5+ ATT. That's a fix, not a feature. I'd be open to taking that part in.

The UIScene lifecycle migration is also something we'll need at some point for Flutter 3.38+ compatibility, so that's useful groundwork.

If you'd be willing to trim this down to just those two things (internal AEM attribution in the existing event methods + UIScene migration), rebase onto current main, and drop the SDK constraint bumps (we still support older Flutter versions), I'd be happy to review that for merge.

For the App Links and standalone AEM pieces I'd suggest combining with other Flutter packages that wrap those parts of the Facebook SDK, or creating a separate plugin for them. Happy to link to it from the README if you do.

@g-apparence
Copy link
Copy Markdown
Author

Hey, thank you for replying.

I think that AEM is now the new attribution standart. And there is no point of using the facebook sdk without it.
fetchDeferredAppLink can be mandatory if you want to improve your server side events.
This allow to send meta which actual ads triggered a purchase and help meta attribution. It's not something you want from another package and I believe all those are required for anyone that want to be serious on running ads.

@michaeljajou
Copy link
Copy Markdown

I second this ^ AEM is the new standard for Meta App Attribution. Tracking is rendered useless without it, and it uses deferred deep linking for app event attribution

@DennisAlund
Copy link
Copy Markdown
Member

I hear you both, and I agree AEM is critical for attribution in the post-ATT world. I'm happy to take the internal AEM recording wired into logEvent() and logPurchase(). That's the part that makes this plugin's existing functionality work properly. Without it, events go out but attribution is broken. That's a fix.

Where we differ is on fetchDeferredAppLink() and recordAndUpdateAEMEvent() as new public APIs. These come from different Facebook SDK modules and there are other flutter plugins that cover that.

I understand the appeal of having it all in one package, but expanding scope like that creates maintenance burden, makes the plugin harder to reason about, and works against the modularity that Meta designed into their SDK.

So I think the way forward is to: trim this to the internal AEM attribution + UIScene migration.

For the App Links piece, I genuinely think a separate plugin is the right home.

@g-apparence
Copy link
Copy Markdown
Author

Facebook split those things for internal logistics.
They have multiple team when we are just a few developers here adding a wrapper around those.

It's not because meta have different packages that we need to split everything.

If you run ads using meta you need all those things together.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants