Page MenuHomePhabricator

Spike Investigate impression event data sent from iOS app to `app_donor_experience`
Open, MediumPublicSpike

Description

Spike Questions

  • Are the numbers we have from last year over-inflated?
    • Are the queries querying the wrong thing?
    • Were the events emitted in a different way?
  • Are the numbers have from this year under-inflated?
    • Are the queries wrong?
    • Are the events emitted in a different way?
    • Are they being emitted correctly?

Goal

  • Is it possible to have confidence in the parity of both the events emitted and our ability to query them?

Background from Shay
Event counts we are questioning:
active_interface = article_banner
action = impression
action_data: campaign_id
platform = ios

in schema app_donor_experience

It looks as if some of these events are firing and tracking successfully, but not all. Banner impression events need to be triggered for all users, all appearances. See: Apps Donor Experience Instrumentation Documentation

image.png (1×786 px, 194 KB)

When looking at event counts for impression events we saw a significant reduction in events when compared to EN campaign impressions from last year's data. We had implemented measuring impression events in app_donor_experience to replace the deprecated MobileWikiAppiOSFeed. Because of changes to announcement we want to verify that data is being sent properly, though this may also very likely be an issue with user data sharing/increased Apple Privacy restrictions.

I looked at DAUs and events recorded in other schemas (app_session, ios_navigation_events) and saw similarly low event/unique users counts. Additionally looked at user app version distribution for app_donor_experience EN impression events (result was 75.4% version 7.4.5.2871 and 24.4% version 7.4.6.2972). Investigative data

iOS Banner impression counts used to come from MobileWikiAppiOSFeed, which is deprecated. The query used by us and FR Tech to get impression counts when MobileWikiAppiOSFeed schema was still active was as follows:

SELECT				
year,				
month,				
day,				
COUNT(*) AS event_count				
FROM event.MobileWikiAppiOSFeed				
WHERE year = 2022				
AND ( ( month = 11 AND day = 29 ) OR ( month = 11 AND day = 30 ) OR month = 12 )				
AND event.action = 'impression'				
AND ( event.label = 'announcement' OR event.label = 'article_announcement' )
  • On my end I will be investigating app uniques using web request image loading events to get an approximate distribution of app DAU uniques by opt-in/opt-out based on uniques in 'wmfuuid' in x_analytics_map web request data. Thsi will give us an idea of scale for uniques we may be missing with app_session daus. This data will also be helpful to have for when we remove sharing opt-in/opt-out to see effect of change for our data accessibility.

Event Timeline

SNowick_WMF renamed this task from Investigate impression event data sent from iOS app to `app_donor_experience` to Spike Investigate impression event data sent from iOS app to `app_donor_experience`.Jan 30 2024, 5:12 PM
Restricted Application changed the subtype of this task from "Task" to "Spike". · View Herald TranscriptJan 30 2024, 5:16 PM

Note: We should also look and see if the release after NL/IT campaigns (which opened up the new donor experience for EN users) didn't mess anything up.

https://github.com/wikimedia/wikipedia-ios/commit/850f72744a7592c2bc7a73c6985c813f1d1e95b6

HNordeenWMF raised the priority of this task from Low to Medium.Apr 11 2024, 6:55 PM
SNowick_WMF updated the task description. (Show Details)
SNowick_WMF added a subscriber: HNordeenWMF.
JTannerWMF moved this task from Needs Triage to Up next on the Wikipedia-iOS-App-Backlog board.

We'll pick this up after image recommendations

@SNowick_WMF

Are the numbers we have from last year over-inflated?

Maybe slightly. event.label = 'announcement' means the user saw the campaign in an Explore feed card, which logged impressions whenever the card was scrolled into view. This would result in many more impression counts than a modal on an article. That being said, these were for very old app versions (if they aren't let me know!), so I would expect those to be a very small set of inflated numbers. A more apples-to-apples query would be to remove this part and only use event.label = 'article_announcement'.

Besides that, the article_announcement impression event is logged in pretty much the same spot, so I would expect numbers to be close. I have a few guesses on what could be different:

1.
Starting in the 2023 campaigns, we are using the device country code (Settings > General > Language & Region > Region) as opposed to the Geo-IP country code for determining campaigns. Maybe this code sometimes doesn't match up with the campaign's country code. @SNowick_WMF Did we see impressions from all Big English countries? If possible, can you tell if all countries were lower than last year, or just one?

2.
The design changed. While we do have a "Maybe later" option which should increase impressions, we also have an additional dismissal button (Close button + I already donated).

Old:

Screenshot 2023-11-28 at 4.27.01 PM.jpeg (2×1 px, 1 MB)

New:

745.PNG (1×800 px, 355 KB)

3.
We moved all metrics to MEP between the 2022 and 2023 campaigns, so this could be a deeper library issue with MEP. It's possible that our work there caused some users to lose their logging opt-in status. Hopefully the auto-opt-in would have fixed that issue in the meantime.

I also recall there always being some discrepancies between the legacy system and MEP. I'm not sure how far we got into closing the gap, but this is an old task that we worked on to try and fix the problems - T261987.

Adding notes from our discussion in our meeting today - summary is we will wait and see if the impression counts are in expected range at outset of campaign - there are many variables that could explain the decline, the most impactful was the global decline we saw before we changed user data sharing. Toni has checked the code and verified the wiring is in place. We are limited in our ability to test any of the hypotheses here due to the campaigns being limited by date and not ongoing events.

Leaving answers for the 3 points made by Toni so we have record:

  1. The possible country code mismatch should not have effected campaign numbers but it is possible - I will keep an eye out in next campaign to make sure this is not a possible obstruction.
  2. Toni made the very good point that users have more options to 'opt out' and this could have an effect on our numbers. Even with those events users should still have an impression event, users would have both events on same date. I beleive when I investigated I looked into this but our data was limited to only a small set of users so comparison/percentage calcs are unreliable.
  3. It is possible there are discrepancies between old Legacy numbers and MEP numbers - another possible source of count decline.

We will revisit once campaigns are live

Keeping an eye on this - so far impression counts look consistent and not severely low as we were seeing before. Counts are avg. 44.7% of JP DAU. Data

@SNowick_WMF could you close this one out if it all looks good now?