Page MenuHomePhabricator

AMC – Opt-in for logged out users
Closed, DeclinedPublic

Description

NOTE: Please familiarise yourself with the thorough investigation done in T211195: [Spike 16hrs] Investigate opt-in audience and instrumentation, especially T211195#4819336.
NOTE: Allowing AMC users to opt into mobile is not yet on Readers Web's roadmap.

Background

Starting this fiscal year (FY2018-19), Readers Web are introducing the Advanced Mobile Contributions mode to the mobile site (herein "AMC"; see T198313: [GOAL] Advanced mobile contributions for the rationale, a high-level overview of the project, and links to on-wiki documentation). Like the beta mobile mode, users will have to opt-in to AMC mode but note well that users can opt into either mode independently.

During discussions around T210653: [EPIC] AMC - Opting in and in T211195: [Spike 16hrs] Investigate opt-in audience and instrumentation Readers Web decided that the complexity of allowing logged out users to opt into AMC was such that it should be de-scoped until they've shipped a set of AMC features.

One aspect of the complexity of allowing logged out users to opt into AMC is how we can deliver different HTML and assets to the UA:

In T211195: [Spike 16hrs] Investigate opt-in audience and instrumentation, @pmiazga noted that if you've opted into mobile beta mode, then you'll always miss the edge caches. Per T182235#4752852, this isn't too worrisome, as mobile beta mode pageviews constitute ~0.5% of all mobile pageviews.

Should the edge caches behave the same way for users who've opted into AMC?

Considerations

  • Missing the edge caches incurs a performance penalty which may bias a user's perception of the AMC, should we serve these requests from the edge caches?
    • Do we know what performance penalty a logged in mobile site user incurs?
  • Readers Web can't estimate how many logged out users would opt in, so we can't be sure about what pressure we'd put on the edge caches
  • Readers Web are generally unsure of SRE/Traffic's feeling towards splitting the edge caches

Event Timeline

@Joe: Here's the task I promised to create during the Readers Web/Readers Infra/Services/SRE interlock meeting on Wednesday, 23rd January /cc @ggellerman

Thanks @phuedx for opening the task!

I would want to involve Traffic in the discussion, but first let me make sure I've understood your needs:

based on an opt-in feature, you want to be able to show a different version of some pages to users of the mobile frontend; and you're wondering about how caching might work best in this case.

Is my understanding of the problem correct?

@Joe: Yes. That's correct. Do note that this is the current behaviour for the beta mode of the mobile site (visit https://m.mediawiki.org/wiki/Special:MobileOptions and enable "MediaWiki ß"). I think it's worth wondering how caching best works for both that and this new opt-in feature.

@ovasileva @phuedx is it useful to still have this ticket open? If so, should it be in Readers-Web-Backlog or tracking?

BBlack added a subscriber: BBlack.

The swap of Traffic for Traffic-Icebox in this ticket's set of tags was based on a bulk action for all tickets that aren't are neither part of our current planned work nor clearly a recent, higher-priority emergent issue. This is simply one step in a larger task cleanup effort. Further triage of these tickets (and especially, organizing future potential project ideas from them into a new medium) will occur afterwards! For more detail, have a look at the extended explanation on the main page of Traffic-Icebox . Thank you!

Declining. This is not currently a part of our roadmap