Closed Bug 595393 Opened 15 years ago Closed 15 years ago

Add WebTrends tracking to SpreadFirefox.com

Categories

(Websites Graveyard :: spreadfirefox.com, defect)

Product:
Websites Graveyard
Component:
spreadfirefox.com
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: mary, Unassigned)

References

Details

Hey all: Looks like Urchin tracking is busted on SFx. Rather than fixing it, let's move to WebTrends. Can we get this added? https://intranet.mozilla.org/Webanalytics
What are the meta tags that I have to add?
I'm not sure what you're asking. Why do you need a meta tag? You should have to add any.
(In reply to comment #2) > I'm not sure what you're asking. Why do you need a meta tag? You should have > to add any. Blake - What should Webdev do in order to implement Webtrends tracking on this site? Is it a matter of following these directions https://intranet.mozilla.org/Webanalytics#Track_a_New_Domain, or is anything else needed? Not sure of the process here.
Laura pretty much asked the question I had in mind. Thanks Laura!
Just need to follow the directions, nothing else needed.
I have completed the first three steps; the fourth step I did by writing a Drupal module that injects the needed JavaScript code. It is committed at r74385.
Keywords: qawanted
YTB :)
Also, how do we get this to the finish line? Does QA need to look at this? Thanks :)
(In reply to comment #8) > Also, how do we get this to the finish line? Does QA need to look at this? > Thanks :) Good question Mary. There's no official QA for this but we can confirm that the tracking is in place by looking at the reporting. As of today, 23 hours past Wilson's commit of http://viewvc.svn.mozilla.org/vc?revision=74385&view=revision the Spreadfirefox.com report is showing in Webtrends, but no new data is flowing through. It gives this error: "No report data is currently available for the profile you selected. Please check later to see if analysis completed, or select a different profile." Not sure why as I'd expect enough time to have passed for the initial data collection. Wilson or Blake, does that 4th step SVN commit mean the tracking should be live?
My commit needs to be deployed to production. After that, whoever has access to the admin account on production should log in and enable the SFX Webtrends module in the Mozilla category.
(In reply to comment #10) > My commit needs to be deployed to production. After that, whoever has access to > the admin account on production should log in and enable the SFX Webtrends > module in the Mozilla category. Got it, thanks for the specifics. Please let us know when it's deployed, and we can go from there.
Let's push it live pretty please :)
Kourge: Can you file a bug to push this to production w. the revision # (if I got that right!)? Thanks!
Keywords: push-needed
Depends on: 597555
In the future, please cc myself and Krupa on SFx bugs for the time-being, thanks! I never saw this bug (since I don't watch SFx, as it's largely been dormant for a while now), and am only now finding out that we have something to test. (We shouldn't push without testing, so removing push-needed until QA has a chance to look at this.) Mary, did someone test before comment 12?
Keywords: push-needed
OS: Mac OS X → All
Hardware: x86 → All
Hey there - Sorry - should've checked with you, but I didn't think it could be tested since it was domain specific.
(In reply to comment #15) > Hey there - Sorry - should've checked with you, but I didn't think it could be > tested since it was domain specific. OK -- maybe it can't; I usually end up asking Blake anyway. Removing "qawanted" and re-adding "push-needed".
Keywords: qawanted → push-needed
merge to production in r74753, IT push bug is bug 597555
Status: NEW → RESOLVED
Closed: 15 years ago
Keywords: push-needed
Resolution: --- → FIXED
The WebTrends scripts are live on prod; Blake/Laura -- please verify you're getting reports. Thanks!
data's coming in!
(In reply to comment #19) > data's coming in! Can you please mark the bug too, when you verify? Thanks.
thought the status was already resolved fixed...
(In reply to comment #21) > thought the status was already resolved fixed... Yes, it is; the life-cycle of a bug is RESOLVED FIXED and then VERIFIED FIXED; the latter is set by the person who can actually verify the bug is fixed, the feature is implemented, data is coming in etc. That's typically QA, but not when it comes to domain-specific knowledge, which in this case is metrics. Of course I can always set the status to verified based on your comment, but it's better if you'd do that; this is standard Bugzilla practice.
okay, just didn't know the procedure. happy to do this for anything metrics related :)
Status: RESOLVED → VERIFIED
(In reply to comment #23) > okay, just didn't know the procedure. happy to do this for anything metrics > related :) Thanks, Blake -- that helps out a ton (and saves an extra bugmail per bug) :)
Product: Websites → Websites Graveyard
You need to log in before you can comment on or make changes to this bug.