Support attribution from the Microsoft Store
Categories
(Firefox :: Installer, enhancement, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox101 | --- | fixed |
People
(Reporter: nalexander, Assigned: bhearsum)
References
Details
(Whiteboard: [fidedi-tikka])
Attachments
(3 files)
Firefox implements a bespoke attribution system to determine what, if any, promotional campaign sparked the download and install of the product. Roughly speaking, the downloaded stub installer has attribution data encoded in its signature, which it writes to disk at install time. The installed product reads that attribution data and reports it via regular old telemetry. Since MSIX packages don't have an install time step, the system cannot succeed. We'd still like attribution for Microsoft Store installs, and Windows has an API for getting this at run time.
It looks like the magic words are “cid” (campaign ID): see https://docs.microsoft.com/en-us/windows/uwp/publish/create-a-custom-app-promotion-campaign. It does look like Firefox could fetch this attribution data from Windows/the Microsoft Store: see this SO question. This ticket tracks wiring up the XPCOM components for accessing the campaign ID (similar to the technical details of Bug 1743465, I expect) and then using those components in AttributionCode.jsm to produce the attribution file from the campaign ID.
Updated•4 years ago
|
| Reporter | ||
Comment 1•4 years ago
|
||
It looks like testing this is pretty easy: install from the Microsoft Store with an &cid=... URL parameter in the link to the ms-windows-store:// URL. See the linked documentation above.
| Assignee | ||
Comment 2•4 years ago
|
||
I'm likely working on this in the next month or so.
Updated•4 years ago
|
| Assignee | ||
Comment 3•4 years ago
|
||
| Assignee | ||
Comment 4•4 years ago
|
||
I've done a significant amount of digging and testing here, and I'm still not at a point where this feels like it can be useful. It's possible that I'm missing something, or doing something wrong -- but based on the patch posted and some other testing (see below) I haven't found a way to actual capture the campaign IDs within Firefox.
Here's a summary of the issues:
- I have not been able to pull campaign IDs out of Firefox installs done through the Microsoft Store in any way, nor on any Windows version. They always come up as an empty string regardless of Windows version, whether or not I'm signed into the Microsoft Store, and every other variation I've tried.
- I have been able to see some campaign IDs show up on the Partner Centre -- but only for installs done on Windows 11, while signed into the Microsoft Store. No installs done on Windows 10 have shown up, nor have Windows 11 ones shown up if I wasn't signed into the Store before I installed. There's also a 4-5 day lag for campaign data on that dashboard.
- Even with a very small test app, which uses the exact code from the link in comment #0, campaign IDs were only available for installs done when signed into the Microsoft Store (this seemed to work for Windows 10 & 11). It is notable that this was a C# app uploaded as an .msixbundle (which means Microsoft builds it themselves AFAICT) -- but ultimately it uses the same APIs, so the behaviour differences are pretty surprising, and do make me wonder if my C++ translation of the code has an issue. (Although I did find some other C++ code that looks almost the same, which makes that seem less likely: https://github.com/jaimerodriguez/CampaignIdUWP/blob/master/WRL/WinRTComponent/WRLSample/WRLSample.Shared/CampaignIdHelper.cpp)
A second set of eyes would be appreciated here, and it may be time to poke Microsoft for some pointers as well.
| Assignee | ||
Comment 5•4 years ago
|
||
An update:
After a conversation with nalexander, I tested again on a machine that had never installed Firefox Nightly through the Store -- and I got a campaign id out of the API! It appears as if there's some very long lived (possibly forever?) caching that does not get reset after an uninstall/reinstall, or anything else I tried. I was able to make it work for both Windows 10 and Windows 11 when I was signed into the Microsoft Store, but still no luck finding it when not signed in.
At this point I think it would be good to have QA do a bit of testing in totally fresh installs to remove any chance that my testing is invalid. Here are the instructions for doing so. Note that they must be done from a fresh Windows install to avoid any contamination. Ideally, these tests would be run on Windows 10 & Windows 11. I'll send an installation through Slack, as I don't want our internal-only Nightly URLs to leak.
Scenario 1:
- Install Firefox Nightly through the link provided through Slack
- Open the Browser Console
- Run the following:
let wpm = Cc["@mozilla.org/windows-package-manager;1"].getService(Ci.nsIWindowsPackageManager)
wpm.campaignId
Expected resulted: wpm.campaignId should be "bug1756209campaigntest"
Scenario 2:
- Sign into the Microsoft Store with an accoun that has never installed Firefox Nightly through the Store before.
- Install Firefox Nightly through the link provided through Slack
- Open the Browser Console
- Run the following:
let wpm = Cc["@mozilla.org/windows-package-manager;1"].getService(Ci.nsIWindowsPackageManager)
wpm.campaignId
Updated•4 years ago
|
Comment 6•4 years ago
|
||
Followed the two scenarios on both Windows 10 and Windows 11 with clean environments using the link I was provided on Slack. For both scenarios the same "bug1756209campaigntest" message was shown after introducing the command in browser console.
After that, I tried installing the build without an user logged in the Windows store (as I think this is another possible scenario) and after introducing the command in browser console, an empty "" was shown as a return.
Please let me know if I can help further with the testing. Thank you!
| Assignee | ||
Comment 7•4 years ago
|
||
Nearly all the complexity here is abstracted away in the previous patch, so this is quite straightforward other than the one oddity noted in the comments.
Depends on D141987
Updated•4 years ago
|
Updated•4 years ago
|
| Assignee | ||
Comment 8•4 years ago
|
||
Updated•4 years ago
|
Comment 9•4 years ago
|
||
Comment on attachment 9273054 [details]
data review request
Data Review
- Is there or will there be documentation that describes the schema for the ultimate data set in a public, complete, and accurate way?
Yes, the patch contains documentation that will live at https://searchfox.org/mozilla-central/source/toolkit/components/telemetry/docs/data/environment.rst
- Is there a control mechanism that allows the user to turn the data collection on and off?
Yes, through the standard telemetry preference
- If the request is for permanent data collection, is there someone who will monitor the data over time?
The collection is scheduled for a single release cycle, with :bhearsum responsible for it
- Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?
Category 1, Technical Data
- Is the data collection request for default-on or default-off?
Default-on
- Does the instrumentation include the addition of any new identifiers (whether anonymous or otherwise; e.g., username, random IDs, etc. See the appendix for more details)?
No
- Is the data collection covered by the existing Firefox privacy notice?
Yes
- Does the data collection use a third-party collection tool?
No
Result
data-review+
Comment 10•4 years ago
|
||
Comment 11•4 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/1ac4b75549ae
https://hg.mozilla.org/mozilla-central/rev/45d880cce7be
Description
•