As discussed here: https://bugzilla.mozilla.org/show_bug.cgi?id=1019395#c4; we want to count users who are coming through FxA pages from sync migration notifications. Pass "entrypoint=migration" in these cases: - create account - attach account - resend email - forget email/account (assuming this button from the pre-verified state invokes a fxa-content-server api)
Drew, this will impact the front-end stuff you are doing. Katie: one concern I have here is that we then lose exactly *what* migration entry-point was used - ie, I'd have thought we want to be able to differentiate between the infobar, the hamburger menu and the sync prefs pane. Would it maybe make sense to add a new query param - something like ?entryPoint=menupanel&isMigration=true?
:markh, yeah, I was looking at the hamburger menu invoking the sync prefs, but now I see thats not true in all cases (and that doesn't count the infobar). Probably a good idea to separate the as you propose, fxa-content-server issue here: https://github.com/mozilla/fxa-content-server/issues/1906
:ckarlof, can you weigh in on the new query param proposed? "isMigration=true"
(In reply to Katie Parlante from comment #2) > :markh, yeah, I was looking at the hamburger menu invoking the sync prefs, > but now I see thats not true in all cases FTR, I believe it is only there for FxA based accounts. Part of the migration is that "legacy" accounts will now also see an entry in the hamburger (the first sync-related entry they will have ever seen) which will start the migration process - after that they'll be an FxA user and will see permanently get the entry taking them to prefs. > (and that doesn't count the infobar). Yeah - if we add a new "infobar" entrypoint we know it *must* be from a migration - but we might as well be consistent (ie, both a new entrypoint for the infobar and it always includes the migration param too)
Sounds generally ok. Stylistically, we already have a mix of camel case and snake case in our URL params, so it would be nice to be ambiguous about that. :) migration=true? Since this may not be the last migration, we might consider being more explicit. migration=sync1.1? or it could be to what we're migrating to: migration=sync1.5
(In reply to Chris Karlof [:ckarlof] from comment #5) > Since this may not be the last migration, we might consider being more > explicit. migration=sync1.1? or it could be to what we're migrating to: > migration=sync1.5 Sure, lets go with migration=sync1.5
oops - I forgot about this bug and landed that query param in bug 1119104 (although note we went with migration=sync11 to reflect where we were coming from rather than where we were going to)