Mobile App Acquisition - race condition in Android

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
 

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(). 

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

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. 

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

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? 

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