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
Here are the criteria that determine which campaign a user gets and which banner is shown. 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.

Server-side
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.

Client-side
The ResourceLoader modules  and   process the list of available campaigns. If appropriate, they choose a campaign and a banner, then fetch it via a background call to  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.