etienneb@chromium.org sdefresne@chromium.org 1456716

Logged whenever history database initialization fails. The frequency of logging will tell you the total failure rate. True indicate that we think the database is non-recoverable and it will be deleted. It should be re-created the next time Chrome is started. False indicates we think the error is temporary (like out of disk space or file locked). Chrome will run with no history database and nothing will be done to try to fix the error. See History.InitializationFailureStep for which particular step of history initialization failed. Warning: this histogram was expired from 2024-02-11 to 2025-08-21; data may be missing.

ydago@chromium.org dullweber@chromium.org 1456716

The time that passed while performing a browsing data deletion using the ClearBrowsingDataOnExitList policy. The deletion will be for all time. Warning: this histogram was expired from 2025-07-01 to 2026-04-15; data may be missing.

ydago@chromium.org dullweber@chromium.org 1456716

The time that passed while performing a scheduled data deletion using the BrowsingDataSettings policy. The deletion will be for a specific hourly time range, the data types being deleted are {DeletionType}. Warning: this histogram was expired from 2025-07-01 to 2026-04-15; data may be missing.

zalmashni@google.com rainhard@chromium.org 1456716

Recorded whenever history data is queried for display on chrome://history (i.e. when the page is opened, when the user scrolls to the bottom of the available list, and when the user changes the search terms). Records the number of duplicate visits removed from each query on the client side. If kBrowsingHistorySimilarVisitsGrouping experimentis enabled, duplicate visits are those that have the same host and title whithin the same day. If the experiment is disabled, duplicate visits are those that have the same URL whithin the same day.

treib@chromium.org src/components/sync/OWNERS 1456716

dullweber@chromium.org msramek@chromium.org 1456716

Records the duration of a ChromeBrowsingDataRemoverDelegate task for {Task} deletion.

dullweber@chromium.org msramek@chromium.org 1456716

The time that passed while performing a browsing data deletion with an origin filter. The deletion might be for all time or specific time range.

dullweber@chromium.org msramek@chromium.org 1456716

The time that passed while performing a full browsing data deletion.

dullweber@chromium.org msramek@chromium.org 1456716

The time that passed while performing a browsing data deletion for a set of origins.

dullweber@chromium.org msramek@chromium.org 1456716

Record tasks from BrowsingDataRemoverImpl that took more than 180s to finish.

dullweber@chromium.org msramek@chromium.org 1456716

Record tasks from ChromeBrowsingDataRemoverDelegate that took more than 180s to finish.

dullweber@chromium.org msramek@chromium.org 1456716

Record tasks from StoragePartition that took more than 180s to finish.

dullweber@chromium.org msramek@chromium.org 1456716

Records the duration of a BrowsingDataRemoverImpl task for {Task} deletion.

dullweber@chromium.org msramek@chromium.org 1456716

The time that passed while performing a browsing data deletion for a restricted amount of time (e.g. "Last hour") without an origin filter.

ayui@chromium.org chrome-owp-storage@google.com 1456716

Recorded when the user presses the 'clear' button when presented with the list of important sites they might want to exclude from clearing browsing data. We record the number of sites the user deselected, or protected, from clearing. The default has all sites selected. This histogram expired between M95 and M115, and may have incomplete data within that range.

ayui@chromium.org chrome-owp-storage@google.com 1456716

Recorded when the user presses the 'clear' button when presented with the list of important sites they might want to exclude from clearing browsing data. We record the percent of sites the user deselected, or protected, from clearing. The default has all sites selected, which is 0%. Note: To reduce the number of empty buckets, the percent is divided by 5. This histogram expired between M95 and M115, and may have incomplete data within that range.

ayui@chromium.org chrome-owp-storage@google.com 1456716

Recorded when the user presses the 'clear' button in the clear browsing dialog. We record 'true' if the important sites dialog is shown. This histogram expired between M95 and M115, and may have incomplete data within that range.

ayui@chromium.org chrome-owp-storage@google.com 1456716

Recorded when we successfully fetched important sites in the clear browsing data screen. This is the number of sites that we think are important to the user. This histogram expired between M95 and M115, and may have incomplete data within that range.

dullweber@chromium.org msramek@chromium.org 1456716

The number of tasks that are in the task queue when the BrowsingDataRemover is destroyed.

msramek@chromium.org 1456716

Recorded when the user deletes their browsing data. Shows whether cookies and/or cache were among the selected data types.

msramek@chromium.org 1456716

Recorded when the user deletes their browsing data manually from the ClearBrowsingData dialog. Shows whether cookies and/or cache were among the selected data types.

mcrouse@chromium.org chrome-journeys@google.com 1457319

Logged when the user closes the chrome://history/journeys page (e.g. closed tab, navigated in the same tab, or closed browser). Logs whether the user made a query on their history from the journeys page.

mcrouse@chromium.org chrome-journeys@google.com 1457319

Logged when the user closes the chrome://history/journeys page (e.g. closed tab, navigated in the same tab, or closed browser). Logs the number of {Event} over the period of a single visit to the Journeys UI.

mcrouse@chromium.org chrome-journeys@google.com 1457319

Logged when the user closes the chrome://history/journeys page (e.g., closed tab, navigated in the same tab, or closed browser). Logs whether the users interaction with the UI was deemed successful or not. Success is defined as a link was clicked, a cluster was opened, or a deletion event occurred.

mcrouse@chromium.org chrome-journeys@google.com 1457319

Logged when the user closes the chrome://history/journeys page (e.g. closed tab, navigated in the same tab, or closed browser). Logs the state that started the use of the journeys page (e.g., a direct navigation to journeys page).

manukh@chromium.org chrome-journeys@google.com 1457319

Logged when the user closed the chrome://history/journeys page (e.g. closed tab, navigated in the same tab, or closed browser). Logs the # of links opened from the journeys page.

mcrouse@chromium.org chrome-journeys@google.com 1457319

Logged when the user closes the chrome://history/journeys page (e.g. closed tab, navigated in the same tab, or closed browser). Logs the number of queries the user made while on the journeys page, only logged if at least one query was made.

sophiechang@chromium.org chrome-journeys@google.com 1457319

Logs whether the canonical search term for the cluster was overridden when one was already generated for it. Logged for all but the first search visit in each cluster processed that has multiple search visits when the Journeys UI is shown. A cluster can have multiple search visits and we expect that search visits in the same cluster all have the same search term (or no search term at all). However, this does not seem to be true as we have seen crashes in the wild that make this assumption. This metric tracks how often a search visit had non-empty search terms that differed from the search terms of the previous search visit with non-empty search terms in the same cluster.

sophiechang@chromium.org chrome-journeys@google.com 1457319

Logs the time taken to cluster visits once the visits have been finalized with all the necessary information for clustering, which is performed on a background worker. This does not include any thread hop or queuing delay. Logged when clusters have been calculated based on any request to cluster visits, which could be triggered from several things, including loading the journeys UI, putting a query in the journeys page, etc.

sophiechang@chromium.org chrome-journeys@google.com 1457319

Logs the time taken to determine how clusters should be displayed once the initial context clusters have been formed, which is performed on a background worker. This does not include any thread hop or queuing delay. Logged when clusters have been calculated based on any request to cluster visits, which could be triggered from several things, including loading the journeys UI, putting a query in the journeys page, etc. This is a segment within `History.Clusters.Backend.ComputeClusters.ThreadTime`.

sophiechang@chromium.org chrome-journeys@google.com 1457319

Logs the time taken to run the steps during a clustering pass that are required for determinining the triggerability for a cluster, which is performed on a background worker. This does not include any thread hop or queuing delay. Logged when clusters have been calculated based on any request to cluster visits, which could be triggered from several things, including loading the journeys UI, putting a query in the journeys page, etc. This is a segment within `History.Clusters.Backend.ComputeClusters.ThreadTime`.

sophiechang@chromium.org chrome-journeys@google.com 1457319

Logs the time taken to run the initial context clustering pass, which is performed on a background worker. This does not include any thread hop or queuing delay. Logged when clusters have been calculated based on any request to cluster visits, which could be triggered from several things, including loading the journeys UI, putting a query in the journeys page, etc. This is a segment within `History.Clusters.Backend.ComputeClusters.ThreadTime`.

sophiechang@chromium.org chrome-journeys@google.com 1457319

Logs the reason why a cluster was filtered out of the return set for each cluster provided to the clustering backend when invoked by {Source}. Note that a single cluster can log multiple values in this metric if it is ineligible for multiple reasons.

sophiechang@chromium.org chrome-journeys@google.com 1457319

Logs the number of clusters {Segment} each time {Source} invokes the clustering backend with a functional filtering configuration. Note that the max count is limited to the size of the initial batch sent to the clustering backend.

manukh@chromium.org chrome-journeys@google.com 1457319

Logs the number of keywords stored in the primary cache. Each keyword may actually be multiple words. Logged each time the primary cache is refreshed, i.e. on omnibox key stroke limited to at most once every 2 hours, though clearing history items will reset the cache timer.

mcrouse@chromium.org chrome-journeys@google.com 1457319

Logs the total number of clusters returned for requested visits. Logged when clusters have been calculated based on any request to cluster visits, which could be triggered from several things, including loading the journeys UI, putting a query in the journeys page, etc..

sophiechang@chromium.org chrome-journeys@google.com 1457319

Logs the number of visits that are "below the fold" in each cluster after hidden and done visits have been culled. Logged for each cluster that is shown to the user in the Journeys WebUI.

sophiechang@chromium.org chrome-journeys@google.com 1457319

Logs the percentage of visits that are "below the fold" in each cluster after hidden and done visits have been culled. Logged for each cluster that is shown to the user in the Journeys WebUI.

mcrouse@chromium.org chrome-journeys@google.com 1457319

Logs the total number of visits requested to be clustered by the backend. Logged when any request to cluster visits is made, which could be triggered from several things, including loading the journeys UI, putting a query in the journeys page, etc..

sophiechang@chromium.org chrome-journeys@google.com 1457319

Logs the time taken to process a batch of visits (joining existing History visit metadata with any additional Search, engagement, content metadata) and is performed on the UI thread. This does not include any thread hop or queuing delay. Can be logged multiple times when a request to cluster visits is made, which could be triggered from several things, including loading the journeys UI, putting a query in the journeys page, etc... depending on how many visits were sent to the backend to cluster.

sophiechang@chromium.org chrome-journeys@google.com 1457319

This histogram records the time taken (excluding queuing delay) to retrieve visits from the History database, which occurs on the History DB thread. Logged once per request to cluster visits is made, which could be triggered from several things, including loading the journeys UI, putting a query in the journeys page, etc.

manukh@chromium.org chrome-journeys@google.com 1457319

Near startup and every 1 hour afterwards, unclustered visits are clustered, and the clusters are persisted in the history DB. As needed, both fresh and persisted clusters are fetched. Clusters are fetched for: a) displaying on the Journeys WebUI and b) generating keyword caches to match with omnibox inputs and show journey chips or suggestions in the omnibox. Each update consists of multiple batches of 1-3 days. The number of batches depends on how long ago the last update occurred, which could have been 0-90 days ago. Recorded for every batch of visits clustered; can be recorded more than once every hour. {Segment}

manukh@chromium.org chrome-journeys@google.com 1457319

Near startup and every 1 hour afterwards, unclustered visits are clustered, and the clusters are persisted in the history DB. As needed, both fresh and persisted clusters are fetched. Clusters are fetched for: a) displaying on the Journeys WebUI and b) generating keyword caches to match with omnibox inputs and show journey chips or suggestions in the omnibox. This histogram records the latency breakdown for updating clusters. Recorded for every batch of visits clustered; can be recorded more than once every hour. This slice records the time between the main thread requesting and {Segment}.

sophiechang@chromium.org chrome-journeys@google.com 1457319

On navigation, context clusters are created, grown, and persisted. On startup and every 1 hour afterwards, these context clusters have their triggability calculated. Context clusters older than 2 hours are not updated are not re-updated after the initial triggability is calculated. However, if there are unclustered visits (due to visits from before the user had context clustering enabled or synced visits without a cluster ID), they will also be context clustered with their triggerability calculated as well. When a user visits the Journeys WebUI, persisted clusters (both those with and without triggerability calculated) are fetched. Clusters are then augmented with appropriate metadata needed for displaying on the Journeys WebUI (e.g. ranking, deduping, labeling). When the keyword cache used to match omnibox inputs and show journey chips or suggestions in the omnibox needs updating, context clusters (both those with and without triggerability calculated) are fetched. This histogram records whether there was at least one cluster's triggerability was updated {Segment}. Recorded for every batch of clusters to be updated; can be recorded more than once every hour (Finch-configurable).

sophiechang@chromium.org chrome-journeys@google.com 1457319

On navigation, context clusters are created, grown, and persisted. On startup and every 1 hour afterwards, these context clusters have their triggability calculated. Context clusters older than 2 hours are not updated are not re-updated after the initial triggability is calculated. However, if there are unclustered visits (due to visits from before the user had context clustering enabled or synced visits without a cluster ID), they will also be context clustered with their triggerability calculated as well. When a user visits the Journeys WebUI, persisted clusters (both those with and without triggerability calculated) are fetched. Clusters are then augmented with appropriate metadata needed for displaying on the Journeys WebUI (e.g. ranking, deduping, labeling). When the keyword cache used to match omnibox inputs and show journey chips or suggestions in the omnibox needs updating, context clusters (both those with and without triggerability calculated) are fetched. This histogram records whether there were unclustered visits left to cluster in the first run of this task. When this trends to all false, this additional step can get deleted. Recorded for every batch of clusters to be updated; can be recorded more than once every hour.

manukh@chromium.org chrome-journeys@google.com 1457319

On navigation, context clusters are created, grown, and persisted. On startup and every 1 hour afterwards, these context clusters have their triggability calculated. Context clusters older than 2 hours are not updated are not re-updated after the initial triggability is calculated. However, if there are unclustered visits (due to visits from before the user had context clustering enabled or synced visits without a cluster ID), they will also be context clustered with their triggerability calculated as well. When a user visits the Journeys WebUI, persisted clusters (both those with and without triggerability calculated) are fetched. Clusters are then augmented with appropriate metadata needed for displaying on the Journeys WebUI (e.g. ranking, deduping, labeling). When the keyword cache used to match omnibox inputs and show journey chips or suggestions in the omnibox needs updating, context clusters (both those with and without triggerability calculated) are fetched. This histogram records the latency breakdown for updating cluster triggerability. Recorded for every batch of clusters to be updated; can be recorded more than once every hour. This slice records the time between the main thread requesting and {Segment}.

mcrouse@chromium.org chrome-journeys@google.com 1457319

Logs whether a cluster was filtered for having {ClusterFilterReason}. Logged when finalizing each individual cluster which occurs at the end of every clustering backend request.

sophiechang@chromium.org chrome-journeys@google.com 1457319

When the user visits a page, `ContextClustererHistoryServiceObserver` considers whether to add the visit to a new cluster or an existing cluster. This histogram records the processing breakdown for persisting visits to group them into context clusters. Recorded each time {Segment}. The histograms here summed up with the histograms as part of `History.Clusters.ContextClusterer.VisitProcessingLatency` record the total latency for context clustering.

sophiechang@chromium.org chrome-journeys@google.com 1457319

When we decide a new visit belongs to a new cluster, we asyncly reserve a new cluster ID and add the visit to the cluster. When subsequent visits belong to the same cluster, we asyncly add those visits to the cluster. When the latter occurs before the former completes, i.e. when there are multiple visits done that belong in the same cluster before the cluster ID was reserved, we queue those subsequent visits and only add them when the cluster ID is reserved. This histogram records the number of visits that were waiting to be persisted while waiting for the persisted ID of the containg cluster to be received. Recorded at most once per cluster that is generated via the navigation graph.

sophiechang@chromium.org chrome-journeys@google.com 1457319

When the user visits a page, `ContextClustererHistoryServiceObserver` considers whether to add the visit to a new cluster or an existing cluster. This histogram records the processing breakdown for processing visits to group them into context clusters. Recorded each time {Segment}. The histograms here summed up with the histograms as part of `History.Clusters.ContextClusterer.DbLatency` record the total latency for context clustering.

sophiechang@chromium.org chrome-journeys@google.com 1457319

Records whether a user that is Journeys eligible has Journeys enabled. This is recorded once at the start of the session.

manukh@chromium.org chrome-journeys@google.com 1457319

Records the total amount of time spent populating the keyword cache, measured via the wall clock. Most of this time is not on the main thread. The total time spent populating the keywords cache will be: History.Clusters.KeywordCache.Latency = (number of batches) * (latency of fetching and computing clusters + History.Clusters.KeywordCache.ThreadTime). Historically, the breakdown of fetching and computing latency was recorded in History.Clusters.Backend.GetMostRecentClusters.* histograms.

pnoland@chromium.org chrome-journeys@google.com 1457319

Records the amount of time spent reading all caches from the pref service and deserializing them. Recorded when these caches are read from prefs, which is once at startup. This is not recorded if the pref service is null.

manukh@chromium.org chrome-journeys@google.com 1457319

This measures the amount of main thread time spent populating the keyword cache AFTER we get it from the backend. See History.Clusters.KeywordCache.Latency for the full wall clock time.

pnoland@chromium.org chrome-journeys@google.com 1457319

Records the amount of time spent serializing and writing a keyword cache to the pref service. Recorded every time a cache is written to prefs, which is every time one is updated. This is not recorded if the pref service is null.

olivierli@chromium.org manukh@chromium.org 1457319

This histogram records the total time taken to convert and process visits in all history cluster available. This is recorded once after the conversion, deduplication and sorting of the clusters. This is recorded using the highest precision clock possible. Like most time measurements this will not have the same behavior regarding system sleep on all platforms. See bit.ly/chrome-clocks-and-sleep for more details. Since the measurement is taken after the operation is over it will be missing if the operation never completes. This can happen if the user or the system shuts down chrome because of the unresponsiveness. A decidedly imperfect strategy to evaluate how often this happens is to compare total counts with another histogram that is recorded before the operation starts ("History.Clusters.Backend.GetClusterLatency"). Such analysis has to be conducted with care. Consult with Metrics team if curious.

mahmadi@chromium.org chrome-journeys@google.com 1457319

Recorded every time the user {ClusterAction} in chrome://history/journeys. The value represents the 0-indexed index of the cluster.

mahmadi@chromium.org chrome-journeys@google.com 1457319

Recorded every time the user {RelatedSearchAction} a related search suggestion in a history cluster in chrome://history/journeys. The value represents the 0-indexed index of the related search suggestion in the respective cluster.

mahmadi@chromium.org chrome-journeys@google.com 1457319

Recorded every time the user toggles the visibility of the history clusters Web UI shown at chrome://history/journeys from the history Web UI sidebar. The value represents the visibility of the history clusters Web UI.

mahmadi@chromium.org chrome-journeys@google.com 1457319

Recorded every time the user {VisitAction} a {VisitType} in a history cluster in chrome://history/journeys. The value represents the 0-indexed index of the visit in the respective cluster.

manukh@chromium.org chrome-journeys@google.com 1457319

The time elapsed between subsequent cluster update tasks (HistoryClustersServiceTaskUpdateClusters). Depending on finch params, this occurs either: 1) Never (e.g. if updating and persisting clusters is disabled). 2) OR N time after startup in addition to every M time; where N is typically 5-60 minutes, and M is typically 1-12 hours. 3) OR on keyword refresh request bounded to at most every M time, where M is typically 1-12 hours. Keyword refresh requests occur when the omnibox input looks like a search query and journeys in the omnibox is enabled.

manukh@chromium.org chrome-journeys@google.com 1457319

Records the amount of time the Journeys WebUI is open. This timer is started when the Journeys WebUI is loaded. The Journeys WebUI is loaded when either the user directly goes to the Journeys WebUI, or when the user switches to the Journeys tab from a different tab. The timer is stopped and the elapsed time recorded when either the whole WebUI is closed, or if the user disables the Journeys preference, or if the user switches tabs off the Journeys tab onto a different one. Elapsed times longer than one hour are recorded as one hour.

sophiechang@chromium.org chrome-journeys@google.com 1456716

Size of History DB file. Duplicate of Profile.HistorySize and Sqlite.SizeKB.History. Logged on initialization of the History DB on 1% of starts.

sophiechang@chromium.org chrome-journeys@google.com 1456716

The exact database error encountered when initializing the database, if failed.

jpgravel@chromium.org etienneb@chromium.org 1456716

The version of the database found on disk if it's too old to be migrated to the current version.

jpgravel@chromium.org etienneb@chromium.org 1456716

The version of the database loaded during initialization. This is the version loaded from disk, before the database is migrated to the current version.

mpearson@chromium.org mjzhang@chromium.org chrome-analysis-team@google.com 1456716

Number of unique domains visited by the user within a calendar day in user's local timezone, excluding domains that have only ever had visits with a 4XX/5XX HTTP response code. For each regular profile (not incognito, guest, system, etc.), reported at profile open (which usually happens at startup) for each unreported day (up to 7 days) prior to the current date, and also reported once every 24 hours thereafter for the latest unreported day, while the profile remains open. If no domains are visited in a given day, a count of 0 will be reported for that day. Warning about Android activity types (custom tabs, browser app, etc.): Do not look at this data using an activity type filter; when looking at data from Android, use "Android Chrome (All)". Why? This histogram reflects all usage of the browser. Using a filter such as "Browser App" is not appropriate because it doesn't make sense to ask "how many web sites were visited in Chrome (in any mode) the last week but only tell me if the answer if this current launch was in browser app mode." Warning about delayed data: Chrome may upload logs on a given day without uploading this histogram. This can happen because Chrome uploads logs initially upon startup. This histogram is emitted shortly _after_ startup. In the case of short sessions, it's possible the log with this histogram did not have time to be uploaded. Generally the log will be cached and uploaded the next time the user starts Chrome. We should still get one count per calendar day; it simply may not be on the day the metric was computed. (Exception: on Android before M-91, sometimes these emitted histograms were lost due to lack of robust "background logging".) Note: This histogram attempts to emit every 24 hours that the device is on, but the timer does not increment while the machine is suspended. Prefer the V4 version of this metric which accounts for suspended time.

mpearson@chromium.org mjzhang@chromium.org chrome-analysis-team@google.com 1456716

Number of unique domains visited by the user within a 28 calendar day period in user's local timezone, excluding domains that have only ever had visits with a 4XX/5XX HTTP response code. For each regular profile (not incognito, guest, system, etc.), reported at profile open (which usually happens at startup) for each unreported 28-day period (up to 7 periods) ending on the current day, current day - 1, current day - 2, etc. Also reported once every 24 hours thereafter for the latest unreported period, while the profile remains open. If no domains are visited during a 28-day period, a count of 0 will be reported for that period. Warning about Android activity types (custom tabs, browser app, etc.): Do not look at this data using an activity type filter; when looking at data from Android, use "Android Chrome (All)". Why? This histogram reflects all usage of the browser. Using a filter such as "Browser App" is not appropriate because it doesn't make sense to ask "how many web sites were visited in Chrome (in any mode) the last week but only tell me if the answer if this current launch was in browser app mode." Warning about delayed data: Chrome may upload logs on a given day without uploading this histogram. This can happen because Chrome uploads logs initially upon startup. This histogram is emitted shortly _after_ startup. In the case of short sessions, it's possible the log with this histogram did not have time to be uploaded. Generally the log will be cached and uploaded the next time the user starts Chrome. We should still get one count per calendar day; it simply may not be on the day the metric was computed. (Exception: on Android before M-91, sometimes these emitted histograms were lost due to lack of robust "background logging".) Note: This histogram attempts to emit every 24 hours that the device is on, but the timer does not increment while the machine is suspended. Prefer the V4 version of this metric which accounts for suspended time.

mpearson@chromium.org mjzhang@chromium.org chrome-analysis-team@google.com 1456716

Number of unique domains visited by the user within a 7 calendar day period in user's local timezone, excluding domains that have only ever had visits with a 4XX/5XX HTTP response code. For each regular profile (not incognito, guest, system, etc.), reported at profile open (which usually happens at startup) for each unreported 7-day period (up to 7 periods) ending on the current day, current day - 1, current day - 2, etc. Also reported once every 24 hours thereafter for the latest unreported period, while the profile remains open. If no domains are visited during a 7-day period, a count 0 will be reported for that period. Warning about Android activity types (custom tabs, browser app, etc.): Do not look at this data using an activity type filter; when looking at data from Android, use "Android Chrome (All)". Why? This histogram reflects all usage of the browser. Using a filter such as "Browser App" is not appropriate because it doesn't make sense to ask "how many web sites were visited in Chrome (in any mode) the last week but only tell me if the answer if this current launch was in browser app mode." Warning about delayed data: Chrome may upload logs on a given day without uploading this histogram. This can happen because Chrome uploads logs initially upon startup. This histogram is emitted shortly _after_ startup. In the case of short sessions, it's possible the log with this histogram did not have time to be uploaded. Generally the log will be cached and uploaded the next time the user starts Chrome. We should still get one count per calendar day; it simply may not be on the day the metric was computed. (Exception: on Android before M-91, sometimes these emitted histograms were lost due to lack of robust "background logging".) Note: This histogram attempts to emit every 24 hours that the device is on, but the timer does not increment while the machine is suspended. Prefer the V4 version of this metric which accounts for suspended time.

mpearson@chromium.org mjzhang@chromium.org chrome-analysis-team@google.com 1456716

orinj@chromium.org src/components/history_embeddings/OWNERS

The status returned by the answerer after calling ComputeAnswer. ComputeAnswer is called once for each query as it is entered in a history_embeddings UI (history page, side panel). This is not once per keystroke due to debouncing logic and other constraints on query acceptance (minimum length, number of terms, etc.) but is still frequent enough that cancellation is common and expected.

orinj@chromium.org src/components/history_embeddings/OWNERS

The time the HistoryEmbeddingsService waited to receive a response from the answerer after calling ComputeAnswer. ComputeAnswer is called once for each query as it is entered in a history_embeddings UI (history page, side panel). This is not once per keystroke due to debouncing logic and other constraints on query acceptance (minimum length, number of terms, etc.) but is still frequent enough that cancellation is common and expected.

orinj@chromium.org sophiechang@chromium.org

The time spent on the Storage sequence to read existing passages and embeddings from the database so it can be used as a cache to avoid re-embedding identical passages from the same URL. Logged each time page passages are retrieved. (This metric includes SQL query time only; no waits.)

orinj@chromium.org sophiechang@chromium.org

When the HistoryEmbeddings database is opened, this histogram is logged to indicate whether initialization succeeded.

orinj@chromium.org manukh@chromium.org

Number of database statement iteration rows skipped due to embeddings data load failure. If a row is skipped, only one counter is incremented to reflect the reason; the check order is: passages, embeddings, mismatches. Logged once for each full iteration, which happens when the database is queried; this may include a time range or not, and may exhaust all rows or stop early if a new query is initiated.

orinj@chromium.org manukh@chromium.org

Number of database statement iteration rows skipped due to embeddings count mismatching passages count. If a row is skipped, only one counter is incremented to reflect the reason; the check order is: passages, embeddings, mismatches. Logged once for each full iteration, which happens when the database is queried; this may include a time range or not, and may exhaust all rows or stop early if a new query is initiated.

orinj@chromium.org manukh@chromium.org

Number of database statement iteration rows skipped due to passages data load failure. If a row is skipped, only one counter is incremented to reflect the reason; the check order is: passages, embeddings, mismatches. Logged once for each full iteration, which happens when the database is queried; this may include a time range or not, and may exhaust all rows or stop early if a new query is initiated.

orinj@chromium.org manukh@chromium.org

Number of database statement iteration rows yielded with valid data. Logged once for each full iteration, which happens when the database is queried; this may include a time range or not, and may exhaust all rows or stop early if a new query is initiated.

orinj@chromium.org src/components/history_embeddings/OWNERS

Number of passages that contained only ASCII characters when passages are stored to the database. Logged each time passages are successfully inserted or replaced in the database. This happens for each page visit when the tab is kept open for several seconds after all tabs finish loading. See also the related metrics History.Embeddings.DatabaseStoredNonAsciiPassages and History.Embeddings.DatabaseStoredNonAsciiPassageRatio.

orinj@chromium.org src/components/history_embeddings/OWNERS

Percentage of passages that contain non-ASCII characters when passages are stored to the database. Logged each time passages are successfully inserted or replaced in the database. This happens for each page visit when the tab is kept open for several seconds after all tabs finish loading. See also the related metrics History.Embeddings.DatabaseStoredAsciiPassages and History.Embeddings.DatabaseStoredNonAsciiPassages.

orinj@chromium.org src/components/history_embeddings/OWNERS

Number of passages that contained any non-ASCII characters when passages are stored to the database. Logged each time passages are successfully inserted or replaced in the database. This happens for each page visit when the tab is kept open for several seconds after all tabs finish loading. See also the related metrics History.Embeddings.DatabaseStoredAsciiPassages and History.Embeddings.DatabaseStoredNonAsciiPassageRatio.

sophiechang@chromium.org zekunjiang@google.com

Whether one embeddings generation attempt involves a passage in the cache. Logged each time the embedder attempts to generate one embeddings vector. On a cache hit, no tokenization or model execution will be attempted so the relevant histograms won't be recorded either.

sophiechang@chromium.org zekunjiang@google.com

Periodically samples CPU utilization of the embedder process. A sample is taken every 30 seconds while the embedder service is running. The utilization is in 0-100% range per CPU, which is then summed up and multiplied by 100.

sophiechang@chromium.org zekunjiang@google.com orinj@chromium.org src/components/history_embeddings/OWNERS

History.Embeddings.Embedder.CpuUsage2, sliced by embedder running state. This histogram is recorded only if the embedder is not running at both the beginning and end of the sample period.

sophiechang@chromium.org zekunjiang@google.com orinj@chromium.org src/components/history_embeddings/OWNERS

History.Embeddings.Embedder.CpuUsage2, sliced by embedder running state. This histogram is recorded only if the embedder is running at both the beginning and the end of the sample period.

sophiechang@chromium.org zekunjiang@google.com orinj@chromium.org src/components/history_embeddings/OWNERS

History.Embeddings.Embedder.CpuUsage2, sliced by embedder running state. This histogram is recorded only if the embedder is running at either the beginning or the end of the sample period, but not both.

sophiechang@chromium.org zekunjiang@google.com

Whether an attempt to generate embeddings was successful. Logged each time the embedder attempts to generate embeddings.

sophiechang@chromium.org zekunjiang@google.com

The time it took to load the embeddings model. Logged each time the embeddings model is successfully loaded.

sophiechang@chromium.org zekunjiang@google.com

Whether the attempt to load the embeddings model succeeded. Logged each time loading of the embeddings model was attempted.

sophiechang@chromium.org zekunjiang@google.com

Whether the tokenized input was truncated during embeddings generation. Logged each time an input tokenization succeeds.

wittman@chromium.org orinj@chromium.org src/components/history_embeddings/OWNERS

The time it took to launch the PassageEmbeddingsService. Logged each time the service is successfully launched.

sophiechang@chromium.org zekunjiang@google.com

Whether the model metadata received from optimization guide model provider is valid. Logged each time the embedder receives an model update from optimization guide.

sophiechang@chromium.org zekunjiang@google.com

The number of milliseconds spent to generate embeddings for a passage. Logged each time embeddings generation succeeds for a passage.

sophiechang@chromium.org zekunjiang@google.com

The number of milliseconds spent to generate embeddings for a passage, measured in thread time. Logged each time embeddings generation succeeds for a passage, if ThreadTicks measurement is supported.

sophiechang@chromium.org zekunjiang@google.com

The length of the token array that each passage is encoded into. Logged each time an input tokenization succeeds.

sophiechang@chromium.org zekunjiang@google.com

The number of milliseconds spent to generate one embeddings vector for a user query. Logged each time embeddings generation succeeds for a user query.

sophiechang@chromium.org zekunjiang@google.com

The number of milliseconds spent to generate one embeddings vector for a user query, measured in thread time. Logged each time embeddings generation succeeds for a user query, if ThreadTicks measurement is supported.

sophiechang@chromium.org zekunjiang@google.com

The time it took to load the sentencepiece model. Logged each time the sentencepiece model is successfully loaded.

sophiechang@chromium.org zekunjiang@google.com

Whether the attempt to load the sentencepiece model succeeded. Logged each time loading of the sentencepiece model was attempted.

sophiechang@chromium.org zekunjiang@google.com

The number of milliseconds spent tokenizing an input string. Logged each time the embedder successfully tokenizes an input string.

sophiechang@chromium.org zekunjiang@google.com

Whether an attempt to tokenize an input string to the embedder was successful. Logged each time the embedder attempts to tokenize a string.

orinj@chromium.org src/components/history_embeddings/OWNERS

Whether a search result could be included in the final result set based on its embedding score alone, without the word match boost from text search. This is logged for each result that passes the threshold filter with its total score including the word match boost, so it signals how helpful the boost from text search is in yielding results that would not have been included otherwise.

sophiechang@chromium.org zekunjiang@google.com

Number of URLs that matched the query and are allowed to be shown based on the content visibility policy. Logged each time a query leveraging history embeddings is performed.

orinj@chromium.org src/components/history_embeddings/OWNERS

Number of URLs that were added to a result set due to having a sufficient word match score and an insufficient total score. Logged each time a query leveraging history embeddings is performed.

sophiechang@chromium.org orinj@chromium.org

Number of URLs that were found but discarded for insufficient score (i.e. not reaching the configured search score threshold). Logged each time a query leveraging history embeddings is performed.

orinj@chromium.org src/components/history_embeddings/OWNERS

Number of URLs that were kept in a result set due to having a sufficient word match score and an insufficient total score, after capping to the maximum count for presentation to the user. Logged each time a query leveraging history embeddings is performed. Note, this differs from History.Embeddings.NumUrlsAddedByWordMatch in that it measures after capping. Comparing these two metrics can reveal how much word matches are pushed off the list by first total score results.

sophiechang@chromium.org zekunjiang@google.com src/components/history_embeddings/OWNERS

Number of URLs that matched the query. Logged each time a query leveraging history embeddings is performed.

orinj@chromium.org src/components/history_embeddings/OWNERS

Round trip request and response time for a single passage extraction. The clock starts just before the browser requests passages from a renderer, and stops just after results are received. Logged each time passages are successfully retrieved from a RenderFrameHost.

orinj@chromium.org src/components/history_embeddings/OWNERS

Number of passages retrieved from a single page passage extraction. Logged each time passages are retrieved from a RenderFrameHost.

orinj@chromium.org src/components/history_embeddings/OWNERS

Whether a dedicated web contents title passage was inserted at the beginning of the extracted passages vector. Logged each time passages are extracted.

orinj@chromium.org src/components/history_embeddings/OWNERS

The sum of passage text sizes for all passages retrieved from an extraction. Logged each time passages are retrieved from a RenderFrameHost.

orinj@chromium.org manukh@chromium.org

Whether a quality log entry was prepared when a history embeddings result was selected while quality logging was enabled.

orinj@chromium.org src/components/history_embeddings/OWNERS

Indicates query was answerable and passed to answerer. Logged each time a query could be passed to the answerer, i.e. when search is complete and top passages are ready to provide the context.

sophiechang@chromium.org zekunjiang@google.com

Whether the attempt to compute the query embedding succeeded. Logged each time an embedding was requested for a query.

orinj@chromium.org robertogden@chromium.org

Indicates query filter status every time a query is checked for filtering.

orinj@chromium.org src/components/history_embeddings/OWNERS

Number of jobs (groups of passages) that were already scheduled by the SchedulingEmbedder at the moment a new job is enqueued.

orinj@chromium.org src/components/history_embeddings/OWNERS

The number of milliseconds that a job existed in the SchedulingEmbedder job queue. Logged when a job is successfully completed by having all its passages embedded. Failed or canceled jobs do not log this histogram.

mahmadi@chromium.org src/components/history_embeddings/OWNERS

The status of a job when leaving the SchedulingEmbedder job queue. Logged when a job is successfully completed by having all its passages embedded, or when a job fails or is canceled.

orinj@chromium.org src/components/history_embeddings/OWNERS

Number of passages that were already scheduled by the SchedulingEmbedder at the moment a new job is enqueued.

orinj@chromium.org src/components/history_embeddings/OWNERS

Whether the search completed without interruption. Logged each time a vector database search is performed.

orinj@chromium.org src/components/history_embeddings/OWNERS

The number of milliseconds spent searching. Logged each time a vector database search is performed.

orinj@chromium.org src/components/history_embeddings/OWNERS

The number of embeddings searched. Logged each time a vector database search is performed.

orinj@chromium.org src/components/history_embeddings/OWNERS

The number of passages that were modified by removing non-ASCII characters. Note that this value is still useful even when the passage text itself is not used in the search (word match boosting is optimized for speed) because passages counted by this metric also indicate embeddings that were calculated from modified source passages. Logged each time a vector database search is performed.

orinj@chromium.org src/components/history_embeddings/OWNERS

The number of milliseconds spent on the passage scanning portion of the search, i.e. the text search required to compute word match score boost. Includes scoring for embeddings and word match boost scoring from text search. Logged each time a vector database search is performed.

orinj@chromium.org src/components/history_embeddings/OWNERS

The number of milliseconds spent on the scoring portion of the search. Includes scoring for embeddings and word match boost scoring from text search. Logged each time a vector database search is performed.

orinj@chromium.org src/components/history_embeddings/OWNERS

The number of passages that had their embeddings scored zero during search due to the source passage containing non-ASCII characters. Logged each time a vector database search is performed.

orinj@chromium.org src/components/history_embeddings/OWNERS

The number of milliseconds spent on the core of the vector database search. Logged each time a vector database search is performed.

orinj@chromium.org src/components/history_embeddings/OWNERS

The number of URLs searched. Logged each time a vector database search is performed.

wittman@chromium.org orinj@chromium.org src/components/history_embeddings/OWNERS

Number of embeddings that were computed for a tab that were stale by the time the computation completed, because the tab navigated away from the page in the mean time.

wittman@chromium.org orinj@chromium.org src/components/history_embeddings/OWNERS

The time it took to compute embeddings for one service round trip. Logged each time the embeddings are successfully computed.

wittman@chromium.org orinj@chromium.org src/components/history_embeddings/OWNERS

The time it took to compute embeddings with a priority other than the priorities with specific histograms, for one service round trip. Logged each time the embeddings are successfully computed.

wittman@chromium.org orinj@chromium.org src/components/history_embeddings/OWNERS

The time it took to compute embeddings with kPassive priority, for one service round trip. Logged each time the embeddings are successfully computed.

wittman@chromium.org orinj@chromium.org src/components/history_embeddings/OWNERS

The time it took to compute embeddings with kUrgent priority, for one service round trip. Logged each time the embeddings are successfully computed.

wittman@chromium.org orinj@chromium.org src/components/history_embeddings/OWNERS

The time it took to compute embeddings with kUserInitiated priority, for one service round trip. Logged each time the embeddings are successfully computed.

orinj@chromium.org src/components/history_embeddings/OWNERS

Tracks user actions related to History Embeddings in various bins within a single histogram. The first bucket of this histogram is logged for users with History Embeddings disabled too, to provide a baseline, and to serve as a guardian metric for the Embeddings experiments.

sophiechang@chromium.org zekunjiang@google.com

Whether the visibility model was available to determine whether the search results should be shown to the user for a given query. Logged each time a query leveraging history embeddings is performed.

rogerm@chromium.org sky@chromium.org 1456716

Size of the Favicons database in MB. This is calculated as the number of pages consumed by the database multiplied by the page size. Logged on initialization of the Favicon DB on 1% of starts.

treib@chromium.org 1456716

The number of foreign visits (i.e. visits coming from another device) in the DB table which came from "legacy" clients, i.e. those still using the Sessions sync integration. Recorded on initialization of the History DB on 1% of starts, only if any foreign visits exist (i.e. basically for users with History Sync on).

treib@chromium.org 1456716

The number of foreign visits (i.e. visits coming from another device) in the DB table which have an originator_from|opener_visit but are missing a corresponding local from|opener_visit. Recorded on initialization of the History DB on 1% of starts, only if any foreign visits exist (i.e. basically for users with History Sync on).

treib@chromium.org 1456716

The number of foreign visits (i.e. visits coming from another device) in the DB table which have an originator_from_visit but are missing a corresponding local from_visit, and a matching visit actually exists in the DB. Recorded on initialization of the History DB on 1% of starts, only if any foreign visits exist (i.e. basically for users with History Sync on).

treib@chromium.org 1456716

The number of foreign visits (i.e. visits coming from another device) in the DB table which have an originator_opener_visit but are missing a corresponding local opener_visit, and a matching visit actually exists in the DB. Recorded on initialization of the History DB on 1% of starts, only if any foreign visits exist (i.e. basically for users with History Sync on).

treib@chromium.org 1456716

The number of foreign visits (i.e. visits coming from another device) in the DB table. Recorded on initialization of the History DB on 1% of starts, only if any foreign visits exist (i.e. basically for users with History Sync on).

calamity@chromium.org src/chrome/browser/resources/history/OWNERS 1456716

The page of the History page shown to the user. Logged each time the user loads the History page or switches pages. This histogram expired on 2021-03-01, was renewed on 2021-09-01, and may have incomplete data within that range.

sky@chromium.org sdefresne@chromium.org 1456716

The phase of history initialization that failed. This histogram is only logged on database initialization failure. History.AttemptedToFixProfileError will tell how often initialization fails overall.

sky@chromium.org mpearson@chromium.org 1456716

The number of typed URLs in the history database that are read into the "in memory" history database. This in memory copy of the typed URLs is used for synchronous inline autocomplete on the UI thread, while the larger slower service is run off of disk on a background thread. Recorded on profile open.

mpearson@chromium.org chrome-omnibox-team@google.com 1456716

Number of history items in the in-memory url index. Recorded on profile open when restoring from a cache file and again shortly after profile open when rebuilding the in-memory url index from history.

kyraseevers@chromium.org tiffanysong@google.com

Whether HistoryTabHelper::DidFinishNavigation() encountered a navigation with a 4XX - 5XX status code. This value is recorded in both the chrome/ and ios/ code paths. This will help us determine the number of error navigations that could potentially be added to the HistoryDB if the early return is removed.

etienneb@chromium.org jpgravel@chromium.org 1456716

Indicates whether an existing history database has a meta table or not. Logged each time the history table is initialized.

etienneb@chromium.org sdefresne@chromium.org 1456716

History database version from which history migration failed. If there are higher than normal migration failures, this histogram will indicate which migration step failed. Warning: this histogram was expired from M77 to M108; data may be missing.

mpearson@chromium.org sky@chromium.org 1456716

Unique hostnames in History database urls table with last-visit times in the last 30 days. Metrics are logged on initialization of the History DB on one-third of starts.

mpearson@chromium.org sky@chromium.org 1456716

Unique URLs in History database urls table with last-visit times in the last 30 days. Metrics are logged on initialization of the History DB on one-third of starts.

hitarthkothari@google.com ckitagawa@chromium.org

Records the number of most visited site suggestions that are removed because they are considered visual duplicates of a higher-scoring suggestion. The deduplication logic is triggered when two tiles share the same hostname and have titles that are identical within the first 10 characters. This metric is recorded on the first call to VisitSegmentDatabase::QuerySegmentUsage during a browser session where the visual deduplication feature is active. This function is called each time the user loads the New Tab Page (NTP).

jinsukkim@google.com chrome-connective-tissue-team@google.com 1456716

The time in milliseconds the query takes to fetch the list of app IDs. The query is made to the local database only, not to the server side via network. This is called when history UI is opened. Only logged on Android.

mahmadi@chromium.org chrome-desktop-search@google.com

The amount of time for HistoryBackend::QueryMostRepeatedQueriesForKeyword() to extract up to the requested number of search terms from the HistoryDatabase db_ and sort them by frecency scores to produce the most repeated search terms. Excludes the case where local HistoryDatabase db_ is unavailable, i.e. where the query doesn't really happen. Emitted on NTP load and on omnibox popup shown on Android where the repeatable queries are requested to be shown in the Most Visited tiles.

mahmadi@chromium.org chrome-desktop-search@google.com

The amount of time for HistoryBackend::QueryMostVisitedURLs() to extract up to the requested number of most visited URLs from the HistoryDatabase db_ and sort them by descending frecency scores. Excludes the case where local HistoryDatabase db_ is unavailable and the query doesn't really happen. Emitted on NTP load and on Omnibox popup focus.

treib@chromium.org src/components/sync/OWNERS

Records the number of history entries that the user deleted via the history UI, when the deletions are sent to WebHistoryService (i.e. only for users who have history sync enabled). One history entry corresponds to one row (or checkbox) in the history UI, and represents all visits to a single URL on a given day. E.g. visiting a URL N times on the same day will have 1 row in the UI; and deleting that row will record 1 to this metric.

orinj@chromium.org

Logs the zero-based index of the result clicked. For Embeddings and Traditional history types, this logs the index of the visit with respect to visits of the same type only. For example, the first matching Traditional visit has index 0, even though it's displayed below all Embeddings matches. For Grouped history, this logs the index of the visit WITHIN its containing cluster. This is to match the History.Clusters.UIActions UMAs. This does not log anything shown directly in the omnibox suggest surface. This UMA is further sliced into per-type slices, and the sum of those histograms equals the unsliced histogram. The maximum index is 99, and clicks above that are clamped to that maximum.

orinj@chromium.org

Logs the type of the History result clicked from History UI surfaces. Note, this does NOT include any results clicked from the omnibox suggest surface, even if they are History or @history site search suggestions.

kyraseevers@chromium.org tiffanysong@google.com

Whether HistoryTabHelper::DidFinishNavigation() returned early due to !ShouldUpdateHistory() in chrome/ or IsError() in ios/. This will help us determine the number of navigations that could potentially be added to the HistoryDB if the early returns are removed.

mahmadi@chromium.org chrome-omnibox-team@google.com

The amount of time it takes to asynchronously query the most visited URLs and the most repeated queries, if applicable, from the history service. Excludes the case where local HistoryDatabase db_ is unavailable, i.e. where the query doesn't really happen. Emitted on NTP load and on omnibox popup shown on Android where the Most Visited tiles are shown.

svend@chromium.org kyraseevers@chromium.org

Whether a newly added URLRow is hidden. Emitted when a URLRow is added to the History database. Intended to monitor how much the number of hidden rows added increases when saving page visits with HTTP response code 404 to the History database.

mpearson@chromium.org sky@chromium.org 1456716

Number of rows in urls table in History DB. Metrics are logged on initialization of the History DB on 1% of starts.

svend@chromium.org kyraseevers@chromium.org

Whether a page visit recorded in the History DB was added due to a navigation with an HTTP response code of 404. Visits added due to a 404 includes a) 404 visits themselves and b) redirects in chains that end in a 404 visit. Recorded after a visit is successfully added to the History DB (because this includes redirects, one user-initiated navigation can result in multiple emissions). Intended to monitor what proportion of newly recorded visits are 404s when saving page visits with HTTP response code 404 to the History database. See also `History.VisitedLinks.AdditionCausedBy404`.

svend@chromium.org kyraseevers@chromium.org

When we attempt to add a VisitedLink to the in-memory partitioned hashtable, records whether that record is added due to a visit with an HTTP response code 404. Recorded on every attempt to write a VisitedLink entry, including those for redirects (i.e., for a redirect chain ending in a 404, there will be one emission per redirect, all emitted as true, since the 404 is what is causing the redirects' addition to the hashtable). Intended to monitor the proportion of VisitedLink entries that are for 404s, after allowing 404 visits to be saved to History. See also `History.VisitAddedDueTo404`.

kyraseevers@chromium.org tiffanysong@google.com

When VisitedLinkReader's in-memory hashtable is initialized, this metric records the value for table_length_ (the maximum number of entries that can be held in that hashtable).

kyraseevers@chromium.org tiffanysong@google.com

When a new in-memory hashtable is created in VisitedLinkWriter, this metric records the size of the memory allocated for that new hashtable in MB.

kyraseevers@chromium.org tiffanysong@google.com

When a new URL fingerprint is added to the VisitedLink hashtable, this metric logs value for used_items_ (the number of entries in the hashtable containing an actual fingerprint value rather than a placeholder).

kyraseevers@chromium.org tiffanysong@google.com

After the partitioned hashtable has completed building on the DB thread, we return to the main thread and determine the per-origin salts corresponding to each navigation that took place during the build. The VisitedLinkUpdater then sends those salts to their corresponding VisitedLinkReader instance. Each time a VisitedLinkUpdater sends per-origin salts, this histogram records how many salts were in the map.

kyraseevers@chromium.org tiffanysong@google.com

When VisitedLinkWriter is asked to add a URL, it calculates that URL's fingerprint and tries to add that fingerprint to the hashtable. This metric records the result of that function: AddFingerprint(). If the fingerprint is already in the table, we record kAlreadyVisited. If we haven't seen this fingerprint before and it can be successfully stored in the hashtable, we record kNewVisit. Any other outcomes due to table sizing errors are recorded as kTableError.

kyraseevers@chromium.org tiffanysong@google.com

For each visit being logged in the VisitedLinks hashtable by the HistoryService, record whether its ui::PageTransition type came from the main frame.

kyraseevers@chromium.org tiffanysong@google.com

For each visit being logged in the VisitedLinks hashtable by the HistoryService, record its PageTransitionForVisitedLinks type. This enum represents our ui::PageTransition types of interest (link vs. typed vs. subframe) and a catch-all other bucket.

tiffanysong@google.com kyraseevers@chromium.org

WebView collapses the triple-key space into a flat 1D key-space and hashes using a static constant salt, meaning the database loses the natural entropy of Chrome's randomized salt scheme. This metric monitors if the static salt causes hash clustering by recording the collision count for each visited link lookup. Recorded on every visited link lookup in Android WebView.

kyraseevers@chromium.org tiffanysong@google.com 1456589

Number of rows in visited_links table in History DB. Metrics are logged on initialization of the History DB on 1% of starts.

mpearson@chromium.org sky@chromium.org 1456716

Number of rows in visits table in History DB. Metrics are logged on initialization of the History DB on 1% of starts.

treib@chromium.org src/components/history/OWNERS 1456716

Recorded whenever a QueryHistory request in WebHistoryService completes successfully. Records the number of visits that were returned.

treib@chromium.org src/components/history/OWNERS 1456716

Recorded whenever a QueryWebAndAppActivity request in WebHistoryService completes successfully. Records the outcome, i.e. whether the user is opted in to web and app activity.

treib@chromium.org src/components/history/OWNERS 1456716

Recorded whenever a {RequestType} request finishes in WebHistoryService. Records the outcome (success/failure) of the request.

mpearson@chromium.org sky@chromium.org 1456716

Unique hostnames in History database urls table with last-visit times in the last 7 days. Metrics are logged on initialization of the History DB on one-third of starts.

mpearson@chromium.org sky@chromium.org 1456716

Unique URLs in History database urls table with last-visit times in the last 7 days. Metrics are logged on initialization of the History DB on one-third of starts.

zalmashni@google.com chrome-browser-privacy-team@google.com

Recorded for each context menu action click on an actor-annotated visit in the chrome://history page.

zalmashni@google.com chrome-browser-privacy-team@google.com

Records if actor-annotated visits are contained in the history items shown on the chrome://history page. Recorded every time the history page queries for history.

kalinino@google.com polonium@google.com

Records the category of critical action (e.g. form fill, password manager login, federated login, download, or OTP) opened from the chrome://history page. Recorded in WebUI when the user clicks an action linkout row under an agent-annotated visit to navigate to its external management surface.

kalinino@google.com polonium@google.com

Records the total number of critical actions attached to a single agent-annotated browsing history visit item on the chrome://history page. Recorded for each agent-annotated visit whenever browsing history entries are retrieved and prepared for display (on initial page load, search, or infinite scroll).

kalinino@google.com polonium@google.com

Records the time (in milliseconds) taken to query and retrieve critical actions from the local database for agent-annotated history visits. Recorded each time chrome://history receives a batch of history results containing agent visits and completes fetching their corresponding critical actions.

zalmashni@google.com chrome-browser-privacy-team@google.com

Recorded for each context menu action click on a regular (non-actor annotated) visit in the chrome://history page.

rpop@google.com chrome-analysis-team@google.com 1456716

Histogram for usage of the section in the history page that allows the user to access tabs from other devices. OtherSessionsActions.OPENED_LINK_VIA_CONTEXT_MENU was added for M-76. This histogram is of special interest to the chrome-analysis-team@. Do not change its semantics or retire it without talking to them first.

kalinino@google.com polonium@google.com

Records the total round-trip time (in milliseconds) taken to query, assemble, and deliver browsing history results to the chrome://history page. Recorded each time the history page requests history data (on initial page load, when performing a search, or when scrolling down to load more items). Recorded for queries where {HasCriticalActions}.