1403384 - Additional analytics tagging

Status: RESOLVED FIXED

(Websites :: Web Analytics, task)

Description

[Wes Contreras]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36

Steps to reproduce:

Identified links that we missed in the original tagging effort.



Expected results:

Add some additional data- attributes to those links:

1. The "doubled its speed" link under "2x faster":

   data-link-type="link" data-link-name="doubled its speed"

2. The "30% less memory" link under "Lean, mean speed machine"

   data-link-type="link" data-link-name="30 percent less memory"

3. The "up to 44% faster" link under "Powerful privacy"

   data-link-type="link" data-link-name="up to 44 percent faster"


Apologies for not catching those links in the initial design.

Comment 1

[Gareth Cull [:garethc]]

Eric, there were a few links that were missed on the /quantum/ page. Can you please prioritize this as this data is missing from our /quantum/ dashboard. Thanks.

Comment 2

[Eric Renaud [:erenaud]]

Alex - can you please assess LOE here? Asking because you submitted the originial PR - but if you're occupied w. Cliqz we can ask Schalk to do this.

Comment 3

[Alex Gibson [:agibson]]

(In reply to Wes Contreras from comment #0)
> User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6)
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36
> 
> Steps to reproduce:
> 
> Identified links that we missed in the original tagging effort.
> 
> 
> 
> Expected results:
> 
> Add some additional data- attributes to those links:
> 
> 1. The "doubled its speed" link under "2x faster":
> 
>    data-link-type="link" data-link-name="doubled its speed"
> 
> 2. The "30% less memory" link under "Lean, mean speed machine"
> 
>    data-link-type="link" data-link-name="30 percent less memory"
> 
> 3. The "up to 44% faster" link under "Powerful privacy"
> 
>    data-link-type="link" data-link-name="up to 44 percent faster"
> 
> 
> Apologies for not catching those links in the initial design.

We can't add data attributes to these strings without breaking translations for l10n. The outbound links are all blog properties that we own however, so could we add utm params to those links instead?

Comment 4

[Wes Contreras]

UTM parameters should be used for marketing referrals only, and should never be used on links within the site. 

Would adding JavaScript to an onmousedown event be an option? We can accomplish the same goals that way.

Comment 5

[Gareth Cull [:garethc]]

@wes Is there any rule we can create in GTM to listen for clicks on those href values on the /quantum/ page?

Comment 6

[Wes Contreras]

It's possible, but future changes to the page (id or class name changes being the most common) could break the tagging, and it can be hard to maintain due to the complexity of the overall configuration.

If it's our only option, though, we'll do it rather than leave it untagged.

Comment 7

[Alex Gibson [:agibson]]

(In reply to Wes Contreras from comment #4)
> UTM parameters should be used for marketing referrals only, and should never
> be used on links within the site. 
> 
> Would adding JavaScript to an onmousedown event be an option? We can
> accomplish the same goals that way.

As previously stated, these aren’t links within the site. They are external blogs on a separate domain.

Comment 8

[Wes Contreras]

We don't want to use UTM parameters on any link within a mozilla.org page that leads to another mozilla.org page. Using them breaks the session and impairs our ability to rollup reporting across all of mozilla.org, as well as some other negative impacts. UTM parameters should be restricted to use on links from outside of Mozilla properties, like SEM, display ads, email blasts, and the like. 

Are we able to add JS code to fire the event with the link click, or do we need to implement an event listener via GTM (with the risk of it breaking with future DOM changes)?

Comment 9

[Alex Gibson [:agibson]]

(In reply to Wes Contreras from comment #8)
> We don't want to use UTM parameters on any link within a mozilla.org page
> that leads to another mozilla.org page. Using them breaks the session and
> impairs our ability to rollup reporting across all of mozilla.org, as well
> as some other negative impacts. UTM parameters should be restricted to use
> on links from outside of Mozilla properties, like SEM, display ads, email
> blasts, and the like. 
> 
> Are we able to add JS code to fire the event with the link click, or do we
> need to implement an event listener via GTM (with the risk of it breaking
> with future DOM changes)?

www.mozilla.org is an entirely separate website (with a separate GA implementation) to blog.mozilla.org. We routinely link to our blogs and other external sites using utm params, so I don’t see why this is an issue here.

Comment 10

[Alex Gibson [:agibson]]

Case example: https://github.com/mozilla/bedrock/blob/master/bedrock/base/templates/includes/global-nav.html

Comment 11

[Wes Contreras]

If it's a separate GA implementation, then the traffic collected there wouldn't be available for reporting in www.mozilla.org, so UTM parameters wouldn't accomplish our goals here.

I'll talk to Gareth separately about how that's structured and UTM parameter use in general.

Comment 12

[Alex Gibson [:agibson]]

Since we own the GA implementation for both sites, adding utm params that are distinct to the marketing campaign should give us the numbers we need in terms of referrals to the blog posts. I’m not sure I get why this is more complicated, or why this differs from any other page. Hopefully agareth can provide some insight.

Comment 13

[Alex Gibson [:agibson]]

To be clear, if we have to do this in JS we can - but my preference would be to not add more JS to the page that serves no purpose other than link tracking, especially if there is already a simpler viable option.

Comment 14

[Wes Contreras]

After talking through the options with Gareth, we implemented via GTM. Please try to let us know if there are future changes to this page so we can be sure this tagging still works.

We can close this.

Comment 15

[Alex Gibson [:agibson]]

Thanks, closing.