- Mark as New
- Follow
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report
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.
Views
Replies
Total Likes