Page MenuHomePhabricator

Can we allow fallback to alternative campaign if mixin would hide this one
Open, MediumPublic4 Estimated Story Points



  • Campaign 1, priority high, has "Impression diet" mixin set to show a maximum of 5 impressions
  • Campaign 2, priority medium, does not have any impression diet mixin

Current behaviour: User sees 5 times banners from Campaign 1, and then no more banners
Desired behaviour: User sees 5 times banners from Campaign 1, and then banners from Campaign 2

It would be a big improvement for dealing with overlapping campaigns with different requirements (especially overlap between community and fundraising campaigns).

Event Timeline

Pcoombe raised the priority of this task from to Needs Triage.
Pcoombe updated the task description. (Show Details)
Pcoombe added subscribers: Pcoombe, Jseddon, jrobell.

@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?

atgo renamed this task from Allow fallback to alternative campaign if mixin would hide this one to Spike: Can we allow fallback to alternative campaign if mixin would hide this one.Mar 15 2016, 7:07 PM
atgo triaged this task as Medium priority.
atgo updated the task description. (Show Details)
atgo set Security to None.
atgo moved this task from Triage to Blocked or not fr-tech on the Fundraising-Backlog board.
atgo moved this task from Blocked or not fr-tech to Sprint +3 on the Fundraising-Backlog board.

As a nice to have, we may want fallback information on the allocation page:

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 set the point value for this task to 2.Jun 10 2016, 9:08 PM
AndyRussG moved this task from Doing to Review on the Fundraising Sprint Licking Cookies board.

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
DStrine renamed this task from Spike: Can we allow fallback to alternative campaign if mixin would hide this one to Can we allow fallback to alternative campaign if mixin would hide this one.Jun 23 2017, 5:31 PM
DStrine removed a project: Spike.
DStrine changed the point value for this task from 2 to 4.

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

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

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

@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!

This task has been assigned to the same task owner for more than two years. Resetting task assignee due to inactivity, to decrease task cookie-licking and to get a slightly more realistic overview of plans. Please feel free to assign this task to yourself again if you still realistically work or plan to work on this task - it would be welcome!

For tips how to manage individual work in Phabricator (noisy notifications, lists of task, etc.), see for available options.
(For the records, two emails were sent to assignee addresses before resetting assignees. See T228575 for more info and for potential feedback. Thanks!)