Google Analytics attribution params not being recorded in dynamic_link_first_open event

[damienix]

• Xcode version: 10.1
• Firebase SDK version: 5.16.0
• Firebase Component: Dynamic Links
• Component version: 5.16.0/3.4

Steps to reproduce:

Hi, I'm struggling to get iOS attribution via dynamic links working on iOS. I'm using dynamic links where I set the UTM parameters. On Android, this is working as I'd expect. When a user installs the app (on mobile) from a dynamic link, their future analytics event contain campaign params. I can confirm this by capturing these events:

campaign, source and medium are recorded in dynamic_link_first_open, but they are also recorded (without extra data) in the next event (not set). I'm not sure which actually sets the attribution params for the user, can you tell me that?

On iOS after opening the link, and then installing the app I get no UTM parameters included in the event, there's also no (not set) event. As said before, I suspect that one of these events sets the attribution, but I haven't found any information on which, please confirm.

I found that on iOS dynamic_link_first_open or dynamic_link_app_open (doesn't matter which as it's handled by the same code) will report campaign parameters when opened when the app is already installed. AFAIU in that case the app receives the params via a deep link and is handled by different code. Also, this is counted properly in the Conversions tab.

I found that UTM params are lost when the links (obtained from clipboard) are processed by FIRPostInstallAttributionCompletionHandler which then only passes FIRDynamicLink for further processing, and this class doesn't contain UTM data. Old params are replaced by match_type and match_message only.

https://github.com/firebase/firebase-ios-sdk/blob/master/Firebase/DynamicLinks/FIRDLDefaultRetrievalProcessV2.m#L127-L155

I was testing this on https://github.com/firebase/quickstart-ios/tree/master/dynamiclinks/DynamicLinksExample

Relevant Code:

I've prepared the PR #2461 with the code that seems to fix the problem for me i.e. with this change I see UTM parameters properly reported in dynamic_link_first_open event the same as I see them on Android plus extra (not set) event the UTM params, though I haven't debugged where (not set) event is fired and why :) I assume the will save the attribution for a particular user.

Let me know if you have any questions, TBH I still hope that maybe I did something wrong, if not then I can't imagine how no one had been complaining about this for months... 😦 Is this possible? 😉

Damian

[google-oss-bot]

I found a few problems with this issue:

• I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
• This issue does not seem to follow the issue template. Make sure you provide all the required information.

[damienix]

I see that newer issues are being answered by humans, so just wondering if I missed something during the creation of this issue. Or maybe things just are taking longer in this case...

Cheers,
Damian

[paulb777]

@damienix Thanks for the thorough issue investigation and description.

Yes, issues are answered based on a combination of domain knowledge and availability. I'll see if we can make some progress on this one soon.

[damienix]

Great, thanks!

[maksymmalyhin]

@damienix Thank you for so detailed information.
It looks like there is an issue with the parameters and your proposed fix looks relevant. I am going to slightly modify it to make sure all parameters are passed and processed by the application.

[paulb777]

Fixed in #2478

[b-onc]

@paulb777 Hello,
We had a problem where using branch.io links, consecutive app opens did not report any utm parameters. (facebook persists this data). We overcame this by persisting the data ourselves and re-reporting it on app start.

Now that we've came across this issue, we wonder if they're the same & that is fixed. We're trying to test but could not find a way. We report AnalyticsEventCampaignDetails when a branch.io link is used to open/install. DebugView only shows (not set) event with the correct parameters, but does not include the parameters for any other event. How can we test that Firebase persists these data?

[damienix]

@b-onc I second your question, about what makes Firebase remember UTM campaign for a particular user. Which event does it?

Meanwhile, to my understanding, technically these params are stored in some internal place and attach to subsequent events as campaign parameters. Though I think there's some magic happening to set them as in the live BigQuery export of the events (intraday table) there are no campaign params. They're only saved after closing the day and closing the table of the day.

So I believe there's no better way of testing than making sure the campaign params are logged in the event (we still don't know which event but probably link_open or (not set) one) plus checking campaign params in BigQuery/Firebase reports the next day (or a few hours later for reports).

P.S. I find this article showing how complicated and "magic" attributing really is https://support.google.com/firebase/answer/6317518?hl=en

[b-onc]

@damienix

So I believe there's no better way of testing than making sure the campaign params are logged in the event (we still don't know which event but probably link_open or (not set) one) plus checking campaign params in BigQuery/Firebase reports the next day (or a few hours later for reports).

Exactly, but the (not set) event is not reported for consecutive launches. I wish DebugView showed the parameters in consecutive events (medium at least) so we could be sure.

[maksymmalyhin]

@b-onc Let me clarify the issue you have.

The app behaviour:

1. When the application is launched with the link, then proper UTM campaign parameters are passed into application and you can see an event including those parameters in DebugView
2. When your application is started by a user (no link was used) then no UTM campaign parameters are passed to the app and no events with UTM campaign parameters can be found in DebugView

Please let me know if this is not precise.

What you would like to know:

1. If UTM parameters were correctly registered
2. Anything else?

[b-onc]

@maksymmalyhin Sorry for the late response.

When the application is simulated as launched via a link (by tracking utm parameters with AnalyticsEventCampaignDetails), we see a (not set) event including our utm parameters. Consecutive events in the same session do no have the utm parameters set.

Consecutive normal launches (no link simulation, no utm tracking code) do not have this (not set) event and events do not have the utm parameters.

We want to know if UTM parameters were correctly registered and they persist between launches. We worked around this before by persisting the paramters by ourselves and tracking AnalyticsEventCampaignDetails every time the app is launched. We want to know if this bug solves our issue too so we can remove that custom code that persists/re-tracks the utm params.

[maksymmalyhin]

@b-onc no problem.
The current ticket doesn't change behaviour in your case. Would you be able to create a separate ticket, please?

[damienix]

I'll refer once more to the documentation: https://support.google.com/firebase/answer/6317518?hl=en

Attribution windows

The attribution window for first_open conversion events is 30 days.

Once a first_open conversion event is attributed to a campaign, then all other conversion events for that same combination of user and app are attributed to that same campaign until the attribution window expires in 1 year. The attribution window is renewed for 1 year with each subsequent conversion that occurs before expiration.

The attribution window for a re-engagement campaign is 6 months.

So @b-onc attribution seems to be based on time-based windows rather than logging the event every app open. This has also been working for me for past few months. What is totally not clear to me is which window applies to opening dynamic links: 30 days, 0.5y or 1 year.

Any chance that some of the Firebasers explains that in more datail?