T54777#7724456 would let us avoid storing preferences and A/B flags on account creation. For tours we could probably reduce storage size (especially once temp users are introduced) by making "not seen" the default value. Changing the default value will be cumbersome though.

Two ideas:

1. Reset user properties to defaults after some period of time (180 days? 90 days?) for inactive users. We delete welcome survey responses after 90 days; it would be like that, but for other properties.
2. Use cookies on account creation for tours instead of database backed user properties

In T304538#7917601, @kostajh wrote:

Two ideas:

1. Reset user properties to defaults after some period of time (180 days? 90 days?) for inactive users. We delete welcome survey responses after 90 days; it would be like that, but for other properties.

I'm not sure that's a good idea. I'm afraid this kinda negates the effect the positive reinforcement project will have on the users, as it will make contributing harder if an user returns back. It's also quite counter-intuitive (and unless the account vanishes in full, unexpected by users).

2. Use cookies on account creation for tours instead of database backed user properties

This sounds like a good idea to me. We might be able to even use a long-expiry WAN cache – I guess it's quite unlikely users will see the tour for their first time in more than a month, so that might be enough.

I think this will roughly fall into three buckets:

• A/B test placements and feature flags: if the core functionality mentioned in T54777#7724456 becomes available, these can probably be rewritten to be functionally equivalent but not store any preference data (other than users manually opting out of their A/B test placement).
• tour "seen" flags, flags for the blue dot thingie: for more obscure tours, it might be fine to stick with the DB. For tours shown to a large fraction of new users (which is the case for most of our tours) we should be cautious about DB use. We could use cookies (disadvantages: users will see the tour again on a different device, inflates response size), local storage (disadvantages: users will see the tour again on a different device, tours must be fully client-side), use the DB with time-limits (ie. don't show the tour if the user is X days old, whether or not they have seen them), use the DB in some more compact way (bitflags?), maybe use global user preferences (less storage space needed, it's on x1 where space is cheaper, probably better UX). Or maybe once A/B / feature-flag preferences are fixed this is not such a big deal anymore.
• genuine data storage, e.g. welcome survey or mentor information. Probably not a big deal in itself if the other issues are solved.

In T304538#7917961, @Tgr wrote:

• tour "seen" flags, flags for the blue dot thingie: for more obscure tours, it might be fine to stick with the DB. For tours shown to a large fraction of new users (which is the case for most of our tours) we should be cautious about DB use. We could use cookies (disadvantages: users will see the tour again on a different device, inflates response size), local storage (disadvantages: users will see the tour again on a different device, tours must be fully client-side), use the DB with time-limits (ie. don't show the tour if the user is X days old, whether or not they have seen them), use the DB in some more compact way (bitflags?), maybe use global user preferences (less storage space needed, it's on x1 where space is cheaper, probably better UX). Or maybe once A/B / feature-flag preferences are fixed this is not such a big deal anymore.

What about using the WANObjectCache for this? When a user registers, we'd create entries in the cache for each tour/navigation guide. As the user completes the tours, interacts with the blue dot, etc, we'd delete the cache item.