[Reader IA] Add number of followed sites and tags to Reader analytics events

[RenanLukas]

We should add the number of followed sites and tags to Reader analytics events where it makes sense. This should be aligned with iOS so we use the same keys and values.

[thomashorta]

@RenanLukas, on my last 1:1 with @develric we discussed sending new events for followed sites and followed tags count by hooking directly into the EventBus observers in the Subscription feed (here).

We didn't discuss what the event details but I was thinking something like:

Event name: reader_following_fetched Properties:

• type (String): either blogs or tags.
• count (int): number of following blogs or tags (depending on type).

This could be at least a first step into getting this number into our analytics without adding extra fetches on screens that don't use that information on the UI, avoiding data consumption and possible performance issues, while tracking the most up-to-date information.

The caveat is that we would get those events only on the "Subscriptions" feed and we will likely track it multiple times, as we fetch that data on refresh and other situations (though there could be some logic to only track when the data is different from the last tracked event or something).

What do you think?

[RenanLukas]

Hey @thomashorta 👋

As discussed in DM yes, this also makes sense to me as a first step.

though there could be some logic to only track when the data is different from the last tracked event or something

💯

[daniloercoli]

Related to https://github.com/wordpress-mobile/WordPress-Android/issues/19907

[daniloercoli]

Rather than incorporating new information into a single event, we could add it to the user_property and refresh metadata either when the Reader is accessed or when the app is launched. By utilizing metadata, this information would be included in every event sent from the app.

See refreshMetadata

[thomashorta]

Rather than incorporating new information into a single event, we could add it to the user_property and refresh metadata either when the Reader is accessed or when the app is launched. By utilizing metadata, this information would be included in every event sent from the app.

That makes sense, though bear in mind this means that events sent before we fetch the information will be different from events after the fetch, even in the session since we only fetch that data in the Reader Subscriptions feed currently. So it could get difficult to interpret the data in situations like:

• Before user ever uses Reader->Subscriptions (all events will be sending the information of 0 subscriptions)
• Every time the user subscribes to blogs and tags from other platforms (we only update if they open Subscriptions feed)

The workaround would be fetching that outside the Reader, on App Start or something, but it's extra information that's not exactly needed for the user and could block the flow (if we want to be 100% sure the data is updated before any events).

But I agree that would be more desirable in the long run. The comment above (https://github.com/wordpress-mobile/WordPress-Android/issues/19836#issuecomment-1906152787) is a suggestion for a temporary solution that will provide reliable and up-to-date subscriber information for users that access the feeds that load such information, with the caveat that will not trigger at all for users that don't use the Subscription feed/Reader.

Maybe it would make sense to make it a different GH issue, for clarity?