Mobile App Acquisition - race condition in Android

[christa_mabee]

I've implemented Mobile App Acquisition as instructed here: https://marketing.adobe.com/resources/help/en_US/mobile/android/acquisition.html 

I've run into the situation where sometimes the InstallEvent request fails to pick up any of the campaign information. It is always coming through, this is apparent because I save that info when the INSTALL_REFERRER Intent is received and then add it to a custom tracking even that happens later. Instead those attributes get automatically tacked on to whatever request happens next (usually a track page) and then not processed by the server. Taking my device and repeatedly clicking on the link, installing, opening, and uninstalling the app shows that the InstallEvent request fails to pick up that campaign info about a quarter of the time. That's a lot of misattributed clicks, so I'm very interested in some way to prevent this. 

[jared_butterfie]

Hi Christa,

I would double check the value of referrerTimeout in your config file, as you can see in step 4 of https://marketing.adobe.com/resources/help/en_US/mobile/android/acquisition.html.

That value is the number of seconds the SDK will wait prior to sending any lifecycle hits while it retrieves the campaign information. If the value is 5 (the default), you could try increasing it to give the app more time to retrieve the campaign info.

Jared Butterfield
Mobile Engineer
Adobe Marketing Cloud
 

[christa_mabee]

Given that our problem is a race condition where other tracking gets sent before the acquisition hit and thus absorbs the campaign data (why does that happen?) I don't think waiting even longer to send the acquisition hit would make the problem less frequent.

The information is definitely present and in the intent provided to Analytics.processReferrer(). 

[hpeterso]

Hi Christa,

referrerTimeout is the amount of time we will hold off sending hits to wait for referrer data. Increasing this value will enable our library to wait longer before sending that initial install hit in order to get and append the referrer data to this hit instead of going into a subsequent hit.

Hunter Peterson

Sr. Mobile Engineer

Adobe Marketing Cloud

[christa_mabee]

Hi Hunter, thanks for looking at this. 

My concern is that the longer that timeout is the more likely it is that another tracking event will occur before that lifecycle hit gets sent. That's why I'm calling it a race condition. There is no way (that I can find) to detect when that InstallEvent hit was sent, I can track when the app reaches Analytics.processReferrer() but that returns void immediately. There's no indication that it's now safe to start sending other tracking events. If it went out to the network immediately, we're fine, but if for some reason it got delayed then my app just starts tracking as per normal and sends out something, which absorbs the utm_campaign etc values, which screws up tracking because then the InstallEvent hit doesn't seem to get them. 

If there is some way to tell whether it was safe to start tracking I could work around this, or if the other tracking events could be prevented from absorbing those variables then it would be safe to increase the timeout without losing the referrer data to a faster request. 

That being said, I'm totally willing to try that again. In your experience, what's a good timeout value to use? I've tried 1, 5, and 60, with varyingly poor results. 

[hpeterso]

Christa,

Im sorry I have been going on the assumption that you are configured for offline tracking (in your ADBMobileConfig.json - "offlineEnabled" : true) is this the case? If so, the below information is how it is handled. 

When this timeout is set we automatically handle when to send subsequent track calls. Meaning if your timeout is 10, we will queue all hits until either the referrer data is collected or the 10 seconds passes. You should not need to control or handle when to call track calls based off of referrer.

Hunter Peterson
Sr. Mobile Engineer
Adobe Marketing Cloud

[christa_mabee]

Using offlineEnabled plus a timeout of 10 didn't help, but that plus a timeout of 60 did. 

Unfortunately, due to the need to continue tracking un-upgraded versions of the app, we can't turn on offline tracking on the report suite. Apparently that'd cause the server to drop all of those tracking requests, since they don't include a timestamp. So... I shall continue to dig. 

Edit: actually, would it hurt anything to enable offline tracking in the app but not on the server? 

[christa_mabee]

Aha! No, offlineEnabled is false. I'll give that a shot. 

[hpeterso · Accepted solution]

Christa,

Unfortunately if you would like to configure your report suite for offline tracking there is a bit more to it than just changing that value. While is a simple thing to change in the sdk, but you will need to contact client care and have them configure your report suite to have timestamping enabled (hits with timestamps will not be processed into our system unless this is configured). 

For your current configuration, I would not set this timeout to anything over 30 seconds. Please try to set it to 30 and see if this solves the issue you are seeing.

Hunter Peterson
Sr. Mobile Engineer
Adobe Marketing Cloud