Closed Bug 1208240 Opened 4 years ago Closed 4 years ago
Move the Adjust initialization to Browser
App and observe FHR opt-out
Currently, the Adjust initialization happens in GeckoApplication, which is triggered for background services as well as Firefox. We have people looking at retention data from Adjust and this means we are over-counting. We should also make Adjust observe the FHR opt-out policy.
Attachment #8665658 - Flags: review?(nalexander)
Comment on attachment 8665658 [details] [diff] [review] move-adjust-oncreate v0.1 Review of attachment 8665658 [details] [diff] [review]: ----------------------------------------------------------------- Patch is fine. I don't understand your assertion about double-counting, but I expect it's semantics. We are counting "App starts" as Android defines them and not what users or marketers consider "uses". It's extremely unlikely that we are double-counting an individual such "App start". If we are double-counting *devices* that do phone home, that's a problem with Adjust's device identifier; but I'm not sure how we would even identify such an issue. Now, if we are using "App starts" as a proxy for "uses", then yes, we are double-counting. But we're "double-counting" a nonsense result to a badly posed question.
Attachment #8665658 - Flags: review?(nalexander) → review+
Actually, mfinkle: I don't think this is fine. You're moving from "once in Application.onCreate" to every-time the Fennec Activity is instantiated. That could be a lot more frequently than what we think of as a "use". For example, if you have Don't Keep Activities, going back and forth between Fennec and Settings will result in a huge number of "uses". I counter: we should consider always sending the Application.onCreate (to track installs), but only after the FHR opt-out is resolved in favour of data reporting; and then we should collect Adjust events for things about the Activity life-cycle that we care about. If you're convinced that "BrowserApp.onCreate" is a good enough proxy for the one thing you want, then roll on.
It's worth giving more context: I'm not worried about "double-counting", but "over-counting". Imagine this scenario: 1. A person installs Fennec and launches it. 2. The person sets up Sync. 3. The person uses Fennec two days a week. Adjust pings can be used to create "retention" data. We are over-counting right now because Adjust counts Sync launches as usage which probably happen every day, but the person really only used Fennec two days. Adjust does not double-count per-day pings. Once a day is all that is really counted. More than once a day is not an issue. Lastly, We know that it's impossible to opt-out of FHR/Adjust to skip the initial install tracking ping. That's fine since install tracking is the real value to Marketing. But we want to allow people to opt-out of sending pings after install.
Comment on attachment 8665658 [details] [diff] [review] move-adjust-oncreate v0.1 Approval Request Comment [Feature/regressing bug #]: bug 1207314 (initial landing) [User impact if declined]: This patch provides better user privacy support via opt-out, and better retention metrics for Growth and Marketing. It would be great to have this in Fx42 for the November release. [Describe test coverage new/current, TreeHerder]: This has been on Nightly for a while. No regressions noticed. [Risks and why]: Low risk, just moved the existing code to a different initialization point. [String/UUID change made/needed]: None
Comment on attachment 8665658 [details] [diff] [review] move-adjust-oncreate v0.1 Improve privacy, taking it. Should be in 42 beta 8.
landed on aurora as https://hg.mozilla.org/releases/mozilla-aurora/rev/292719e5e24b - setting flags for mark
this cause problems during uplift to beta grafting 303779:3df7e101b38d "Bug 1208240 - Move the Adjust initialization to BrowserApp and observe FHR opt-out r=nalexander" merging mobile/android/base/BrowserApp.java warning: conflicts during merge. merging mobile/android/base/BrowserApp.java incomplete! mark, could you take a look? thanks !
You need to log in before you can comment on or make changes to this bug.