Status

support.mozilla.org
Knowledge Base Software
RESOLVED INVALID
6 years ago
6 years ago

People

(Reporter: atopal, Assigned: rrosario)

Tracking

unspecified
2012-02-07

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
We have a discrepancy of up to 40% between our log data and the Webetrends data. Our current hypothesis is that people don't stay on sites long enough to trigger the Wetbrends JS, but are always counted in our logs.  

We want to test this hypothesis by putting the Webtrends JS on top of the page for a 48 hour period and cross check the results with our log data for that period.

We need two things:

1. Since this could potentially have side effects, we need a waffle flag to activate this behavior on a single site, to test it on production.

2. We need a waffle flag to switch this behavior on and off for the en-US KB.
(Assignee)

Comment 1

6 years ago
(In reply to Kadir Topal [:atopal] from comment #0)
> 1. Since this could potentially have side effects, we need a waffle flag to
> activate this behavior on a single site, to test it on production.
> 
> 2. We need a waffle flag to switch this behavior on and off for the en-US KB.

Doesn't #2 solve #1? Flags are activated independently on stage, prod, etc. Or maybe I don't understand #1.


Keep in mind that this will definitely affect the perceived performance of the pages. I just did a few tests and webtrends takes 250-600ms to download for me.
(In reply to Ricky Rosario [:rrosario, :r1cky] from comment #1)
> Keep in mind that this will definitely affect the perceived performance of
> the pages. I just did a few tests and webtrends takes 250-600ms to download
> for me.

JS in the <head> has gotten a lot better, and does download in parallel with most other things (not iframes, meh). But the time it takes to parse and execute will push back the onload event.

Open this page with Firebug on to see the effects.
http://stevesouders.com/cuzillion/?ex=10008&title=Scripts+Block+Downloads

This is likely fine if we know this is a very short-term experiment.
(Assignee)

Comment 3

6 years ago
(In reply to Ricky Rosario [:rrosario, :r1cky] from comment #1)
> I just did a few tests and webtrends takes 250-600ms to download
> for me.

Scratch that, we serve webrends.js and that in turn does the request I mention above. But hopefully that doesn't block anything.
(Assignee)

Comment 4

6 years ago
(In reply to Ricky Rosario [:rrosario, :r1cky] from comment #1)
> I just did a few tests and webtrends takes 250-600ms to download
> for me.

Scratch that, we serve webrends.js and that in turn does the request I mention above. But hopefully that doesn't block anything.
(Reporter)

Comment 5

6 years ago
(In reply to Ricky Rosario [:rrosario, :r1cky] from comment #1)
> (In reply to Kadir Topal [:atopal] from comment #0)
> > 1. Since this could potentially have side effects, we need a waffle flag to
> > activate this behavior on a single site, to test it on production.
> > 
> > 2. We need a waffle flag to switch this behavior on and off for the en-US KB.
> 
> Doesn't #2 solve #1? Flags are activated independently on stage, prod, etc.
> Or maybe I don't understand #1.

#1 is there to test this out quickly on production on a single page before activating it for everyone. The reason being that if page loading time skyrockets we would have only affected a few users. I guess we can go with #2 only and inconvenience all our users for 2 minutes as the worst case. 

 
> Keep in mind that this will definitely affect the perceived performance of
> the pages. I just did a few tests and webtrends takes 250-600ms to download
> for me.

Wow, that sounds like a lot, although I have no idea if that is normal. I think this goes to show that we should start planning for automatic page load time testing on SUMO soon, but that just as a side note.
(Assignee)

Updated

6 years ago
Assignee: nobody → rrosario
Whiteboard: u=sumo-team c=wiki s=2012.3 p= → u=sumo-team c=wiki s=2012.3 p=1
Target Milestone: --- → 2012-02-07
(In reply to Kadir Topal [:atopal] from comment #5)
> ...if page loading time
> skyrockets we would have only affected a few users.

Keep in mind we don't have a way of measuring onload time from actual users right now.
(Assignee)

Comment 7

6 years ago
This is for KB pages only.
(Reporter)

Comment 8

6 years ago
(In reply to James Socol [:jsocol, :james] from comment #6)
> (In reply to Kadir Topal [:atopal] from comment #5)
> > ...if page loading time
> > skyrockets we would have only affected a few users.
> 
> Keep in mind we don't have a way of measuring onload time from actual users
> right now.

Yeah we would just test this manually from our own connections from a number of places on the globe. Sucks, but I guess for 48 hours we can live with it, and the end justifies the means in this case.
(Reporter)

Updated

6 years ago
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INVALID
Whiteboard: u=sumo-team c=wiki s=2012.3 p=1
(Assignee)

Comment 9

6 years ago
FTR, per IRC discussion:

<Topal>: ... Ibai did some comparisons and it looks like the 30% difference between logs and webtrends does not have a significant effect, so we're going to leave that as it is
You need to log in before you can comment on or make changes to this bug.