Closed Bug 616881 Opened 14 years ago Closed 14 years ago

Download Tracker is not functioning

Categories

(Websites Graveyard :: firefoxlive.mozilla.org, defect)

defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jsmith, Unassigned)

References

()

Details

Attachments

(1 file)

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b7) Gecko/20100101 Firefox/4.0b7 Build Identifier: The download tracker is not functioning. People are noticing that the percentage doesn't change and that they are not any closer to helping the cubs, which is part of the draw to the site. Reproducible: Always Steps to Reproduce: Visit the site.
If we are tracking by IP it might just be tracking the load balancer IP behind Zeus and not the remote IP.
Assignee: jslater → nobody
Component: Design → firefoxlive.mozilla.org
Product: Marketing → Websites
QA Contact: design → firefoxlive
We'll regroup tomorrow morning and assess what needs to be done - this will definitely be one of the top priorities. Even on Friday we were seeing news reports that the site was stuck at 56%, so if it's now stuck at 23% for long people will begin to think something is up. Given that we're really tracking 3 different things (non-Firefox users clicking on the download 3.6 button, Firefox 3.6 and below users clicking on the download Fx4 beta button, and Fx4 beta users clicking on the tell a friend button) I'd be fine simply tracking the # of clicks. If there are other ways I'm certainly open, but the main thing is going the simplest route that gets this working.
Status: UNCONFIRMED → NEW
Ever confirmed: true
A few further thoughts on this... We should use this opportunity to reset the download counter at 0 and move on to the next treat. We can say that they've already earned the jungle gym (are currently in the process of getting that sent to the zoo) and can add some messaging about what the next treat is. I'll post that here soon. In the meantime, this is the top priority of things to fix today. Rafael/Sebastian, do you want to have a call to discuss?
I'm having a hard time tracking where currentDownloads comes from. The general idea is that we need to make sure we're filtering on IP and pooling results -- if both of those are happening properly, we should be in good shape. In the wp-polls plugin we already have something similar: ### Function: Get IP Address if(!function_exists('get_ipaddress')) { function get_ipaddress() { if (empty($_SERVER["HTTP_X_FORWARDED_FOR"])) { $ip_address = $_SERVER["REMOTE_ADDR"]; } else { $ip_address = $_SERVER["HTTP_X_FORWARDED_FOR"]; } if(strpos($ip_address, ',') !== false) { $ip_address = explode(',', $ip_address); $ip_address = $ip_address[0]; } return esc_attr($ip_address); } } Looks like this data is coming /javascript/data_downloads.json, but from what I can tell, however, nothing is updating that file... ? So are we supposed to be tracking site metrics and updating data_downloads.json manually?
Here's some text to replace the "Next special treat: a jungle gym!" copy: You've already earned a jungle gym for the cubs. Next: yummy treats! Or, if that's too long, we can just go with: Next special treat: yummy snacks! (But I'd prefer the former if possible.)
Slight copy change to comment #5 based on input from the Knoxville Zoo: You've already earned a jungle gym for the cubs. Next: grass flats! Or, if that's too long, we can just go with: Next special treat: grass flats! (But I'd prefer the former if possible.)
copy has been updated. morgamic and I will figure out how to manage the download tracker updates. Seems to be working but checked this morning and it's still at 3%. keeping this open.
One more copy change: the header on the download tracker for Fx4 beta users reads: "Download for Treats" Copy should read: "Earn Treats for the Cubs"
Any updates on this thread? Download is still static at 3%.
As far as I can tell, it's not even dynamic. It reads from a static JSON file that doesn't get updated -- either that or I'm not seeing where the JSON gets updated from.
Does that mean we'll have to push a change every day? That seems like a pretty high pain-in-the-ass factor for WebDev, QA & IT.
Could the reward copy and the goal percentage be updated through WordPress as variables / post meta data? Requires some webdev changes upfront but no ongoing work for the three teams.
Yeah -- we'd have to remove the call to setDownloads and instead inject it into the download post so we can update it whenever we need to.
Since the main js file is included in the footer, we'll have to: - move firefox_live-min.js prior to the content pane - probably remove data_downloads.json (it is called "data_dowloads.json" in SVN!) - add a conditional to check if currentDownloads is typof == 'undefined' and set a default progress if so - otherwise, call setDownloads([#####]) inside a script tag as a part of the downloads post
This moves the site js and jquery to the header, which allows us to call setDownloads in the download post (wp post content). It will allow us to update it whenever we want via content edits.
Code to put in content: <script type="text/javascript"> setDownloads([######]); </script>
r79057; need to inject the code from comment #16 into stage to verify.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Still stuck at 37%.
Can we at least manually adjust this number higher today?
Reopening until someone does comment 16, so I/Raymond/others can verify on staging.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Anybody can update this in wordpress. Edit the download post. Like I said before it's not dynamic because the work wasn't actually done to log and retrieve download data. Since nobody caught this prior to launch, we can either manually update on an agreed schedule or have a dev put in 1-2 days of developmentto fix this in January. Their work
If you edit, only edit in HTML mode.
I updated the download tracker to 62% (I thought that was a reasonable number) and the change is live.
Currently broken in staging due to bug 618915, likely (not that it matters anyway).
Team - if we're going to manually update this number it needs to happen once a day, if not twice. The number not changing is a huge perception problem - is this possible?
It's not an ideal solution, but it looks like this is something we'll have to push manually a couple of times a week. Fwiw, we're resetting the counter and announcing a new treat target tonight.
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
Product: Websites → Websites Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: