Bugzilla

(Anna already has some context for this) 

TLDR: we'd like production-ize and schedule a new desktop feature usage table that looks substantially like the query at [1].

## Overview

Currently, telemetry related to desktop feature usage is spread across many pings/tables, and the correct way off aggregating these measures is not always straightforward. (The term "feature usage" here refers telemetry designed to measure behaviors about specific browser features, e.g. the password manager, pinned tabs etc). 

We'd like to create a simplified view onto the most important and frequently used metrics related to Desktop browser feature usage by creating a new "feature usage" table. 

## Why We Want This

There are two intended uses for this table:

1. For Data Scientists: exploratory modeling of client behavior sometimes involves training models with many features/measurements. In the past this has involved substantial work in the way of custom queries that pull from many sources. It would be more efficient to have a single table of client-day data that is likely to contain most of the variables of interest. 

2. For Users of Looker:  We can lower the looker learning curve for PMs and other non-data-team users by collecting together the most commonly asked-for metrics related to desktop feature usage into a single Looker explore (rather than having these measures spread across e.g. clients_daily and events tables). The existence of this per-aggregated table will make implementing this Looker view much easier. 

## Table Overview

[1] links to a prototype query. the query was used to generate a small sample table at `mozdata.analysis.csl_feature_set_test_v1`

Important things to know about how this was constructed, in terms of assumptions and what we're trying to achieve (likely to be points for discussion):

1. The table has a wide, client-day format similar to clients_daily (one row per client per day).  
2. We would like to implement this in a way such that is maximally easy to add new measures. New features/telemetry are being added all the time and we see this dataset as eventually being the place to go for metrics related to new browser features (aspirational).
3. **The query linked above does not currently implement this**, however we intend there to be a special handling of null vs 0 values. In particular, we intend to coalesce all nulls for numerical measures to 0 in cases where the client was on an eligible browser version (i.e. a version where the underlying telemetry was implemented); otherwise leave the measure as null for ineligible versions. This would require, for each measurement, comparing the reported app_version against a minimum version from some metadata. The spreadsheet at [2] contains the minimum version for all the measurements contained in the prototype query.
4. (There was a bit of back and forth about this) we do not intend to expose all of these measurements in looker - some of them have not been verified in detail by DS to be reliable. We intend to reflect which measurements have been verified via some metadata - e.g. the "vetted" column in the spreadsheet at [2]. We hope this adds a (manageable) layer of curation to the dataset that will increase people's trust in the vetted metrics, while not gatekeeping and still allowing quick additions of other metrics that haven't been scrutinized (i.e. caveat emptor on all metrics that have `vetted` = FALSE in the spreadsheet).
5. Currently, the query for [1] operates on a 1% sample. This is generally enough data for DS needs and we believe (tentatively) that scaling the results by 100 for use in looker should be OK. The main downside here is that this blocks client-level joins to other telemetry (e.g. from experiments). Assuming the cost savings are substantial, I think this will be fine. In any case, I think at least starting out on a sample makes sense, and we can evaluate later if we run into use cases for the full dataset.

I think that covers the main points for now. Generally all of the above is negotiable, so please let us know if any of it presents major problems. 

[1] https://github.com/mozilla/feature_table/blob/main/query.sql
[2] https://docs.google.com/spreadsheets/d/1AwrhjWn_ujlyhpeCwBGN_5Fqfl8frYx_PEoN_t5abhY/edit#gid=1288034616

(Anna already has some context for this) 

TLDR: we'd like production-ize and schedule a new desktop feature usage table that looks substantially like the query at [1].

## Overview

Currently, telemetry related to desktop feature usage is spread across many pings/tables, and the correct way of aggregating these measures is not always straightforward. (The term "feature usage" here refers telemetry designed to measure behaviors about specific browser features, e.g. the password manager, pinned tabs etc). 

We'd like to create a simplified view onto the most important and frequently used metrics related to Desktop browser feature usage by creating a new "feature usage" table. 

## Why We Want This

There are two intended uses for this table:

1. For Data Scientists: exploratory modeling of client behavior sometimes involves training models with many features/measurements. In the past this has involved substantial work in the way of custom queries that pull from many sources. It would be more efficient to have a single table of client-day data that is likely to contain most of the variables of interest. 

2. For Users of Looker:  We can lower the looker learning curve for PMs and other non-data-team users by collecting together the most commonly asked-for metrics related to desktop feature usage into a single Looker explore (rather than having these measures spread across e.g. clients_daily and events tables). The existence of this per-aggregated table will make implementing this Looker view much easier. 

## Table Overview

[1] links to a prototype query. the query was used to generate a small sample table at `mozdata.analysis.csl_feature_set_test_v1`

Important things to know about how this was constructed, in terms of assumptions and what we're trying to achieve (likely to be points for discussion):

1. The table has a wide, client-day format similar to clients_daily (one row per client per day).  
2. We would like to implement this in a way such that is maximally easy to add new measures. New features/telemetry are being added all the time and we see this dataset as eventually being the place to go for metrics related to new browser features (aspirational).
3. **The query linked above does not currently implement this**, however we intend there to be a special handling of null vs 0 values. In particular, we intend to coalesce all nulls for numerical measures to 0 in cases where the client was on an eligible browser version (i.e. a version where the underlying telemetry was implemented); otherwise leave the measure as null for ineligible versions. This would require, for each measurement, comparing the reported app_version against a minimum version from some metadata. The spreadsheet at [2] contains the minimum version for all the measurements contained in the prototype query.
4. (There was a bit of back and forth about this) we do not intend to expose all of these measurements in looker - some of them have not been verified in detail by DS to be reliable. We intend to reflect which measurements have been verified via some metadata - e.g. the "vetted" column in the spreadsheet at [2]. We hope this adds a (manageable) layer of curation to the dataset that will increase people's trust in the vetted metrics, while not gatekeeping and still allowing quick additions of other metrics that haven't been scrutinized (i.e. caveat emptor on all metrics that have `vetted` = FALSE in the spreadsheet).
5. Currently, the query for [1] operates on a 1% sample. This is generally enough data for DS needs and we believe (tentatively) that scaling the results by 100 for use in looker should be OK. The main downside here is that this blocks client-level joins to other telemetry (e.g. from experiments). Assuming the cost savings are substantial, I think this will be fine. In any case, I think at least starting out on a sample makes sense, and we can evaluate later if we run into use cases for the full dataset.

I think that covers the main points for now. Generally all of the above is negotiable, so please let us know if any of it presents major problems. 

[1] https://github.com/mozilla/feature_table/blob/main/query.sql
[2] https://docs.google.com/spreadsheets/d/1AwrhjWn_ujlyhpeCwBGN_5Fqfl8frYx_PEoN_t5abhY/edit#gid=1288034616

(Anna already has some context for this) 

TLDR: we'd like production-ize and schedule a new desktop feature usage table that looks substantially like the query at [1].

## Overview

Currently, telemetry related to desktop feature usage is spread across many pings/tables, and the correct way of aggregating these measures is not always straightforward. (The term "feature usage" here refers to telemetry designed to measure behaviors about specific browser features, e.g. the password manager, pinned tabs etc). 

We'd like to create a simplified view onto the most important and frequently used metrics related to Desktop browser feature usage by creating a new "feature usage" table. 

## Why We Want This

There are two intended uses for this table:

1. For Data Scientists: exploratory modeling of client behavior sometimes involves training models with many features/measurements. In the past this has involved substantial work in the way of custom queries that pull from many sources. It would be more efficient to have a single table of client-day data that is likely to contain most of the variables of interest. 

2. For Users of Looker:  We can lower the looker learning curve for PMs and other non-data-team users by collecting together the most commonly asked-for metrics related to desktop feature usage into a single Looker explore (rather than having these measures spread across e.g. clients_daily and events tables). The existence of this per-aggregated table will make implementing this Looker view much easier. 

## Table Overview

[1] links to a prototype query. the query was used to generate a small sample table at `mozdata.analysis.csl_feature_set_test_v1`

Important things to know about how this was constructed, in terms of assumptions and what we're trying to achieve (likely to be points for discussion):

1. The table has a wide, client-day format similar to clients_daily (one row per client per day).  
2. We would like to implement this in a way such that is maximally easy to add new measures. New features/telemetry are being added all the time and we see this dataset as eventually being the place to go for metrics related to new browser features (aspirational).
3. **The query linked above does not currently implement this**, however we intend there to be a special handling of null vs 0 values. In particular, we intend to coalesce all nulls for numerical measures to 0 in cases where the client was on an eligible browser version (i.e. a version where the underlying telemetry was implemented); otherwise leave the measure as null for ineligible versions. This would require, for each measurement, comparing the reported app_version against a minimum version from some metadata. The spreadsheet at [2] contains the minimum version for all the measurements contained in the prototype query.
4. (There was a bit of back and forth about this) we do not intend to expose all of these measurements in looker - some of them have not been verified in detail by DS to be reliable. We intend to reflect which measurements have been verified via some metadata - e.g. the "vetted" column in the spreadsheet at [2]. We hope this adds a (manageable) layer of curation to the dataset that will increase people's trust in the vetted metrics, while not gatekeeping and still allowing quick additions of other metrics that haven't been scrutinized (i.e. caveat emptor on all metrics that have `vetted` = FALSE in the spreadsheet).
5. Currently, the query for [1] operates on a 1% sample. This is generally enough data for DS needs and we believe (tentatively) that scaling the results by 100 for use in looker should be OK. The main downside here is that this blocks client-level joins to other telemetry (e.g. from experiments). Assuming the cost savings are substantial, I think this will be fine. In any case, I think at least starting out on a sample makes sense, and we can evaluate later if we run into use cases for the full dataset.

I think that covers the main points for now. Generally all of the above is negotiable, so please let us know if any of it presents major problems. 

[1] https://github.com/mozilla/feature_table/blob/main/query.sql
[2] https://docs.google.com/spreadsheets/d/1AwrhjWn_ujlyhpeCwBGN_5Fqfl8frYx_PEoN_t5abhY/edit#gid=1288034616

(Anna already has some context for this) 

TLDR: we'd like production-ize and schedule a new desktop feature usage table that looks substantially like the query at [1].

## Overview

Currently, telemetry related to desktop feature usage is spread across many pings/tables, and the correct way of aggregating these measures is not always straightforward. (The term "feature usage" here refers to telemetry designed to measure behaviors about specific browser features, e.g. the password manager, pinned tabs etc). 

We'd like to create a simplified view onto the most important and frequently used metrics related to Desktop browser feature usage by creating a new "feature usage" table. 

## Why We Want This

There are two intended uses for this table:

1. For Data Scientists: exploratory modeling of client behavior sometimes involves training models with many features/measurements. In the past this has involved substantial work in the way of custom queries that pull from many sources. It would be more efficient to have a single table of client-day data that is likely to contain most of the variables of interest. 

2. For Users of Looker:  We can lower the looker learning curve for PMs and other non-data-team users by collecting together the most commonly asked-for metrics related to desktop feature usage into a single Looker explore (rather than having these measures spread across e.g. clients_daily and events tables). The existence of this pre-aggregated table will make implementing this Looker view much easier. 

## Table Overview

[1] links to a prototype query. the query was used to generate a small sample table at `mozdata.analysis.csl_feature_set_test_v1`

Important things to know about how this was constructed, in terms of assumptions and what we're trying to achieve (likely to be points for discussion):

1. The table has a wide, client-day format similar to clients_daily (one row per client per day).  
2. We would like to implement this in a way such that is maximally easy to add new measures. New features/telemetry are being added all the time and we see this dataset as eventually being the place to go for metrics related to new browser features (aspirational).
3. **The query linked above does not currently implement this**, however we intend there to be a special handling of null vs 0 values. In particular, we intend to coalesce all nulls for numerical measures to 0 in cases where the client was on an eligible browser version (i.e. a version where the underlying telemetry was implemented); otherwise leave the measure as null for ineligible versions. This would require, for each measurement, comparing the reported app_version against a minimum version from some metadata. The spreadsheet at [2] contains the minimum version for all the measurements contained in the prototype query.
4. (There was a bit of back and forth about this) we do not intend to expose all of these measurements in looker - some of them have not been verified in detail by DS to be reliable. We intend to reflect which measurements have been verified via some metadata - e.g. the "vetted" column in the spreadsheet at [2]. We hope this adds a (manageable) layer of curation to the dataset that will increase people's trust in the vetted metrics, while not gatekeeping and still allowing quick additions of other metrics that haven't been scrutinized (i.e. caveat emptor on all metrics that have `vetted` = FALSE in the spreadsheet).
5. Currently, the query for [1] operates on a 1% sample. This is generally enough data for DS needs and we believe (tentatively) that scaling the results by 100 for use in looker should be OK. The main downside here is that this blocks client-level joins to other telemetry (e.g. from experiments). Assuming the cost savings are substantial, I think this will be fine. In any case, I think at least starting out on a sample makes sense, and we can evaluate later if we run into use cases for the full dataset.

I think that covers the main points for now. Generally all of the above is negotiable, so please let us know if any of it presents major problems. 

[1] https://github.com/mozilla/feature_table/blob/main/query.sql
[2] https://docs.google.com/spreadsheets/d/1AwrhjWn_ujlyhpeCwBGN_5Fqfl8frYx_PEoN_t5abhY/edit#gid=1288034616