(For now, this is the "best" place for this bug/issue, until we know what's wrong, at which point we can re-file/move, as appropriate.) Screencast: https://drive.google.com/file/d/0B_gOai245yuJSjIwTURfUUdKRXc/view?usp=sharing I've followed the (temporary, until bug 1320773 and any dependencies are fully fixed) instructions/steps from bug 1279291 and successfully get the test build from bug 1318456. Unless I'm doing something wrong (quite possible, but I'm in desperate need of help, in which case), however, I don't see any stub-attribution entries in Telemetry (bug 1292360 comment 34) nor the postSigningData file mentioned in bug 1292360 comment 39. Steps to Reproduce: 1. Using a recent Windows OS (7 or above), load https://www-demo4.allizom.org/en-US/ (I use Chrome, with the Developer panel open to the "Network" tab) 2. Click on "Download Firefox" 3. Click on/copy the https://bouncer-bouncer.stage.mozaws.net/ URL and substitute "test-stub" for "firefox-stub" in the "?product=" parameter 4. Paste/load that URL and hit Enter 5. Download, run, and finish the installation of the stub installer 6. Make sure you've set the "Show hidden files & folders" pref in your Windows OS 7. In Firefox, go to Options | Advanced | Data Choices, and check the box to enable "Share additional data (i.e., "Telemetry") 8. Restart the browser 9. Load about:telemetry and look for any "attribution" data under Environment Data :: Settings 10. Additionally, look under "C:\Users\[username]\AppData\Local\Mozilla\Firefox" (or equivalent) for postSigningData I'm unable to find neither #9 nor #10, based on the above steps/build; help!
Could manually changing "firefox-stub" to "test-stub" be invalidating the request based against the domain whitelist in bouncer? Not much clue about how that is all set up, just a thought that stick out.
Could be, I get an unaltered test-stub when I try, note the 302: $ wget -O staging.exe "https://bouncer-bouncer.stage.mozaws.net/?product=test-stub&os=win&lang=en-US" --2016-12-20 21:11:08-- https://bouncer-bouncer.stage.mozaws.net/?product=test-stub&os=win&lang=en-US Resolving bouncer-bouncer.stage.mozaws.net... 18.104.22.168 Connecting to bouncer-bouncer.stage.mozaws.net|22.214.171.124|:443... connected. HTTP request sent, awaiting response... 302 Found Location: https://download-installer.cdn.mozilla.net/pub/firefox/nightly/experimental/bug1318456/test-stub.exe [following] --2016-12-20 21:11:11-- https://download-installer.cdn.mozilla.net/pub/firefox/nightly/experimental/bug1318456/test-stub.exe Resolving download-installer.cdn.mozilla.net... 126.96.36.199 Connecting to download-installer.cdn.mozilla.net|188.8.131.52|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 245408 (240K) [application/x-msdownload] Saving to: ‘staging.exe’ staging.exe 100%[===============================================================================================================================================>] 239.66K 175KB/s in 1.4s 2016-12-20 21:11:13 (175 KB/s) - ‘staging.exe’ saved [245408/245408] Also verified the SHA1 is still fda025d247855ef0b28f323fe0ffd1600ae3f13e.
You should only get an altered one if the request to bouncer includes the attribution_code and attribution_sig attributes you should get from www-demo4, assuming you go there with either some utm_* params or an interesting referrer header.
agibson suggests: https://www-demo4.allizom.org/en-US/firefox/new/?utm_source=google&utm_medium=paidsearch&utm_campaign=Brand-US-GGL-Exact&utm_term=download%20firefox&gclid=CKT-i-e11tACFYF7fgod8r4JAw which yields (timestamp & sig specific to my request) https://bouncer-bouncer.stage.mozaws.net/?product=firefox-stub&os=win&lang=en-US&attribution_code=source%3D%26medium%3Dreferral%26campaign%3Dfoo%26content%3D%28not+set%29%26timestamp%3D1482268537&attribution_sig=8c4df1b8632627d4e8a86cf43acf78f4c5bd088353b356be7f81fa9879d5227b Changing firefox-stub to test-stub results in 302 https://stubattribution-default.stage.mozaws.net/?attribution_code=source%3D%26medium%3Dreferral%26campaign%3Dfoo%26content%3D%28not+set%29%26timestamp%3D1482268537&attribution_sig=8c4df1b8632627d4e8a86cf43acf78f4c5bd088353b356be7f81fa9879d5227b&lang=en-US&os=win&product=test-stub 302 https://download.mozilla.org/?lang=en-US&os=win&product=test-stub 302 https://download-installer.cdn.mozilla.net/pub/firefox/nightly/experimental/bug1318456/test-stub.exe ie the test stub with the dummy cert but nothing added to it. Any thoughts oremj ?
Clearing need-info? for Jeremy, as I've gotten this working multiple times, now, for both the "organic" and "campaign"-type flows. A couple of fixes have landed to make this possible: * https://github.com/mozilla-services/stubattribution/commit/5e8d5b4853acabddff25ce13c3f223695d3ac44a * https://github.com/mozilla-services/stubattribution/commit/75d1962e5ba66e6ca676c09180f0b45506886a10 Additionally (and I'm still following up with the Telemetry team on this behavior), the attribution.* fields and their values seem to only appear after Firefox restarts; per bug 1292360 comment 41, they are sent with the "main" Telemetry ping (http://gecko.readthedocs.io/en/latest/toolkit/components/telemetry/telemetry/data/main-ping.html) so I'm unfurling that behavior/expectation, now. Going to mark this as WORKSFORME - it's not INVALID since there were fixes, but I think that's the most-appropriate status, now.
Created attachment 8821600 [details] Screenshot showing associated values for an attribution.medium type of "referral" working
Created attachment 8821601 [details] Screenshot showing associated values for a working attribution.medium type of "paidsearch"
Attachment #8821600 - Attachment description: Screen Shot 2016-12-22 at 11.13.45 AM.png → Screenshot showing associated values for an attribution.medium type of "referral" working
Attachment #8821601 - Attachment description: Screen Shot 2016-12-22 at 11.23.49 AM.png → Screenshot showing associated values for a working attribution.medium type of "paidsearch"
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.