UDL - deferred deeplink vs deeplink conflicting results - Help please

[kpturner]

Report

Plugin Version

6.13.1

On what Platform are you having the issue?

ios and android

What did you do?

Tested UDL (deferred) compared to UDL (non-deferred)

What did you expect to happen?

Once we had behaviour working properly to capture attribution data in our analytics for a deeplink, we expected the same results for a deferred deeplink - but that was not the case

What happened instead?

Deferred deeplinking did not capture the data as expected, so this post is to describe what happened and seek clarification of expected behavior.

Please provide any other relevant information.

We created a deeplink (a banner) that included media_source and campaign information that we make use of.
We defined a function for the UDL_CALLBACK to extract these values and execute some logic accordingly.

When the app is already installed, clicking the deeplink fires this listener function and we are able to extract the data.

When the app is not installed, clicking the deeplink prompts the user to install the app. The listener fires as expected, but media_source and campaign are not present.

Reading this it says: _Note: For new users, the UDL method only returns parameters relevant to deferred deep linking: deep_link_value and deep_link_sub1-10. If you try to get any other parameters (media_source, campaign, afsub1-5, etc.), they return null. so perhaps what we are seeing is expected. Please confirm?

The implication from the rest of the documentation is that despite the fact that the data being passed to the listener will/might exclude the information we need, we can still obtain it by adding a function to the CONVERSION_CALLBACK listener.

However, although this also fires on a deferred deeplink, the data also does not include media_source or campaign. So is this expected or not? Also, the conversion data states that the status is Organic when it should be Non-organic. It also says is_first_launch=false. Why would that be? Would this happen if the user installed, removed, then re-installed by clicking a (deferred) deeplink?

[github-actions[bot]]

👋 Hi @kpturner and Thank you for reaching out to us. In order for us to provide optimal support, please submit a ticket to our support team at support@appsflyer.com. When submitting the ticket, please specify:

• ✅ your AppsFlyer sign-up (account) email
• ✅ app ID
• ✅ production steps
• ✅ logs
• ✅ code snippets
• ✅ and any additional relevant information.

[kpturner]

Already reported to support (no much of a response yet) https://support.appsflyer.com/hc/en-us/requests/550375

[kpturner]

For anyone with a similar query the following describes the behaviour of deferred deeplinks which I found difficult to glean from the docs alone:

Attribution data is available in the Unified Deep Link (UDL) callback data when the app is already installed and a deeplink is clicked.

Attribution is not available in the UDL data if the app is not installed yet - where the install occurs as a result of clicking the same link. In other words, a "deferred" deep link.

However, this is where the behaviour diverges depending on whether the install is deemed to be Organic or Non-organic.

A Non-organic install is one where the app has been installed on a device for the very first time using a deferred deeplink. In this situation, then the attribution data becomes available on the conversion callback data (onConversionDataSuccess).

An Organic install is one that occurs when the user simply goes to the store and installs the app of their own volition OR reinstalls it by clicking a deeplink. In this situation no attribution data is available. When testing, you cannot easily test deferred deeplink attribution data collection unless you can do so on a device or emulator that has not previously installed the app.

A Onelink template can, in addition to attribution data, include special deeplink values called deep_link_value and deep_link_sub1 through to deep_link_sub10.

These values are available on the UDL callback regardless of the type of install. They may be passed as querystring parameters or built in to the template.

The only remaining query is that the conversion data has a flag called is_first_install which seems to be true whether it is a first install or not.