New issue
Advanced search Search tips

Issue 643647 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Aug 2
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Track per-user actives in HKLM...ClientStateMedium for system-level installs

Project Member Reported by grt@chromium.org, Sep 2 2016

Issue description

Use the same aggregation strategy as is used for _NumAccounts and _NumSignedIn. Perhaps _DidRun=1 when setting the value, and _DidRun=0 when clearing it. For user-level installs, write _DidRun into ClientState alongside dr.

Initially, make this addition without removing the old code so that we can compare the two. Eventually delete the old method.

Ganesh: please let me know if there are any special considerations, or if this doesn't quite capture your request. Thanks.
 

Comment 1 by grt@chromium.org, Sep 5 2016

Does Google Update need to clear _DidRun after it reads it (a la ApplicationUsageData::ResetDidRun)?

Comment 2 by grt@chromium.org, Sep 5 2016

Status: Started (was: Assigned)
I checked the code, and currently, App Defined Attributes are not reset a la ApplicationUsageData::ResetDidRun. I presume this would be a problem?
Project Member

Comment 4 by bugdroid1@chromium.org, Sep 6 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f7c30a5abe40796ca0972f541324c6a117d3ca64

commit f7c30a5abe40796ca0972f541324c6a117d3ca64
Author: grt <grt@chromium.org>
Date: Tue Sep 06 20:52:22 2016

Generalized the storage strategy used by UpdateProfileCounts.

This simplifies adding new such stats.

BUG= 643647 
TEST=covered by GoogleUpdateSettingsTest.UpdateProfileCounts*

Review-Url: https://codereview.chromium.org/2308423002
Cr-Commit-Position: refs/heads/master@{#416724}

[modify] https://crrev.com/f7c30a5abe40796ca0972f541324c6a117d3ca64/chrome/installer/util/google_update_settings.cc

Comment 5 by grt@chromium.org, Jun 29 2018

Cc: mpear...@chromium.org
Owner: f...@chromium.org
Status: Assigned (was: Started)
Summary: Track per-user actives in HKLM...ClientStateMedium for system-level installs (was: Move "dr" storage from HKCU...ClientState into HKLM...ClientStateMedium for system-level installs)
felt@ + mpearson@: we discussed a while back whether we should add a new metric to count users in addition to our current strategy of counting only installs. Have either of you thought about this at all since then?

Please either re-assign this back to me (if we should move forward) or mark it as WontFix (if we don't need a per-user active count). Thanks.
Help me page this back in my memory.  How far ago was "a while back", and what do you (did we) mean as "users": profiles, operating system users, or GAIA based on Chrome signed-in status?

Cc: -mpear...@chromium.org
Owner: mpear...@chromium.org
Cc: mpear...@chromium.org
Owner: grt@chromium.org
Assigning back to grt@ for clarification; removing from my queue.
We talked it over at the analysis meeting this week and decided we don't feel a great need to know number Chrome users on machines with system level installs.

In brief, the justification is that both ways of counting ("installs" versus "OS-level users") come with caveats.  We not convinced that switching would make any of the metrics we look at any cleaner or make them easier to understand, so we're fine with sticking with what we already have.
Status: WontFix (was: Assigned)
SGTM. Thanks for discussing and getting back to me.

Sign in to add a comment