Unable to see neither stub-attribution keys/values in Telemetry, nor associated postSigningData file

RESOLVED WORKSFORME

Status

--
blocker
RESOLVED WORKSFORME
2 years ago
10 months ago

People

(Reporter: stephend, Unassigned)

Tracking

(Blocks: 1 bug)

Details

Attachments

(2 attachments)

(Reporter)

Description

2 years ago
(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... 52.0.57.175
Connecting to bouncer-bouncer.stage.mozaws.net|52.0.57.175|: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... 52.84.210.156
Connecting to download-installer.cdn.mozilla.net|52.84.210.156|: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.
(Reporter)

Comment 5

2 years ago
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.
Flags: needinfo?(oremj)
(Reporter)

Comment 6

2 years ago
Created attachment 8821600 [details]
Screenshot showing associated values for an attribution.medium type of "referral" working
(Reporter)

Comment 7

2 years ago
Created attachment 8821601 [details]
Screenshot showing associated values for a working attribution.medium type of "paidsearch"
(Reporter)

Updated

2 years ago
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
(Reporter)

Updated

2 years ago
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"
(Reporter)

Updated

2 years ago
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME

Updated

10 months ago
Product: Testing → Testing Graveyard
You need to log in before you can comment on or make changes to this bug.