Extension:CentralNotice/Allocation system
Allocation is the process of determining the percentage of pageviews each active banner will receive.
Selection criteria
editWhen a client requests a CentralNotice banner, some data about the client is passed to the allocations system: country, language, logged in?, browser device, and sticky bucket when applicable. Since requests are all served by meta.wikimedia.org, some information identifying the sister site is also passed: project name, content language. All of these parameters are matched against selection criteria set on campaigns and banners, to create a list of banners which could potentially be served for this request.
Bucketing
editBanner weights
editOnce the list of potential banners is generated, we calculate the allocation probability for each, and use a random number to select which banner to display. Currently, each banner has a weight which can be set by the admin. Weights are added together, and the probability of displaying a banner is equal to its proportional contribution to the sum of weights. In the future, banner weights will only be compared to other banners from the same campaign, and the overall weight of each campaign will be determined by other factors.
Campaign maximum allocation
editStatus: deployed
If the optional "Limit traffic" box is checked in the campaign edit screen, you can set the maximum allocation that will be used by all banners in the campaign. This is an absolute measure, so if the campaign was receiving 20% of total allocations prior to setting the throttle to 50%, for example, nothing will happen, you will not divide your 20% in half.
If throttling is enabled, the remaining allocations may be shared with lower-priority campaigns. When throttling is not enabled, high-priority campaigns will take up all available allocations, and lower-priority campaigns will not display when the selection criteria overlap.
Moderation by priority
editStatus: in RFC
Higher priority levels may take up to a certain percentage of initially available free space. This means that two banners in two separate campaigns each having 100% requested allocation but at different priority levels will have different allocation with higher priority levels getting higher allocations. For the moment the table is defined as:
| Priority level | Maximum initial allocation |
|---|---|
| Emergency | 100% |
| High | 66% |
| Normal | 66% |
| Low | 100%* |
- It may seem counter-intuitive that the lowest priority gets 100% maximum initial allocation; but it allows the algorithm to completely fill any remaining space with low priority banners.
Checking your work
editThere are two pages which allow you to verify the exact allocations received by each banner:
Special:BannerAllocation is for spot-checking a specific set of allocation criteria.
Special:GlobalAllocation gives an overview of allocations for every possible criteria. The snapshot date can be set to any time in the past or future. If desired, the results can be filtered by criterion, like in Special:BannerAllocation.