Differences between the iOS and Android Reading list flows

1 tap save vs. saving into a reading list

iOS

• On iOS users can tap on the 'save for later' icon to save an article into their default list
• On iOS after saving an article, a hint is shown asking users if they would like to save their article into a reading list

Android

• On Android users must select a reading list to save an article into

Default reading list (aka. Saved)

iOS

• All articles that are saved and unsorted are saved into the default (Saved) list
• On iOS the default reading list is hidden by default, but can be turned on by the user in Settings

Android

• On Android the default reading list cannot be hidden by the user

Saved tab

iOS

• On iOS the Saved tab is segmented, with a view for 'All articles' and 'Reading lists'

Thanks @cmadeo ! This is very helpful!!! :)

Some of these differences may affect how we log the events. I will update this ticket after discussing with other analysts.

@chelsyx and I had a chat about this and came up with a possible solution that would work with a minor modification to the existing Reading Lists schema, and confirmed with @Dbrant that we can do it on Android no problem too. Specifically, there would be a new event action addtodefault:

In T190748#4089869, @cmadeo wrote:

Differences between the iOS and Android Reading list flows

1 tap save vs. saving into a reading list

iOS

• On iOS users can tap on the 'save for later' icon to save an article into their default list
• On iOS after saving an article, a hint is shown asking users if they would like to save their article into a reading list

If that hint disappears before the user taps on it and the article is saved into the (hidden by default) Saved list, the app would send a addtodefault event. If the user taps the hint, there would be addtoexisting or addtonew events depending on what the user does. Unlike Android, there would not be an addclick event.

Android

• On Android users must select a reading list to save an article into

After the addclick event, if the user selects the (always visible) Saved list to add the article to, the app would send a addtodefault event. The app would only send addtoexisting events for existing lists that are not the default Saved list.

Default reading list (aka. Saved)

iOS

• All articles that are saved and unsorted are saved into the default (Saved) list
• On iOS the default reading list is hidden by default, but can be turned on by the user in Settings

Android

• On Android the default reading list cannot be hidden by the user

Chelsy and I agreed that if toggling the visibility of the default (Saved) list is something that needs to be tracked, it should be in a separate schema/funnel that tracks changes to preferences/settings.

Hi @NHarateh_WMF , great work! Thanks so much!

I'm testing the events and here are some issues I found so far:

1, For event_dt, can we have the timestamp in the user's time zone? Example: https://phabricator.wikimedia.org/T186768#4044717
2, Session ID in MobileWikiAppiOSUserHistory for the initial snapshot (first snapshot after download/update) is different from session ID in other EL tables in this first session
3, In our testing beta cluster, duplicated events appear in the table. I just want to confirm with you that we're not sending the same event twice. I will check with AE to see if this is a problem in their backend.

@NHarateh_WMF several other bugs:

1, For the measure variable, we want to save it as double (type=number in the schema), even if it is actually an integer. So measure=1 should be measure=1.0.
2, When a session is very short, say a few seconds, the units of session length (the measure field with action session_end) is milliseconds. However, when the session is longer (a few minutes), the units becomes seconds.
3, When saving the main page in the feed through preview, label=NULL. Is this intentional?
4, When I save through the share option (share icon -> Add to reading list), save events didn't get logged
5, In article view, 3d press on a blue link and then save from preview, label=default currently, and it should be changed to label=out_link;
6, In article view, when I 3d press on read more article and then save from preview, label=default currently, should be changed to label=read_more
7, In article view, when I tap on similar page, then save an article in the list, category=feed; label=NULL currently, should be changed to category=article; label=similar_page
8, The field wiki should be based on the wiki of the article affected. It seems to be based on previous actions in the session currently. Example: From the list of English top read, I tap on search to search in Chinese, then I cancel the search and come back to the English top read, save an article from the list. At this time, wiki=zhwiki in the event, which should be enwiki. And then I come back to the feed/places and save other articles, wiki is still zhwiki.
9, When I open a non-default reading list and remove items from this list, unsave event should not be sent because I only remove the items from this list, but they are still in my default list or other list.
10, When I tap on "Logged in as XXX" in settings to logout, then cancel logout at the popover, the logout event is sent before I confirm to logout.
11, If the user doesn't opt in to send reports during onboarding and opts in in Settings later, we want to send the snapshot when they opt in in Settings.
12, measure_readinglist_itemcount in MobileWikiAppiOSUserHistory table is the sum of item counts in all lists. However, since an article can be saved to multiple lists, this number should be the counts of unique saved articles.

@chelsyx

2. When a session is very short, say a few seconds, the units of session length (the measure field with action session_end) is milliseconds. However, when the session is longer (a few minutes), the units > becomes seconds.

The built-in method we're using to calculate elapsed time is supposed to always return time in seconds - what's the number you were getting for short sessions? I've been seeing 1.xxx, 2.xxx etc

8, The field wiki should be based on the wiki of the article affected. It seems to be based on previous actions in the session currently. Example: From the list of English top read, I tap on search to search in > Chinese, then I cancel the search and come back to the English top read, save an article from the list. At this time, wiki=zhwiki in the event, which should be enwiki. And then I come back to the feed/places and save other articles, wiki is still zhwiki.

We're doing this because the capsule (https://meta.wikimedia.org/wiki/Schema:EventCapsule) requires wiki and for some funnels (for example, Login) we don't have access to the wiki of the article affected

The built-in method we're using to calculate elapsed time is supposed to always return time in seconds - what's the number you were getting for short sessions? I've been seeing 1.xxx, 2.xxx etc

@NHarateh_WMF I can't reproduce the bug neither... Never mind, I guess it was just my mistake :P

We're doing this because the capsule (https://meta.wikimedia.org/wiki/Schema:EventCapsule) requires wiki and for some funnels (for example, Login) we don't have access to the wiki of the article affected

For funnels that don't have an associated article, can we use the user's default wiki? By default wiki, I mean the wiki from which the users' feed come -- I guess it's based on user's primary language, right?

For funnels that don't have an associated article, can we use the user's default wiki? By default wiki, I mean the wiki from which the users' feed come -- I guess it's based on user's primary language, right?

Yup, that's the primary language! So we'll use the affected article's wiki if applicable and fall back on user's primary language (the one used by the feed) otherwise

In T190748#4222997, @NHarateh_WMF wrote:

Yup, that's the primary language! So we'll use the affected article's wiki if applicable and fall back on user's primary language (the one used by the feed) otherwise

@NHarateh_WMF I think this is correct with one exception: for the search funnel, the wiki for all search events depends on which language they are search in, regardless users' primary language. For example, my primary language is English, when I search on English Wikipedia, all search events sent to MobileWikiAppSearch should be enwiki; but when I search on Chinese Wikipedia, all search events sent to MobileWikiAppSearch should be zhwiki.

@NHarateh_WMF Thanks for the great work! I was testing followup/T190748 and here're some followup for the followup :P

4, When I save through the share option (share icon -> Add to reading list), save events didn't get logged

I know you have fixed it when we tap share icon -> 'Add to reading list' on an article view. It would be great if you can add the same event when we tap share icon -> 'Add to reading list' on the map, the top-read list, the search result, the history, etc.

6, In article view, when I 3d press on read more article and then save from preview, label=default currently, should be changed to label=read_more

Looks like you're still working on this one. :)

8, The field wiki should be based on the wiki of the article affected. It seems to be based on previous actions in the session currently. Example: From the list of English top read, I tap on search to search in Chinese, then I cancel the search and come back to the English top read, save an article from the list. At this time, wiki=zhwiki in the event, which should be enwiki. And then I come back to the feed/places and save other articles, wiki is still zhwiki.

As mentioned in T190748#4223647, there is one exception: for the search funnel, the wiki for all search events depends on which language they are search in, regardless users' primary language.

9, When I open a non-default reading list and remove items from this list, unsave event should not be sent because I only remove the items from this list, but they are still in my default list or other list.

Sorry I mess up with this one -- I didn't think about the situation when users turned on "Show Saved reading list":
I turned on "Show Saved reading list" from settings. If I have an article A in both the default list and non-default list, when I open the default list under the 'Saved' tab 'Reading lists' column and remove article A, I will only remove it from the default list, but it is still saved in my non-default list. Now article A is ONLY saved in a non-default list, removing it from the non-default list would unsave it.
Can we send the 'unsave' event when an article is removed from all the lists? i.e. we're no longer to be able to see it under the 'Saved' tab 'All articles' column.

12, measure_readinglist_itemcount in MobileWikiAppiOSUserHistory table is the sum of item counts in all lists. However, since an article can be saved to multiple lists, this number should be the counts of unique saved articles.

Looks like measure_readinglist_itemcount is the count in the default list. Considering the situation described previously, we want it to be the count under the 'Saved' tab 'All articles' column.

Looks like measure_readinglist_itemcount is the count in the default list. Considering the situation described previously, we want it to be the count under the 'Saved' tab 'All articles' column.

the default list is the same as the 'All articles' column under the 'Saved' tab

I know you have fixed it when we tap share icon -> 'Add to reading list' on an article view. It > would be great if you can add the same event when we tap share icon -> 'Add to reading > list' on the map, the top-read list, the search result, the history, etc.

What about adding to list via share sheet in Saved/default list and reading list detail view? Do you want to log that?

@NHarateh_WMF

What about adding to list via share sheet in Saved/default list and reading list detail view? Do you want to log that?

No, because when we "add to reading list" in Saved/default list and reading list detail view, we didn't save new articles -- we only add an article from one reading list to another reading list.

3, In our testing beta cluster, duplicated events appear in the table. I just want to confirm with you that we're not sending the same event twice. I will check with AE to see if this is a problem in their backend.

@chelsyx are you seeing duplicate events being logged as you're testing or are they just duplicate events in the db? I'm sure I logged some duplicate events when I was developing but no event should be logged twice now, I'll double check

Also, do you want the timestamp to be localized for all schemas or only the new ones?

In T190748#4226138, @NHarateh_WMF wrote:

3, In our testing beta cluster, duplicated events appear in the table. I just want to confirm with you that we're not sending the same event twice. I will check with AE to see if this is a problem in their backend.

@chelsyx are you seeing duplicate events being logged as you're testing or are they just duplicate events in the db? I'm sure I logged some duplicate events when I was developing but no event should be logged twice now, I'll double check

@NHarateh_WMF I saw duplicate events in the db at times, probably because I was testing on your unmerged branch that still under development.