http://www.radio1uae.com/sites/default/files/cookiemonster_main.jpg

we are OUT of cookIS???

Here are some types of CentralNotice cookie that could be candidates for removal or transfer to LocalStorage:

1. CN (buckets by campaign)
2. impressionDiet mixin
3. largeBannerLimit mixin
4. hide cookies
5. old-style impression limit cookies set by FR and non-FR banners
6. cookies set by other miscellaneous non-FR banners

I suggest hide cookies (4) be kept on hold until we create a better mechanism for hiding banners across wikis (T117433).

For a few categories, we may want to be able to fall back to cookies if LocalStorage isn't available; we might check again what percentage of our users have that issue.

For cookies set by mixins (2 and 3) I queried the CentralNotice logs for a list of cookies that these mixins have ever set.

impressionDiet

WMAR DesafiosEdicion octubre2015
[empty string]
C15_WMDE_Test01
wmde-fundraising-2015
banner-diet-test
wam-banner-hide
WAM_2015_11_progress_hide
WAM_2015_11_progress_hide-1
centralnotice_bannercount_fr15
WAM_2015_11_progress_hide-2
sciphotogreece
WMNL-register-WCN-2015
bannercount_fundraiser_Dec2015
wmch-fundraising-2015
Fundraising 2015-wmch
wmde-fundraising-thankyou-2015
WMNL-register-drink-2016
WMIL_Wiktionary_Course20152
NorthBrabant
bannercount_fundraiser_2016
bannercount_WMPL_OPP_2016a
wikimania
WMHU_1percent_2016a
WritingWeeksBrussels2016

largeBannerLimit

centralnotice-frbanner-seen-fullscreen

Also, @BBlack has kindly said he might get data on useless cookies we're seeing from clients on production (see T132374).

A query of the banner history logs on Hadoop provides some insight into the percentage of users who get banners but who have problems with LocalStorage. From a sample of 4000 log entries, about 0.4% don't have LocalStorage available in their browsers, and about 0.25% have other LocalStorage errors (file corruption, no space left on device, quota exceeded...). Details are below.

Main questions that I hope we can answer (in view of the above data):

• Do we need to fall back to cookies for users for whom LocalStorage doesn't work?
• If we do need to fall back to cookies, for which features do we need to do so?
• For any features that don't fall back to cookies, what should the banner/campaign functionality be for users without LocalStorage?

Generally, the data shows that only a small percentage of users who ever see banners have problems with LocalStorage. It's probably less than 1%.

(Specifically, it says: Of all users who were targeted by Fundraising campaigns over the last 90 days, who may see banners due to their browsers being compatible with our Javascript, and who don't have Do Not Track enabled in their browsers, probably less than 1% had issues with LocalStorage.)

Here are the features that currently rely on cookies, and that we can consider switching to LocalStorage:

• Bucketing (all campaigns) The "CN" cookie stores which bucket a user is in for each campaign.
• Impression limiting (FR only) For FR only, the impressionDiet mixin uses cookies to count how many banners a user has seen. Non-FR campaigns already use LocalStorage.
• Large banner limiting (FR only) For FR only, the largeBannerLimit mixin uses a cookie to record if a user has seen a large banner. AFIK, non-FR campaigns don't use this feature.

(Two other CentralNotice features also use cookies: GeoIP, and temporarily hiding banners after a user clicks the "close" button. I don't think we should consider switching these features to LocalStorage yet. Regarding the first, GeoIP is used far beyond CentralNotice; changes there should be part of a wider discussion about removing it from CentralNotice. Regarding hiding banners, we can't easily move to LocalStorage because our current way of hiding banners over multiple sites won't work. Instead, I think, we need to look at redoing the whole hide cookie system.)

tl;dr: For bucketing, impression limiting, and large banner limiting, I think we should decide whether a fallback to cookies is needed, and, for any of those features that don't get a cookie fallback, what the functionality should be for users without LocalStorage. That's probably less than 1% of users who currently see banners.

Thanks!!! :)

Some specific proposals, regarding the points just described:

Proposal A

• For bucketing, use LocalStorage, or fall back to a cookie if necessary, on all campaigns.
• For impression limiting and large banner limiting, use LocalStorage, or fall back to cookies if necesssary, only on FR campaigns.
• On non-FR campaigns, follow existing default behaviour for impression limiting and hiding large banners for users without LocalStorage (i.e., in the case of the former, don't show any banners to those users if impressions are being limited, or never show large banner to those users).

Proposal B

• Don't use any cookie fallback. Only serve banners to users with LocalStorage. Don't worry about the less than 1% of users who don't have it.

Proposal C

• Don't use any cookie fallback. For users without LocalStorage: always just use bucket A (but record that this was the case via /beacon/impression, so those users don't mess up A/B test data), show banners randomly some % of the time if banners are being limited, and never show large banners).

Proposal D

• Some combination of the above.

Proposal B is really tempting for consistency. For 'emergency' notifications, are we doing anything to display messages to the javascript-less?

If a 0.65% banner decline is disturbing to fr-all, I'd say go with proposal C. Since we're not touching the hide cookies, we'll at least still quit nagging when people donate.

One other important use of cookies that I don't think was mentioned: long term hiding (250 days) after a user donates.

I think fundraising would be okay just not showing banners for those without working LocalStorage if it's < 1% (Proposal B). However what's the situation with "Do Not Track"? Do we have any idea how many people that is, and what we do for them at the moment?

In T131319#2227327, @Pcoombe wrote:

One other important use of cookies that I don't think was mentioned: long term hiding (250 days) after a user donates.

Ah yes, right! That works almost the same as the hiding when you click on close. In a nutshell, we should leave all "hide" cookies alone for now. (These are the cookies that start with "centralnotice_hide_" and are processed by ext.centralNotice.display.hide.js.)

I think fundraising would be okay just not showing banners for those without working LocalStorage if it's < 1% (Proposal B). However what's the situation with "Do Not Track"? Do we have any idea how many people that is, and what we do for them at the moment?

Currently, the only functionality that changes with "Do Not Track" is banner history (it gets disabled and doesn't send us anything). Since the estimate about LocalStorage availability comes from banner history logs, it can't tell us about those users. However, I don't know any reason users with Do Not Track enabled would have a different rate of LocalStorage availability.

If we go with Proposal B, maybe we could add a data point to /beacon/impression to report when a doesn't have LocalStorage. That way we could monitor the percentage of users left out.

I should also say that Proposal A, while a little more complex, is not at all onerous, and would help site performance just as much as Proposal B for about 99% of users.

Finally: the estimate on LocalStorage availability does have limitations. I haven't broken it down by device type, and it only covers countries where we've fundraised recently. It's possible that for some constituencies (say, maybe, mobile devices in some countries?) the percentage is a bit higher.

Patches for review for T132639 follow Proposal A.

To do this, added limited, optional cookie-based fallback to kvStore...

The main disadvantage that I see so far is that the ext.centralNotice.kvStore RL module is now a dependency of ext.centralNotice.display, which means that it will be loaded for any user for whom there are possible campaigns in choiceData. I can think of a possible way to avoid that, however... (that is... don't store buckets for campaigns with only one bucket, and only load kvStore for users with possible campaigns with more than one bucket in choiceData...) See also T133741.