@@ -2,7 +2,7 @@
 
 Metric Hub is a [repository](https://github.com/mozilla/metric-hub) that contains metric, data source and segment definitions that have been
 reviewed and can be seen as the source of truth.
-Definitions that are part of Metric Hub can be referenced in configurations of other tooling as well, such as [Jetstream](https://experimenter.info/data-analysis/jetstream/overview) and [OpMon](https://docs.telemetry.mozilla.org/cookbooks/operational_monitoring.html?highlight=opmon#operational-monitoring-opmon).
+Definitions that are part of Metric Hub can be referenced in configurations of other tooling as well, such as [Jetstream](https://experimenter.info/data-analysis/jetstream/overview), [OpMon](https://docs.telemetry.mozilla.org/cookbooks/operational_monitoring.html?highlight=opmon#operational-monitoring-opmon), [bigquery-etl](https://github.com/mozilla/bigquery-etl), Python scripts and [Looker](https://mozilla.cloud.looker.com) explores.
 
 Metric Hub is a "thin" metric layer that lies between the Data Warehouse and consumers, such as analysis tools.
 The Data Warehouse contains the datasets and tables referenced in the metric definitions. Analysis tools can reference metrics that are defined in metric-hub.
 
@@ -131,8 +131,8 @@ and the [schema generator].
 The result are tables that contains SQL-friendly field names for all known
 measures, as implemented in the [probe scraper].
 
-A Kubernetes `Live Sink` job (part of the [`ingestion-sink`][ingestion-sink]
-service) reads from the Decoded topic and writes out to
+A Kubernetes `Live Sink` job (a deployment of the [`ingestion-sink`][ingestion-sink]
+Java application, configured for this role) reads from the Decoded topic and writes out to
 **[live ping tables][table layout]**.
 These tables are updated frequently, and typically reflect data within a few
 minutes of it being ingested. They are intended for low-latency access to
 
@@ -11,7 +11,8 @@ The original implementation of the HTTP Edge Server was tracked in
 HTTP submissions come in from the wild, hit a load balancer,
 then the HTTP Edge Server described in this document.
 Data is accepted via a POST/PUT request from clients,
-and forwarded to the [Data Pipeline](gcp_data_pipeline.md), where
+wrapped in a PubSub message, and forwarded to Google Cloud PubSub for the
+[Data Pipeline](gcp_data_pipeline.md), where
 any further processing, analysis, and storage will be handled.
 
 Submission payloads are expected to be optionally-gzipped JSON
 
@@ -2,6 +2,8 @@
 
 The following cookbook describes how to set up automated build and deployment for containers with CircleCI, a useful pattern for scheduling custom jobs in Google Kubernetes Engine.
 
+> **Note:** Google Container Registry (GCR) has been shut down, so this cookbook is outdated. Google Artifact Registry (GAR) is now the standard, required path for MozCloud services deploying containers via ArgoCD; see [How to Publish Container Images to GAR](https://mozilla-hub.atlassian.net/wiki/spaces/SRE/pages/997163545/How+to+Publish+Container+Images+to+GAR).
+
 Note that this method intended for rapid prototyping rather than for production workloads.
 If you need to transition a prototype to a production deployment,
 [file a Data Platform and Tools > Operations bug](https://bugzilla.mozilla.org/enter_bug.cgi?product=Data+Platform+and+Tools&component=Operations)
 
@@ -22,7 +22,8 @@ labels:
   schedule: daily # scheduled in Airflow to run daily
   public_json: true
   public_bigquery: true
-  review_bug: 1414839 # Bugzilla bug ID of data review
+  review_bugs: # Bugzilla bug IDs of data review
+    - 1414839
   incremental_export: false # non-incremental JSON export writes all data to a single location
 ```
 
@@ -39,7 +40,7 @@ The following options define how data is published:
 - `incremental`: indicates how data gets updated based on the query and Airflow configuration
   - `true`: data gets incrementally updated
   - `false`: the entire table data gets updated
-- `review_bug`: Bugzilla bug number to the data review
+- `review_bugs`: list of Bugzilla bug numbers of the data review
 
 Data will get published when the query is executed in Airflow. Metadata of available public
 data on Cloud Storage is updated daily through a separate Airflow task.
 
@@ -6,7 +6,7 @@ GLAM data is also meant to be explored by itself: GLAM aggregation tables are us
 
 ## GLAM final tables (Aggregates dataset)
 
-The following datasets are split in three categories: Firefox Desktop Glean, Firefox Desktop Legacy and Firefox for Android. The tables contain the final aggregated data that powers GLAM.
+The following datasets are split in three categories: Firefox Desktop Glean, Firefox Desktop Legacy and Firefox for Android. The tables contain the final aggregated data that powers GLAM. The `moz-fx-data-shared-prod.glam_etl` tables listed below are views of the authoritative tables in the `moz-fx-glam-prod.glam_etl` dataset.
 
 Each link below points to the dataset's page on [Mozilla's Data Catalog](https://mozilla.acryl.io/) where you can find the dataset's full documentation.
 
 
@@ -20,6 +20,6 @@ Note: gotchas with historical Sponsored Tiles revenue data are outlined [here](h
 | All Mozillians               | `telemetry.newtab`                                              | Firefox Desktop > `Newtab`                           | Expanded `newtab` **desktop** dataset. Requires unnesting events.                                                                                                   |
 | All Mozillians               | `telemetry.newtab_interactions`                                 | Firefox Desktop > New Tab Interactions               | In-development dataset for basic analyses. Available metrics are limited to **desktop** clicks and impressions.                                                     |
 | Contextual Services          | `contextual_services.event_aggregates`                          | Contextual Services > Event Aggregates               | Dataset with Sponsored Tiles and Suggest analyses by advertiser. No longer maintained. Instead use the derived `event_aggregates_[product]` datasets.               |
-| Contextual Services          | `contextual_services.event_aggregates_spons_tiles`              | Contextual Services > Event Aggregates `Spons` Tiles | Workhorse dataset for Sponsored Tiles analyses by advertiser.                                                                                                       |
+| Contextual Services          | `contextual_services.event_aggregates_spons_tiles`              | Contextual Services > Event Aggregates `Spons` Tiles | Being deprecated; superseded by `Newtab` and ad metrics datasets. Dataset for Sponsored Tiles analyses by advertiser.                                               |
 | Contextual Services          | `contextual_services_derived.adm_forecasting`                   | Contextual Services > `AdM` Forecasting              | Dataset with required components for Sponsored Tiles and Suggest revenue forecasts.                                                                                 |
 | Contextual Services, Revenue | `contextual_services.event_aggregates` x `revenue.revenue_data` | Revenue > `AdM` Revenue with Telemetry               | Revenue information combined with usage metrics. This dataset is useful for `CPC` analyses.                                                                         |
@@ -65,6 +65,10 @@ for the ping (default to 1000 per process, governed by a
 
 It was introduced in Firefox 62.
 
+Note that this describes the legacy "event" ping. Glean's "events" ping, which newer
+applications use, is instead sent when the application goes to background or a
+certain number of events is reached.
+
 ### "update" ping
 
 **Obsolete since Firefox 157**
@@ -112,7 +116,8 @@ It was introduced in Firefox 72, replacing the ["optout" ping][optout_ping]
 ### "coverage" ping
 
 The [coverage ping][coverage_ping] ([announcement](https://blog.mozilla.org/data/2018/08/20/effectively-measuring-search-in-firefox/))
-is a periodic census intended to estimate telemetry opt-out rates.
+was a periodic census intended to estimate telemetry opt-out rates.
+It is no longer sent; the ping was removed from Firefox in [bug 1773060](https://bugzilla.mozilla.org/show_bug.cgi?id=1773060).
 
 We estimate that [93% of release channel
 profiles](https://docs.google.com/document/d/1EnQoq9o1sLXTgsbbG8mPnUiWIOmKSINGJOAKyYUm_YA/edit#)
@@ -191,4 +196,4 @@ To augment our data collection, see [Collecting New Data][addprobe] and the
 [addprobe]: https://firefox-source-docs.mozilla.org/toolkit/components/telemetry/start/adding-a-new-probe.html
 [datacollection]: https://wiki.mozilla.org/Firefox/Data_Collection
 [pingsender]: https://firefox-source-docs.mozilla.org/toolkit/components/telemetry/telemetry/internals/pingsender.html
-[coverage_ping]: https://firefox-source-docs.mozilla.org/toolkit/components/telemetry/telemetry/data/coverage-ping.html
+[coverage_ping]: https://github.com/mozilla-firefox/firefox/blob/4c877370d5cb831951ab634bacaa065598ec8d70/toolkit/components/telemetry/docs/data/coverage-ping.md
@@ -38,9 +38,9 @@ Note that while STMO is not yet considered deprecated, Looker is the preferred s
 
 ## Deprecated tools
 
-These tools are still available, but are generally not recommended.
+These tools have been retired and are no longer available.
 
 ### Telemetry Measurement Dashboard
 
-The [Telemetry Measurement Dashboard](https://telemetry.mozilla.org/new-pipeline/dist.html) (TMO) site is the 'venerable standby' of Firefox telemetry analysis tools.
-It is the predecessor to GLAM (see above) and is still lightly maintained until we are sure that GLAM covers all of its use cases.
+The [Telemetry Measurement Dashboard](https://telemetry.mozilla.org/new-pipeline/dist.html) (TMO) site was the 'venerable standby' of Firefox telemetry analysis tools.
+It is the predecessor to GLAM (see above). As of December 5, 2024, the data system underpinning it was turned off entirely; use GLAM instead.
@@ -14,10 +14,10 @@ This section contains definitions and information about standard metrics used at
 
 Daily Active Users or DAU counts the number of unique profiles active in the product on each day. This is intended to approximate the number of people using the product each day.
 
-The most accurate and up-to-date metric information can be found on the
+Supporting metric information can be found on the
 [Metrics Inventory](https://mozilla-hub.atlassian.net/wiki/spaces/DATA/pages/620494911/Metrics+Inventory) page in Confluence (Mozilla LDAP required).
 
-The official source code definitions for the metrics can be found in
+The canonical, official source code definitions for the metrics can be found in
 [metric-hub](https://github.com/mozilla/metric-hub/tree/main/definitions) on GitHub.
 
 ### Details
@@ -42,7 +42,7 @@ If the number of users stays constant, but the average number of active profiles
 
 This measure attempts to tell us whether, after creating a profile, the user returned at any point in the next 6 days. This is meant to measure whether a product is successful in engaging users early on: at present, many users churn after the first run and we want to measure whether efforts to make them stick around are succeeding.
 
-This metric is used for all mobile applications, excluding Fenix and Firefox Preview, and is a top-level OKR inside Mozilla for 2020. It can apply both on the level of a specific product (e.g. Firefox iOS, Lockwise for Android) as well as an aggregate measure across all mobile products and devices. This metric is _not_ used for Firefox desktop.
+This metric is used for all mobile applications, excluding Fenix and Firefox Preview, and was a top-level OKR inside Mozilla in 2020. It can apply both on the level of a specific product (e.g. Firefox iOS, Lockwise for Android) as well as an aggregate measure across all mobile products and devices. This metric is _not_ used for Firefox desktop.
 
 ### Details