Change Details

This task is for CentralNotice code to fix the banner bump, that is, the jump in page content due to banners loading and being injected in the background. The method proposed here to fix this issue is to use ESI (edge-side injection) in the simplest possible way, in the Varnish layer, to add banners directly to the base HTML. Banner content would be retrieved via a call to Special:BannerLoader. Responses from that page would be deterministically based on the contents of a cookie, which would be set by client-side code on the previous pageview. The cookie would contain at least the name of the banner to be injected and the campaign associated with it, though it could also be configured to include additional targeting data points, depending on cache capacity. (Those additional data points are not hard requirements for this approach, but they would help make the system fully responsive to changes in campaign and banner settings.) In addition to allowing banner content to be fully deterministic based on cookie content, this method would require relatively little new code, compared to other possible approaches to fixing the banner bump, since existing CentralNotice client-side code would continue to do the heavy lifting of banner selection, as occurs in the current system. We would run basically all existing client-side code and would retain all existing features for banner selection, impression limiting, data reporting, large-then-small banners, A/B testing, other banner sequences, banner hiding, etc. From the perspective of client-side code, the main difference would be that, instead of loading and injecting a banner, a cookie would be set to request banner injection by the cache on the user’s next pageview. The main disadvantage of this approach is that banners would only be shown the second time a user visits the site, over the course of an active campaign that targets the user. To eliminate the risk to Fundraising that this might entail, we should also include a feature to detect infrequent users who are not likely to return to the site before the end of a campaign. We can guess how likely they are not to return during the campaign based on the value of the WMF-Last-Access cookie, which tells us how long it’s been since the user’s last visit to the site. So, if a user is targeted by an active Fundraising campaign, and if they seem unlikely to return to the site before the campaign ends, we would revert to the current system, and load and inject the banner immediately on that pageview. While this would still cause a banner bump on a small number of pageviews, the overall gains in site usability would be extremely significant.

This task is for CentralNotice code to fix the banner bump, that is, the jump in page content due to banners loading and being injected in the background. The method proposed here to fix this issue is to use ESI (edge-side injection) in the simplest possible way, in the Varnish layer, to add banners directly to the base HTML. Banner content would be retrieved via a call to Special:BannerLoader. Responses from that page would be deterministically based on the contents of a cookie, which would be set by client-side code on the previous pageview. The cookie would contain at least the name of the banner to be injected and the campaign associated with it, though it could also be configured to include additional targeting data points, depending on cache capacity. (Those additional data points are not hard requirements for this approach, but they would help make the system fully responsive to changes in campaign and banner settings.) In addition to allowing banner content to be fully deterministic based on cookie content, this method would require relatively little new code, compared to other possible approaches to fixing the banner bump, since existing CentralNotice client-side code would continue to do the heavy lifting of banner selection, as occurs in the current system. We would run basically all existing client-side code and would retain all existing features for banner selection, impression limiting, data reporting, large-then-small banners, A/B testing, other banner sequences, banner hiding, etc. From the perspective of client-side code, the main difference would be that, instead of loading and injecting a banner, a cookie would be set to request banner injection by the cache on the user’s next pageview. The main disadvantage of this approach is that banners would only be shown the second time a user visits the site, over the course of an active campaign that targets the user. It is possible that for certain campaigns, the lack of a banner on the first pageview could affect response rate. At this writing, without having looked at the data, we can only guess which types of campaigns would be most affected, and to what degree. While we can never know for sure when a user will return to the site, we can probably guess the likelyhood of them returning over the course of a campaign by looking at how long it's been since their last visit. This data point is available in the WMF-Last-Access cookie. To eliminate the risk to any campaign due to the lack of a banner on the first pageview, we can include a feature to revert to the old system, and inject a banner client-side on that pageview, if a user seems unlikely to return before the campaign ends. While this would still cause a banner bump on a small number of pageviews, the overall gains in site usability would still be extremely significant. For campaigns that **must** show a banner on every pageview (like maintenance or blackout campaigns) we can also revert to the old system. A follow-on feature could add a new setting to always inject banners server-side for such "every pageview" campaigns. This should work fine, since such campaigns don't use on randomness or data stored on the client, and all basic targeting information is available server-side (though some extra work would be required to get that information to the code that needs it).

This task is for CentralNotice code to fix the banner bump, that is, the jump in page content due to banners loading and being injected in the background. The method proposed here to fix this issue is to use ESI (edge-side injection) in the simplest possible way, in the Varnish layer, to add banners directly to the base HTML. Banner content would be retrieved via a call to Special:BannerLoader. Responses from that page would be deterministically based on the contents of a cookie, which would be set by client-side code on the previous pageview. The cookie would contain at least the name of the banner to be injected and the campaign associated with it, though it could also be configured to include additional targeting data points, depending on cache capacity. (Those additional data points are not hard requirements for this approach, but they would help make the system fully responsive to changes in campaign and banner settings.) In addition to allowing banner content to be fully deterministic based on cookie content, this method would require relatively little new code, compared to other possible approaches to fixing the banner bump, since existing CentralNotice client-side code would continue to do the heavy lifting of banner selection, as occurs in the current system. We would run basically all existing client-side code and would retain all existing features for banner selection, impression limiting, data reporting, large-then-small banners, A/B testing, other banner sequences, banner hiding, etc. From the perspective of client-side code, the main difference would be that, instead of loading and injecting a banner, a cookie would be set to request banner injection by the cache on the user’s next pageview. The main disadvantage of this approach is that banners would only be shown the second time a user visits the site, over the course of an active campaign that targets the user. To eliminate the risk to Fundraising that this might entailIt is possible that for certain campaigns, the lack of a banner on the first pageview could affect response rate. At this writing, we should also include a feature to detect infrequent users who are not likely to return to the site before the end of a campaign.ithout having looked at the data, Wwe can guess how likely they are not to return during theonly guess which types of campaign based on the value of the WMF-Last-Access cookies would be most affected, which tells us how long it’s been since theand to what degree. While we can never know for sure when a user’s last visit will return to the site., So,we can probably guess the likelyhood of them returning over the course of a campaign by looking at how long it's been since their last visit. if a user is targeted by an active Fundraising campaignThis data point is available in the WMF-Last-Access cookie. To eliminate the risk to any campaign due to the lack of a banner on the first pageview, and if they seem unlikely to returnwe can include a feature to the site beforerevert to the campaign endsold system, we would revert to the current systemand inject a banner client-side on that pageview, and load and inject the banner immediately on that pageviewif a user seems unlikely to return before the campaign ends. While this would still cause a banner bump on a small number of pageviews, the overall gains in site usability would still be extremely significant. For campaigns that **must** show a banner on every pageview (like maintenance or blackout campaigns) we can also revert to the old system. A follow-on feature could add a new setting to always inject banners server-side for such "every pageview" campaigns. This should work fine, since such campaigns don't use on randomness or data stored on the client, the overall gains in site usability would be extremely significantand all basic targeting information is available server-side (though some extra work would be required to get that information to the code that needs it).