> (eg, those misleading metrics, the extra load and storage on the token server) So I'm not too worried about extra load and storage on the tokenserver - if we hadn't made this change, we'd expect the majority of these users to end up fully syncing anyway. I'm also not terribly worried about inflating server-side tokenserver metrics, because I don't believe we monitor those for KPIs etc. Here are my concerns about continuing to get this data from tokenserver: * Allocating users to a storage node when they don't actually intend to sync, might affect the load-balancing of users across nodes, causing some nodes to be underutilized or inflating our measures of how many users can be supported by a given node. * FxA metrics might report that the user has used the "sync" service when they really haven't, affecting segmentation and analysis of retention, conversation rates, and other important metrics. * Due to the above, marketing platform might think the user has used the "sync" service when they really haven't, which might result in the user getting a confusing onboarding experience, or missing out on sync upsell opportunities. I think we can mitigate these concerns while shipping a fairly minimal change by doing the following: 1) Adding a new "look but dont touch" endpoint to tokenserver, which reports the status of a user but doesn't assign them to a storage node if they don't already have one. * I'm thinking `GET /1.0/sync/1.5/userinfo` versus the exisiting `GET /1.0/sync/1.5/` but am open to bikeshedding. * The browser can call this instead of the existing tokenserver endpoint for users who have not enabled sync. * In the future we might be able to use this to report more information about the user, e.g. whether they've made any sync data choices. 2) When Firefox generates a BrowserID assertion in order to talk to said endpoint, have it send `service=5882386c6d801776` in the query parameters rather than `service=sync` (or no `service` parameter, which I think may be the current behaviour). * This will avoid confusing the FxA metrics, which pull the list of used services from values seen in this field. * This will require a partial revert of [this fxa server-side change](https://github.com/mozilla/fxa/pull/2553), but ces't la vie. I'll try to timebox a prototype on the tokenserver side to see if this is reasonable in practice.
Bug 1584356 Comment 9 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
> (eg, those misleading metrics, the extra load and storage on the token server) So I'm not too worried about extra load and storage on the tokenserver - if we hadn't made this change, we'd expect the majority of these users to end up fully syncing anyway. I'm also not terribly worried about inflating server-side tokenserver metrics, because I don't believe we monitor those for KPIs etc. Here are my concerns about continuing to get this data from tokenserver: * Allocating users to a storage node when they don't actually intend to sync, might affect the load-balancing of users across nodes, causing some nodes to be underutilized or inflating our measures of how many users can be supported by a given node. * FxA metrics might report that the user has used the "sync" service when they really haven't, affecting segmentation and analysis of retention, conversation rates, and other important metrics. * Due to the above, marketing platform might think the user has used the "sync" service when they really haven't, which might result in the user getting a confusing onboarding experience, or missing out on sync upsell opportunities. I think we can mitigate these concerns while shipping a fairly minimal change by doing the following: 1) Adding a new "look but dont touch" endpoint to tokenserver, which reports the status of a user but doesn't assign them to a storage node if they don't already have one. * I'm thinking `GET /1.0/sync/1.5/userinfo` versus the exisiting `GET /1.0/sync/1.5/` but am open to bikeshedding. * The browser can call this instead of the existing tokenserver endpoint for users who have not enabled sync. * In the future we might be able to use this to report more information about the user, e.g. whether they've made any sync data choices. 2) When Firefox generates a BrowserID assertion in order to talk to said endpoint, have it send `service=5882386c6d801776` in the query parameters rather than `service=sync` (or rather than sending no `service` parameter, which I think may be the current behaviour). * This will avoid confusing the FxA metrics, which pull the list of used services from values seen in this field. * This will require a partial revert of [this fxa server-side change](https://github.com/mozilla/fxa/pull/2553), but ces't la vie. I'll try to timebox a prototype on the tokenserver side to see if this is reasonable in practice.