1162192 - Add Google Analytics conversion tracking to https://accounts.firefox.com/

Status: RESOLVED FIXED

(Cloud Services :: Server: Firefox Accounts, defect)

Description

[Ben Niolet]

We would like to add Google Analytics tracking to https://accounts.firefox.com/

This is important as we use the spring 2015 campaign to drive users to create Firefox accounts. We don't currently have a landing page to drive users to, so as our various channels (social, email and snippet) encourage Firefox Accounts creation, we need a way to measure conversions for testing and optimization purposes.

Comment 1

[Ryan Kelly [:rfkelly]]

Putting third-party javascript on that page will substantially weaken our security story around the encryption in Firefox Accounts.

Perhaps we can measure what we need using the custom metrics system we already have in place?  I'm adding Shane Tominlson who's most familiar with that system.  Shane, thoughts?

Comment 2

[Ryan Kelly [:rfkelly]]

Ben, it'd be great if you could give a bit more of a breakdown of the kind of things you'd like measured for the spring campaign.  It's possible we're already tracking some of them and just need to set you up with the right access, or funnel the data over to the appropriate place.

Comment 3

[Ben Niolet]

Hey Ryan. Totally get it, about GA being a bad idea. 

Here's what we'd want: 

We want to track the number of accounts created on that page by source. So if we were using GA, we'd have UTM tags in our various URLs to the page that would allow us in GA to create a breakdown of which channel drove x number of conversions. Email xx percent of total YY and social / Facebook zz percent of total yy and so on. 

Our hope was that if it were GA it would be fairly simple to incorporate this data into the user engagement metrics dashboard we're launching this quarter. Ideally this is information that we can tap into for the spring campaign as well as on an ongoing basis for the dashboard that will track key organizational metrics (browser downloads, accounts created, etc).

Comment 4

[[e-mail]]

Hey team! Similar to how we can directly track back campaigns and content to Firefox downloads, our hope is that we can do the same thing with Accounts. It would be valuable to identify what kind of content works, and what kind of content doesn't in driving accounts sign ups. 

One thought is that we create an Accounts Web page that we can track do, and look at conversion from there. It would contain all of the value props for Accounts. 

I don't think this is going to happen in Q2, but we'd love to find a way to track our efforts and optimize accordingly if we can in the meantime!

Comment 5

[Shane Tomlinson [:stomlinson]]

Hi Ben,

Before saying what we already have that may accommodate your needs, what circumstances are you going to be sending users to FxA? There is not much value in signing up for an FxA account unless the authentication cycle is used to sign into a relying service.

That said, we have two fields [1][2] in place that may offer you the data you are after: campaign and entrypoint. These are currently only collected when FxA is opened by Firefox desktop, but it should be pretty trivial to have that data collected in other scenarios.

`campaign` is meant to be the campaign identifier, e.g., "spring_2015_fx_for_ios" or something similar. Perhaps that is similar to a UTM tag.
`entrypoint` has so far been pretty specific to the browser - if the user opens FxA from preferences, `entrypoint` is `prefs` for example. We could also expand this to include a URI or some other identifier that represents where the user came from.

This data is sent to the Heka metrics infrastructure, which Katie Parlante could probably help you with.


[1] - https://github.com/mozilla/fxa-content-server/blob/cdd999e395d560f67762c3b3d258859e5852902a/app/scripts/models/reliers/fx-desktop.js#L23
[2] - https://github.com/mozilla/fxa-content-server/blob/cdd999e395d560f67762c3b3d258859e5852902a/app/scripts/models/reliers/fx-desktop.js#L25

Comment 6

[Chris More [:cmore]]

This is a duplicate of bug 971963, but we need to revisit it since a lot has changed since the old bug was filed.

Comment 7

[Ben Niolet]

Thanks Ryan and Shane. 

I misspoke (mistyped?) somewhat when I filed this bug. As Michaela noted above, the real need here is for our dashboard project which is meant to be a high level look at how our channels are performing against key company metrics. 

Adding Josephine Tanumijaya, who is building the dashboard for relationship marketing (the team formerly known as user engagement). The idea is that KPIs such as Firefox Accounts created will feed into this dashboard and give us insight into the extent to which our channels (social, snippet and email) are driving these types of conversions. 

Josephine, this NI is to catch you up on the bug topic. Can you review Shane's comment above and see if there is any potential link up with the data collection scenario he outlined.

Comment 8

[[:josephine]]

Chris, 

Thanks for the info on bug 971963. That is really useful. Are you currently loading any of the data provided by Katie Parlante to GA or other means?

I'm adding Katie on this bug. We might have to discuss ways to get the data from her.

Comment 9

[Chris More [:cmore]]

I talked to Josephine and mentioned that she should talk to Shane Tomlinson about how the metrics work on accounts.firefox.com and to see if we can parse any of the data to do attribution by channel.

Comment 10

[Katie Parlante]

Josephine, we can get you a rollup of the appropriate client-metrics data (the data that is being collected by accounts.firefox.com) in whatever format is useful (tsv files, redshift tables, etc.). Perhaps the next step is for you and Shane to define what fields that rollup should contain (I can help as well).

Once that is defined and we know what we want to do, log a bug against Mozilla Services::Metrics: Pipeline to get the filters written to create the rollup.

Comment 11

[[:josephine]]

Hi Katie,

Thanks! Before deciding on which format, can I get a sample data of the firefox accounts? For Michaela's team, there is specific information that they want to be able to track, eg. account signups are driven from the campaigns done in social (facebook & twitter), email and snippet.

So could you please send a sample data of all the fields you are tracking on firefox account?

Comment 12

[Katie Parlante]

Josephine, we're getting you access to the fxa data: https://bugzilla.mozilla.org/show_bug.cgi?id=1164983

Comment 13

[Shane Tomlinson [:stomlinson]]

The content server portion of the code needed to specify `campaignId` and `entrypoint` has been merged [1]. This feature should make its way to production on FxA train 38, which will be sent to prod the week of June 1st.


[1] - https://github.com/mozilla/fxa-content-server/pull/2432

Comment 14

[Ryan Kelly [:rfkelly]]

Hi Josephine, just to sanity-check as we come up to the release, do you need further action from us on the FxA side of things before June 2nd?

IIUC the next action here is to define some metrics rollups to feed into your dashboards.  If this is happening in other bugs, please link them here for context.

> there is specific information that they want to be able to track,
> eg. account signups are driven from the campaigns done in social (facebook & twitter), email and snippet.

Any incoming links from these will need to specify the query parameters outlined by Shane in Comment 5.  Once details are finalized, it would be great if you could summarize the `campaign` and/or `entrypoint` values we should expect in this bug.  That way we can keep on eye out for them in production and make sure things are working smoothly.

Comment 15

[[:josephine]]

Hi Ryan,

I set up a meeting with Shane to discuss details on the two fields: campaign and entrypoint, tomorrow. What I'd like to find out is the process of how the two fields are being populated, by whom, is Michaela's team (Community Marketing) getting involved in determining the campaign and entrypoint for the Fx Account registration?

Shane, please let me know if the timing works for you. Liz, I think you need to come to this meeting as well. I'll send you an invite. Ryan, you're welcome to join us too!

Thanks,
Josephine

Comment 16

[Shane Tomlinson [:stomlinson]]

Josephine, that time works for me.

I do not believe anybody is using `campaign`. `entrypoint` is only sent by the browser when the user is signing in to Sync. If the user is signing in from the about:home, one value is sent, if from the preferences#sync panel, another value. I am unsure of what those values are currently, but we could just as easily pass either a URL or another known identifier that can be used to search through metrics.

Comment 17

[Katie Parlante]

Here's the bug for passing along the campaign id, this needs to get implemented: https://bugzilla.mozilla.org/show_bug.cgi?id=1084622

Here's a scenario where its needed:
- sample tweet: https://twitter.com/firefox/status/602889379367886848
- The bit.ly link includes information for GA:
https://www.mozilla.org/en-US/firefox/sync/?utm_source=twitter&utm_medium=social&utm_content=sm5252015&utm_campaign=sync
- Clicking on "Get started" invokes the account signup page with the entrypoint, but no "campaign":
about:accounts?action=signup&entrypoint=uitour

A slightly different scenario:
- sample tweet: https://twitter.com/firefox/status/524590991248855040
- the bit.ly link goes directly to: https://accounts.firefox.com/signup?utm_source=firefoxsocialmedia

Instead of utm_source=firefoxsocialmedia, perhaps get the team doing the tweeting to use something like entrypoint=firefoxsocialmedia&campaign=<someid>

Comment 18

[Ryan Kelly [:rfkelly]]

Without committing to anything...in the future, I don't think it'd be out of the question for us to look for these "utm_*" query parameters and either normalize them into our own "endpoint/campaign" pararms, or just include them in our metrics event tagging directly.

That won't ship for June 2 though; campaign= and entrypoint= are all we will have for that timeframe.

Comment 19

[[:josephine]]

Updating on the discussion with Shane yesterday:
- the Kibana access that I went through with Katie is client data
- client data is sampled, 10% of actual account registration
- the registration is a 2 steps process: step 1 - register and step 2 - verify email
- the client data does not link the 2 steps ie we don't know if the person who did the 1st step had done the 2nd step. So we have 10% of people who did the 1st step and 10% of people who did the 2nd step, but they can be different or the same people in each of the 10%.

After much discussion with the Community Marketing team, the following are the requirements for account registrations:
1. actual account registration data is required, not sampled
2. they want to be able to count number of people who complete step 1 (register) and step 2 (verify email)

Now the question is: Katie, can we have this data from the server logs? If yes, who should we talk to?

Thanks,
Josephine

Comment 20

[Ryan Kelly [:rfkelly]]

We can get total counts of "/account/create" and "/recovery_email/verify_code" from the server logs, but they will not be broken down by the "entrypoint" or "campaign" parameters since we don't see those on the server side.  (Unless we're extremely very lucky and can see them in the Referer header, but I wouldn't count on that for the verification case).

Comment 21

[[:josephine]]

For the Community Marketing team, sample data is not useful to track their campaign. 

Will there be any plans to get 100% of data on the client side? If not, is there any other way the Community Marketing team can track and measure their campaigns for account registration?

Comment 22

[Katie Parlante]

Ryan is correct: we can get a very accurate count of people who complete step 1 and 2, but we have no way to segment that by entrypoint or campaign.

Comment 23

[Ryan Kelly [:rfkelly]]

> Will there be any plans to get 100% of data on the client side?

Yes, we can certainly work towards doing this and I think it's probably the right approach long-term.  Unfortunately we won't be able to ramp up to 100% in time for the June 2 campaign.

Comment 24

[Ryan Kelly [:rfkelly]]

I feel like we could get a pretty decent estimate of totals by combining the sampled client-side metrics with absolute counts from the server.  Unfortunately I can't think of a good short-term solution for hitting requirements from Comment 19.

Comment 25

[[:josephine]]

Hi Ryan,

I spoke with Michaela and the team. It doesn't have to be ready by June 2 campaign. 

But we definitely want to do it right. It would be good to discuss requirements further and take into account the future forwards, eg Android, or other demographic such as country and locale...I'm just throwing of ideas here but we do need to discuss. Please let me know the best time for us to chat and who else we should include in the chat.

Thanks,
Josephine

Comment 26

[Ryan Kelly [:rfkelly]]

(/cc :edwong for project management and planning context)

Shane is probably the best person to drive this from our side, but he's PTO this week.  I'm happy to chat e.g. tomorrow to ensure we can keep things moving forward, will reach out in priv msg to make a time.

Comment 27

[Shane Tomlinson [:stomlinson]]

ref https://github.com/mozilla/fxa-content-server/issues/2579

Comment 28

[[:josephine]]

Last conversation with Ryan Kelly and Chris More Jun 5th:
- Chris sent list of fields used by GA that can be added to Fx Accounts:
source,medium,campaign
- Also from comment 25: adding country, locale and products (desktop,android,fxos)

Please let me know if this is in the works for this quarter.

Comment 29

[Ryan Kelly [:rfkelly]]

Yes indeed, this will be part of our work in Q3.

> - Chris sent list of fields used by GA that can be added to Fx Accounts:

Preliminary work on capturing and forwarding GA metrics is being worked on currently and will hopefully be included in the next FxA deployment:

  https://github.com/mozilla/fxa-content-server/pull/2689

We're also working to ensure that metrics sampling is consistent across email verification loops:

  https://github.com/mozilla/fxa-content-server/pull/2688

A final step for getting you what you need with GA might be something like "sample metrics at 100% when there are utm_* parameters present".

> - Also from comment 25: adding country, locale and products (desktop,android,fxos)

We already include user-agent details in our logs, and it seems straightforward to include the Accept-Languge header.  For country, will we have to do some sort of geo-lookup based on IP address or similar?

I filed the following to track these requests:

  https://github.com/mozilla/fxa-content-server/issues/2717
  https://github.com/mozilla/fxa-content-server/issues/2718

From the previous comment, country and locale were "just throwing of ideas here" - can you give us a suggestion on the relative importance of logging these extra features?

Comment 30

[Katie Parlante]

(In reply to Ryan Kelly [:rfkelly] from comment #29)
> > - Also from comment 25: adding country, locale and products (desktop,android,fxos)
> 
> We already include user-agent details in our logs, and it seems
> straightforward to include the Accept-Languge header.  For country, will we
> have to do some sort of geo-lookup based on IP address or similar?
> 
> I filed the following to track these requests:
> 
>   https://github.com/mozilla/fxa-content-server/issues/2717
>   https://github.com/mozilla/fxa-content-server/issues/2718
> 
> From the previous comment, country and locale were "just throwing of ideas
> here" - can you give us a suggestion on the relative importance of logging
> these extra features?

IIRC client metrics currently includes "lang" -- not sure if this comes from the Accept-Language header. FWIW, we're doing IP based lookup for unified telemetry on the heka edge nodes -- arguably we should set this up for all the cloud server logs.

Comment 31

[Ryan Kelly [:rfkelly]]

> IIRC client metrics currently includes "lang"

So it does!  I actually went looking for that before filing the bug, but must have skimmed right over it.  Thanks Katie.

Comment 32

[Vlad Filippov (:vladikoff)]

>  Our hope was that if it were GA it would be fairly simple to incorporate this data into the user 
> engagement metrics dashboard we're launching this quarter. Ideally this is information that we can tap
> into for the spring campaign as well as on an ongoing basis for the dashboard that will track key
> organizational metrics (browser downloads, accounts created, etc).


We had a bit more discussion about this and we are going to try connect our existing client metrics and send GA events from the **server**.

However, we need a bit of help from the Growth Team. Is there someone who can explain the current GA campaign setup and which events are important to the Growth team. Meeting someone on Vidyo for ~30 minutes would be really useful.

Comment 33

[[:josephine]]

Chris More is the contact from the Growth Team. He's in this bug too.

Comment 34

[Chris More [:cmore]]

Yup! I can help.

Who should I send an invite to?

Comment 35

[Chris More [:cmore]]

Please use the GA UA ID here for the measurement protocol pings to GA from FxA:

https://bugzilla.mozilla.org/show_bug.cgi?id=971963#c0

Comment 36

[Chris More [:cmore]]

Gareth: please add recommendations on the event category, name, label (UA spec) for the FxA team to pass to GA.

Comment 37

[Chris More [:cmore]]

Shane: Please let me know all of the non-productions instances of accounts.firefox.com hostnames. Also, please let me know all @mozilla.com emails that should have access to the GA account for testing and to see the data.

Comment 38

[Gareth Cull [:garethc]]

Let's use this doc to fill in all of the triggers and events that we'll want to pass to GA:
https://docs.google.com/spreadsheets/d/14Uo2wY_grgSHs-gJ6RFrc_IF54j2C7p-MM5JJT4794M/edit#gid=0

Comment 39

[Shane Tomlinson [:stomlinson]]

cmore, these are the folks we'd like to add to the GA account:

* [e-mail] (myself)
* [e-mail] (Vladislav Filippov, dev)
* [e-mail] (Ryan Feeley, UX)
* [e-mail] (Ryan Kelly, manager)
* [e-mail] (Chris Karlof, manager)

Data will be sent from the following servers:
* dev stacks - https://*.dev.lcip.org/
* stage - https://accounts.stage.mozaws.net/
* production - https://accounts.firefox.com/

If *.dev.lcip.org is too open-ended, the servers can be restricted to:
* latest development - https://latest.dev.lcip.org/
* stable testing - https://stable.dev.lcip.org/

Comment 40

[Gareth Cull [:garethc]]

cmore,

I updated the event naming conventions for accounts in the doc mentioned in comment 38. Can you please review? What other triggers would you like to have? Also not sure if we need labels for some of these events...what do you think?

Comment 41

[Vlad Filippov (:vladikoff)]

(In reply to Gareth Cull [:garethc] from comment #40)
> cmore,
> 
> I updated the event naming conventions for accounts in the doc mentioned in
> comment 38. Can you please review? What other triggers would you like to
> have? Also not sure if we need labels for some of these events...what do you
> think?

I seem to be getting "to use this feature visit: EVENT-TRACKING.COM" when I try to submit events without a value (i.e no `ev`). Have you seen that before? What value do you prefer for that ? I can just put "1" if we have no values.

See image: http://v14d.com/i/55ad46b7ef9cd.png

Comment 42

[Vlad Filippov (:vladikoff)]

This what the events look like in my dev env:  http://v14d.com/i/55ad4efc13825.png

Comment 43

[Vlad Filippov (:vladikoff)]

Chris, Gareth, We are going to be using the UA- from this comment: https://bugzilla.mozilla.org/show_bug.cgi?id=1162192#c35

Please let us know if that is not correct ahead of deployment. 

Could you also add the list of developers to the GA dashboard? See https://bugzilla.mozilla.org/show_bug.cgi?id=1162192#c39

Comment 44

[Shane Tomlinson [:stomlinson]]

I'm happy to report that [1][2][3] and [4] have all merged in the fxa-content-server.

[1] - https://github.com/mozilla/fxa-content-server/pull/2689
[2] - https://github.com/mozilla/fxa-content-server/pull/2787
[3] - https://github.com/mozilla/fxa-content-server/pull/2756
[4] - https://github.com/mozilla/fxa-content-server/pull/2779

What we have now:

* GA utm_* query params are consumed and sent to our metrics infrastructure.
* A user is able to be correlated from signup->verification, even if they verify on a second device. 
* GA based metrics are not sampled.
* GA events are reported to GA from our backend.

This should go into our stage server today or tomorrow for testing to begin.

Comment 45

[Chris More [:cmore]]

(In reply to Shane Tomlinson [:stomlinson] from comment #39)
> cmore, these are the folks we'd like to add to the GA account:
> 
> * [e-mail] (myself)
> * [e-mail] (Vladislav Filippov, dev)
> * [e-mail] (Ryan Feeley, UX)
> * [e-mail] (Ryan Kelly, manager)
> * [e-mail] (Chris Karlof, manager)
> 
> Data will be sent from the following servers:
> * dev stacks - https://*.dev.lcip.org/
> * stage - https://accounts.stage.mozaws.net/
> * production - https://accounts.firefox.com/
> 
> If *.dev.lcip.org is too open-ended, the servers can be restricted to:
> * latest development - https://latest.dev.lcip.org/
> * stable testing - https://stable.dev.lcip.org/

I've added all the users above to the accounts.firefox.com web property.

I then created two additional views for dev and stage instances with specific sub-domain filters. 

See attachment below.

Comment 46

[Chris More [:cmore]]

Attachment: accounts.firefox.com instances

Comment 47

[Vlad Filippov (:vladikoff)]

This is done and live with Train-42.

Comment 48

[Chris More [:cmore]]

After talking to :vladikoff, non-prod accounts.firefox.com instances will use separate UA-xxxxx strings and thus I am going to delete the non-prod instances in GA. Also, since the GA requests are being sent server-side, I cannot do hostname filtering thus I will remove all filters.

Comment 49

[Jean Collings]

Josephine, 
Picking up from Comment 25 - can you help me clarify where we landed on being able to track Accounts sign ups when we point users to mozilla.org/firefox/sync? I know once users land on that page and click on the "Let's Sync" button - it goes to about:accounts but I think that's where the tracking ends.

I also know we can track GA via accounts.firefox.com but we don't send users there directly. Any insight would be helpful as I know that one of our marketing KPIs is to get email opt-ins which majority will be driven through Accounts. It's very important that we can track sign ups from any given source (email, snippets, etc.).

Thanks!

Comment 50

[Chris More [:cmore]]

Shane/Vlad: do you know if we have any analytics in FxA on about:accounts as Jean mentioned above or it is only on the website known as accounts.firefox.com? Does about:accounts contain an iframe to accounts.firefox.com?

Comment 51

[Vlad Filippov (:vladikoff)]

> it is only on the website known as accounts.firefox.com?

Yeap that's correct, about:accounts is just an iframe

Comment 52

[Chris More [:cmore]]

(In reply to Vlad Filippov :vladikoff from comment #51)
> > it is only on the website known as accounts.firefox.com?
> 
> Yeap that's correct, about:accounts is just an iframe

Ok, so if about:accounts is just an iframe, is the iframe pointing to accounts.firefox.com?

Comment 53

[Vlad Filippov (:vladikoff)]

(In reply to Chris More [:cmore] from comment #52)
> (In reply to Vlad Filippov :vladikoff from comment #51)
> > > it is only on the website known as accounts.firefox.com?
> > 
> > Yeap that's correct, about:accounts is just an iframe
> 
> Ok, so if about:accounts is just an iframe, is the iframe pointing to
> accounts.firefox.com?

Yeap! it's similar to the first run flow. For the first run flow we have a system in place where all utm_ params that are passed to it get passed to the iframed accounts.firefox.com. I don't believe the about:accounts iframe has the same in place

Comment 54

[Chris More [:cmore]]

(In reply to Vlad Filippov :vladikoff from comment #53)
> (In reply to Chris More [:cmore] from comment #52)
> > (In reply to Vlad Filippov :vladikoff from comment #51)
> > > > it is only on the website known as accounts.firefox.com?
> > > 
> > > Yeap that's correct, about:accounts is just an iframe
> > 
> > Ok, so if about:accounts is just an iframe, is the iframe pointing to
> > accounts.firefox.com?
> 
> Yeap! it's similar to the first run flow. For the first run flow we have a
> system in place where all utm_ params that are passed to it get passed to
> the iframed accounts.firefox.com. I don't believe the about:accounts iframe
> has the same in place

Ok, makes sense. Good to know. As Jean mentioned in comment 49, is there any problem with pointing people to accounts.firefox.com instead of about:accounts since we can pass UTM tags to accounts.firefox.com?

Comment 55

[Shane Tomlinson [:stomlinson]]

(In reply to Chris More [:cmore] from comment #54)
> (In reply to Vlad Filippov :vladikoff from comment #53)
> > (In reply to Chris More [:cmore] from comment #52)
> > > (In reply to Vlad Filippov :vladikoff from comment #51)
> > > > > it is only on the website known as accounts.firefox.com?
> > > > 
> > > > Yeap that's correct, about:accounts is just an iframe
> > > 
> > > Ok, so if about:accounts is just an iframe, is the iframe pointing to
> > > accounts.firefox.com?
> > 
> > Yeap! it's similar to the first run flow. For the first run flow we have a
> > system in place where all utm_ params that are passed to it get passed to
> > the iframed accounts.firefox.com. I don't believe the about:accounts iframe
> > has the same in place
> 
> Ok, makes sense. Good to know. As Jean mentioned in comment 49, is there any
> problem with pointing people to accounts.firefox.com instead of
> about:accounts since we can pass UTM tags to accounts.firefox.com?


Your proposal would likely get a huge thumbs up from Mark Hammond, who has been advocating scrapping about:accounts for the past year. 

Allowing users to sign up to Sync sans about:accounts is not a technical problem, the firstrun flow proves this. The problems will instead be UX, and possibly server load. about:accounts and about:preferences#sync have state machines that allow graceful screen transitions whenever the user's account status changes. The server load comment is because FxA embedded in about:accounts prevents a problem where both the browser and FxA poll for the user's verification status [1]. With push notifications we should be able to mitigate at least the browser half of the problem.

What is the concrete goal, to send users to FxA to sign up for Sync from different social media campaigns, and have the campaign tracked?

Adding markh and rfeeley for their input.

[1] - https://github.com/mozilla/fxa-content-server/issues/2038

Comment 56

[Mark Hammond [:markh] [:mhammond]]

While Shane's correct about me wanting to get rid of about:accounts, that's not trivial nor a high priority. It sounds like we just need some URL params to get passed through about:accounts?

(In reply to Jean Collings from comment #49)
> Picking up from Comment 25 - can you help me clarify where we landed on
> being able to track Accounts sign ups when we point users to
> mozilla.org/firefox/sync?

Where is the code for this? I'm guessing it uses the UITour "showFirefoxAccounts" message to do this? If so, the accounts.firefox.com URL should get "entrypoint=uitour" but no other campaign tracking.

> I know once users land on that page and click on
> the "Let's Sync" button - it goes to about:accounts but I think that's where
> the tracking ends.

Right - so if what I said above is true, it shouldn't be difficult to get additional params passed through this funnel.

Shane, can you point at us the magic behind mozilla.org/firefox/sync?

Comment 57

[Shane Tomlinson [:stomlinson]]

:markh(In reply to Mark Hammond [:markh] from comment #56)

> Shane, can you point at us the magic behind mozilla.org/firefox/sync?

That is magic that I do not know. :jpetto works on bedrock, passing the ni-buck.

Comment 58

[[e-mail]]

(In reply to Shane Tomlinson [:stomlinson] from comment #55)
> (In reply to Chris More [:cmore] from comment #54)
> > (In reply to Vlad Filippov :vladikoff from comment #53)
> > > (In reply to Chris More [:cmore] from comment #52)
> > > > (In reply to Vlad Filippov :vladikoff from comment #51)
> > > > > > it is only on the website known as accounts.firefox.com?
> > > > > 
> > > > > Yeap that's correct, about:accounts is just an iframe
> > > > 
> > > > Ok, so if about:accounts is just an iframe, is the iframe pointing to
> > > > accounts.firefox.com?
> > > 
> > > Yeap! it's similar to the first run flow. For the first run flow we have a
> > > system in place where all utm_ params that are passed to it get passed to
> > > the iframed accounts.firefox.com. I don't believe the about:accounts iframe
> > > has the same in place
> > 
> > Ok, makes sense. Good to know. As Jean mentioned in comment 49, is there any
> > problem with pointing people to accounts.firefox.com instead of
> > about:accounts since we can pass UTM tags to accounts.firefox.com?
> 
> 
> Your proposal would likely get a huge thumbs up from Mark Hammond, who has
> been advocating scrapping about:accounts for the past year. 
> 
> Allowing users to sign up to Sync sans about:accounts is not a technical
> problem, the firstrun flow proves this. The problems will instead be UX, and
> possibly server load. about:accounts and about:preferences#sync have state
> machines that allow graceful screen transitions whenever the user's account
> status changes. The server load comment is because FxA embedded in
> about:accounts prevents a problem where both the browser and FxA poll for
> the user's verification status [1]. With push notifications we should be
> able to mitigate at least the browser half of the problem.
> 
> What is the concrete goal, to send users to FxA to sign up for Sync from
> different social media campaigns, and have the campaign tracked?
> 
> Adding markh and rfeeley for their input.
> 
> [1] - https://github.com/mozilla/fxa-content-server/issues/2038

Hi Shane -- to your question about our goal:

It is a topline Marketing goal to increase Account sign ups. In order for us to meet this (across all marketing initiatives from social efforts, to email efforts, to in-product communications efforts, to ad efforts, to Website efforts and more), we need to be able to track and optimize our content performance. 

My suggestion is to change all Web links that point to about:accounts and make them point to accounts.firefox.com, so that we're able to tag our link parameters and dig into Google Analytics data. 

Thoughts?

Comment 59

[Vlad Filippov (:vladikoff)]

ni'ing Ryan Kelly :)

Comment 60

[Ryan Kelly [:rfkelly]]

> My suggestion is to change all Web links that point to about:accounts and make them
> point to accounts.firefox.com

I'm pretty sure web content *can't* link to about:accounts (or to about: URLs in general) so the only place we have to worry about this is on the https://mozilla.org/firefox/sync/, which uses special APIs provided by the browser to trigger it.

So there's potentially two related tasks to spin out of this:

* adjust the magic that supports /firefox/sync so that it can pass through tracking parameters
* agree on a strategy and URL format for other campaigns to link to accounts.firefox.com directly

Leaving ni? for myself because I want to come back to this with some more details later today

Comment 61

[Mark Hammond [:markh] [:mhammond]]

(In reply to Ryan Kelly [:rfkelly] from comment #60)
> So there's potentially two related tasks to spin out of this:
> 
> * adjust the magic that supports /firefox/sync so that it can pass through
> tracking parameters

Hopefully :jpetto can tell us about this. Also, a related task here will be front-end changes to allow these to be passed down.

> * agree on a strategy and URL format for other campaigns to link to
> accounts.firefox.com directly

The details escape me, but IIRC there are one or 2 issues that leave us preferring about:accounts. It may simply be the "choose what to sync" support, but that's been addressed in 45 (ie, it may be that we can only hit accounts.firefox.com when the UA indicates 45 or later?). Regardless, once we get to the point where the flow works well enough to avoid about:accounts, we might as well then kill about:accounts!

Comment 62

[Jonathan Petto [:jpetto]]

Unfortunately, I am not the magician you're looking for. On mozilla.org/firefox/sync, we use the UITour library [1] to open up about:accounts [2]. The query params added to about:accounts are dictated by the UITour lib. As far as I understand it, changes to UITour require changes to the Firefox product.

It sounds like the use case is for UITour to check for a pre-defined set of query params in the current URL and pass those along to about:accounts? Is that accurate?

MattN - Could you let us know if adding such functionality to UITour would be feasible?

[1] http://bedrock.readthedocs.org/en/latest/uitour.html
[2] https://github.com/mozilla/bedrock/blob/master/media/js/firefox/sync.js#L136

Comment 63

[Mark Hammond [:markh] [:mhammond]]

(In reply to Jon Petto [:jpetto] from comment #62)
> Unfortunately, I am not the magician you're looking for. On
> mozilla.org/firefox/sync, we use the UITour library [1] to open up
> about:accounts [2]. The query params added to about:accounts are dictated by
> the UITour lib. As far as I understand it, changes to UITour require changes
> to the Firefox product.

Thanks - that's the information I was looking for.

> https://github.com/mozilla/bedrock/blob/master/media/js/firefox/sync.js#L136

I'm confident we could change the UITour libs to pass url params down - but I'm not sure who would need to change the line above to pass the appropriate params down?

(clearing ni? on MattN as I think I've answered it for him)

Comment 64

[Jonathan Petto [:jpetto]]

I definitely can be of assistance making code changes to bedrock. If the showFirefoxAccounts() call on /firefox/sync [1] needs to be changed, please file a separate bug with the specifics and I'll take care of things on that end.

(I can also update the UITour docs [2] if necessary.)

[1] https://github.com/mozilla/bedrock/blob/master/media/js/firefox/sync.js#L136
[2] http://bedrock.readthedocs.org/en/latest/uitour.html

Comment 65

[Mark Hammond [:markh] [:mhammond]]

(In reply to Jon Petto [:jpetto] from comment #64)
> I definitely can be of assistance making code changes to bedrock. If the
> showFirefoxAccounts() call on /firefox/sync [1] needs to be changed, please
> file a separate bug with the specifics and I'll take care of things on that
> end.

I've filed bug 1244929 for the changes necessary in Firefox itself. I'm not sure where the matching bedrock bug should be filed.

Comment 66

[Jonathan Petto [:jpetto]]

(In reply to Mark Hammond [:markh] from comment #65)
> (In reply to Jon Petto [:jpetto] from comment #64)
> > I definitely can be of assistance making code changes to bedrock. If the
> > showFirefoxAccounts() call on /firefox/sync [1] needs to be changed, please
> > file a separate bug with the specifics and I'll take care of things on that
> > end.
> 
> I've filed bug 1244929 for the changes necessary in Firefox itself. I'm not
> sure where the matching bedrock bug should be filed.

bedrock isn't the easiest to find in bugzilla. Other Products -> www.mozilla.org, then either Bedrock or Pages & Content.

Comment 67

[Ryan Kelly [:rfkelly]]

Since it's now possible for web content to sign the user into sync without invoking UITour, I wonder if we should work towards updating https://www.mozilla.org/firefox/sync with an experience more akin to what you've got on https://www.mozilla.org/firefox/accounts and the first-run page, using an embedded FxA API to do the login directly.

Does https://www.mozilla.org/firefox/accounts properly track campaign metrics?  It seems like that may be a better location to which to direct users - it's a smoother experience with fewer clicks than https://www.mozilla.org/firefox/sync, and you've got much more control over the experience than a direct link to https://accounts.firefox.com.

> It is a topline Marketing goal to increase Account sign ups.

In the interests of transparency and expectation-setting, I also want to mention that ramping up additional growth is explicitly not a topline goal for the Accounts team this year.

Continuing our current rate of growth is clearly important (and last year's work by the Growth team has put us in a really strong position on that front!) but in line with the rest of the Firefox product org, for 2016 the Accounts team will be be focusing more on quality and engagement/retention than on driving further increases in our daily signup rate.

That said, metrics-supporting work like this bug and its follow-ups is definitely doable.  I just want to be up-front about our overall priorities for the year, since it came up in the conversation above.

Comment 68

[Jonathan Petto [:jpetto]]

(In reply to Ryan Kelly [:rfkelly] from comment #67)
> Since it's now possible for web content to sign the user into sync without
> invoking UITour, I wonder if we should work towards updating
> https://www.mozilla.org/firefox/sync with an experience more akin to what
> you've got on https://www.mozilla.org/firefox/accounts and the first-run
> page, using an embedded FxA API to do the login directly.
> 
> Does https://www.mozilla.org/firefox/accounts properly track campaign
> metrics?  It seems like that may be a better location to which to direct
> users - it's a smoother experience with fewer clicks than
> https://www.mozilla.org/firefox/sync, and you've got much more control over
> the experience than a direct link to https://accounts.firefox.com.

We have GA/GTM set up on all mozilla.org pages (including /firefox/accounts/), so I'm sure any standard campaign metrics can easily be tracked (if they aren't automatically tracked already).

It wouldn't be a monumental task to update the logic on /firefox/sync/ to redirect users to /firefox/accounts/ instead of opening about:accounts. I believe the biggest issue there is that /firefox/accounts/ is not currently localized. (Which could of course be remedied.)

It would also be possible to embed the FxA iframe on /firefox/sync/, but that would require having a UI/UX conversation.

Anyway, we definitely have better options than opening about:accounts with UITour available to us.

Comment 69

[Chris More [:cmore]]

For some of our upcoming channel tests, we are going to use the /firefox/accounts/ page as it has GA tracking on it already and we can segment it by campaign UTM tags.

Comment 70

[[e-mail]]

Jon -- is it possible to make the Accounts button link on the Sync page (https://www.mozilla.org/firefox/sync/) redirect or go to accounts.firefox.com rather than about:accounts?

We have multiple in-product messages that go to the Sync page and we'd love to be able to track Accounts sign ups from there.

Comment 71

[Ryan Feeley [:rfeeley]]

(In reply to [e-mail] from comment #70)
> Jon -- is it possible to make the Accounts button link on the Sync page
> (https://www.mozilla.org/firefox/sync/) redirect or go to
> accounts.firefox.com rather than about:accounts?

Note that a user merely visited accounts.firefox.com does not provide Firefox with what it needs for Sync to be configured. The entry point has to come from native Firefox UI (or a permissioned button like on the Sync marketing page)

Comment 72

[[e-mail]]

(In reply to Ryan Feeley [:rfeeley] from comment #71)
> (In reply to [e-mail] from comment #70)
> > Jon -- is it possible to make the Accounts button link on the Sync page
> > (https://www.mozilla.org/firefox/sync/) redirect or go to
> > accounts.firefox.com rather than about:accounts?
> 
> Note that a user merely visited accounts.firefox.com does not provide
> Firefox with what it needs for Sync to be configured. The entry point has to
> come from native Firefox UI (or a permissioned button like on the Sync
> marketing page)

Ah. I see. I thought otherwise. In that case, Jon you can disregard my comment. 

User functionality is the most important priority, but we will continue to not be able to gauge or optimize our success until we solve for this issue.

Comment 73

[Mark Hammond [:markh] [:mhammond]]

FTR, bug 1244929 just landed on fx-team and I opened bug 1250758 for the matching bedrock changes. This doesn't mean we shouldn't investigate ways to remove about:accounts from this flow, but it at least gives us a way to track the campaigns in the meantime. Please add additional comments around this in either of those bugs.