Page MenuHomePhabricator

Spike: Investigate cause of large banner impression surge in NL and ES fr campaigns
Open, Needs TriagePublic

Description

tl;dr: As compared to last year, there are more banner impressions, yet less page views, in the NL and ES campaigns. This is especially the case for large banners. Please see the initial (last) e-mail in the thread copied below for details.

Andrew Green
3:29 PM (21 minutes ago)

to Maximilian, Jessica, Peter, me, Elliott, fr-tech, Data
Hi!

Wow... Thanks for the detailed info... I'm just digging into this now.

Katie's suggestion a of new proxy would make sense, except that this is happening at the same time in two countries, which doesn't sound too likely (though not impossible).
It could be a change or issue with how pageviews are counted (for example, a change in how bots are filtered out?)... Or also some new Javascript issue, maybe due to the refactoring, or an update in another part of Mediawiki code.

If I understand the reports you sent, it looks like the amounts raised have declined, but the total number of donations increased on mobile, and in NL, they increased on desktop, while in ES, they decreased on desktop? While the donation rate (by time?) decreased?
I guess I'll first try looking at the campaign configuration and checking for JS issues, then try to understand the data more, and maybe bother you with some questions and/or queries we might try to dig deeper...
Thanks much!!! TTY soon, cheers,
Andrew

On 09/05/17 01:37 PM, Katie Horn wrote:
Hmm. Could this be explained by some kind of internet "speed accelerator" coming into use, which largely functions by caching initial pageloads somewhere outside of our systems, but the javascript still fires causing those users viewing cached articles to see fresh banners?

This is, of course, a complete shot in the dark.

-Katie

On 09/05/17 01:05 PM, Maximilian Pany wrote:
Hi Andrew (CC Jessica, Peter, David, Elliot, and fr-tech),

I hope all is well!

Now that both the NL and ES campaigns are finished, we are looking more closely at some of the trends in banner impressions. One that particular struck us is a large increase in banner impressions with a simultaneous decrease in page views from last year to this year for both NL and ES campaigns (see tables 3-6 in the attached monitoring reports, each just for one language of the campaigns).

This trend is particularly pronounced for desktop, but also exists for mobile and iPad (although page views have increased for mobile devices, they are far outpaced by an increase in impressions). While we found some difference in the central notice settings from last year to this year for maximum banners seen (last year went from unlimited to a max of three impressions while this year stayed at a constant max of 10) potentially accounting for some differences, we are also seeing a big increase in large banners (table 6 in the reports), which shouldn’t be due to differences in max amount seen.

Specifically, we see:

  • nlNL: 7.4% decrease in desktop page views with a 91% increase in desktop large banner impressions
  • esES: 22.4% decrease in desktop page views with a 69% increase in desktop large banner impressions

These numbers seem so discordant (it’s hard to believe that we really have that many more users and that they each, on average, visit wikipedia less often!) that we are contemplating alternative explanations. Our list of hypotheses includes (in no particular order):

[1] More non-user impressions this year than last — scrapers/crawlers/spiders generating more impressions this year (perhaps because of a change on our side or on the crawler side)

  • How could we best check this in the data?
  • After talking to Elliot, this sounds less likely given that many crawlers don’t run java script and if they do, tend to respect robots.txt. Did anything with respect to this change?

[2] Some impressions that are not actually user impressions get recorded as such in the lutetium/frdev1001 data, and this number has increased for some reason (perhaps a technical change?) from last year to this year

  • Where exactly does the data in the pgehres.bannerimpressions table come from?
  • Is there any chance that it might include banner impressions that the user never saw, perhaps because they were hidden or previously closed (i.e., had a “hidden” or “close” reason code in banner history)?

[3] There was a change in the proportion of page views getting impressions from last year to this year, perhaps because not all eligible page views last year received impressions

  • My understanding is that this is not randomly sampled but that 100% of non-logged in users in a country in which a campaign is running get banners delivered (unless they closed it or have reached max) — is this correct?
  • Peter mentioned that some changes might have been made to the refactor code, but thought that this is unlikely to affect things — is that right, Peter?

[4] There is a hiccup in how we analyze these data

  • Unlikely, given that we process impression data from this year and last year in the same way — if we’d accidentally inflate these data, both years should be affected the same and their shouldn’t be an artificial increase
  • We have triple-checked our code from pulling these data to processing them, but a mistake hiding somewhere always remains a possibility

[5] These increases in impressions are real and represent new users

[6] What potential explanation did I forget?

We were hoping that you might be able to answer our questions above and/or might have an idea of what’s going on.

Thank you very much!!!

Best,
Max

Event Timeline

AndyRussG renamed this task from Large banner impression surge in NL and ES fr campaigns to Spike: Investigate cause of large banner impression surge in NL and ES fr campaigns.May 12 2017, 5:34 PM
AndyRussG updated the task description. (Show Details)
AndyRussG added a subscriber: Mpany.

Hi!

I activated a test campaign (since the original ones are no longer active) on aa.wikibooks, and added one of the large banners, to test out the JS in a live context. I didn't see any problems, and the switching to buckets for smaller banners worked fine for me.

From the report (Table 6) it looks like the increase in impressions is there for both large and small banners, no?

I was about to suggest that maybe this is due to the increased impression limit. (BTW, I just noticed that mobile campaigns were limited to 1000, not 10, impressions.) However, that shouldn't cause an increase in large banner impressions, since large banners should only be shown on the first impression, if at all. (Maybe this is why you're mainly concerned about the large banner increase, I guess--since an increase in small banner impressions is expected?)

The pattern of buckets for Spain looks reasonable on Pivot. At first, there are a lot of views for all buckets, then the large banner buckets start to fall, as more users have seen a large banner.

The pattern of status codes also looks reasonable. For desktop in Spain, there's the expected increase in banners hidden due to close button clicks, donations and max impressions reached.

Here are some things to check:

  • Exactly how these numbers are being calculated. For example, exactly which campaigns and status codes are in the impression numbers, and which countries, languages and projects are in the page view numbers? I noticed that for Spain, we have campaigns for Spanish, English and Catalan. Are we getting the right page view numbers for this? Also, if you're using the pgehres database for impression numbers, it might be best to double-check with Hive, which is not sampled and should be better at filtering out robots and proxies. (However for total impressions in Spain from all the campaigns, I'm seeing even higher impression numbers on Pivot, which uses Hive, and should at least exclude most robots. :/ )
  • Are the impression/page view ratios for the campaigns generally sane? I really wasn't able to check this with the Pivot pageview tool because it doesn't let you filter on language. For this, normally we query Hive directly. The general approach is to take sample blocks of time and try to filter page views on exactly the same criteria that CentralNotice uses to target the campaign.
  • What might have changed between last year's campaign and this year's? For example, were they at the same time of year? There are annual and weekly cycles, and also some technical issues with the data have sometimes caused pretty big shifts. For example, in the report card you can select eswiki (nlwiki isn't there) and see some shifts and markers on the timeline about that. See also Pivot.
  • Is there anything unusual about the impressions? In Hive, we could look for a high concentration of IP blocks, or specific user agents, to look for undetected proxies (like Katie suggested) or robots, or platform-specific JS issues. Especially, if it's possible (?), we might look for some characteristic that correlates with no or very few donations.
  • Unnoticed server-side errors? We can check for response codes for Special:BannerLoader (some errors are not handled correctly, see T158124 and T152723) and other server logs.
  • Any other evidence of problems with the code that limits large banner display/hides banners? Even though the bucket numbers and status code numbers look OK, as mentioned above, they might not be... If users are somehow being shown multiple large banners, that might show up in banner history. Or in user feedback--have there been any comments from the users about something like that? (Not long ago there was a ticket about banners not closing properly... which I think we assumed to be not a real issue... Can't find the task just now, though. Maybe we should check that the proportion of 2.1 (banner cancelled due to close button) status codes is about the same as in previous campaigns?)

A few more tidbits...

  • Where exactly does the data in the pgehres.bannerimpressions table come from?
  • Is there any chance that it might include banner impressions that the user never saw [...] ?

The table is based on sampled data from calls to beacon/impression. Because it's sampled, it's less accurate than the data in Hive, but it's available more quickly. There's a Python program that fills this up from a Kafkatee pipeline. It should only count banners actually displayed. Also, it's a bit old and could use reworking.

More non-user impressions this year than last — scrapers/crawlers/spiders generating more impressions this year (perhaps because of a change on our side or on the crawler side)

  • How could we best check this in the data?

As mentioned above, Hive has the best info... pageview and webrequest tables (the latter being where we look at beacon/impression requests) have good data. Especially we can look at these fields: agent_type, x_analytics_map.proxy and x_analytics_map.nocookies. Some proxies do run Javascript then throw away whatever is set in cookies or localStorage (where we set the large banner seen identifier)... And proxies have problems taking donations. Also, issues with how we process these fields might impact on the pageview data you're getting. (I think the pageview data you have comes from Hive and filters out agent_type=spider, but the data in pgehres.bannerimpressions does not.)

There was a change in the proportion of page views getting impressions from last year to this year, perhaps because not all eligible page views last year received impressions

  • My understanding is that this is not randomly sampled but that 100% of non-logged in users in a country in which a campaign is running get banners delivered (unless they closed it or have reached max) — is this correct?

That's what should happen, but in practice it's more complex--as mentioned, this year, community campaigns partly blocked out FR campaigns for a bit. If something like that happened a lot last year, for both ES and NL campaigns, it could have caused this issue.

However, the increase in impressions is far greater than the increase in donations, resulting in a decreased donation rate.

So donation rate is by number of impressions, not time? If so, also an indication of supposed impressions that are not really shown to actual users...

Mmm also, we could check if something similar is happening to currently active campaigns...

Aaaaarggh! Fun, fun, fun!!

I hope this is useful :) Please also let me know how I should contribute to checking this out, and if you see stuff I've missed or mistakes... As always, pls don't hesitate to send further questions....

Just checked the logstash and the webrequest logs for Special:BannerLoader. Didn't find anything.

(In logstash, only a bunch of StaleCampaignException messages for old community campaigns--nothing related to FR, filed T165335 to investigate, though. For Special:BannerLoader, I queried status codes for April 24th. Only OK status codes for FR banners, so, nothing that would affect numbers due to client-side bugs mentioned above, either.)