Extension:CentralNotice/Campaign and banner selection
CentralNotice determines which campaign to show to a user. If a campaign has more than one banner, CentralNotice also decides which of those banners to show the user.
These decisions take into account several criteria. Some of these criteria are available on the server, and others are only known in the user's browser.
Following are more details about how this works.
Here are the criteria that determine which campaign a user gets and which banner is shown.
|Criteria||Notes||Available on server?||Available on client?|
|Project||For example, Wikipedia, Wikinews, etc.||Yes||Yes|
|Country||Not currently, but maybe one day||Yes|
|Logged-in status||Not currently, but maybe one day||Yes|
|Device||Not currently, but maybe one day||Yes|
|Bucket||Users buckets are stored in a cookie in the browser. A user can be in different buckets for different campaigns.||No||Yes|
|Random numbers||These are generated in the browser.||No||Yes|
|Additional user details||Extra information stored in the browser and used only by certain campaigns. Examples include: Did the user click to close a banner? How many times have they seen a banner? Have they donated to the WMF? How many edits has the user performed?||No||Yes|
Country, logged-in status and device could conceivable be made available server-side. This would improve performance, since less processing would take place on the client. See the related Phabricator task for more.
Bucket and additional user details will not be available server-side, since they're user-specific. The additional user details should not be associated with users server-side, for privacy reasons.
The list of campaigns and banners available to a user is constructed in PHP and is sent to the client as JSON in the PHP-based ResourceLoader module
The ResourceLoader module
ext.centralNotice.display process the list of available campaigns. If appropriate, it chooses a campaign and a banner, then fetch it via a background call to