Extension talk:CentralNotice/Allocation system
Great to see this write-up! There's still the issue of "impedance" match between the implementation and the desired effect. It seems like, in practice admins want to display a banner to an approximate fraction of site visitors. I think we can present this as an optional knob, probably at the campaign level. It would look like, "show banners 5% of the time". Let's get rid of banner weights in the UI, and calculate them based on this new knob. Adamw (talk) 22:51, 12 February 2013 (UTC)
- Except what happens when you have multiple banners in a campaign? Or do you mean -- get rid of 'campaign weights' and use your new knob? Mwalker (WMF) (talk) 22:57, 12 February 2013 (UTC)
- Since all of our campaigns are a single banner, or AB or ABCD tests, banner weights are always set equal. So we can assign campaign weight using a target allocation proportion, and banner weights if they are still useful are simply campaign weight / N banners. Adamw (talk) 23:38, 12 February 2013 (UTC)
- According to James Alexander, the community commonly runs campaigns with multiple banners and varying weights. He did suggest that they could just create multiple campaigns, but that seems like a non-optimal solution. Mwalker (WMF) (talk) 01:27, 13 February 2013 (UTC)
- Since all of our campaigns are a single banner, or AB or ABCD tests, banner weights are always set equal. So we can assign campaign weight using a target allocation proportion, and banner weights if they are still useful are simply campaign weight / N banners. Adamw (talk) 23:38, 12 February 2013 (UTC)
We should probably just hardcode "blank" banner deliver into CN. Perhaps there is a universal blank banner. Adamw (talk) 22:51, 12 February 2013 (UTC)
- Blank banners are taken care of by default -- they are just non allocated slots Mwalker (WMF) (talk) 22:57, 12 February 2013 (UTC)
- I almost agree. However, we might want special effects on a particular campaign, where the "blank" banner is used to tweak some cookies. This is interesting, because generally that will be some javascript which runs, but does not take up an allocation slot. So, maybe that effect would be achieved by having a 100% allocation campaign, with optional banners and a bannerjs hiding module outside of the banner DOM. Adamw (talk) 23:38, 12 February 2013 (UTC)
- Yep -- that's how we'll do it. Mwalker (WMF) (talk) 01:27, 13 February 2013 (UTC)
- I almost agree. However, we might want special effects on a particular campaign, where the "blank" banner is used to tweak some cookies. This is interesting, because generally that will be some javascript which runs, but does not take up an allocation slot. So, maybe that effect would be achieved by having a 100% allocation campaign, with optional banners and a bannerjs hiding module outside of the banner DOM. Adamw (talk) 23:38, 12 February 2013 (UTC)
Explain that there is an "hideable" property on banners.
Please define "non-terminal" slot in more detail. I understand now, but will not in a month.
I disagree with the "underallocated" step. There shouldn't be a need for this. Adamw (talk) 22:51, 12 February 2013 (UTC)
- You mean this can be done at the same time as original allocation in a priority? Probably -- but all the methods I came up with would not have the 'stacking' property I was going for. Suggestions? Mwalker (WMF) (talk) 22:57, 12 February 2013 (UTC)
- Here's another problem -- we cannot estimate how often a hiding module will fall through to the next entry in the slot's stack. We would have to apply the same hiding module to all banners, and have 100% campaign allocation. This makes it an especially "unfair" algorithm to clean up any underallocation using higher stack depths. I guess what I'm saying is, the first campaign seems more sensitive to actual statistics. My suggestion would be, a) add expected campaign allocations in the priority. b) If these are > 100%, normalize and emit a warning (on the admin page).
- It's not unfair -- that's why it's a two step process -- they get the allocation they requested balanced amongst everything in their priority and lower priority things can't usurp a higher priority. Anything extra they get is just that, extra. I do like the bit about warning on the Admin page though.
- Here's another problem -- we cannot estimate how often a hiding module will fall through to the next entry in the slot's stack. We would have to apply the same hiding module to all banners, and have 100% campaign allocation. This makes it an especially "unfair" algorithm to clean up any underallocation using higher stack depths. I guess what I'm saying is, the first campaign seems more sensitive to actual statistics. My suggestion would be, a) add expected campaign allocations in the priority. b) If these are > 100%, normalize and emit a warning (on the admin page).
Another thing: what is "max(totalcampaignweights, 100)" about? Adamw (talk) 22:51, 12 February 2013 (UTC)
- It's a math hack to allow the non allocated slots. It assumes that a weight is an integer from 1 to 100 where 100 means 100%. Mwalker (WMF) (talk) 01:27, 13 February 2013 (UTC)
Draft 2
editVery nice simplifications!
Regarding Moderation by Priority — personally, I think all priority levels should have the ability to eat up all traffic before it reaches lower-priority campaigns. Either way, this needs to be the result of a community discussion. Like, the percentages are editable on-wiki.
Typo in the algorithm:
bannerAlloc[banner].Actual *= TotalAllocInPri( priority, requested ) / ( MaxPriAlloc( priority ) * freeAllocation )
should be:
bannerAlloc[banner].Actual /= TotalAllocInPri( priority, requested ) / ( MaxPriAlloc( priority ) * freeAllocation )
One more minor detail: Campaign.sumOfWeights needs to account for filtered-out banners, for example a campaign with one mobile and one desktop banner should still get 100% potential allocation for whichever banner is visible on the current platform.
Otherwise, it looks really good. Maybe write a section about the admin UI impact of these changes.