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.
To choose a campaign and a banner, CentralNotice uses a mixed system: first, the server creates a list of possible campaigns and banners for the user, based on the information it has available. Then, JavaScript in the browser filters this list, makes the final selection, fetches the chosen banner from the server, and injects it into the DOM.
Following are more details about how this works.
Criteria
editHere 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 |
| Language | 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.
Stages
editServer-side
editThe 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 ext.centralNotice.choiceData.
Client-side
editThe 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 Special:BannerLoader and inject it into the DOM. Processes involving additional user details are currently handled by JavaScript included in banners, but this will change soon; see Campaign-associated mixins and banner history.