Per bug 1216740, we are creating two funnelcakes to do a cohort test on downloads acquired via the fall campaign. We are just going to do en-US + Germany on Windows. There will need to be an optimizely test created on /firefox/new/ that only executes when: * Referral contains /firefox/choose/ * OS = Windows * Language = English or German * Browser = Non-Firefox I will get the test details page and optimizely test set up to get reviewed.

Funnelcake 58: de https://app.optimizely.com/edit?experiment_id=3719470293 Funnelcake 59: en-US https://app.optimizely.com/edit?experiment_id=3731352335 Everything is set up and I guessed at the download.mozilla.org based off of the previous funnelcakes. Once the funnelcakes are built, I can update if needed.

Also, I need the utm_campaign that we are going to be using in the campaign as I need to match only that click through traffic.

Pull the utm campaign tags from this spreadsheet: https://docs.google.com/spreadsheets/d/1zJvYgH6ugZR_3VMNhnyIFiHDQzHjghh6Om4iaW-jMGI/edit#gid=1412402163 The issue is that most utm_campaign tags are specific locations and I need to match languages. With that, I will match utm_campaign regex "utm_campaign=fx\-fall\-15.+" with their language set to either English or German.

:garethc: can you peer review the two experiments in comment 1 and give a r+ if they look fine?

:jpetto: two funnelcake experiments in comment 1. Only code is: $(".os_win > .download-link").attr({"href":"https://download.mozilla.org/?product=firefox-42.0-SSL-f58&os=win&lang=de"}); and $(".os_win > .download-link").attr({"href":"https://download.mozilla.org/?product=firefox-42.0-SSL-f59&os=win&lang=en-US"}); Links currently 404 because they are not ready yet, but just making sure we are all ready for the final functional and code review.

Code looks good. r+

Ok, I got the experiments working right on demo4, but I need optimizely enabled on /firefox/choose/ to handle the IE8 pop up window use case. I had to make changes to the audiences and will do final testing after demo4 has optimizely on /firefox/choose/. bug 1219795 is for the optimizely flag.

Well, I have it sort-of working, but I am running into what I think is a JS-timing issue. Here's what I have going on. Note that the funnelcakes aren't live so they currently 404. For the /firefox/choose/ page, I have this jquery running: $(".os_win > .download-link").attr({"data-direct-link":"https://download.mozilla.org/?product=firefox-42.0-SSL-f59&os=win&lang=en-US"}); On the download button divs, there is an href to the second scene and a data-direct-link for old IE to use for the pop up window. For old IE, the jquery above changes that URL, pop up uses the funnelcake, and it still goes to the second scene. Works for them. For newer IE and Chrome, I modify I use this code on the /firefox/new/ page: $(".os_win > .download-link").attr({"href":"https://download.mozilla.org/?product=firefox-42.0-SSL-f59&os=win&lang=en-US"}); This just changes the URL to the download from the stub installer to the funnelcake. The issue is that it looks like when you call the second scene directly via ?scene=2#download-fx, it doesn't use the .download-link href for the URL to the download that should pop. Is this true?

I am doing my testing here: https://www.allizom.org/en-US/firefox/choose/?utm_campaign=fx-fall-15-test :jpetto: thoughts?

As far as I can tell, this is a JS timing issue. The URL used for the auto-download when linking directly to scene 2 comes from the "click here" link in the "Your download should begin automatically. If not, click here." message. That URL is populated from whichever <li> is visible within the primary download button (each platform has its own <li>). The "click here" href is populated on $(document).ready. The "click here" link is triggered in $window.on('load') (which happens sometime shortly after $(document).ready). Based on my investigation today, it appears Optimizely's JS is firing *after* our $(document).ready code but *before* our $window.on('load'). From the docs [1], it appears Optimizely executes its JS on a timer. Every 50ms, it checks to see if the DOM is ready. I'm guessing somewhere in one of those 50ms intervals our $(document).ready executes, and then Optimizely decides it can execute, but I can't be sure, as I can't see the exact code Optimizely is using to determine when it should execute. Long story short, I believe the fix is to just have Optimizely set the href for both the button *and* the "click here" link. I've tested this on a Windows VM and it seems to work. I've updated the JS in the Optimizely experiment, so give it a try on stage. [1] https://help.optimizely.com/hc/en-us/articles/200040335#evaluate_js

It looks like the funnelcake from the second scene on /firefox/new/ is still very problematic and I can't get it to consistently work. It worked during the spring campaign fine and it doesn't now. We believe that the JS in the page is finishing before Optimizely can do its thing and thus the randomness if the funnelcake is delivered. From talking to jpetto, we removed the 1.5s delay on the second scene pop up after we removed the second scene images. Removing that delay is probably why the funnelcake isn't working now and why it worked in the spring campaign. We can probably resolve this issue by: * Adding the 1.5s delay back for the second scene just for this segment: ** en-US OR de locale AND ** when document.referrer contains utm_campaign=fx-fall-15 AND ** platform is Windows AND ** browser is *not* Firefox This would limit the scope of this delay to only the funnelcake audience.

Actually, we found the problem and it seems to be an IE thing, but could be a Optimizely+IE thing that we need to investigate further. The only change I made to get it to work is when looking at the referring URL, I just use the substring of fx-fall-15 instead of utm_campaign=fx-fall-15 and it worked perfectly. Even changing it to regex or a custom JS didn't make a difference.

The solution to the above problem was to just use the fx-fall-15 in the referring URL instead of utm_campaign=fx-fall-15. I will file an Optimizely bug to know why it didn't like including the UTM parameters for IE. Funnelcakes launched the morning of November 3rd and running fine.