-
Notifications
You must be signed in to change notification settings - Fork 57
Capture first launch deep link for product page attribution #491
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -18,5 +18,5 @@ let sdkVersion = """ | |
| */ | ||
|
|
||
| let sdkVersion = """ | ||
| 4.16.2 | ||
| 4.16.3 | ||
| """ | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -1050,6 +1050,11 @@ public final class Superwall: NSObject, ObservableObject { | |
| /// - **`deepLink_open` trigger**: Any deep link can trigger a paywall if you've configured | ||
| /// a `deepLink_open` trigger in your Superwall dashboard. | ||
| /// | ||
| /// The first deep link received during the first app session after install is | ||
| /// also saved as the `firstDeepLinkUrl` user attribute. If you assign deep links | ||
| /// to your App Store custom product pages, you can use this attribute to break | ||
| /// down results and filter audiences by the product page that drove the install. | ||
| /// | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ℹ️ The static |
||
| /// This method is designed to work in a handler chain pattern where multiple handlers | ||
| /// process deep links. It returns `true` only for URLs that Superwall will handle, | ||
| /// allowing other handlers to process non-Superwall URLs. | ||
|
|
@@ -1111,6 +1116,11 @@ public final class Superwall: NSObject, ObservableObject { | |
| // logout after that would otherwise leave the new user without attributes. | ||
| dependencyContainer.mmpAttributionManager.reapplyCachedAcquisitionAttributes() | ||
|
|
||
| // The first-session deep link is install-scoped too. Re-apply it so the | ||
| // new user keeps the `firstDeepLinkUrl` attribute used for product page | ||
| // attribution. | ||
| dependencyContainer.deepLinkRouter.reapplyFirstSessionDeepLinkAttribute() | ||
|
|
||
| dependencyContainer.paywallManager.resetCache() | ||
| presentationItems.reset() | ||
| Task { | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
queue.syncis used to atomically check-and-write, which is correct. However, once the URL is stored (get()returns non-nil), every subsequent deep link during the first session still enters the sync block and performs acache.read()disk read before returningfalse. The existing pattern for similar flags (e.g.,_didTrackFirstSeen,_didTrackFirstSession) keeps an in-memory shadow variable that eliminates the disk round-trip on hot paths. Adding aprivate var _didRecordFirstSessionDeepLink = false(initialized fromcache.read(FirstSessionDeepLinkURL.self) != nilininit, and set totrueafter the first successful write) would make all subsequent calls a pure in-memory check with no disk I/O.Prompt To Fix With AI
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!