treib@chromium.org src/components/sync/OWNERS Records the account managed status that was asynchronously determined during sync startup. Only recorded if the status was not known synchronously (see `Sync.AccountManagedStatusSynchronousOutcome`). Also see `Sync.AccountManagedStatusDuration` for timings. treib@chromium.org src/components/sync/OWNERS Records the time it took to determine the account managed status during sync startup. Only recorded if the status was not known synchronously (see `Sync.AccountManagedStatusSynchronousOutcome` and `Sync.AccountManagedStatusAsynchronousOutcome`). treib@chromium.org src/components/sync/OWNERS Records the account managed status during sync startup, or "pending" if the status wasn't known yet - in that case, see `Sync.AccountManagedStatusAsynchronousOutcome`. rgod@google.com ylahodiuk@google.com iOS only. Account menu settings page displays an error on top whenever there is any user actionable error. Records the type of an error that is visible to the user when they navigate to the account menu settings page or when it appears while the user is on that page. skym@chromium.org ckitagawa@chromium.org The amount of time it takes to assocate windows. The goal of this process is to match tab sync data with live tabs. This process is currently run in multiple situations, which this histogram is emitted separately for. Ideally as little time is spent as possible doing this. treib@chromium.org src/components/sync/OWNERS Logged when a data type is backed off. This histogram can help explain changes in Sync.PostedClientToServerMessageError2::PARTIAL_FAILURE. mtatarski@google.com src/components/sync/OWNERS Records whether Bookmarks batch upload is disabled due to the bookmark limit being exceeded. Recorded when the batch upload local data description for bookmarks is requested, provided there are local bookmarks available to upload. Note: This metric is recorded in GetLocalDataDescription to avoid double logging during the migration process itself, but this means its trigger depends on how often GetLocalDataDescription is called by external UI code. rsult@google.com chrome-signin-team@google.com Records the data types that are available in the Batch Upload. A data type is available if it has local items displayed. Records when the dialog is first shown. rsult@google.com chrome-signin-team@google.com Records the data types that are selected in the Batch Upload. A data type is considered selected if some items are checked in the dialog when the user saves the choices. Records when the dialog is closed only after the users saves their choice - not for any other way the dialog is closed. rsult@google.com chrome-signin-team@google.com Records the percentage of selected items versus the available items per data type in the Batch Upload. It is recorded only for data types that are available and that are selected. Records when the dialog is closed after the users saves their choice - not for any other way the dialog is closed. rsult@google.com chrome-signin-team@google.com Records the reason for closing the Batch Upload Dialog. Recorded when the dialog is closed. rsult@google.com chrome-signin-team@google.com Records the entry point from which the Batch Upload Dialog was opened. Records when the dialog is first shown. ankushkush@google.com src/components/sync/OWNERS Logged when batch upload of local data for a data type is requested via SyncService::TriggerLocalDataMigration() (normally by one of the UI entry points). Note that at the time of writing, this metric only supports PASSWORDS, BOOKMARKS and READING_LIST. This replaced Sync.BatchUpload.Requests2, which omitted types that issued requests but weren't healthy. amelies@google.com chrome-signin-desktop-team@google.com Records that the user {Action} the dialog which asks them to confirm whether they want to move a bookmark from account to local storage. This histogram is usually recorded twice per dialog, once for `Shown` and once for the following user action (accepted, declined, or explicitly closed). It is only recorded once with `Shown` if the browser is closed while the dialog is opened. amelies@google.com chrome-signin-desktop-team@google.com Records that the user {Action} the dialog which asks them to confirm whether they want to move a bookmark from local to account storage. This histogram is usually recorded twice per dialog, once for `Shown` and once for the following user action (accepted, declined, or explicitly closed). It is only recorded once with `Shown` if the browser is closed while the dialog is opened. `BookmarkAccountStorageMoveDialogType` refers to the type of dialog: * `Download or upload version` is the version of the dialog which can be used for either uploading or downloading a bookmark, usually triggered through a drag and drop by the user in a folder of a different storage (account vs. local). This dialog is triggered for merged surfaces such as the bookmarks bar or the side panel, not unmerged surfaces such as the bookmark manager. * `Upload only version` is the version of the dialog which can only be used for uploading a bookmark without specifying the location, triggered by clicking on a local bookmark's cloud upload icon in the bookmark manager. rushans@google.com mastiz@chromium.org Records if the entity is marked to be reuploaded. It is recorded on each incoming bookmark update from the server during {UpdateType}. rushans@google.com mastiz@chromium.org Records whether a GUID was found within BookmarkSpecifics, if an originator_client_item_id of valid GUID format was used to replace it, or if the field was left empty. Recorded when processing a remote bookmark update, except for permanent nodes, which are created server-side and don't have an originator client item ID. rushans@google.com mastiz@chromium.org Records the number of valid and non-duplicate updates processed during initial merge for bookmarks that are reachable when traversing the bookmark tree, including permanent folders. Recorded during the initial merge procedure after deduplication. rushans@google.com mastiz@chromium.org Records the number of unsynced entities (bookmarks or folders) as a result of the initial merge for bookmarks. This includes local creations (i.e. did not match any entity in the server) as well as local modifications (e.g. pending reupload). Recorded upon completion of the initial merge procedure. rushans@google.com mastiz@chromium.org Records the number of received input updates considered valid during initial merge for bookmarks, prior to deduplication, including permanent folders and unreachable nodes (see Sync.BookmarkModelMerger.ReachableInputUpdates for a more strict variant). Invalid updates contribute to metric Sync.ProblematicServerSideBookmarksDuringMerge. Recorded during the initial merge procedure. rushans@google.com mastiz@chromium.org Measures the initial bookmark merge time broken down by different stages. Recorded after every initial merge procedure {UpdatesCount}. rushans@google.com mastiz@chromium.org Records whether the parent GUID for a bookmark was read from the BookmarkSpecifics or from the SyncEntity.parent_id field. Recorded when processing remote updates for each non-deletion update. mtatarski@google.com src/components/sync/OWNERS Records the source of the parent GUID for a bookmark when processing remote updates. Recorded for each non-deletion update. mtatarski@google.com src/components/sync/OWNERS Records the number of bookmarks when the sync limit is exceeded. This helps inform what the new limit should be. Recorded when the error is detected (on sync start, update received, or initial merge). mastiz@chromium.org rushans@google.com Records different types of bookmark entities having the same GUIDs. It's recorded on each found duplicate when processing remote bookmarks from the sync server during the initial merge. mtatarski@google.com src/components/sync/OWNERS Recorded when the user clicks on the "Learn more" link regarding the bookmarks limit exceeded error. Recorded by the UI surface that triggered the click. mtatarski@google.com src/components/sync/OWNERS Records whether the bookmarks limit exceeded error was present when a sign-out confirmation dialog was shown. This helps track how often this specific error is a reason for the confirmation dialog. Recorded on all platforms. rushans@google.com mastiz@chromium.org The reason why the persisted metadata for a bookmark model is considered corrupted. It either has corrupted data or doesn't match the bookmark model. It's recorded at start up only if the initial sync has been performed already. It's recorded after loading the metadata. rushans@google.com mastiz@chromium.org Records if a remote sync update for a bookmark, excluding folders, contains a favicon. It is recorded upon initial and incremental updates, when the local state is about to be modified. mtatarski@google.com src/components/sync/OWNERS Records the success or failure of decrypting the sync bootstrap token. This token is used to decrypt sync data when a custom passphrase is set. mtatarski@google.com src/components/sync/OWNERS Records the success or failure of encrypting the sync bootstrap token. This token is used to decrypt sync data when a custom passphrase is set. ankushkush@google.com treib@chromium.org Recorded when metadata is cleared while the data type was not running{ClearTime}. rushans@google.com treib@chromium.org Records the duration of each successful Commit request for {SyncDataType}. rushans@google.com treib@chromium.org Records the number of entries in a commit request. Recorded only when the commit request was successfully sent and a response was received (i.e. no network or protocol error). rushans@google.com treib@chromium.org Emitted per network Commit() request to the sync server and datatype. Records the outcome of each commit attempt per data type (success or one of various error codes). rushans@google.com treib@chromium.org Records whether the data type manager was configured for the first time (i.e. whether the user signed in within the same browser session). Recorded whenever sync configuration finishes successfully. Note that this metric is not recorded if the configuration takes too much time or is aborted. rushans@google.com treib@chromium.org Whether the data type manager is configured for the first time, i.e. the user signs in. Recorded when configuring the data type manager is started (e.g. on profile load when a user is signed in or the user signs in, enables or disables sync, etc). mastiz@chromium.org treib@chromium.org Whether the full Sync feature or only the Sync transport layer is being configured. Recorded when configuring the data types for any reason: Most commonly during browser startup, but also after initial setup, after a reconfiguration by the user, or when switching between full feature mode and transport mode. treib@chromium.org src/components/sync/OWNERS The reason that triggered a configuration cycle. Recorded when configuring the data types for any reason: Most commonly during browser startup, but also after initial setup, or after a reconfiguration by the user. mastiz@chromium.org treib@chromium.org Breakdown of sync data types being configured. This is different from Sync.CustomTypes in that this captures all active devices, not just those that are choosing a custom sync configuration. A sync configuration refers to the process of initializing or updating the set of active, syncing data types. This is triggered under several scenarios: most commonly, when a user signs in for the first time (setting up a new client); upon browser restart or profile load while already signed in (restarting sync for an existing client); when the user changes sync toggles or settings (reconfiguration); when an identity/authentication error is resolved; when key crypto-related events occur (such as decryption key acquisition or entering a correct custom passphrase); and as a result of other more advanced triggers such as error conditions. Note that not all platforms support all data types. As such, comparing across platforms should only look at the common data types. treib@chromium.org src/components/sync/OWNERS Time spent configuring data types for {ConfigurationType}. Recorded when DataTypeManagerImpl finishes. bwwilliams@google.com treib@chromium.org src/components/sync/OWNERS Records the service status of the CrossDevicePrefTracker every time a client calls one of the Query APIs (GetValues() or GetMostRecentValue()). This metric helps determine how often clients attempt to read cross-device preferences when the tracker is unavailable. Recorded immediately upon API invocation. jhimawan@google.com bwwilliams@google.com treib@chromium.org src/components/sync/OWNERS Records the possible outcomes after checking for settings to import from a remote device. Recorded when we conclude that the user has no settings to import (which can happen for several reasons) or when we show a snackbar allowing the user to undo/redo. mmoskvitin@google.com treib@chromium.org Key derivation method used for sync custom passphrase on successful decryption of pending keys, i.e. when a passphrase is requested and the user types in the correct one. "Not set" will never be reported for this metric, since we always have an explicit key derivation method on successful decryption. mmoskvitin@google.com treib@chromium.org State of the derivation method used for sync custom passphrase on startup. Reported only when the passphrase type is CUSTOM_PASSPHRASE. mmoskvitin@google.com treib@chromium.org Time taken to derive keys in Nigori using a given key derivation method. This histogram is always recorded with one of the key derivation method suffixes. mastiz@chromium.org treib@chromium.org Breakdown of sync users whose cryptographer has pending keys. mmoskvitin@google.com mastiz@chromium.org Breakdown of sync users whose cryptographer is fully ready for encryption and decryption (initialized and no pending keys). mmoskvitin@google.com treib@chromium.org For users who have *not* selected the "Sync Everything" option, this records all the OS data types they have selected to sync. Samples are taken every time the Sync data types are (re)configured, which typically happens during startup and when the user changes any Sync settings. treib@chromium.org mastiz@chromium.org For Sync-the-feature users who have *not* selected the "Sync Everything" option, this records all the data types they have selected to sync. Samples are taken every time the Sync data types are (re)configured, which typically happens during startup and when the user changes any Sync settings. NOTE: This does NOT include OS datatypes. Use Sync.CustomOSSync for those. See also "Sync.SelectedTypesInTransportMode" which is the corresponding histogram for Sync-transport users, and "Sync.SyncEverything2" which is the histogram for whether the user has selected the "Sync Everything" option. treib@chromium.org mastiz@chromium.org The Sync-the-feature "active" status of {SyncDataType} for the purpose of the SyncToSignin migration. Recorded on profile creation/startup, capturing the state from just before shutdown during the previous run of Chrome (i.e. before re-evaluation). Recorded only if `Sync.FeatureStatusForSyncToSigninMigration` recorded "active". rushans@google.com treib@chromium.org Recorded once per commit message after which the quota for the given data type is depleted. If the commit cycle contains 150 commit messages for a given data type and the quota has initially 100 tokens, the quota gets depleted after first 100 messages and this histogram gets recorded for all the remaining messages (i.e. ~50 times) for the data type. Quota is tracked (and this metric gets recorded) only for data types that can be committed via JS API of extensions. rushans@google.com treib@chromium.org Recorded once per local change that gets scheduled for committing with an extra long nudge delay. This happens if and only if the commit quota for this data type for this user is depleted. Quota is tracked (and this metric gets recorded) only for data types that can be committed via JS API of extensions. This metric is not very reliable as nudging for local changes happens via thread hopping and there is no guarantee whether a local change will nudge for commit _before_ or _after_ it actually gets committed. rushans@google.com mastiz@chromium.org Recorded once per activation of a(n) {StorageType} data type; the value is the duration of the setup (time from the start of the configuration of sync until the data type receives all its sync data and the data is ready for the user). This metric is used for monitoring general health of sync client-side code. rushans@google.com mastiz@chromium.org Counts the number of entries for each data type. The count is based on metadata entries for the type. Recorded after sync configuration. This metric is used for monitoring general health of sync client-side code. A sync configuration refers to the process of initializing or updating the set of active, syncing data types. This is triggered under several scenarios: most commonly, when a user signs in for the first time (setting up a new client); upon browser restart or profile load while already signed in (restarting sync for an existing client); when the user changes sync toggles or settings (reconfiguration); when an identity/authentication error is resolved; when key crypto-related events occur (such as decryption key acquisition or entering a correct custom passphrase); and as a result of other more advanced triggers such as error conditions. treib@chromium.org rushans@google.com Recorded once for every sync entity change (whenever it is about to be commited to the server or updated from the server). This metric is used for monitoring general health of sync client-side code. Note: This is only recorded with a data type suffix. The base version is never recorded. Note: this metric may be recorded multiple times for the same entity change, e.g. if there is a retry commit after a server error, hence compare its changes against Sync.CommitResponse{SyncDataType}. rushans@google.com src/components/sync/OWNERS Records the resolution of a conflict per sync entity on incremental update. This metric should be compared against Sync.DataTypeEntityChange to compare with the total number of incremental updates. Not recorded for NIGORI. treib@chromium.org rushans@google.com Recorded whenever ClientTagBasedDataTypeProcessor triggers a data type failure (recorded for both Start and Run failures). It distinguishes call sites for triggering such failures. mastiz@chromium.org rushans@google.com Estimated memory usage by sync datatype in kilobytes. Recorded after sync configuration. This metric is used for monitoring general health of sync client-side code. A sync configuration refers to the process of initializing or updating the set of active, syncing data types. This is triggered under several scenarios: most commonly, when a user signs in for the first time (setting up a new client); upon browser restart or profile load while already signed in (restarting sync for an existing client); when the user changes sync toggles or settings (reconfiguration); when an identity/authentication error is resolved; when key crypto-related events occur (such as decryption key acquisition or entering a correct custom passphrase); and as a result of other more advanced triggers such as error conditions. rushans@google.com src/components/sync/OWNERS Recorded when ClientTagBasedDataTypeProcessor checks stored metadata consistency upon processor startup or activation. Tracks whether metadata is consistent or what mismatch/error occurred for {SyncDataType}. mmoskvitin@google.com treib@chromium.org Counts the number of unsynced entities for each data type, including tombstones. Recorded {Event}. mastiz@chromium.org treib@chromium.org Records whenever an orphan metadata is encountered by the ClientTagBasedDataTypeProcessor. rushans@google.com mastiz@chromium.org Histogram of the run failures for the different sync datatypes. These are failures that occur after startup while the datatype is syncing. This is one of the base sync health metrics. The Sync.DataTypeStoreBackendError and Sync.DataTypeErrorSite histograms may help diagnosing the problem. rushans@google.com mastiz@chromium.org Histogram of the startup failures for the different sync datatypes. These are failures that occur during startup before the data type is fully loaded. These errors are caused by failures in reading metadata (or data) from the DB or by another failure in interaction with the model. The Sync.DataTypeStoreBackendError and Sync.DataTypeErrorSite histograms may help diagnosing the problem. treib@chromium.org rushans@google.com Records the LevelDB Status error code for DataTypeStore {Operation} operations. Recorded when there is an error while communicating with the DB for any data type that uses the DataTypeStore. This metric should be used together with Sync.DataType[Run|Start]Failures2 to figure out the root cause of the data type failure. In case of an IOError, `Sync.DataTypeStoreBackendError.{Operation}.IOError` is also recorded. treib@chromium.org mtatarski@google.com Records the base::File::Error code for DataTypeStore {Operation} operations when the LevelDB status is IOError. treib@chromium.org rushans@google.com Records the outcome of the initialization of the DataTypeStoreBackend, which typically happens once every browser startup (or more precisely, profile initialization). rushans@google.com src/components/sync/OWNERS Records the data type for which a unique position in the correct order could not be generated. Recorded for each failed attempt of unique position generation (normally, for each local entity creation or update). This metric should be compared against Sync.DataTypeEntityChange3 to compare with the total number of incremental updates. rushans@google.com src/components/sync/OWNERS This histogram is similar to Sync.DataTypeUniquePositionError but it is recorded only when the incorrect order of valid unique positions is detected (as opposed to invalid unique positions). Recorded whenever an incorrect order is detected while generating unique position between two entities. This metric should be compared against Sync.DataTypeEntityChange3 to compare with the total number of incremental updates. treib@chromium.org rushans@google.com Recorded whenever a remote update for a particular data type gets dropped for the following reason: {Reason}. mastiz@chromium.org rushans@google.com chrome-metrics-team@google.com The largest number of active and concurrently syncing devices known to any profile. May be 0 when there are no signed in/syncing profiles open. Logged with every UMA log. ssid@chromium.org mastiz@chromium.org chrome-metrics-team@google.com The largest number of active and concurrently syncing devices of type {DeviceType} known to any profile. May be 0 when there are no signed in/syncing profiles open. Logged with every UMA log. treib@chromium.org src/components/sync/OWNERS Device statistics: Records the number of additional syncing clients (i.e. not counting this client) of a non-primary account. Recorded at most once per day (30 seconds after profile initialization) for every non-primary account. treib@chromium.org src/components/sync/OWNERS Device statistics: Records the number of additional syncing clients (i.e. not counting this client) of a non-primary account which are opted in to history sync. Recorded at most once per day (30 seconds after profile initialization) for every non-primary account. treib@chromium.org src/components/sync/OWNERS Device statistics: Records the number of distinct platforms among the additional syncing clients (i.e. not counting this client) of a non-primary account. Recorded at most once per day (30 seconds after profile initialization) for every non-primary account. treib@chromium.org src/components/sync/OWNERS Device statistics: Records the number of distinct platforms among the additional syncing clients (i.e. not counting this client) of a non-primary account where at least one client on that platform is opted in to history sync. Recorded at most once per day (30 seconds after profile initialization) for every non-primary account. treib@chromium.org src/components/sync/OWNERS Device statistics: Records the platform and form factor of each additional syncing client (i.e. not counting this client) of each non-primary account. Multiple clients with the same platform and form factor are recorded individually. Recorded at most once per day (30 seconds after profile initialization), but with one sample per other client. treib@chromium.org src/components/sync/OWNERS Device statistics: Records the platform of each additional syncing client (i.e. not counting this client) of each non-primary account. Multiple clients with the same platform are recorded individually. Recorded at most once per day (30 seconds after profile initialization), but with one sample per other client. treib@chromium.org src/components/sync/OWNERS Device statistics: Records the overall outcome, i.e. whether primary and/or non-primary accounts have other syncing devices. Recorded at most once per day (30 seconds after profile initialization). treib@chromium.org src/components/sync/OWNERS Device statistics: Records the overall outcome, i.e. whether primary and/or non-primary accounts have other syncing clients on other platforms. Recorded at most once per day (30 seconds after profile initialization). treib@chromium.org src/components/sync/OWNERS Device statistics: Records the history opt-in status of the primary account, across this device and any other signed-in-to-Chrome devices. Recorded at most once per day (30 seconds after profile initialization). treib@chromium.org src/components/sync/OWNERS Device statistics: Records the history opt-in status of the primary account, across this device and any other signed-in-to-Chrome devices *on different platforms* only. Recorded at most once per day (30 seconds after profile initialization). treib@chromium.org src/components/sync/OWNERS Device statistics: Records the multi-device readiness of the primary account, i.e. whether there are other signed-in-to-Chrome devices. Recorded at most once per day (30 seconds after profile initialization). treib@chromium.org src/components/sync/OWNERS Device statistics: Records the multi-platform readiness of the primary account, i.e. whether there are other signed-in-to-Chrome devices *on different platforms*. Recorded at most once per day (30 seconds after profile initialization). treib@chromium.org src/components/sync/OWNERS Device statistics: Records the number of additional syncing clients (i.e. not counting this client) of the primary account. Recorded at most once per day (30 seconds after profile initialization). treib@chromium.org src/components/sync/OWNERS Device statistics: Records the number of additional syncing clients (i.e. not counting this client) of the primary account which are opted in to history sync. Recorded at most once per day (30 seconds after profile initialization). treib@chromium.org src/components/sync/OWNERS Device statistics: Records the number of distinct platforms among the additional syncing clients (i.e. not counting this client) of the primary account. Recorded at most once per day (30 seconds after profile initialization). treib@chromium.org src/components/sync/OWNERS Device statistics: Records the number of distinct platforms among the additional syncing clients (i.e. not counting this client) of the primary account where at least one client on that platform is opted in to history sync. Recorded at most once per day (30 seconds after profile initialization). treib@chromium.org src/components/sync/OWNERS Device statistics: Records the platform and form factor of each additional syncing client (i.e. not counting this client) of the primary account. Multiple clients with the same platform and form factor are recorded individually. Recorded at most once per day (30 seconds after profile initialization), but with one sample per other client. treib@chromium.org src/components/sync/OWNERS Device statistics: Records the platform of each additional syncing client (i.e. not counting this client) of the primary account. Multiple clients with the same platform are recorded individually. Recorded at most once per day (30 seconds after profile initialization), but with one sample per other client. treib@chromium.org src/components/sync/OWNERS Device statistics: The outcome of an individual statistics request, recorded when a request completes. treib@chromium.org src/components/sync/OWNERS Device statistics: Whenever all GetUpdates requests that were started (see `Sync.DeviceStatistics.RequestsStartedCount`) have completed, records the success of the entire operation. treib@chromium.org src/components/sync/OWNERS Device statistics: Whenever GetUpdates requests are started for the purpose of device statistics metrics, records the number of requests (= the number of accounts in the profile). This happens at most once per day, 30 seconds after profile initialization. treib@chromium.org src/components/sync/OWNERS Device statistics: The fetch response to an individual statistics network request, i.e. the network error if any, and the HTTP response code otherwise. Recorded when a network request completes. rushans@google.com treib@chromium.org Records the result of the download updates step of the sync cycle. This metric is recorded only once per sync cycle and records the last error encountered during the cycle. mtatarski@google.com treib@chromium.org The time between SyncServiceImpl::TryStart() being called and the encryptor being received from OSCryptAsync. ankushkush@google.com treib@chromium.org Size of individual sync entity specifics (not including tombstones) in bytes, without the sync metadata. Recorded right before an entity is committed to the server. ankushkush@google.com treib@chromium.org Size of individual sync entities (not including tombstones) in bytes, including the sync metadata. Recorded right before an entity is committed to the server. See also `Sync.EntitySizeOnCommit.Tombstone.*` for tombstones. ankushkush@google.com treib@chromium.org Size of individual sync tombstones in bytes, including the sync metadata. Recorded right before an entity is committed to the server. See also `Sync.EntitySizeOnCommit.Entity.*` for non-tombstones. treib@chromium.org mastiz@chromium.org The overall status of Sync-the-feature for the purpose of the SyncToSignin migration, recorded on profile creation/startup, capturing the state from just before shutdown during the previous run of Chrome (i.e. before re-evaluation). See also data-type-specific statuses in `Sync.DataTypeActiveForSyncToSigninMigration.*`. Before M130, "disabled" and "paused" were recorded to a single bucket (number 1, "Disabled or Paused"). treib@chromium.org mastiz@chromium.org Recorded when HistorySyncBridge encounters a database error. As a result, the bridge stops operating (and tracking metadata) for the rest of the runtime of Chrome. ankushkush@google.com src/components/sync/OWNERS Android only. Identity error card is shown to signed-in non-syncing users, whenever the user navigates to account settings and there exists an identity error. Recorded whenever an error card is shown to the user, and if the user interacts with the card (i.e. presses the button to resolve the error). ankushkush@google.com src/components/sync/OWNERS Android only. Identity error message is shown to signed-in non-syncing users with an identity error, when certain conditions are met. Recorded whenever a message is shown to the user, and if the user interacts with the message(i.e. either dismissing the message or pressing the button to resolve the error). rushans@google.com treib@chromium.org An outcome of handling incoming sync invalidations, recorded for each incoming FCM message when sync engine is registered for invalidations. This metric shows only the number of incoming messages regardless of the number of invalidated data types. treib@chromium.org mastiz@chromium.org An approximate state of sync at profile startup. Logs a few reasons sync definitely wouldn't be able to start, or that it probably can start. A dashboard stop and clear will fall under "turned off and setup not completed". Only recorded for "regular" profiles, i.e. those in which Sync might actually start. This excludes incognito profiles, guest profiles, system profiles (used for the profile picker), lockscreen profiles, etc. mastiz@chromium.org nyquist@chromium.org src/components/sync/OWNERS Recorded true when a Sync invalidation is received with an FCM dispatch timestamp in the future relative to the client's clock, indicating clock skew, using {SyncInvalidationLatencySource}. Recorded false when a valid latency sample (non-negative) is recorded. Note that ServerBased.* metrics are recorded cumulatively; a single sample is recorded in every histogram whose uncertainty threshold is satisfied. mastiz@chromium.org nyquist@chromium.org src/components/sync/OWNERS The uncertainty (estimated error range) of the network time used for recording Sync.InvalidationFcmDeliveryLatency.ServerBased.* histograms. Recorded only when the network time is successfully retrieved and available. mastiz@chromium.org nyquist@chromium.org src/components/sync/OWNERS The pure FCM delivery latency of Sync invalidations for {SyncDataType}, measured from server dispatch (FCM exact publish time in payload) to client receipt, using {SyncInvalidationLatencySource}. Note that ServerBased.* metrics are recorded cumulatively; a single sample is recorded in every histogram whose uncertainty threshold is satisfied. mmoskvitin@google.com treib@chromium.org Histogram tracks the number of invalidations received per sync data type. rushans@google.com src/components/sync/OWNERS Records true whenever OnMessagesDeleted is called on FCMHandler. This metric should be compared against Sync.IncomingInvalidationStatus total count to compare the ratio of deleted messages in FCM. Note: messages can be deleted if there are too many incoming FCM messages from different sender IDs on one client, i.e. not only sync invalidations. Refer to FCM documentation for more details. rushans@google.com treib@chromium.org Records the time required for sync invalidations to be fully initialized. The metric is calculated against sync engine creation time (may be deferred from browser startup). This metric may be reported several times during browser session whenever SyncEngine is reset, e.g. when sync was disabled and re-enabled again. mastiz@chromium.org nyquist@chromium.org src/components/sync/OWNERS Recorded true when a Sync invalidation is received with a timestamp in the future relative to the client's clock, indicating clock skew, using {SyncInvalidationLatencySource}. Recorded false when a valid latency sample (non-negative) is recorded. Note that ServerBased.* metrics are recorded cumulatively; a single sample is recorded in every histogram whose uncertainty threshold is satisfied. mastiz@chromium.org nyquist@chromium.org src/components/sync/OWNERS The uncertainty (estimated error range) of the network time used for recording Sync.InvalidationTransitLatency.ServerBased.* histograms. Recorded only when the network time is successfully retrieved and available. mastiz@chromium.org nyquist@chromium.org src/components/sync/OWNERS The end-to-end transit latency of Sync FCM invalidations for {SyncDataType}, measured from server dispatch (publish time in payload) to client receipt, using {SyncInvalidationLatencySource}. Note that ServerBased.* metrics are recorded cumulatively; a single sample is recorded in every histogram whose uncertainty threshold is satisfied. mastiz@chromium.org rushans@google.com Records different causes for BookmarkSpecifics to be deemed invalid. Issues are recorded upon verifying validity of specifics received from the server. mmoskvitin@google.com mastiz@chromium.org The reason for a failure decrypting the keystore Nigori. igorruvinov@chromium.org pastarmovj@chromium.org Tracks the number of times the local sync backend was enabled by the user. Recorded when the SyncService is created, i.e. during profile startup. igorruvinov@chromium.org pastarmovj@chromium.org Tracks the size of the local sync backend database file. Recorded every time the roaming profile file is written by the client. igorruvinov@chromium.org pastarmovj@chromium.org Error code describing failure to read persisted sync state from local file. Recorded when an error is encountered during opening or reading of the local sync state file. igorruvinov@chromium.org pastarmovj@chromium.org Tracks the number of times the Roaming profile cannot be retrieved. Recorded when the SyncService is created, i.e. during profile startup. rushans@google.com treib@chromium.org Records local changes happening during an ongoing remote incremental update. rushans@google.com treib@chromium.org src/components/sync/OWNERS Logged when the GetUpdates response didn't contain a progress marker for an expected/requested data type. Recorded once per missing data type. mtatarski@google.com src/components/sync/OWNERS Records the type of model error encountered in {SyncDataType}. ankushkush@google.com treib@chromium.org Records the time taken for all data types to finish loading, initiated from ModelLoadManager::LoadModels(). ankushkush@google.com treib@chromium.org Recorded whenever a data type fails to complete loading, called from ModelLoadManager::LoadModels(), before the timeout. This type is ignored and the rest of types which have loaded are marked ready for configuration. This type would ultimately be stopped once gets out of MODEL_STARTING state. mtatarski@google.com src/components/sync/OWNERS Records the success or failure of decrypting the Nigori local data from disk. This data contains sync's encryption keys. mtatarski@google.com src/components/sync/OWNERS Records the success or failure of encrypting the Nigori local data to disk. This data contains sync's encryption keys. mastiz@chromium.org treib@chromium.org Freshness of the sync data per received sync entity update, excluding reflections, for {SyncDataType}. The time represents the clock difference from the model being modified (usually on another device) until the change is processing by this instance of the browser. The time is capped at 1 week. Beware of potential clock skew due to two clients being involved. rushans@google.com treib@chromium.org Records the time between receiving invalidations and applying updates (including empty) per datatype. Recorded once per sync cycle for each datatype which had invalidations triggered GetUpdates. Note that only invalidations received during the current browser session are considered. rushans@google.com treib@chromium.org Records the result of downloading updates for a data type when requested (i.e. there was at least one invalidation during a sync cycle). Recorded at the end of a sync cycle (excluding requests without invalidations for the data type). rushans@google.com src/components/sync/OWNERS Recorded if commit of outgoing password sharing invitations fails with a datatype-specific error code returned from the server. Records the returned error. Sync.CommitResponse.OUTGOING_PASSWORD_SHARING_INVITATION can be used to compare with the total number of commit requests. treib@chromium.org mastiz@chromium.org The active sync passphrase type at sync startup. treib@chromium.org src/components/sync/OWNERS Sync passphrase type collected at each metrics upload. The implementation relies on the kSyncCachedPassphraseType pref, and thus can record the correct value before sync engine initialization. Signed-out users are counted in the "unknown" bucket. Recorded only after profile initialization. mastiz@chromium.org mmoskvitin@google.com The active sync passphrase type when the client receives a NOT_MY_BIRTHDAY or ENCRYPTION_OBSOLETE event from the server. mamir@chromium.org mastiz@chromium.org Records whether password notes are set in password specifics proto or the backup field. Recorded when decrypting password entity update upon download from the sync server. ankushkush@google.com src/components/sync/OWNERS Logs the count of local passwords moved to the account store. This is logged when, upon a batch upload request, passwords have been moved to the account store. Note that passwords may not have been uploaded to the server yet. Upload happens as part of the regular commit process. shabdan@google.com rushans@google.com Number of acknowledged and dropped invalidations broken down by reason. Recorded during browser shutdown, after a sync cycle or on incoming invalidation. skym@chromium.org ckitagawa@chromium.org Records the result of whether the placeholder tab had its local session found, had its data resynced successfully, or remained unsynced. mastiz@chromium.org treib@chromium.org src/components/sync/OWNERS Number of network requests issued by sync to the sync server, grouped by content type. Note: this metric is recorded before the request is sent and it may be impacted by network / server errors (e.g. due to retries). Compare against Sync.URLFetchResponse. mastiz@chromium.org treib@chromium.org src/components/sync/OWNERS A sync error code received from the sync server as a result of a client-initiated request. Note that this excludes network errors (e.g. client offline) and HTTP errors. mastiz@chromium.org treib@chromium.org src/components/sync/OWNERS Time taken for a client-initiated request to be sent over the network and receive the response from the sync server. treib@chromium.org src/components/sync/OWNERS The data type(s) which encountered a partial (i.e. data-type-specific) error as a result of a client-initiated request. Recorded when a request resulted in a PARTIAL_FAILURE (and the server provided the list of affected data types). This histogram can help explain changes in Sync.PostedClientToServerMessageError2::PARTIAL_FAILURE. mastiz@chromium.org rushans@google.com src/components/sync/OWNERS Emitted per network Commit() request to the sync server and datatype. It helps estimate how much load each datatype puts on the server. Note that the sum across buckets does not represent the total number of requests sent to the server, since multiple datatypes can be grouped in a single request. See Sync.PostedClientToServerMessage for the total number of requests/messages. Note: this metric is recorded before the request is sent and it may be impacted by network / server errors (e.g. due to retries). Compare against Sync.CommitResponse. mastiz@chromium.org rushans@google.com src/components/sync/OWNERS Emitted per network GetUpdates() request to the sync server and datatype. It represents how much load each datatype puts on the server. Note that the sum across buckets does not represent the total number of requests sent to the server, since multiple datatypes can be grouped in a single request. See Sync.PostedClientToServerMessage for the total number of requests/messages. Note: this metric is recorded before the request is sent and it may be impacted by network / server errors (e.g. due to retries). mastiz@chromium.org rushans@google.com Emitted per network GetUpdates() request to the sync server, it represents the reason for sending such GetUpdates() request. ankushkush@google.com src/components/sync/OWNERS Records the syncable preference id when it is changed. This is recorded as soon as an OnPrefValueChanged notification is received. Note that this is only recorded for syncable preferences and has been introduced to investigate metric changes in crbug.com/418991364. This is different from Sync.SyncablePrefValueChanged in the sense that this one is recorded even before the pref sync data type has started. mastiz@chromium.org rushans@google.com Records different issues encountered when processing incremental bookmark updates from the sync server. rushans@google.com mastiz@chromium.org Records different issues encountered when processing remote bookmarks from the sync server during the initial merge procedure. mmoskvitin@google.com treib@chromium.org For every user event that is recorded, this histogram records the type of event (i.e. which of the "oneof event" entries in the UserEventSpecifics proto was set). rushans@google.com treib@chromium.org Recorded whenever the sync engine is restarted. The recorded value is the calling site of ResetEngine. Before 08/2024, the bucket "Upgrade client error" used to record other events too (any call to the old StopAndClear() API, removed in crbug.com/40797392). ankushkush@google.com mahmadi@chromium.org Recorded whenever search engines sync is being stopped, for example, upon signout and there exists an account-only search engine which is set as the default search engine. Such a search engine is copied to local storage. ankushkush@google.com mahmadi@chromium.org Recorded whenever a new keyword is added. This records whether the keyword has account data. If it does not, the local value is copied to the account. ankushkush@google.com mahmadi@chromium.org Records the count of new changes committed to the sync server for search engines upon every startup and/or initial sync and upon every incremental update, separately for each type of sync change (add, delete or update). ankushkush@google.com mahmadi@chromium.org Recorded upon every initial merge/startup if there exists a local search engine that is a duplicate of a remote search engine. Records whether the conflicting local search engine is the default search provider, which if so, ignores the account value. ankushkush@google.com mahmadi@chromium.org Upon every search engine update, records whether the update only updates the favicon url. If true, the update is not committed to the sync server. ankushkush@google.com mahmadi@chromium.org Recorded whenever search engines sync is being stopped, for example, upon signout. For each search engine with account data, records whether there exists local data. Note that this is not recorded upon browser shutdown. ankushkush@google.com mahmadi@chromium.org Upon every initial merge/startup while going over the existing data to build the sync data, if a local synced search engine is untouched and autogenerated, records whether it is a prepopulated search engine. This should always be false. ankushkush@google.com mahmadi@chromium.org Upon every initial merge/startup while going over the existing data to build the sync data, if a local synced search engine is untouched and autogenerated, records whether it is a starter pack entry. This should always be false. ankushkush@google.com mahmadi@chromium.org Records whether an untouched autogenerated search engine is received from the server, can be during both initial and incremental updates. ankushkush@google.com mahmadi@chromium.org Upon receiving an untouched autogenerated search engine from the sync the server, records whether it is a prepopulated search engine. This should always be false. ankushkush@google.com mahmadi@chromium.org Upon receiving an untouched autogenerated search engine from the sync the server, records whether it is a starter pack entry. This should always be false. ankushkush@google.com mahmadi@chromium.org If a new search engine is added/deleted/updated, records whether it is untouched and autogenerated. ankushkush@google.com mahmadi@chromium.org If an untouched and autogenerated search engine is added/deleted/updated, records whether it is a prepopulated search engine. ankushkush@google.com mahmadi@chromium.org If an untouched and autogenerated search engine is added/deleted/updated, records whether it is a starter pack entry. This should always be false. treib@chromium.org mastiz@chromium.org For users in transport mode (i.e. without Sync-the-feature enabled), this records which data types they have selected. Samples are taken every time the Sync data types are (re)configured, which typically happens during startup and when the user changes any Sync settings. See also "Sync.SyncEverything2" and "Sync.CustomSync3" which are the corresponding histograms for Sync-the-feature users. rushans@google.com treib@chromium.org Counts the number of commit results while committing sharing message. ankushkush@google.com src/components/sync/OWNERS Logs whether the user chooses to proceed with signout or not, after a warning dialog about unsynced data is shown. True means the user continued with sign out, False means the action was cancelled. Note: iOS only. mastiz@chromium.org treib@chromium.org src/components/sync/OWNERS Recorded on browser startup if the SyncEngine initialization is deferred by a fixed (configurable) delay due to performance reasons. In some cases, a data type may force sync to start before the delay finishes, causing the recorded time to be smaller. This histogram records the time spent after the SyncServiceImpl *creation* but before the SyncEngine initialization. ankushkush@google.com src/components/sync/OWNERS This is recorded everytime a remote incremental update is received for a syncable pref. This does not take into account whether the pref exists locally or if has the same value. treib@chromium.org src/components/sync/OWNERS This is recorded everytime a syncable pref of type {SyncDataType} is changed locally. This does not include changes sent during the initial sync/merge. ankushkush@google.com src/components/sync/OWNERS Records if the metadata was empty or invalid during startup, leading to a possible clearing of data in the syncable service, triggered by the SyncableServiceBasedBridge. This is recorded once per type upon profile load. This is to let the data types clear the sync data if needed to avoid leaking stale account data. ankushkush@google.com treib@chromium.org During browser startup, if sync is enabled and initial data exists, this records the time until a SyncableService is ready to process changes (both locally and coming from the server). The value is the duration from when SyncableServiceBasedBridge was initialized to the time when SyncableService has started (this comprises of loading all data from disk and MergeDataAndStartSyncing()). rgod@google.com ylahodiuk@google.com Records whenever user dismisses a sync error infobar displayed for a specific error. iOS only. Note: Recorded from M135. Keep in mind when comparing with Sync.SyncErrorInfobarDisplayed histogram that was introduced much earlier. rgod@google.com ylahodiuk@google.com jlebel@chromium.org chrome-signin-team@google.com Enumeration of error conditions that displays an infobar to the user triggered by a following event: {SyncErrorInfobarTrigger} iOS only. treib@chromium.org mastiz@chromium.org Boolean histogram for whether the "Sync Everything" option was selected by a Sync-the-feature user. Samples are taken every time the Sync data types are (re)configured, which typically happens during startup and when the user changes any Sync settings. mmoskvitin@google.com treib@chromium.org Analogous to Sync.SyncEverything2 for Chrome OS sync settings. Reflects whether the "Sync Everything" option was selected by the user for OS datatypes. Samples are taken every time the Sync data types are (re)configured, which typically happens during startup and when the user changes any Sync settings. ankushkush@chromium.org src/components/sync/OWNERS The decision whether to migrate the user from sync-setup-incomplete state to signed-in history-off state. This is recorded for all users upon profile load. rushans@google.com treib@chromium.org Counts of responses (both http code and net error code) for Sync stopped event URL fetches. Note that requests that timed out are not covered by this histogram; see Sync.SyncStoppedURLFetchTimedOut for that. rushans@google.com treib@chromium.org Whether a Sync stopped event URL fetch timed out or not. Note that this records true on timeout and false on success, but doesn't record anything if the fetch failed for any other reason. ankushkush@google.com src/components/sync/OWNERS Within the wider Sync-to-Signin migration, this records various steps in the Extensions-specific migration. The migration is requested by the central Sync-to-Signin migration on profile initialization, and happens at most once per browser session (and typically exactly once per profile). "Total count" and "Bucket proportion" are not really meaningful; instead compare the absolute sizes of the various buckets. ankushkush@google.com src/components/sync/OWNERS This records the type of Sync-to-Signin migration that a user underwent, either just now or in a previous browser run. This is recorded upon profile creation/startup for all users. treib@chromium.org mastiz@chromium.org src/components/sync/OWNERS Within the wider Sync-to-Signin migration, this records various steps in the ReadingList-specific migration. The migration is requested by the central Sync-to-Signin migration on profile initialization, and happens at most once per browser session (and typically exactly once per profile). "Total count" and "Bucket proportion" are not really meaningful; instead compare the absolute sizes of the various buckets. ankushkush@google.com src/components/sync/OWNERS Within the wider Sync-to-Signin migration, this records various steps in the Stats table cleanup process from the Account Password Store. The cleanup is requested by the central Sync-to-Signin migration on profile initialization, and happens at most once per browser session (and typically exactly once per profile). "Total count" and "Bucket proportion" are not really meaningful; instead compare the absolute sizes of the various buckets. ankushkush@google.com src/components/sync/OWNERS Within the wider Sync-to-Signin migration, this records various steps in the Themes-specific migration. The migration is requested by the central Sync-to-Signin migration on profile initialization, and happens at most once per browser session (and typically exactly once per profile). "Total count" and "Bucket proportion" are not really meaningful; instead compare the absolute sizes of the various buckets. treib@chromium.org mastiz@chromium.org src/components/sync/OWNERS The outcome of the decision whether the Sync-to-Signin migration should run or not (and why). Recorded on profile creation/startup, only on iOS. Note that the number of samples in the "Migrate" bucket can be compared to the total count of "Sync.SyncToSigninMigrationOutcome" to verify that all migrations that were started also finished. treib@chromium.org mastiz@chromium.org src/components/sync/OWNERS The outcome of the decision whether the Sync-to-Signin migration should run or not (and why) for {SyncDataTypeForSyncToSigninMigration}. Recorded on profile creation/startup, only on iOS, and when the overall decision was to {SyncToSigninMigrationMode} (see `Sync.SyncToSigninMigrationDecision`). ankushkush@google.com treib@chromium.org src/components/sync/OWNERS Records the execution mode (Synchronous vs Asynchronous) of the Sync-to-Signin migration. Recorded upon profile creation/startup iff the migration is happening. treib@chromium.org mastiz@chromium.org src/components/sync/OWNERS The outcome of the overall Sync-to-Signin migration, recorded when the migration finishes. Note that the total count of this histogram can be compared to the number of samples in the "Migrate" bucket of "Sync.SyncToSigninMigrationDecision" to verify that all migrations that were started also finished. treib@chromium.org mastiz@chromium.org src/components/sync/OWNERS The outcome of moving the bookmarks JSON file from the local to the account location, during the Sync-to-Signin migration. Recorded only if the overall migration ran and decided to migrate bookmarks (see Sync.SyncToSigninMigrationDecision.Migration.BOOKMARK). treib@chromium.org mastiz@chromium.org plcoirier@chromium.org src/components/sync/OWNERS The outcome of moving the encrypted bookmarks JSON file from the local to the account location, during the Sync-to-Signin migration. Recorded only if the overall migration ran and decided to migrate bookmarks (see Sync.SyncToSigninMigrationDecision.Migration.BOOKMARK) and the Bookmarks encryption feature is enabled. ankushkush@google.com src/components/sync/OWNERS The number of extensions that were deduplicated during the Sync-to-Signin migration. An extension is deduplicated iff the extension exists locally and on account. Recorded only if the overall migration ran and decided to migrate extensions (see Sync.SyncToSigninMigrationDecision.Migration.EXTENSION). treib@chromium.org mastiz@chromium.org src/components/sync/OWNERS The outcome of moving the passwords DB file from the local to the account location, during the Sync-to-Signin migration. Recorded only if the overall migration ran and decided to migrate passwords (see Sync.SyncToSigninMigrationDecision.Migration.PASSWORD). ankushkush@google.com src/components/sync/OWNERS Records the outcome of the theme deduplication during the Sync-to-Signin migration. Theme is deduplicated iff the same theme exists locally and on account. Recorded only if the overall migration ran and decided to migrate themes (see Sync.SyncToSigninMigrationDecision.Migration.THEME). treib@chromium.org mastiz@chromium.org src/components/sync/OWNERS The time taken for the Sync-to-Signin migration. Recorded on profile creation/startup, only if the migration actually ran. Note that the total count of this histogram can be compared to the number of samples in the "Migrate" bucket of "Sync.SyncToSigninMigrationDecision" to verify that all migrations that were started also finished. treib@chromium.org src/components/sync/OWNERS Records the number of synced devices shown when the TabsFromOtherDevices side panel ({Version}) is opened. Recorded once when the side panel is opened and data is loaded. treib@chromium.org src/components/sync/OWNERS Records events for the TabsFromOtherDevices side panel ({Version}). Recorded when the side panel is created, opened, closed, or a tab is opened from it. treib@chromium.org src/components/sync/OWNERS Records the 0-based index of the device from which a tab is opened in the TabsFromOtherDevices side panel ({Version}). Recorded when a tab is opened. treib@chromium.org src/components/sync/OWNERS Records the index (by recency, i.e., visual order in the side panel) of the tab that was opened within its session/device in the TabsFromOtherDevices side panel ({Version}). Recorded when a tab is opened. treib@chromium.org src/components/sync/OWNERS Records the number of tabs on the initially active/selected device shown when the TabsFromOtherDevices side panel ({Version}) is opened. Recorded once when the side panel is opened and data is loaded. treib@chromium.org src/components/sync/OWNERS Records the total number of synced tabs across all devices shown when the TabsFromOtherDevices side panel ({Version}) is opened. Recorded once when the side panel is opened and data is loaded. treib@chromium.org src/components/sync/OWNERS Records the total time spent with the TabsFromOtherDevices side panel ({Version}) open. Recorded when the side panel is closed or hidden. treib@chromium.org src/components/sync/OWNERS Records the time between opening the TabsFromOtherDevices side panel ({Version}) and opening the first tab from it. Recorded when the first tab is opened. treib@chromium.org src/components/sync/OWNERS Logged when the server instructs the client to throttle all its data types. See also Sync.ThrottledSomeDataTypes which records a different event. This histogram can help explain changes in Sync.PostedClientToServerMessageError2::THROTTLED. treib@chromium.org src/components/sync/OWNERS Logged when the sync server instructs this client to throttle a special list of data types. See also Sync.ThrottledAllDataTypes which records a different event. This histogram can help explain changes in Sync.PostedClientToServerMessageError2::THROTTLED. mtatarski@google.com chrome-sync-dev@chromium.org Recorded whenever SyncService::TriggerRefresh() is called, records the call site/reason why it's called. This method forces a download of latest updates from the server. This histogram helps to track existing and new use cases and have an alert in case there are too many usages of it leading to additional traffic to the server. mmoskvitin@google.com mastiz@chromium.org Records whether attempt of adding trusted vault keys was successful (i.e. whether pending keys state resolved). thomasth@google.com src/components/sync/OWNERS Emitted when a key retrieval flow, initiated by a user action, successfully results in new keys being added to the sync engine. The histogram is enumerated by the UI surface that triggered the retrieval attempt. mmoskvitin@google.com mastiz@chromium.org Records whether user action was required to fetch trusted vault keys upon first sync (i.e. after signin). Recorded only if trusted vault passphrase type is used and at least one encrypted data type is enabled. Recorded at most once per browser/profile lifetime. Note: Before M124, this metric only included Sync-the-feature users. This should mostly make a difference on iOS. mmoskvitin@google.com mastiz@chromium.org Records whether user action was required to fetch trusted vault keys upon startup. Recorded only if trusted vault passphrase type is used and at least one encrypted data type is enabled. Recorded at most once per browser/profile lifetime. {TrustedVaultTimeSinceMigrationSuffix} Note: Before M124, this metric only included Sync-the-feature users. This should mostly make a difference on iOS. mmoskvitin@google.com mastiz@chromium.org Records number of trusted vault keys fetched upon fetching completion. mmoskvitin@google.com mastiz@chromium.org Records whether invocations to the Javascript API chrome.addTrustedSyncEncryptionRecoveryMethod(), when received via Mojo in the browser process, corresponds to an incognito profile. mmoskvitin@google.com mastiz@chromium.org Records whether invocations to the Javascript API chrome.addTrustedSyncEncryptionRecoveryMethod() completed successfully. Instrumented on Android only. mmoskvitin@google.com mastiz@chromium.org Records whether invocations to the Javascript API chrome.addTrustedSyncEncryptionRecoveryMethod() specify a user ID that is known by IdentityManager. Instrumented on Android only. mmoskvitin@google.com mastiz@chromium.org Records invocations to the Javascript API chrome.addTrustedSyncEncryptionRecoveryMethod() and whether the passed arguments could be successfully parsed (which doesn't imply the function actually succeeded). mmoskvitin@google.com mastiz@chromium.org Records whether invocations to the Javascript API chrome.setSyncEncryptionKeys(), when received via Mojo in the browser process, corresponds to an incognito profile. mmoskvitin@google.com mastiz@chromium.org Records invocations to the Javascript API chrome.setSyncEncryptionKeys() and whether the passed arguments could be successfully parsed (which doesn't imply the function actually succeeded). mmoskvitin@google.com mastiz@chromium.org Recorded when user clicks/taps on trusted vault error button for the keys-missing error state. Buckets represents the UI elements which contain trusted vault error button. mmoskvitin@google.com mastiz@chromium.org Recorded when user clicks/taps on trusted vault error button for the recoverability-degraded error state. Buckets represents the UI elements which contain trusted vault error button. mmoskvitin@google.com mastiz@chromium.org Records whether user action was required to improve the recoverability of trusted vault keys. Recorded only if trusted vault passphrase type is used, when keys are locally available and at most once per browser/profile lifetime. {TrustedVaultTimeSinceMigrationSuffix} ankushkush@google.com src/components/sync/OWNERS Records the unsynced data types, when the user switches from one account to another within the same profile, but some data has not been synced yet. Only PASSWORDS, BOOKMARKS, READING_LIST and CONTACT_INFO are considered. This metric is only recorded when kSeparateProfilesForManagedAccounts feature is enabled. Note: iOS only. ankushkush@google.com src/components/sync/OWNERS Records the unsynced data types, when the user switches from one account to another with two different profiles, but some data has not been synced yet. Only PASSWORDS, BOOKMARKS, READING_LIST and CONTACT_INFO are considered. Note: iOS only. ankushkush@google.com src/components/sync/OWNERS Records the unsynced data types, when the user clicks on sign out but some data has not been synced yet. Only PASSWORDS, BOOKMARKS, READING_LIST and CONTACT_INFO are considered. Note: iOS only. rushans@google.com src/components/sync/OWNERS Records whether the access token is valid before a Sync URL fetch is attempted (no URL fetch is made if the access token is invalid). When kSyncValidateAccessToken is enabled, the token expiry is also verified. mastiz@chromium.org treib@chromium.org Counts of responses (both http code and net error code) for Sync URL fetches. Note that requests that timed out are not covered by this histogram; see Sync.URLFetchTimedOut for that. mastiz@chromium.org treib@chromium.org rushans@google.com Whether a URL fetch timed out or not. Timing out implies the fetch was stalled for an unknown reason. Note that this records true on timeout and false on success, but doesn't record anything if the fetch failed for any other reason. mmrashad@google.com chrome-signin-team@google.com Recorded once for each new UserActionableError state the user encounter per browser startup. Records which error state that prevent Sync from working well or working at all. ankushkush@google.com src/components/sync/OWNERS Recorded whenever the batch upload dialog queries the local theme data. This is true iff there exists a local theme, and false otherwise. ankushkush@google.com src/components/sync/OWNERS Recorded whenever the batch upload dialog triggers the local theme migration. Only the true value is recorded. ankushkush@google.com src/components/sync/OWNERS Recorded whenever themes sync is being stopped, for example, upon signout. This is true iff a saved local theme existed. A false value would imply that no local theme data existed which can happen if a batch upload was triggered previously. ankushkush@google.com src/components/sync/OWNERS Records whether the theme prefs have already been migrated from the syncing version to the non-syncing replacement. Recorded once per browser startup. ankushkush@google.com src/components/sync/OWNERS Records the incoming syncing theme pref. Recorded once upon browser startup when remote theme prefs are received from the server, iff they have been never read before. The count of the metric should ultimately reach zero. ankushkush@google.com src/components/sync/OWNERS Records the theme pref migrated from the syncing version to the non-syncing replacement. Recorded once per browser startup during pref migration iff the theme pref has not already been migrated.