зеркало из https://github.com/mozilla/data-docs.git
Use a consistent format (STMO#<number>) for all links to STMO
This keeps the naming consistent and also provides a hint about how old / new a query might be. Co-Authored-By: Jan-Erik Rediger <jrediger@mozilla.com>
This commit is contained in:
William Lachance
Jan-Erik Rediger
Родитель
86b48c909f
Коммит
bde81f45a8
|
|
@ -30,7 +30,7 @@ When you start to evaluate trends, be aware of events from the past that may inv
|
|||
- **Sep 30 2021 - Oct 06 2021** - [Submissions from some countries were rejected][bug1733953].
|
||||
- **Sep 30 2021 - Oct 04 2021** - [Submissions from clients on some older platforms were dropped][bug1733953].
|
||||
- **Aug 23 2021 - Aug 29 2021** - [Approximately 1/251 of pings were improperly labeled as coming from Kansas City, US][bug1729069].
|
||||
- **Aug 05 2021 - Aug 31 2021** - Drop in search metrics (`tagged_sap`, `tagged_follow_on`, `search_with_ads`, `ad_click`) in Fenix due to probe expiry. [Incident report](https://docs.google.com/document/d/1C29HmYponPcqtX4yR4QA7uBkhhkAM76WqMW3PQBnL_g/edit) and [query](https://sql.telemetry.mozilla.org/queries/82098/source#203423).
|
||||
- **Aug 05 2021 - Aug 31 2021** - Drop in search metrics (`tagged_sap`, `tagged_follow_on`, `search_with_ads`, `ad_click`) in Fenix due to probe expiry. [Incident report](https://docs.google.com/document/d/1C29HmYponPcqtX4yR4QA7uBkhhkAM76WqMW3PQBnL_g/edit) and [`STMO#203423`](https://sql.telemetry.mozilla.org/queries/82098/source#203423).
|
||||
- **Feb 16 2021 - Feb 25 2021** - [A small number of stub installer pings may have been discarded due to URI deduplication][bug1694764].
|
||||
- **August 6, 2020** - [Pings with "automation" tag in X-Source-Tags will no longer appear in stable tables][bq1215]
|
||||
This is particularly relevant for removing pings related to automated testing of Fenix.
|
||||
|
|
@ -232,7 +232,7 @@ Other types of pings are not sent with Pingsender.
|
|||
This is usually okay because Firefox is expected to continue to run long
|
||||
enough to send these pings.
|
||||
|
||||
Mobile clients do not have Pingsender. Therefore, a delay occurs as described in [this query][delay_q].
|
||||
Mobile clients do not have Pingsender. Therefore, a delay occurs as described in [`STMO#49867`][delay_q].
|
||||
|
||||
[bug 1310703]: https://bugzilla.mozilla.org/show_bug.cgi?id=1310703
|
||||
[bug 1374270]: https://bugzilla.mozilla.org/show_bug.cgi?id=1374270
|
||||
|
|
@ -257,7 +257,7 @@ Summary of reasons for this decision:
|
|||
|
||||
In general, data coming from an application instance not run by a human is not wanted in analysis. As of this writing, [GeckoDriver](https://github.com/mozilla/geckodriver) (one of the official mechanisms to launch and control an automated version of Firefox for e.g. web compatibility testing) is [configured _not_ to send Telemetry by default](https://searchfox.org/mozilla-central/rev/baf1cd492406a9ac31d9ccb7a51c924c7fbb151f/testing/geckodriver/src/prefs.rs#154) but we can't control for other things people might do in the field.
|
||||
|
||||
On desktop, one field to watch out for is headless mode (`environment.system.gfx.headless` in the main ping): if that field is set, you are for certain not working with a version of Firefox being operated by a real human. You can see an example of some client pings with this field set skewing the nightly numbers in [bug 1643341](https://bugzilla.mozilla.org/show_bug.cgi?id=1643341). An easy solution is to just filter out these types of clients in your analysis. You can see an example of this pattern in [this query](https://sql.telemetry.mozilla.org/queries/71781/source).
|
||||
On desktop, one field to watch out for is headless mode (`environment.system.gfx.headless` in the main ping): if that field is set, you are for certain not working with a version of Firefox being operated by a real human. You can see an example of some client pings with this field set skewing the nightly numbers in [bug 1643341](https://bugzilla.mozilla.org/show_bug.cgi?id=1643341). An easy solution is to just filter out these types of clients in your analysis. You can see an example of this pattern in [`STMO#71781`](https://sql.telemetry.mozilla.org/queries/71781/source).
|
||||
|
||||
## Build Ids
|
||||
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ the next task is scheduled.
|
|||
|
||||
Failures are ignored.
|
||||
|
||||
The raw data is available in BigQuery (see an example [ADI query in Redash](https://sql.telemetry.mozilla.org/queries/66481)).
|
||||
The raw data is available in BigQuery (see [`STMO#66481`](https://sql.telemetry.mozilla.org/queries/66481)).
|
||||
|
||||
Telemetry only reports whether blocklist checking is enabled or disabled
|
||||
on the client; there is no data in telemetry about blocklist fetches,
|
||||
|
|
|
|||
|
|
@ -125,8 +125,8 @@ On the pipeline side, the event data is made available in different datasets:
|
|||
|
||||
- [`main_summary`](../../datasets/batch_view/main_summary/reference.md) has a row for each main ping and includes
|
||||
its event payload for Firefox versions before 62.
|
||||
- [`events`](../../datasets/batch_view/events/reference.md) contains a row for each event received from main pings and event pings. See [this sample query](https://sql.telemetry.mozilla.org/queries/52582/source).
|
||||
- `telemetry_mobile_event_parquet` contains a row for each mobile event ping. See [this sample query](https://sql.telemetry.mozilla.org/queries/52581/source).
|
||||
- [`events`](../../datasets/batch_view/events/reference.md) contains a row for each event received from main pings and event pings. See [`STMO#52582`](https://sql.telemetry.mozilla.org/queries/52582/source).
|
||||
- `telemetry_mobile_event_parquet` contains a row for each mobile event ping. See [`STMO#52581`](https://sql.telemetry.mozilla.org/queries/52581/source).
|
||||
- `focus_events_longitudinal` currently contains events from Firefox Focus.
|
||||
|
||||
# Data tooling
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ WHERE date(submission_timestamp) >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY)
|
|||
GROUP BY crash_date
|
||||
```
|
||||
|
||||
[Link to query in STMO](https://sql.telemetry.mozilla.org/queries/67925/).
|
||||
[`STMO#67925`](https://sql.telemetry.mozilla.org/queries/67925/).
|
||||
|
||||
Although the total crash counts is not always useful, you may want to restrict
|
||||
a query to a channel or some other dimensions, and also facet the results. Therefore, you can add a few more fields to the SQL:
|
||||
|
|
@ -30,7 +30,7 @@ GROUP BY normalized_os,
|
|||
crash_date
|
||||
```
|
||||
|
||||
[Link to query in STMO](https://sql.telemetry.mozilla.org/queries/67927/)
|
||||
[`STMO#67927`](https://sql.telemetry.mozilla.org/queries/67927/)
|
||||
|
||||
These are just initial examples. You can query across all the fields in
|
||||
a telemetry crash ping, which provides useful information about the crashes themselves. You can view a summary of the available fields in the STMO schema browser, referring to [the documentation on the Firefox crash ping](https://firefox-source-docs.mozilla.org/toolkit/components/telemetry/data/crash-ping.html)
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ LIMIT
|
|||
3
|
||||
```
|
||||
|
||||
[link](https://sql.telemetry.mozilla.org/queries/71333/source)
|
||||
[`STMO#71333`](https://sql.telemetry.mozilla.org/queries/71333/source)
|
||||
|
||||
Running this query on STMO, we get the following output:
|
||||
|
||||
|
|
@ -83,7 +83,7 @@ FROM
|
|||
intermediate;
|
||||
```
|
||||
|
||||
[link](https://sql.telemetry.mozilla.org/queries/71408/source)
|
||||
[`STMO#71408`](https://sql.telemetry.mozilla.org/queries/71408/source)
|
||||
|
||||
Which yields:
|
||||
|
||||
|
|
@ -129,7 +129,7 @@ CROSS JOIN
|
|||
UNNEST(percentiles.percentile_nested);
|
||||
```
|
||||
|
||||
[link](https://sql.telemetry.mozilla.org/queries/71410/source)
|
||||
[`STMO#71410`](https://sql.telemetry.mozilla.org/queries/71410/source)
|
||||
|
||||
Which gives us this set of results:
|
||||
|
||||
|
|
@ -199,9 +199,9 @@ CROSS JOIN
|
|||
)
|
||||
```
|
||||
|
||||
[link](https://sql.telemetry.mozilla.org/queries/71472/source)
|
||||
[`STMO#71472`](https://sql.telemetry.mozilla.org/queries/71472/source)
|
||||
|
||||
As an implementation note, observe that we don't use `histogram_merge` here as we do above: doing so would require using [`ARRAY_AGG`](https://cloud.google.com/bigquery/docs/reference/standard-sql/functions-and-operators#array_agg) which can break down when processing large amounts of data. Instead we create an intermediate result (the `per_build_day` `WITH` statement) and then reprocess it into a structured representation. If you're curious what the version using `histogram_merge` would look like, see [this example](https://sql.telemetry.mozilla.org/queries/71413/source).
|
||||
As an implementation note, observe that we don't use `histogram_merge` here as we do above: doing so would require using [`ARRAY_AGG`](https://cloud.google.com/bigquery/docs/reference/standard-sql/functions-and-operators#array_agg) which can break down when processing large amounts of data. Instead we create an intermediate result (the `per_build_day` `WITH` statement) and then reprocess it into a structured representation. If you're curious what the version using `histogram_merge` would look like, see [`STMO#71413`](https://sql.telemetry.mozilla.org/queries/71413/source).
|
||||
|
||||
In any case, rendering the data this query returns, we get a chart like this:
|
||||
|
||||
|
|
@ -285,7 +285,7 @@ CROSS JOIN
|
|||
UNNEST(percentiles.percentile_nested);
|
||||
```
|
||||
|
||||
[link](https://sql.telemetry.mozilla.org/queries/71489/source)
|
||||
[`STMO#71489`](https://sql.telemetry.mozilla.org/queries/71489/source)
|
||||
|
||||
You'll notice this query groups by `client_id` in addition to `build_id` before `mozfun.hist.normalize`. Grouping by `client_id` gives each user equal representation and prevents "power users" from skewing the result.
|
||||
|
||||
|
|
@ -370,7 +370,7 @@ CROSS JOIN
|
|||
UNNEST(percentiles.percentile_nested);
|
||||
```
|
||||
|
||||
[link](https://sql.telemetry.mozilla.org/queries/71437/source)
|
||||
[`STMO#71437`](https://sql.telemetry.mozilla.org/queries/71437/source)
|
||||
|
||||
If we do this, we see this chart:
|
||||
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ WHERE event_category = 'pwmgr'
|
|||
AND sample_id=0
|
||||
```
|
||||
|
||||
[link](https://sql.telemetry.mozilla.org/queries/73401/source)
|
||||
[`STMO#73401`](https://sql.telemetry.mozilla.org/queries/73401/source)
|
||||
|
||||
## Scheduling
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ limit to a short submission date range.
|
|||
## Accessing the Data
|
||||
|
||||
The `main_summary` table is accessible through STMO.
|
||||
Here's an [example query](https://sql.telemetry.mozilla.org/queries/4201/source).
|
||||
See [`STMO#4201`](https://sql.telemetry.mozilla.org/queries/4201/source) for an example.
|
||||
|
||||
## Data Reference
|
||||
|
||||
|
|
|
|||
|
|
@ -56,7 +56,7 @@ each `country` would be the same as if MAU were calculated only by `channel`.
|
|||
#### Accessing the Data
|
||||
|
||||
The data is available in Re:dash and BigQuery. Take a look at this full running
|
||||
[example query in Re:dash](https://sql.telemetry.mozilla.org/queries/62029/source#159510).
|
||||
[example query in Re:dash (`STMO#159510`)](https://sql.telemetry.mozilla.org/queries/62029/source#159510).
|
||||
|
||||
# Data Reference
|
||||
|
||||
|
|
|
|||
|
|
@ -219,6 +219,6 @@ randomly assigned to one and only one bucket. If we sum MAU numbers for each
|
|||
bucket individually, we can use resampling techniques to determine the magnitude
|
||||
of variation and assign a confidence interval to our sums.
|
||||
|
||||
As an example of calculating confidence intervals, see the
|
||||
[Desktop MAU KPI query in STMO](https://sql.telemetry.mozilla.org/queries/61957/source)
|
||||
As an example of calculating confidence intervals, see
|
||||
[`STMO#61957`](https://sql.telemetry.mozilla.org/queries/61957/source)
|
||||
which uses a jackknife resampling technique implemented as a BigQuery UDF.
|
||||
|
|
|
|||
|
|
@ -87,7 +87,7 @@ GROUP BY
|
|||
date, app_name
|
||||
```
|
||||
|
||||
[link to query on STMO](https://sql.telemetry.mozilla.org/queries/74291/source)
|
||||
[`STMO#74291`](https://sql.telemetry.mozilla.org/queries/74291/source)
|
||||
|
||||
### Calculate Apple App Store Activity for a given day and app by source
|
||||
|
||||
|
|
@ -110,7 +110,7 @@ GROUP BY
|
|||
date, app_name, source
|
||||
```
|
||||
|
||||
[link to query on STMO](https://sql.telemetry.mozilla.org/queries/74290/source)
|
||||
[`STMO#74290`](https://sql.telemetry.mozilla.org/queries/74290/source)
|
||||
|
||||
## Scheduling
|
||||
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ GROUP BY 1,2
|
|||
ORDER BY 1
|
||||
```
|
||||
|
||||
[Link to query in STMO](https://sql.telemetry.mozilla.org/queries/72054)
|
||||
[`STMO#72054`](https://sql.telemetry.mozilla.org/queries/72054)
|
||||
|
||||
## Scheduling
|
||||
|
||||
|
|
|
|||
|
|
@ -98,7 +98,7 @@ ORDER BY
|
|||
Store_Visits DESC
|
||||
```
|
||||
|
||||
[link to query on STMO](https://sql.telemetry.mozilla.org/queries/74289/source)
|
||||
[`STMO#74289`](https://sql.telemetry.mozilla.org/queries/74289/source)
|
||||
|
||||
### Calculate Google Play Store activity for a given day by source and app
|
||||
|
||||
|
|
@ -120,7 +120,7 @@ ORDER BY
|
|||
package_name, Store_Visits
|
||||
```
|
||||
|
||||
[link to query on STMO](https://sql.telemetry.mozilla.org/queries/74288/source)
|
||||
[`STMO#74288`](https://sql.telemetry.mozilla.org/queries/74288/source)
|
||||
|
||||
## Scheduling
|
||||
|
||||
|
|
|
|||
|
|
@ -12,4 +12,4 @@ The `attitudes_daily` table is accessible through STMO using the
|
|||
`Telemetry (BigQuery)` data source.
|
||||
The full table name is `moz-fx-data-shared-prod.telemetry.attitudes_daily`.
|
||||
|
||||
Here's an [example query](https://sql.telemetry.mozilla.org/queries/63937/source#163424).
|
||||
Here's an [example query (`STMO#163424`)](https://sql.telemetry.mozilla.org/queries/63937/source#163424).
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ The HyperLogLog variable is a far more efficient way to count distinct elements
|
|||
but comes with some complexity.
|
||||
To find the cardinality of an HLL use `cardinality(cast(hll AS HLL))`.
|
||||
To find the union of two HLL's over different dates, use `merge(cast(hll AS HLL))`.
|
||||
The [Firefox ER Reporting Query](https://sql.telemetry.mozilla.org/queries/81/source#129)
|
||||
The [Firefox ER Reporting Query (`STMO#81`)](https://sql.telemetry.mozilla.org/queries/81/source#129)
|
||||
is a good example to review.
|
||||
Finally, Roberto has a relevant write-up
|
||||
[here](https://ravitillo.wordpress.com/2016/04/12/measuring-product-engagment-at-scale/).
|
||||
|
|
@ -31,8 +31,7 @@ Finally, Roberto has a relevant write-up
|
|||
#### Accessing the Data
|
||||
|
||||
The data is available in STMO.
|
||||
Take a look at this
|
||||
[example query](https://sql.telemetry.mozilla.org/queries/81/source#129).
|
||||
Take a look at [`STMO#81`](https://sql.telemetry.mozilla.org/queries/81/source#129).
|
||||
|
||||
#### Further Reading
|
||||
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ s3://telemetry-parquet/crash_summary/v1/
|
|||
```
|
||||
|
||||
`crash_summary` is accessible through STMO.
|
||||
Here's an [example query](https://sql.telemetry.mozilla.org/queries/4793/source).
|
||||
Here's an [example query (`STMO#4793`)](https://sql.telemetry.mozilla.org/queries/4793/source).
|
||||
|
||||
#### Further Reading
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@
|
|||
## Example Queries
|
||||
|
||||
Getting a large number of different crash measures across many platforms and channels
|
||||
([view on STMO](https://sql.telemetry.mozilla.org/queries/4769/source)):
|
||||
([`STMO#4769`](https://sql.telemetry.mozilla.org/queries/4769/source)):
|
||||
|
||||
```sql
|
||||
SELECT window_start,
|
||||
|
|
@ -39,7 +39,7 @@ GROUP BY window_start, channel, build_id, version, os_name
|
|||
```
|
||||
|
||||
Get the number of `main_crashes` on Windows over a small interval
|
||||
([view on STMO](https://sql.telemetry.mozilla.org/queries/51677)):
|
||||
([`STMO#51677`](https://sql.telemetry.mozilla.org/queries/51677)):
|
||||
|
||||
```sql
|
||||
SELECT window_start as time, sum(main_crashes) AS main_crashes
|
||||
|
|
|
|||
|
|
@ -34,8 +34,8 @@ FROM
|
|||
|
||||
Example queries:
|
||||
|
||||
- [Join `heavy_users` with `main_summary` to get distribution of `max_concurrent_tab_count` for heavy vs. non-heavy users](https://sql.telemetry.mozilla.org/queries/47041/source#127382)
|
||||
- [Join `heavy_users` with `longitudinal` to get crash rates for heavy vs. non-heavy users](https://sql.telemetry.mozilla.org/queries/47044/source#127385)
|
||||
- [Join `heavy_users` with `main_summary` to get distribution of `max_concurrent_tab_count` for heavy vs. non-heavy users (`STMO#47041`)](https://sql.telemetry.mozilla.org/queries/47041/source#127382)
|
||||
- [Join `heavy_users` with `longitudinal` to get crash rates for heavy vs. non-heavy users (`STMO#47044`)](https://sql.telemetry.mozilla.org/queries/47044/source#127385)
|
||||
|
||||
## Schema
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ Each column represents a field from the main ping.
|
|||
Most fields contain **arrays of values**, with one value for each ping associated with a `client_id`.
|
||||
Using arrays give you access to the raw data from each ping,
|
||||
but can be difficult to work with from SQL.
|
||||
Here's a [query showing some sample data](https://sql.telemetry.mozilla.org/queries/4188#table)
|
||||
Here's a [query showing some sample data (`STMO#4188`)](https://sql.telemetry.mozilla.org/queries/4188#table)
|
||||
to help illustrate.
|
||||
|
||||
#### Background and Caveats
|
||||
|
|
@ -31,7 +31,7 @@ Please note that this dataset only contains release (or opt-out) histograms and
|
|||
|
||||
The `longitudinal` is available in STMO,
|
||||
though it can be difficult to work with the array values in SQL.
|
||||
Take a look at this [example query](https://sql.telemetry.mozilla.org/queries/4189/source).
|
||||
Take a look at [`STMO#4189`](https://sql.telemetry.mozilla.org/queries/4189/source).
|
||||
|
||||
The data is stored as a parquet table in S3 at the following address.
|
||||
|
||||
|
|
|
|||
|
|
@ -11,4 +11,4 @@ This dataset also has detailed search aggregates by each add-on, broken out by o
|
|||
The `addons_daily` table is accessible through STMO using the
|
||||
`Telemetry (BigQuery)` data source.
|
||||
|
||||
Here's an [example query](https://sql.telemetry.mozilla.org/queries/71007/source).
|
||||
See [`STMO#71007`](https://sql.telemetry.mozilla.org/queries/71007/source) for an example.
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ GROUP BY 1,
|
|||
2
|
||||
```
|
||||
|
||||
[STMO Source](https://sql.telemetry.mozilla.org/queries/53884/source)
|
||||
[`STMO#53884`](https://sql.telemetry.mozilla.org/queries/53884/source)
|
||||
|
||||
### Scheduling
|
||||
|
||||
|
|
|
|||
|
|
@ -98,4 +98,4 @@ Data can also be accessed through the public HTTP endpoint: [https://public-data
|
|||
## Code Reference
|
||||
|
||||
You can find the query that generates the SSL dataset
|
||||
[here](https://sql.telemetry.mozilla.org/queries/49323/source#table).
|
||||
[`STMO#49323`](https://sql.telemetry.mozilla.org/queries/49323/source#table).
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ specific delivery characteristics:
|
|||
|
||||
| Reason | Sent when | Notes |
|
||||
| ------------------ | ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| shutdown | Firefox session ends cleanly | Accounts for about [80%][main_reasons] of all "main" pings. Sent by Pingsender immediately after Firefox shuts down, subject to conditions: Firefox 55+, if the OS isn't also shutting down, and if this isn't the client's first session. If Pingsender fails or isn't used, the ping is sent by Firefox at the beginning of the next Firefox session. |
|
||||
| shutdown | Firefox session ends cleanly | Accounts for about 80% of all "main" pings ([`STMO#3434`][main_reasons]). Sent by Pingsender immediately after Firefox shuts down, subject to conditions: Firefox 55+, if the OS isn't also shutting down, and if this isn't the client's first session. If Pingsender fails or isn't used, the ping is sent by Firefox at the beginning of the next Firefox session. |
|
||||
| daily | It has been more than 24 hours since the last "main" ping, and it is around local midnight | In long-lived Firefox sessions we might go days without receiving a "shutdown" ping. Thus the "daily" ping is sent to ensure we occasionally hear from long-lived sessions. |
|
||||
| environment-change | Telemetry Environment changes | Is sent immediately when triggered by Firefox (Installing or removing an addon or changing a monitored user preference are common ways for the Telemetry Environment to change) |
|
||||
| aborted-session | Firefox session doesn't end cleanly | Sent by Firefox at the beginning of the next Firefox session. |
|
||||
|
|
|
|||
|
|
@ -133,7 +133,7 @@ These codes also occasionally change so there will be gaps in the data.
|
|||
|
||||
Additionally, changes to search engine URL formats can cause problems with our data collection.
|
||||
See
|
||||
[this query](https://sql.telemetry.mozilla.org/queries/47631/source#128887)
|
||||
[`STMO#128887`](https://sql.telemetry.mozilla.org/queries/47631/source#128887)
|
||||
for a notable example.
|
||||
|
||||
## Limited historical data
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
|
||||
# Example Queries
|
||||
|
||||
_Percent of users we predict will click an ad in the **next** 365 days by Engine._ ([source](https://sql.telemetry.mozilla.org/queries/74878/source))
|
||||
_Percent of users we predict will click an ad in the **next** 365 days by Engine._ ([`STMO#74878`](https://sql.telemetry.mozilla.org/queries/74878/source))
|
||||
|
||||
```sql
|
||||
SELECT
|
||||
|
|
@ -23,7 +23,7 @@ GROUP BY
|
|||
1
|
||||
```
|
||||
|
||||
_LTV Value of Users Over Lifetime (by `days_since_created_profile`) of Users Active in Past 7 Days_ ([source](https://sql.telemetry.mozilla.org/queries/74867/source#187036))
|
||||
_LTV Value of Users Over Lifetime (by `days_since_created_profile`) of Users Active in Past 7 Days_ ([`STMO#187036`](https://sql.telemetry.mozilla.org/queries/74867/source#187036))
|
||||
|
||||
```sql
|
||||
SELECT
|
||||
|
|
@ -105,7 +105,7 @@ root
|
|||
|
||||
# Model Performance
|
||||
|
||||
There is additionally a dataset, `ltv_daily_model_perf`, that tracks the LTV model's prediction performance each day it is re-trained. For a given day, one could check the performance with the following [query](https://sql.telemetry.mozilla.org/queries/75244/source#187873):
|
||||
There is additionally a dataset, `ltv_daily_model_perf`, that tracks the LTV model's prediction performance each day it is re-trained. For a given day, one could check the performance with the following [query (`STMO#187873`)](https://sql.telemetry.mozilla.org/queries/75244/source#187873):
|
||||
|
||||
```sql
|
||||
SELECT
|
||||
|
|
|
|||
|
|
@ -42,4 +42,4 @@ For more details, see the [search data documentation].
|
|||
|
||||
|
||||
## Gotcha
|
||||
Although `search_aggregates` table is created on top of `search_clients_engines_sources_daily`, you may expect the total search metrics reported to match exactly. It's actually not the case. In case you notice the total number reported in `search_aggregates` higher than `search_clients_engines_sources_daily`, it's most likely due to [Shredder](https://mana.mozilla.org/wiki/display/DATA/Shredder). `search_aggregates` table is aggregated beyond the client level, so shredder doesn’t have to touch it. But `search_clients_engines_sources_daily` contains `client_id` and is subject to shredder. It's expected to lose up to 1% of rows every month as Firefox responds to clients' deletion requests, which would reduce count in `search_clients_engines_soruces` but not in `search_aggregates`. An example query to show such a difference can be found [here](https://sql.telemetry.mozilla.org/queries/84302/source).
|
||||
Although `search_aggregates` table is created on top of `search_clients_engines_sources_daily`, you may expect the total search metrics reported to match exactly. It's actually not the case. In case you notice the total number reported in `search_aggregates` higher than `search_clients_engines_sources_daily`, it's most likely due to [Shredder](https://mana.mozilla.org/wiki/display/DATA/Shredder). `search_aggregates` table is aggregated beyond the client level, so shredder doesn’t have to touch it. But `search_clients_engines_sources_daily` contains `client_id` and is subject to shredder. It's expected to lose up to 1% of rows every month as Firefox responds to clients' deletion requests, which would reduce count in `search_clients_engines_soruces` but not in `search_aggregates`. An example query to show such a difference can be found in [`STMO#84302`](https://sql.telemetry.mozilla.org/queries/84302/source).
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ GROUP BY submission_date
|
|||
ORDER BY submission_date
|
||||
```
|
||||
|
||||
[link to query on STMO](https://sql.telemetry.mozilla.org/queries/51140/source)
|
||||
[`STMO#51140`](https://sql.telemetry.mozilla.org/queries/51140/source)
|
||||
|
||||
## Scheduling
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@
|
|||
|
||||
## Example Queries
|
||||
|
||||
[This query](https://sql.telemetry.mozilla.org/queries/51141/source)
|
||||
[`STMO#51141`](https://sql.telemetry.mozilla.org/queries/51141/source)
|
||||
calculates searches per `normalized_channel` for US clients on an arbitrary day.
|
||||
If you have trouble viewing this query,
|
||||
it's likely you don't have the proper permissions.
|
||||
|
|
|
|||
|
|
@ -10,12 +10,12 @@
|
|||
|
||||
## Example Queries
|
||||
|
||||
[This retention query](https://sql.telemetry.mozilla.org/queries/70349/source#177176)
|
||||
[`STMO#70349`](https://sql.telemetry.mozilla.org/queries/70349/source#177176)
|
||||
gives the WoW retention of users in different segments. Similar to GUD, a user is
|
||||
considered retained if they do they same activity the next week. Note here the
|
||||
outage from Armagaddon, and the outage for ad click telemetry in October.
|
||||
|
||||
[This query](https://sql.telemetry.mozilla.org/queries/70348/source#177160)
|
||||
[`STMO#70348`](https://sql.telemetry.mozilla.org/queries/70348/source#177160)
|
||||
shows the amount of different search activity taken by clients. We can use it
|
||||
to determine the % of clients who partake in each activity, regardless of their
|
||||
baseline amount of activity.
|
||||
|
|
|
|||
|
|
@ -35,4 +35,4 @@ The `normalized_os_version` table can be used to map the sent version to the "di
|
|||
of the OS.
|
||||
|
||||
The table uses a regular expression to look up the OS version so `REGEXP_CONTAINS` should be used.
|
||||
An example query can be found here: <https://sql.telemetry.mozilla.org/queries/67040/source>
|
||||
An example query can be found in [`STMO#67040`](https://sql.telemetry.mozilla.org/queries/67040/source).
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ GROUP BY
|
|||
submission_date
|
||||
```
|
||||
|
||||
You can run this query on [STMO](https://sql.telemetry.mozilla.org/queries/72012/source).
|
||||
You can run this query on [`STMO#72012`](https://sql.telemetry.mozilla.org/queries/72012/source).
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -97,7 +97,7 @@ GROUP BY 1,2
|
|||
ORDER BY 1
|
||||
```
|
||||
|
||||
[link](https://sql.telemetry.mozilla.org/queries/72054/source)
|
||||
[`STMO#72054`](https://sql.telemetry.mozilla.org/queries/72054/source)
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче