Special:RecordImpression should die in a fire
OpenPublic

Older changes are hidden. Show older changes.
AndyRussG set Story Points to 2.Via WebFeb 16 2015, 8:16 PM
AndyRussG removed Story Points.Via WebFeb 16 2015, 9:03 PM
AndyRussG set Story Points to 4.
AndyRussG moved this task to In Analysis on the § Fundraising Sprint Devo workboard.
atgo added a subscriber: atgo.Via WebFeb 17 2015, 6:24 PM

@Krinkle @faidon now that we have the temporary fix, could we downgrade priority or close this?

faidon lowered the priority of this task from "Unbreak Now!" to "Normal".Via WebFeb 17 2015, 6:26 PM

Downgrading, but since this is as you said a temporary, this should probably stay open? As I understand it, it would still be a pretty big deal performance-wise when we run campaigns so it would be best to not put this on the backburner.

gerritbot added a comment.Via ConduitFeb 17 2015, 6:43 PM

Change 188395 abandoned by Ejegg:
Special:RecordImpression now sampled client-side

https://gerrit.wikimedia.org/r/188395

atgo added a comment.Via WebFeb 17 2015, 10:50 PM

Thanks @faidon. We're looking into longer term solutions... there's a spike for it here: T88614

AndyRussG added a comment.Via WebFeb 18 2015, 2:14 AM

I'm pretty sure the more permanent solution should involve:

  • A logging mechanism that has to be explicitly turned on for a given CentralNotice campaign, instead of being on for all campaigns or on by default.
  • Sending back more than just the name of the banner shown and info about client-side banner hiding. Instead, we'll store and send back the history of hide or show results from the last n (maybe 5 or so?) impressions. This will get us better analytics and banner-logic debugging than we have now.
  • Some kind of configurable sampling, with higher sample rates than the one we just set set for non-campaigns. (I dunno, maybe 20% rather than 1%? Not quite sure yet how it'll play out...)

NEway, I think there's no way out of sending some data from the client during campaigns. For these cases, performance-enhancing measures might include (in addition to sampling):

  1. Use a data transfer and storage mechanism that's easy on our servers.
  2. Time the actual call so we ease the load on clients (like maybe delay it for a few seconds to make sure all page rendering and other server communication has finished, or something like that).

No. 1 is the issue I'd love to have some more input on: what'll be the best way to send the data? Maybe EventLogging to Kafka (T68528)?

tl;dr: For the more permanent solution, sending some data from clients during campaigns is still inevitable. What do you recommend as the best way to do that?

GOIII added a subscriber: GOIII.Via WebFeb 28 2015, 1:19 AM

With the so-called workaround in place, my F-12 Developer tool's console (Win 8.1/IE 11) still reports something similar to...

DOM7009: Unable to decode image at URL: https://meta.wikimedia.org/w/index.php?title=Special:RecordImpression&country=US&uselang=en&project=wikisource&db=enwikisource&anonymous=false&device=desktop&banner=stewvote&campaign=Stewvote&bucket=1&bucketStart=1423418400&bucketEnd=1427738340&reason=close&result=hide

... on every page load or refresh. Searching for DOM7009 at Microsoft provides little to go on as well.

And fwiw... I must have dismissed the banner notifying us of the Steward elections 4 or 5 times already in case it matters.

Nemo_bis added a project: Performance.EditedVia WebMar 1 2015, 11:59 AM
Nemo_bis added a subscriber: Nemo_bis.

Please, please, please kill it, just kill it, now. We can no longer afford paying a cost of 500+ ms on every single pageview on our projects, when *no banner* is shown at all, and when *no use* is made at all of the data.

How many millions of users has this bug already cost us? How many billions of authentic page views? Who's going to pay the bill?

Plus, this is IMHO a blocker for HTTPS by default, as time spent over SSL negotiation is multiplied by the number of domains involved, and this bug adds meta.wikimedia.org gratuitously.

Nemo_bis added a subscriber: MZMcBride.Via WebMar 1 2015, 12:01 PM
Nemo_bis added a project: HTTPS-by-default.
Nemo_bis removed Story Points.
Nemo_bis edited the task description. (Show Details)Via WebMar 1 2015, 12:18 PM
Krenair added a subscriber: Krenair.Via WebMar 1 2015, 12:40 PM
AndyRussG added a comment.Via WebMar 1 2015, 4:56 PM

Hi, all! @GOIII and @Nemo_bis, thanks so much for your feedback, really appreciated! :)

@GOIII, as you saw, you got S:RI because of the Stewards election banner. Since the decision about whether to actually show that banner (based on the user's number of edits, I think) is in made in Javascript downloaded with the banner, the currently deployed workaround doesn't help, unfortunately. (My understanding is that that specific JS may need a revamp, BTW.)

@Nemo_bis, thanks for sending that test...! In this case I'm pretty sure it's the strategy consultation campaign that's hammering away.

In both these cases, we have massive campaigns targeting tons of users. As stated, this is exactly the situation in which the workaround doesn't help.

Below you'll find more replies, and an update about where we are with a more permanent solution. But first let me say that I can think of a couple options to further strengthen this workaround. I'll try to make a patch today and reserve a deploy slot for tomorrow. (The options I'm thinking of are: a small Mixin for controlling S:RI sampling on a per-campaign basis via JS in the banners, and automatically use sampling if the random number for the final banner selection chooses no banner allocation.)

Performance

@Nemo_bis, I appreciate the concern, but I guess I have to disagree with your interpretation of the data. This is a background call that happens simultaneous to many others. While it surely has an impact due to network use and processor cycles consumed, it's not a "cost of 500ms", if by that you mean it delays the displaying of every page by 500 ms. That's not happening. It's still important that we fix it, though.

Use of data from S:RI

This data is used to compare the effectiveness of fundraising banners. Since FR banners are often fetched from the server but not actually displayed because of JS logic in the same payload, S:RI is the only way for FR to count actual banner displays. (This will change soon—see below.) Please ask @ellery if you need more details. I do know that FR pulls that data quite a lot.

(BTW, personally, I'd be thrilled if such tests and data were publicly reviewable—and I think maybe they once were, to some extent, though also, I think, no one paid much attention to them. Anyway, those are my two-cents-with-my-WMF-hat-off, as regards something related to this that's worth asking for. And apologies to my overburdened colleagues for suggesting something that could mean more overbudrening... ;) )

Note that there have also been requests for impression numbers for non-FR banners, including the Stewards vote banner and the strategy consultation.

Prioritizing dev effort

Please understand that CentralNotice is at once legacy software and a single point of possible failure. Please also understand that FR's banner tests are important, since the more effective banners are, the less they have to be shown. We have to balance time spent fixing technical debt (like this), doing new things right, improving tests and CI, general maintenance, etc. All things considered, I think the balance we've struck so far is quite reasonable.

Medium-term solution

We've been working a lot on a more permanent solution. We expect it'll look like this. I'll try to put more doc on mediawiki.org soon.

Here are some Phabricator tasks for implementing that plan (more are needed, though): T90913, T90915, T90917

Thanks!!! :)

GOIII added a comment.Via WebMar 1 2015, 6:58 PM

Hi, all! GOIII and Nemo_bis, thanks so much for your feedback, really appreciated! :)

GOIII, as you saw, you got S:RI because of the Stewards election banner. Since the decision about whether to actually show that banner (based on the user's number of edits, I think) is in made in Javascript downloaded with the banner, the currently deployed workaround doesn't help, unfortunately. (My understanding is that that specific JS may need a revamp, BTW.)

Tsk... please read more carefully. I always get A message in my console whether or not there are any new "announcements" or not on every single page click-in or refresh. Here is the current incarnation

DOM7009: Unable to decode image at URL: https://meta.wikimedia.org/w/index.php?title=Special:RecordImpression&country=US&uselang=en&project=wikisource&db=enwikisource&anonymous=false&device=desktop&reason=empty&result=hide

I don't know...... seems kind of hard to cache a cookie for a page that doesn't really exist --> and thus the attempt to process the bang .png that doesn't really exist either instead?

GOIII added a comment.Via WebMar 1 2015, 7:01 PM

Here's some more tidbits...

NetworkData.xml

AndyRussG added a comment.Via WebMar 1 2015, 7:29 PM

@GOIII, I did read carefully and I do understand that that is what is happening.

Please go to your JS console, and type mw.cnBannerControllerLib.choiceData. That will show you any campaigns/banners that are targeting you. Right now, every time you see any campaigns and banners in that variable, S:RI will be called, even if a banner is not actually displayed on your screen.

You can also visit the meta campaign administration page to see what campaigns are up. Often there are only campaigns that target a segment of users, which is what the original workaround was for. However, right now there are massive ones, so the workaround as it stands doesn't help.

Once again, I'll be preparing additional improvements to the workaround to go out ASAP. :)

GOIII added a comment.Via WebMar 1 2015, 8:22 PM

I just dismissed the Campaign: 2015 WMF Strategy Consultation maybe a few hours ago -- which was part of the console message I was getting for every click-in/refresh before the "generic" one I'm getting now (posted in my previous).

Like I said - it makes no difference: New Notice, Old Notice, Dismissed Notice (A dismissed message typically stays dismissed btw), I ALWAYS get something mentioning some Special: page at meta regardless. Most of the time its one pointing to Special:RecordImpression

Hope that helps.

AndyRussG added a comment.Via WebMar 1 2015, 9:05 PM

Thanks @GOIII... Yes, that is the expected behavior with the campaigns that are up now. When you dismiss a banner, the record of that dismissal is only stored locally on your machine, and CentralNotice doesn't take that information into account until pretty late in the process. So yes, in that case S:RI will still be called. Restructuring things so that and other similar decisions happen earlier is part of the more permanent fix.

We'll keep everyone posted about work on all this... :)

awight added a comment.Via WebMar 2 2015, 2:55 AM

@AndyRussG has already mentioned it, but I want to repeat that there is a plan which will get rid of Special:RecordImpression. Once we can move so-called banner diet logic (hiding a banner for an individual after a small number of impressions) out of banners, we will know whether to show or suppress a banner before delivering it, and S:RI will not be needed any more.

I also want to acknowledge that @Nemo_bis is correct to say that S:RI can delay the page load, if for some reason meta.wikimedia.org is slower to respond than the other components of the page. However, in the waterfall graph for it.wikiquote, Special:RecordImpression was not the limiting element, MediaWiki:Apri-chiudi.js was.

gerritbot added a comment.Via ConduitMar 2 2015, 3:48 AM

Change 193767 had a related patch set uploaded (by AndyRussG):
Special:RecordImpression: sample for allocation gaps, too

https://gerrit.wikimedia.org/r/193767

AndyRussG added a comment.Via WebMar 2 2015, 5:50 AM

@awight, thanks! Hrmm, in deference to my own stubbornness I had to try it! Locally simulating a slow response from S:RI, I found that, yes, the tab's throbber kept spinning until S:RI replied. However, the page was fully displayed and interactive as normal, even while S:RI was pending and the throbber animation went on. I didn't notice any delays in the execution of other JS.

So I'll stick to my claim that this is not causing a 500ms bump, even when the response from S:RI is the last to return. True, in that (probably rare) scenario we'll get an undesirable throbber effect a bit longer. But... I'll not purchase the hyperbole of millions of users cast off and devoured by latency sharks. ;p

Once more, that very much doesn't mean we don't have to fix it. ;) We do!!!

gerritbot added a comment.Via ConduitMar 2 2015, 6:12 AM

Change 193777 had a related patch set uploaded (by AndyRussG):
Special:RecordImpression: include sample rate

https://gerrit.wikimedia.org/r/193777

gerritbot added a comment.Via ConduitMar 2 2015, 6:54 AM

Change 193779 had a related patch set uploaded (by AndyRussG):
WIP Special:RecordImpression: sample by default, custom rates

https://gerrit.wikimedia.org/r/193779

AndyRussG added a comment.Via WebMar 2 2015, 7:10 AM

The last patch requires campaigns to explicitly turn off S:RI sampling via JS in the banners. If they don't, S:RI will client-side sample at the rate indicated by $wgCentralNoticeSampleRate, currently 1%. It also lets campaigns set a custom sample rate, in case they want something in between $wgCentralNoticeSampleRate and full-on unsampled.

That patch shouldn't be deployed until campaigns that need unsampled data have been updated.

However, the first two patches can be deployed right away, I hope. That should already mitigate the situation, cutting S:RI by 80% for users targeted by the massive but throttled strategy consultation campaign (i.e., there won't be a call for users randomly chosen to not see a banner due to throttling).

gerritbot added a comment.Via ConduitMar 2 2015, 10:35 PM

Change 193767 merged by jenkins-bot:
Special:RecordImpression: sample for allocation gaps, too

https://gerrit.wikimedia.org/r/193767

gerritbot added a comment.Via ConduitMar 2 2015, 10:37 PM

Change 193777 merged by jenkins-bot:
Special:RecordImpression: include sample rate

https://gerrit.wikimedia.org/r/193777

Ejegg added a comment.EditedVia WebMar 3 2015, 3:11 AM

After tonight's deployment, RecordImpression numbers are down by at least 50% even before the new code has worked through everyone's caches.
(sampled 1:100)
15 min ending 20150303-030001: 8402
15 min ending 20150224-030001: 23036

This is mostly due to 100-fold reduction of reason=empty calls, but probably reflects variation in deployed campaigns too.
reason=empty calls:
15 min ending 20150303-030001: 359 (125 POSTs from new code)
15 min ending 20150224-030001: 15125

AndyRussG added a comment.Via WebMar 3 2015, 3:30 AM

Hi... here are the patches deployed for this:

Again, it's not done, but this should be better. There will still be times when you don't see a banner but S:RI is called, but it'll be less, especially just now. Note also that a bug in Firefox prevents the call from appearing in the Network tab. It's visible in Chrome, though.

Thanks, all!! :)

faidon removed a project: HTTPS-by-default.Via WebMar 17 2015, 12:59 AM
Liuxinyu970226 added a subscriber: Liuxinyu970226.Via WebMay 14 2015, 11:51 AM
awight added a subscriber: kevinator.Via WebJun 4 2015, 11:59 PM
faidon raised the priority of this task from "Normal" to "High".Via WebJul 4 2015, 5:39 PM
faidon added subscribers: BBlack, Joe.

The wm2015register campaign caused this on appservers req/s (just a sample from one appserver):

Varnish top RxURLs are now:

1​root@cp1065:~# varnishtop -1bi TxURL|head -20 |cut -d\& -f1
2​ 837.00 TxURL /w/index.php?title=Special:RecordImpression
3​ 227.00 TxURL /w/api.php
4​ 133.00 TxURL /w/api.php?maxlag=5
5​ 121.00 TxURL /w/index.php?title=Special:RecordImpression
6​ 100.00 TxURL /w/api.php?continue=%7C%7C
7​ 82.00 TxURL /w/index.php?title=Special:RecordImpression
8​ 74.00 TxURL /w/index.php?title=MediaWiki:AjaxTranslation.js
9​ 71.00 TxURL /w/index.php?title=Special:RecordImpression
10​ 54.00 TxURL /w/index.php?title=Special:RecordImpression
11​ 50.00 TxURL /w/api.php?continue=%7C%7C
12​ 45.00 TxURL /w/index.php?title=Special:RecordImpression
13​ 32.00 TxURL /w/index.php?title=Special:RecordImpression
14​ 30.00 TxURL /w/index.php?title=Special:RecordImpression
15​ 26.00 TxURL /w/index.php?title=Special:Export
16​ 25.00 TxURL /w/index.php?title=Special:RecordImpression
17​ 23.00 TxURL /w/index.php?title=Special:RecordImpression
18​ 22.00 TxURL /w/index.php?title=Special:RecordImpression
19​ 21.00 TxURL /w/index.php?title=Special:RecordImpression
20​ 21.00 TxURL /w/api.php?inprop=protection
21​ 19.00 TxURL /w/index.php?title=Special:RecordImpression

I think graphs/numbers speak for themselves.

@Joe, @ori, @BBlack & myself all wasted our time with effects correlating to this and other issues today. Both @ori and myself have personally spent a considerable amount of our time over the years for S:RI. What needs to be done for it to die in a fire as the task's name suggests?

Nemo_bis awarded a token.Via WebJul 4 2015, 6:00 PM
AndyRussG added a comment.Via WebJul 4 2015, 8:19 PM

Ouch...!!! @faidon @Joe, @BBlack, @ori, really, really sorry about the wasted time!!! Fortunately we are very close to finishing the changes required to bury this. Here is the most important WIP patch:

https://gerrit.wikimedia.org/r/#/c/221759/

That patch also refactors basically all the banner controller code to make it modular and readable, in addition to supporting the new processes we need. Since it's not complete, I haven't added too many reviewers yet, but it will need review from several teams. Note that I was expecting a gradual shutting down of S:RI--that's why that patch does still support it. I imagine we can make the cutoff more drastic and sudden, though... Mainly that'd be a question of coordinating things with any community banners that need display numbers.

Many thanks in advance for ur thoughtful, incisive and scathing comments!!! ;P

MZMcBride added a comment.Via WebJul 5 2015, 2:15 AM

Prioritizing dev effort

Please understand that CentralNotice is at once legacy software and a single point of possible failure.

Can you please explain what "legacy software" means specifically? Are there newer tools that are now being used to replace CentralNotice? I'm very confused about this.

Please also understand that FR's banner tests are important, since the more effective banners are, the less they have to be shown. We have to balance time spent fixing technical debt (like this), doing new things right, improving tests and CI, general maintenance, etc. All things considered, I think the balance we've struck so far is quite reasonable.

The comments below saying (yet again) to resolve this task, as titled, as soon as possible indicate that the balance your team is making is unreasonable.

As pointed out above in T45250#997918, the only reason this code is still live is that it's part of fundraising, but that's a pretty thin and ugly veil to wear.

Can you (@AndyRussG) or @atgo provide an exact date by which Special:RecordImpression will no longer be live on Wikimedia wikis?

awight added a comment.Via WebJul 5 2015, 3:49 AM

We're hoping to shut off S:RI by the end of the calendar year. The system which will replace it is called banner history, and it's one of Fundraising Tech's top priorities, in active development. That said, expect not to see any sparks flying from this "die in a fire" task until we have the parallel infrastructure built which will replace it.

I really appreciate the tempered criticism we're receiving here--when I originally came up with the Special:RecordImpression malfeature three years ago, I duly walked to the other side of the office and painted my name in feeble capitals at the top of the "fire me" wall. At the time, we were replacing an even more egregious bit of oxygen-poor design work, and S:RI actually saved us a round trip for every page view... Glad this discussion is finally heating up, though. I'd love to see CentralNotice get the attention it deserves, since it's the sole reason we aren't yet another Google rebranded targeted video ad vomitorium.

My invitation to anyone subscribing here who feels feisty or proactive, is to help review or implement the banner history feature at T78089, rather than jabbing at our gangrenous cecum. The faster we can get that done, the more likely S:RI dies within the year. If you go over there, you'll notice all kinds of shiny new things. In the future, thanks to the banner history work, there will be a checkbox for limiting the number of times a banner is displayed to each individual. Currently, the poor admin would have to hunt down and transclude a bunch of obscure onwiki javascript, which will surely change in some incompatible way at an indeterminate time.

As an example of how life sucks, but could be better: the wm2015register campaign failed to follow any of the (underdocumented) best current practices in CentralNotice, such as throttling the amount of traffic to the campaign, limiting the targeted audience, or most importantly, if you're going to spam everyone looking at a wiki, limiting the number of impressions any one victim is subjected to. Under the upcoming banner history / campaign mixin regime, the admin would have checked the box that says "I'm not a sociopath or anything, please show my banner no more than 5 times".

In a world with more FR-tech developers and more months before December, I'd also like to add some tools to help admins be proportionate about how many impressions they're delivering relative to one another. In the wm2015register case, the problem is actually that we're spamming the bloody crap out of the entire world, that should have set off alarms before S:RI did. I'm not surprised that some app servers are heating up, and it's not even particularly informative to point to S:RI when we have a huge systemic issue with allowing people to spam each other in the first place.

/me crunches loudly on peanuts

awight added a comment.Via WebJul 5 2015, 3:49 AM
This comment was removed by awight.
jeremyb added a subscriber: jeremyb.Via EmailJul 5 2015, 4:18 AM

In the wm2015register case, the problem is actually that we're spamming the bloody crap out of the entire world, that should have set off alarms before S:RI did.
... when we have a huge systemic issue with allowing people to spam each other in the first place.

do we have a bug filed for making the right interface for that? or for
notifications for people that opt-in to know when banners hit certain
criteria? there was even a time not so long ago when a related special
page used to regularly timeout (I think it was something like
globalallocation; ah, I guess I'm right: T55443: CentralNotice Out of Memory Error in Special:GlobalAllocation).

the rest of the abuse of CN problem (the users), I think belongs in a
new section at [[m:Talk:CentralNotice/Calendar]][0] rather than
phabricator and also should be mentioned on the centralnotice-admins
mailing list[1].

[0] https://meta.wikimedia.org/wiki/Talk:CentralNotice/Calendar
[1] https://lists.wikimedia.org/mailman/listinfo/centralnotice-admins

BBlack added a comment.Via WebJul 5 2015, 7:31 AM

As an example of how life sucks, but could be better: the wm2015register campaign failed to follow any of the (underdocumented) best current practices in CentralNotice, such as throttling the amount of traffic to the campaign, limiting the targeted audience, or most importantly, if you're going to spam everyone looking at a wiki, limiting the number of impressions any one victim is subjected to. Under the upcoming banner history / campaign mixin regime, the admin would have checked the box that says "I'm not a sociopath or anything, please show my banner no more than 5 times".

In the wm2015register case, the problem is actually that we're spamming the bloody crap out of the entire world, that should have set off alarms before S:RI did. I'm not surprised that some app servers are heating up, and it's not even particularly informative to point to S:RI when we have a huge systemic issue with allowing people to spam each other in the first place.

If this is an unintentionally-bad campaign, can we get it fixed? Can someone shut off the campaign or fix its parameters? AFAICS, the load situation has not changed, and we're still experiencing a related deluge of S:RI hits, and we've had a huge spike of failing appservers that correlate with the request-load peak coming from this a few hours ago. Where can we go or who do we ask to get it corrected?

gerritbot added a comment.Via ConduitJul 5 2015, 8:14 AM

Change 222879 had a related patch set uploaded (by BBlack):
filter S:RI from wm2015register T45250

https://gerrit.wikimedia.org/r/222879

gerritbot added a comment.Via ConduitJul 5 2015, 8:15 AM

Change 222879 merged by BBlack:
filter S:RI from wm2015register T45250

https://gerrit.wikimedia.org/r/222879

Nemo_bis added a comment.Via WebJul 5 2015, 10:54 AM

Yes, the issues with that banner should be reported and discussed at https://meta.wikimedia.org/wiki/Talk:CentralNotice/Calendar

Mainly that'd be a question of coordinating things with any community banners that need display numbers.

I doubt any such banner exists. Either way, the community can serenely do without such numbers for now.

I've read T78089 and associated page and there is no indication on what makes it a blocker for immediate death of Special:RecordImpression.

AndyRussG added a comment.EditedVia WebJul 5 2015, 5:26 PM

Please understand that CentralNotice is at once legacy software and a single point of possible failure.

Can you please explain what "legacy software" means specifically? Are there newer tools that are now being used to replace CentralNotice? I'm very confused about this.

By legacy, I mean it's crufty and should be substantially updated or replaced (or a bit of both). Dive into the code and you'll see what I mean. :) Yes, its contributors include many folks I hold in high esteem!! But it has also accumulated unfinished improvements, support for features no longer in use, and extra complexity due to the need to support a lot more (scale- and featurewise) than originally planned. (BTW, the WIP patch mentioned above does, I think, fix a lot of client-side issues.)

Please also understand that FR's banner tests are important, since the more effective banners are, the less they have to be shown. We have to balance time spent fixing technical debt (like this), doing new things right, improving tests and CI, general maintenance, etc. All things considered, I think the balance we've struck so far is quite reasonable.

The comments below saying (yet again) to resolve this task, as titled, as soon as possible indicate that the balance your team is making is unreasonable.

Hmmm... Well, let's consider both the specific and the general. Certainly a different balance could be sought specifically for killing S:RI. Though I want to say that overall we're giving CN performance very high priority!! (For example, said patch also reduces the amount of code loaded for users in many cases--that's another issue other teams have brought up--and with T103695 we're exploring ways to get beyond the performance limits of the current system.) Upcoming changes should address S:RI, other performance issues, and a large chunk of technical debt, and provide the banner history feature requested by FR, all in one swoop!

I should also call out that having new folks on the FR team does not mean we can go a lot faster right away--pretty soon, though, I think! :)

It seems the more general issue related to this is: how tech priorities and goals are set overall. (Not something to look into much here... maybe worth taking elsewhere, though!)

@BBlack, that patch looks great, thanks for doing that! Also, with the currently deployed CN code, adding the following snippet to JS in any banner should reduce S:RI calls for that banner to 1% of what they'd otherwise be:

mw.centralNotice.onlySampleRI = true;

In the latest version of said WIP patch, I made S:RI sampling the default. With that, campaigns that need full impression numbers would have to explicitly turn sampling off to get them. It also simply turns off S:RI in some cases where it's currently called at the low, sampled rate. (Again, the thought behind this was a gradual shutdown of S:RI. And, again, it's a WIP--I still need to check with all parties that this is OK.)

Mainly that'd be a question of coordinating things with any community banners that need display numbers.

I doubt any such banner exists.

There have been community banners that used in-banner JS to hide banners in certain circumstances, and have asked for impression numbers.

I've read T78089 and associated page and there is no indication on what makes it a blocker for immediate death of Special:RecordImpression.

Just edited the task description of T90917 and commented there. Sorry if it wasn't clear!!

Thanks!!! :)

awight added a subscriber: Jalexander.EditedVia WebJul 5 2015, 5:42 PM

I doubt any such banner exists. Either way, the community can serenely do without such numbers for now.

Agreed. I'd like us to have the numbers anyway for postmortem analysis, but if it helps with the ops burden by all means do whatever is needed with the non-fundraising banners. AFAIK the only non-FR campaign admins who have asked for their impression numbers have been WMDE and @Jalexander.

If this is an unintentionally-bad campaign, can we get it fixed?

Great question. This is definitely not an abusive admin, it's a structural shortcoming in the software that the defaults are to spam the whole world. Unfortuntely, adding the code to limit banner impressions is currently so arcane that we've been too embarrassed to document the process. Or something like that. I tried to make the connection on the talk page, we'll see how that goes.

I've read T78089 and associated page and there is no indication on what makes it a blocker for immediate death of Special:RecordImpression.

It's a blocker in the sense that we need a functional replacement before we retire the old impression counting system. Impression numbers are a must-have for all fundraising banners, it's the only way we can normalize results and compare across campaigns. I'll find an appropriate milestone card and mark the dependency from this task. Seems like the dependencies are pretty clearly marked.

AndyRussG added a comment.Via WebJul 5 2015, 6:59 PM

I doubt any such banner exists. Either way, the community can serenely do without such numbers for now.

Agreed. I'd like us to have the numbers anyway for postmortem analysis, but if it helps with the ops burden by all means do whatever is needed with the non-fundraising banners. AFAIK the only non-FR campaign admins who have asked for their impression numbers have been WMDE and @Jalexander.

Thanks!! :) Yeah, agreed about the second point... FWIW, I was thinking of the steward elections banner, which only showed to logged-in users with a minimum number of edits. Don't know how far their request for impression numbers ever got...

If this is an unintentionally-bad campaign, can we get it fixed?

Great question. This is definitely not an abusive admin, it's a structural shortcoming in the software that the defaults are to spam the whole world. Unfortuntely, adding the code to limit banner impressions is currently so arcane that we've been too embarrassed to document the process. Or something like that. I tried to make the connection on the talk page, we'll see how that goes.

Just added this to the doc on Meta. Arg!!! Really silly of me not to have done that before, really sorry about that!!! :( Also, I remember at one point it was decided that it wasn't necessary to make that the default, though I don't remember why now. I guess that was also a mistake!!!

/me sprints and skips back to the spaghetti refactory...

KTC added a subscriber: KTC.Via WebJul 5 2015, 10:55 PM
KTC added a comment.Via WebJul 6 2015, 3:29 AM

Have set onlySampleRI, and basic javascript/cookie to display up to 2 times per project but that only affect what someone see and not whether the HTML/CSS/JS get loaded in the first place. @Glaisher had set traffic to 50% earlier.

AndyRussG added a comment.Via WebJul 6 2015, 6:29 AM
In T45250#1428586, @KTC wrote:

Have set onlySampleRI, and basic javascript/cookie to display up to 2 times per project

Looks great!! Thanks much!!

that only affect what someone see and not whether the HTML/CSS/JS get loaded in the first place.

Indeed... BTW that'll also be fixed in upcoming changes :)

Nemo_bis added a comment.Via WebJul 6 2015, 11:43 AM

There have been community banners that used in-banner JS to hide banners in certain circumstances, and have asked for impression numbers.

"Asked" doesn't mean "need". There are alternative ways to calculate impressions and I'm pretty sure whoever asked would gladly do without if only they knew it impacts performance for users.

ori added a comment.Via WebJul 22 2015, 9:56 PM

What's the status of this? Are we any closer to the complete shutdown of S:RI?

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptVia HeraldJul 22 2015, 9:56 PM
AndyRussG added a comment.Via WebJul 23 2015, 12:33 AM
In T45250#1473036, @ori wrote:

What's the status of this? Are we any closer to the complete shutdown of S:RI?

This refactor patch (mentioned above) is ready and waiting for review and smoke testing! (It's still marked "WIP" just so we don't merge until enuf eyes have seen it.)

Please see also T106577 for some considerations...

ori added a comment.Via WebJul 24 2015, 10:32 PM

atgo moved this task to Feature requests on the Wikimedia-Fundraising workboard.Via WebJul 30 2015, 11:15 PM

Add Comment