Closed Bug 556378 Opened 15 years ago Closed 15 years ago

AMO: Add WebTrends Tags

Categories

(addons.mozilla.org Graveyard :: Statistics, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: bcutler, Assigned: clouserw)

References

()

Details

(Whiteboard: [z][r])

Attachments

(2 files, 4 obsolete files)

Attached file Zip file of tag (obsolete) —
We are now using WebTrends to track our web analytics. Please sample Addons.mozilla.org traffic at 50%. Below you'll find directions from Dan Bohling (WebTrend's Senior Solution Engineer): "Attached are two documents. First one is the doc for the initial deploy across the discussed sites below. Second is the zip file of the actual tag to use. I’ve only included one tag, we will use the SAME tag across all sites, only difference will be there are three “tokenized” items in the tag that has to be replaced prior to deploy. The solutions doc covers all of that. I will be setting up the actual profiles shortly, datasources are already setup in your account to received the identified DCSID’s."
Attached file Doc for initial deploy (obsolete) —
Summary: Remove SiteCatalyst Tags and Add WebTrends Tags → AMO: Remove SiteCatalyst Tags and Add WebTrends Tags
This should be in both [r] and [z]. We can also remove the Urchin tags.
OS: Mac OS X → All
Priority: -- → P3
Hardware: x86 → All
Target Milestone: --- → 5.9
Group: mozilla-confidential
From webtrends.html: > <!-- Warning: The two script blocks below must remain inline. Moving them to an external --> > <!-- JavaScript include file can cause serious problems with cross-domain tracking. --> Please give us more details about what "serious problems" can occur and how we can avoid them. In order to follow CSP we aren't allowing any inline JS on AMO.
webtrends.js is running document.write and is mutating the global Function prototype: `Function.prototype.wtbind`. Calling document.write prevents us from making this script async. I don't know of a reason we need to stall page load to run the analytics code.
This is out of my realm, but shouldn't the JS go at the bottom of the page, before the close body tag? Will we still take a performance hit by making this change?
Wil, I'm looking into your questions.
(In reply to comment #6) > Wil, I'm looking into your questions. Thanks. https://wiki.mozilla.org/Security/CSP is what I'm talking about. It doesn't have wide (any?) use right now, so our objections are probably new.
(In reply to comment #5) > This is out of my realm, but shouldn't the JS go at the bottom of the page, > before the close body tag? Will we still take a performance hit by making this > change? From http://dev.w3.org/html5/spec/embedded-content-0.html#document.write: > Unless called from the body of a script element while the document is being > parsed, or called on a script-created document, calling this method will clear > the current page first. All of our javascript waits until the page is done loading. The use of document.write in webtrends.js forces it to run while the page is loading, which is going to delay our js (and we want our js to run first since it can affect the look and layout of the page).
okay, thanks Jeff. I'm checking with WebTrends and will let you know when I hear back.
Response from WebTrends: "We’ve had similar requests. The warning is there to discourage the uninitiated (Here be dragons). You can combine all of the inline code into two include file example wtbase.js and wtcollect.js. You can see these in use on several sites (e.g www.depend.com). The wtcollect.js just contains the call _tag.dcsCollect(); The wtbase.js has the following lines added to the bottom var _tag=new WebTrends(); _tag.dcsGetId(); Samples attached. I’m looking into the document.write question."
Attached file wtbase JavaScript (obsolete) —
Attached file wtcollect JavaScript (obsolete) —
Target Milestone: 5.9 → 5.10
Summary: AMO: Remove SiteCatalyst Tags and Add WebTrends Tags → AMO: Remove Omniture Tags and Add WebTrends Tags
Thanks Ken for CCing me. As discussed, I am in need of collecting data from web trends about what are the "top searched for" add-ons that have received a response of add-on not available. This data would be able to help boot strap jetpack add-ons eco system with most desired add-ons that are not yet available in AMO. Thanks Murali
The only thing we're waiting on here is the document.write question. We're scheduling the next AMO milestone on Tuesday. If we don't have this then it'll have to be bumped again.
WebTrends unfortunately doesn't have a ready fix for the document.write question.
Filed bug 558457 to remove the Omniture tags sooner to avoid hefty costs.
Summary: AMO: Remove Omniture Tags and Add WebTrends Tags → AMO: Add WebTrends Tags
Assignee: nobody → clouserw
Whiteboard: [z][r]
Attachment #436704 - Attachment mime type: application/octet-stream → text/plain
Attachment #436705 - Attachment mime type: application/octet-stream → text/plain
wtbase has a pile of hardcoded settings at the top of it. Where is the documentation for those? One of the settings, mappings, requires us to hardcode all of our domains. I can't do this for our development domains because they vary and change too much, but if the JS is loaded on a domain that isn't specified it throws a JS error. If it's running on an unspecified domain it should fail silently. Error: mappings[host] is undefined
(In reply to comment #17) > wtbase has a pile of hardcoded settings at the top of it. Where is the > documentation for those? It's in the docx file. On mozilla.com, I replaced those by dropping an "options" JSON object into the analytics call. If AMO only has a single tracking tag, you can also just hardcode them in the JS file. Code: http://viewvc.svn.mozilla.org/vc/projects/mozilla.com/trunk/includes/js_stats.inc.php?revision=66017&view=markup http://viewvc.svn.mozilla.org/vc/projects/mozilla.com/trunk/js/webtrends.js?revision=66017&view=markup
(In reply to comment #18) > (In reply to comment #17) > > wtbase has a pile of hardcoded settings at the top of it. Where is the > > documentation for those? > It's in the docx file. On mozilla.com, I replaced those by dropping an > "options" JSON object into the analytics call. If AMO only has a single > tracking tag, you can also just hardcode them in the JS file. I'm talking about all the undocumented options in base.js. Like this.i18n is False - should it be True? More importantly than all that, this bug is blocked on my question about mappings in comment 17.
Also, a minor concern, but what do you want the timezone set to? I'm assuming -8 and they'll take care of PDT on their end.
I'm waiting on files and or instructions for this. I can modify the files we have, but it sounds like they might not be the right ones now and I'm not sure why I would be modifying their code anyway. Code freeze is in a few days, this needs to get done or I'll have to bump it to the next milestone.
Looking at the document.writes in the code: The first one writes another script tag to include /wtid.js from our domain. We can concatenate that with wtbase.js and remove that document.write. The second one creates an <img> tag if document.images isn't available. I don't know where document.images would be unavailable, but that can be changed to use document.createElement easy enough. The third writes some debug stuff, which I don't really care about. As Wil said, I'm not excited about modifying their code. Can we get them to fix this upstream?
Group: mozilla-confidential
Will, the files and instructions are in the 1st two attachments (Zip file of tag & Doc for initial deploy).
The first two attachments don't match the .js files you attached, so I guess I'm not understanding what we're doing here. The last .js files attached above will work, but they have some issues that we'd rather webtrends fix instead of us. I'm in the office today in G - do you have time to come by?
Attached patch patch for remoraSplinter Review
r? jbalogh since he had the most comments about this stuff. Here is the patch for remora.
Attachment #436292 - Attachment is obsolete: true
Attachment #436293 - Attachment is obsolete: true
Attachment #436704 - Attachment is obsolete: true
Attachment #436705 - Attachment is obsolete: true
Attachment #441820 - Flags: review?(jbalogh)
Attached patch zamboni patchSplinter Review
And here is zamboni's patch. Untested, because it will use the file after the remora patch is committed. I'm keeping it out of our bundle so it can execute deferred at the very end of the page.
Attachment #441824 - Flags: review?(jbalogh)
Comment on attachment 441820 [details] [diff] [review] patch for remora I don't think you need DCSIMG on the alt tag. I'm not excited about Function.prototype.wtbind, so I guess we'll see if that breaks anything.
Attachment #441820 - Flags: review?(jbalogh) → review+
Comment on attachment 441824 [details] [diff] [review] zamboni patch >diff --git a/templates/base.html b/templates/base.html >index 77275cf..353e7c3 100644 >--- a/templates/base.html >+++ b/templates/base.html >@@ -74,5 +74,14 @@ > <script async defer src="{{ url('addons.buttons.js') }}"></script> > {% block js %}{% endblock %} > {% include "footer.html" %} >+ {# Webtrends Stats Tracking #} >+ <script defer src="{{ MEDIA_URL }}js/webtrends/webtrends.js') }}"></script> This should probably have async too. I don't remember what they do or why I have both, so let's just throw it all in there. >+ <noscript> >+ <div> >+ <img alt="DCSIMG" id="DCSIMG" width="1" height="1" >+ src="https://statse.webtrendslive.com/dcso6de4r0000082npfcmh4rf_4b1e/njs.gif?dcsuri=/nojavascript&amp;WT.js=No&amp;WT.tv=8.6.2" /> >+ </div> The <div> and alt seem unnecessary.
Attachment #441824 - Flags: review?(jbalogh) → review+
(In reply to comment #28) > (From update of attachment 441824 [details] [diff] [review]) > >diff --git a/templates/base.html b/templates/base.html > >index 77275cf..353e7c3 100644 > >--- a/templates/base.html > >+++ b/templates/base.html > >@@ -74,5 +74,14 @@ > > <script async defer src="{{ url('addons.buttons.js') }}"></script> > > {% block js %}{% endblock %} > > {% include "footer.html" %} > >+ {# Webtrends Stats Tracking #} > >+ <script defer src="{{ MEDIA_URL }}js/webtrends/webtrends.js') }}"></script> > > This should probably have async too. I don't remember what they do or why I > have both, so let's just throw it all in there. The way I read the first hit on google (http://www.quackit.com/html_5/tags/html_script_tag.cfm) is if async is in there it will run immediately, despite the defer, so I left it out. > > >+ <noscript> > >+ <div> > >+ <img alt="DCSIMG" id="DCSIMG" width="1" height="1" > >+ src="https://statse.webtrendslive.com/dcso6de4r0000082npfcmh4rf_4b1e/njs.gif?dcsuri=/nojavascript&amp;WT.js=No&amp;WT.tv=8.6.2" /> > >+ </div> > > The <div> and alt seem unnecessary.
(In reply to comment #29) > > This should probably have async too. I don't remember what they do or why I > > have both, so let's just throw it all in there. > > The way I read the first hit on google > (http://www.quackit.com/html_5/tags/html_script_tag.cfm) is if async is in > there it will run immediately, despite the defer, so I left it out. You're right, defer seems to be what we want here. Maybe we should remove defer from the button script and just have it async? I'm using http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html as a reference.
Verified FIXED on both Remora/Zamboni (same file/location/request): Remora: GET webtrends.js https://preview.addons.mozilla.org/js/webtrends/webtrends.js 304 Not Modified preview.addons.mozilla.org 18.2 KB
Status: RESOLVED → VERIFIED
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: