Page MenuHomePhabricator

Estimate level of effort for adoption of EventLogging for Reading Lists via app analytics layer
Closed, ResolvedPublic

Description

This is an engineering research ticket. At the end the iOS dev team should know:

  • The current state of the App Analytics layer initiiated last year
  • The work required to ensure app Id generation is fixed and works as requested
  • The rough level of effort to implement event logging calls as defined by @chelsyx for this feature (T192819)

Related bug: T189356, T189359, T192520

Event Timeline

JMinor created this task.Apr 24 2018, 5:35 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 24 2018, 5:35 PM
chelsyx updated the task description. (Show Details)Apr 24 2018, 5:57 PM
chelsyx updated the task description. (Show Details)Apr 24 2018, 6:05 PM
NHarateh_WMF added a comment.EditedApr 26 2018, 4:05 PM

The work required to ensure app Id generation is fixed and works as requested

I would say this would take max 1/1.5 day of work. With the new analytics layer, all event logging happens via postEvents(_ eventRecords: [EventRecord]) (https://github.com/wikimedia/wikipedia-ios/blob/2cdbb090b4d492bb3f0300bdbb3853ac93cdd5db/WMF%20Framework/EventLoggingService.swift#L319). We would have to make sure that we send the appInstallID that matches that of WMFDailyStatsLoggingFunnel. I can think of a few different solutions. The estimate of max 1/1.5 applies to all of them.

The problem with the current event logging is that, as noted by @chelsyx, we are generating two different appInstallID. One is generated by WMFDailyStatsLoggingFunnel, and the other one is generated by ReadingActionFunnel. If we wanted to use the current event solution, we could delete ReadingActionFunnel (as far as I can tell, all it does is generate the other appInstallID) and send the appInstallID of WMFDailyStatsLoggingFunnel.

If we wanted to use the current event solution, we could delete ReadingActionFunnel (as far as I can tell, all it does is generate the other appInstallID) and send the appInstallID of WMFDailyStatsLoggingFunnel.

Thanks @NHarateh_WMF ! I think this would resolve the bug T189356.

Did you have any chance to look at T189359 ? This one may or may not related to appInstallID, but we will need to get it fixed because we need MobileWikiAppDailyStats to answer any questions about daily active users.

NHarateh_WMF added a subscriber: Fjalapeno.EditedApr 27 2018, 4:30 PM

To sum up:

  • The current state of the App Analytics layer initiiated last year

The new analytics layer is straightforward and easy to use. Right now, we can easily turn it on and off by setting an environment variable (WMF_IS_NEW_EVENT_LOGGING_ENABLED).
I'm still waiting for access to the test data store to test logging events (T193202).

  • The work required to ensure app Id generation is fixed and works as requested

This appears to be a simple change that should take max 1/1.5 day of work (more testing than actual implementation). The comment above (https://phabricator.wikimedia.org/T192941#) explains it in more detail.*

  • The rough level of effort to implement event logging calls as defined by @chelsyx for this feature (T192819)

I would say it's roughly up to 2 weeks of work. Looking through Chelsy's spec, I can't see anything that stands out as particularly difficult to implement.

Per standup, the generation of multiple ids is something I would consider a
bug, as it varies from Android's implementation and the analysts
purpose/understanding of that field. Basically, whatever Android is doing
should be considered the acceptance criteria for iOS.

JMinor awarded a token.May 8 2018, 2:48 AM

Thanks! Excited to get this rolling...

JMinor closed this task as Resolved.Aug 28 2018, 1:12 AM