874076 - Add consumer page google analytics

Status: RESOLVED FIXED

(Marketplace Graveyard :: Consumer Pages, defect, P1)

Description

[Wil Clouser [:clouserw]]

There are about 14 triggers PdM/Marketing would like to add to GA (less that are P1).  The rough code for these is already written in chunks but not on the site at all.

This isn't a convenient little package though so I can't just link to it without some explanation.  Take this bug and find me and I'll explain how to find the info.  Sorry for the vagueness, just not easy to link to.

Comment 1

[Wil Clouser [:clouserw]]

Gareth (garethc on IRC) has offered to help make sure the data is flowing correctly.  He's also a pro at GA (and wrote that sample code) so he can answer questions too.

Comment 2

[Matt Basta [:basta]]

Some questions:
- Login and logout aren't "actions" as they were with zamboni marketplace. Persona might change the signed in state without user action (i.e.: on first load, the user might be signed in but Persona will log the user out automatically or vise versa). Do we only care about user-triggered sign in and sign out or any change of login state?
- Some GA codes surrounding purchases involve information that is available in webpay but not in the consumer page. Should we file bugs for those?
- Is "app maker" meant to read "developer"?
- You can't uninstall apps from the Marketplace, so what do we do with the uninstall-related tracking?
- Language isn't a setting in the Marketplace. Do they still want us to define the language? GA already collects this automatically.

Comment 3

[David Bialer [:dbialer]]

(In reply to Matt Basta [:basta] from comment #2)
> Some questions:
> - Login and logout aren't "actions" as they were with zamboni marketplace.
> Persona might change the signed in state without user action (i.e.: on first
> load, the user might be signed in but Persona will log the user out
> automatically or vise versa). Do we only care about user-triggered sign in
> and sign out or any change of login state?
I think we care mostly about user triggered login, but more importantly, if it is trackable, whether a goals can be measured for getting new users to register, and getting repeat visitors, though not sure if this is directly related to login.

> - Some GA codes surrounding purchases involve information that is available
> in webpay but not in the consumer page. Should we file bugs for those?
yes, but can we track this or do we need a partner to implement something?

> - Is "app maker" meant to read "developer"?
not sure what this is referring to.

> - You can't uninstall apps from the Marketplace, so what do we do with the
> uninstall-related tracking?
not track this since we don't know about it.

> - Language isn't a setting in the Marketplace. Do they still want us to
> define the language? GA already collects this automatically.
No I don't think it is necessary now.

Comment 4

[Matt Basta [:basta]]

(In reply to David Bialer [:dbialer] from comment #3)
> I think we care mostly about user triggered login, but more importantly, if
> it is trackable, whether a goals can be measured for getting new users to
> register, and getting repeat visitors, though not sure if this is directly
> related to login.

We unfortunately can't tell when a user is new or not new. Persona doesn't tell us that. We can start storing data about whether it's the user's first time signing in from that browser/device, but that's all.

I'd say that this metric is probably better measured in other ways, like visits to the My Apps page.

> yes, but can we track this or do we need a partner to implement something?

The doc asks for information like tax, currency code, city, state, and country. We have none of those fields. I could implement it and leave them blank, but that seems like something that webpay has easy access to.

That can always be added later, anyway, since payments aren't even enabled.

> > - Is "app maker" meant to read "developer"?
> not sure what this is referring to.

See row 15


I've gone through and implemented most of this:

https://github.com/mozilla/fireplace/pull/159

There are notes in the pull request about implementation. I've differed from the doc a bit due to technical restrictions, but it shouldn't block anybody (e.g.: returning app slug instead of name/id).

Comment 5

[Christopher Van Wiemeersch [:cvan]]

(In reply to Matt Basta [:basta] from comment #4)
> (In reply to David Bialer [:dbialer] from comment #3)
> > I think we care mostly about user triggered login, but more importantly, if
> > it is trackable, whether a goals can be measured for getting new users to
> > register, and getting repeat visitors, though not sure if this is directly
> > related to login.
> 
> We unfortunately can't tell when a user is new or not new. Persona doesn't
> tell us that. We can start storing data about whether it's the user's first
> time signing in from that browser/device, but that's all.

Since the Zamboni account creation happens here, we can have it returned in the API response here: http://firefox-marketplace-api.readthedocs.org/en/latest/topics/authentication.html#post--api-v1-account-login-

Comment 6

[David Bialer [:dbialer]]

(In reply to Matt Basta [:basta] from comment #4)
> (In reply to David Bialer [:dbialer] from comment #3)
> > I think we care mostly about user triggered login, but more importantly, if
> > it is trackable, whether a goals can be measured for getting new users to
> > register, and getting repeat visitors, though not sure if this is directly
> > related to login.
> 
> We unfortunately can't tell when a user is new or not new. Persona doesn't
> tell us that. We can start storing data about whether it's the user's first
> time signing in from that browser/device, but that's all.
That's a bummer.  The use case here would be having a promotional app that leads to users signing up.  We can probably track a specific app visit that would then lead to a sign-in perhaps?  Have to think about this.

> 
> I'd say that this metric is probably better measured in other ways, like
> visits to the My Apps page.

> 
> > yes, but can we track this or do we need a partner to implement something?
> 
> The doc asks for information like tax, currency code, city, state, and
> country. We have none of those fields. I could implement it and leave them
> blank, but that seems like something that webpay has easy access to.
Can we do this server side from the information getting sent (or should be sent) on a transaction.  Bug 866939.  Not sure if this makes sense since there is no continuity in a session.  What do you think? 
> 
> That can always be added later, anyway, since payments aren't even enabled.
Yes.
> 
> > > - Is "app maker" meant to read "developer"?
> > not sure what this is referring to.
Yes
> 
> See row 15
> 
> 
> I've gone through and implemented most of this:
> 
> https://github.com/mozilla/fireplace/pull/159
> 
> There are notes in the pull request about implementation. I've differed from
> the doc a bit due to technical restrictions, but it shouldn't block anybody
> (e.g.: returning app slug instead of name/id).

Comment 7

[Matt Basta [:basta]]

(In reply to David Bialer [:dbialer] from comment #6)
> That's a bummer.  The use case here would be having a promotional app that
> leads to users signing up.  We can probably track a specific app visit that
> would then lead to a sign-in perhaps?  Have to think about this.

Bear in mind that users don't even need to be logged in to install free apps. We're already tracking purchases, which imply that the user is logging in/registering.

cvan and I went back and forth on this offline for a while. Log in/log out detection can be added, but you're not going to like the data (users automatically get signed out and will need to re-sign in regularly), and more often than not it's going to be scenarios that don't fit into the model of users signing in or signing up simply because of the nature of Persona.

The other issue is that even if we know that the user is signing in for the first time, we don't know that they're a new user. For instance, they might be signing in as [e-mail] but already have an account at [e-mail]. We can't tell that they're the same person.

(In reply to David Bialer [:dbialer] from comment #6)
> Can we do this server side from the information getting sent (or should be
> sent) on a transaction.  Bug 866939.  Not sure if this makes sense since
> there is no continuity in a session.  What do you think? 

I don't believe it's possible to get data into GA from the server side, but I've been wrong before.


I'm going to land my pull request and close this bug. If you think tracking login/out is valuable, I think that's deserving of its own bug so we can discuss a proper implementation and getting valuable data back rather than just auth noise. Same with the eCommerce extension: we should probably talk with the webpay guys and see if there's a place that we can slip the code in there so that we can report the fields that GA asks for rather than hacking it into the consumer pages.

https://github.com/mozilla/fireplace/commit/278e689dd4f0b3be27ee01064a14c645a1e25cfc