@AndyRussG has the most domain knowledge here, and he's working on the ed program for the month. We will look into this and re-triage when he's back.

@AndyRussG Any idea how much work this would be for you?

As a nice to have, we may want fallback information on the allocation page:
https://meta.wikimedia.org/wiki/Special:BannerAllocation

Which one has highest priority? What are the impression limits for a campaign?

Here's what I've found so far:

• This seems to be doable.
• There are no insurmountable blockers, though a few medium-sized issue bits to work on:
  • Adapt campaign and banner selection JavaScript to de-select a campaign if it cedes its pageview to another campaign. This probably means adding methods to clean out state in some objects, and ensuring that some methods that were designed to be called only once can be called multiple times.
  • For Special:BannerAllocation, determine how to show fallback information. If a campaign may fall back, we probably should somehow show allocations for that situation. Potentially could be hairy to visualize all the possibilities in some cases. This is important, however, since there may be campaigns that will show up with fallback that wouldn't be even mentioned in BannerAllocation, and would never be shown, otherwise.
  • How would fallback impact impressions counting, considering that we'd have cases of more than one impression record per pageview (since a banner hide normally is recorded as an impression, and so would whatever the fallback campaign does)? Would this affect how the data is interpreted? Would it be necessary to associate impressions on the same pageview? What about the banner history log?

A few more tidbits we discussed in IRC:

• Fallback would be an option on the impression diet mixin. So, it would be possible to turn fallback off, such that no banner would be shown after the campaign reaches its maximum number of impressions (i.e., the same as how it works now).
• For now, if a banner is hidden due to a close button click or a recent donation, the pageview won't fall back to a different campaign. However, we could change this in the future.

About Special:BannerAllocation: in general, we should think about ways to improve the visualization of this and related data... So really this is part of a larger problem...

Some ideas we talked about this morning: in each table on that page, we could display a new column with information about a campaign's fallback options. If the campaign is using fallback, there could be a button to reveal what fallback campaigns would show, and at what levels, for users for whom the first campaign concedes to a fallback one.

Also, it seems that Special:BannerAllocations could do with a little bit of cleanup first, to reflect the current campaign selection and bucketing model.

@AndyRussG
This looks well thought-through!

Fallback will be useful outside of impression diet, won't it? For example, if a regular community campaign was hidden by the close box? I'd like to see this be a global feature and not coupled to any specific campaign mixin, or to specific campaign preferences, if possible... Do you agree?

I think the BannerAllocation visualization could be split into a followup phase, because it's probably very tricky and like you said, a nice-to-have after the core feature.

@K4-713 @DStrine @AndyRussG @jrobell @MeganHernandez_WMF @Pcoombe I'd really like to bump this one up to being a priority if possible in terms of next CN feature request.

The inability to allow multiple campaigns to run in order of priority is real issue for all campaigns and puts pressure and uncertainty on both WMF and community in terms of scheduling.

@AndyRussG had this to say on IRC

• re: fallback, it doesn't look like a lot of code, but let's call it a 4 just in case, because the logic for choosing a campaign is complex, and runs on almost every pageview on almost every single wiki, so I wouldn't want to mess up any changes there

-Also because of the foregoing we should do unit tests

• The campaign choosing code already has tests, so it'd be a question of adding to those

-I also have a few non-technical concerns
-One actually
-That it could lead to banner flood followed by banner drought, if impression diet settings for overlapping campaigns are not coordinated

• That might also make the allocation page adaptation more important--to be able to coordinate how campaigns interact for a segment of users, it's nice to be able to see them

Any chance of this getting looked at any time soon?

Situations where fallback would have either prevented disruption or ensured effective delivery of campaigns:

• Clashes between fundraising and community campaigns (specifically occurred with Wiki Loves Monuments)
• Privacy policy update - A lack of campaign fallback will prevent us from maximising notification of readers without causing significant disruption to programmatic campaigns

Change 517931 had a related patch set uploaded (by Vedmaka Wakalaka; owner: Vedmaka Wakalaka):
[mediawiki/extensions/CentralNotice@master] Campaign fallback

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

Change 538967 had a related patch set uploaded (by Mepps; owner: Mepps):
[mediawiki/extensions/CentralNotice@master] Change name, default, and add documentation for MaxCampaignFallback

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

Change 517931 merged by jenkins-bot:
[mediawiki/extensions/CentralNotice@master] Campaign fallback

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

@AndyRussG: Hi, both related patches in Gerrit have been merged. Can this task be resolved (via Add Action... → Change Status in the dropdown menu), or is there more to do in this task? Asking as you are set as task assignee. Thanks in advance!