Summary
We have no reliable way to measure how many users have auto-install of desktop updates (autoInstallUpdates) enabled vs disabled. The setting's current state is not emitted as a person property or on any session/boot event, so it cannot be queried directly in PostHog. We should track it definitively.
Why it's currently un-measurable
- The
autoInstallUpdates toggle is a Global Settings field. Toggling it routes through comfy-titlepopup:global-settings-update-field → applySettingSet() in src/main/lib/ipc/registerSettingsHandlers.ts, which runs side-effects and broadcasts the settings-changed IPC but emits no PostHog event.
- The
comfy.desktop.settings.changed telemetry event is only emitted from the per-ComfyUI-instance settings panel (src/renderer/src/lib/.../useComfyUISettings.ts → emitTelemetryAction('comfy.desktop.settings.changed', { setting_key, value_kind, bool_value })). It never fires for the desktop auto-update toggle. As a result, a query filtering setting_key = 'autoInstallUpdates' returns nothing.
- The cohort person-properties registered at boot in
src/renderer/src/lib/rendererBootstrap.ts (registerCohortContext) include app_version, app_channel, local_installation_count, has_launched_cloud, etc. — but not the auto-update setting.
- Net result: there is no person property and no session event that reports the current
autoInstallUpdates state. Adoption of the setting is invisible.
What exists today (partial / behavioral only)
The only related signals are emitted from src/main/lib/updater.ts and reflect isAutoInstallEnabled() at the moment an update is detected/triggered, not the general population:
comfy.desktop.app_update.available → auto_update_setting: 'on' | 'off'comfy.desktop.app_update.install_triggered → auto_update_setting: 'on' | 'off'
These only cover users who actually received an update-available / triggered an install in the window, so they undercount and are biased toward out-of-date users. They are not a substitute for a population-wide state.
Proposed fix
Register the current setting as a PostHog person property at boot (and re-register on change) so adoption is queryable across the whole base:
- Add
auto_install_updates: settings.get('autoInstallUpdates') !== false (and likely install_updates_on_startup) to the cohort registered in registerCohortContext (rendererBootstrap.ts), via registerTelemetryProperties → person $set.
- Re-emit the person property when the setting changes — hook
applySettingSet() / updater.notifyAutoUpdateChanged() in registerSettingsHandlers.ts so the value stays current without waiting for the next boot.
Once shipped, the on/off split is a trivial argMax(person.properties.auto_install_updates, timestamp) per person_id.
Acceptance criteria
Notes
Default is on (autoInstallUpdates !== false; auto-checks/installs enabled unless opted out), so until this lands the practical proxy is "users whose latest app_update.available.auto_update_setting is off" = explicit opt-outs.
Summary
We have no reliable way to measure how many users have auto-install of desktop updates (
autoInstallUpdates) enabled vs disabled. The setting's current state is not emitted as a person property or on any session/boot event, so it cannot be queried directly in PostHog. We should track it definitively.Why it's currently un-measurable
autoInstallUpdatestoggle is a Global Settings field. Toggling it routes throughcomfy-titlepopup:global-settings-update-field→applySettingSet()insrc/main/lib/ipc/registerSettingsHandlers.ts, which runs side-effects and broadcasts thesettings-changedIPC but emits no PostHog event.comfy.desktop.settings.changedtelemetry event is only emitted from the per-ComfyUI-instance settings panel (src/renderer/src/lib/.../useComfyUISettings.ts→emitTelemetryAction('comfy.desktop.settings.changed', { setting_key, value_kind, bool_value })). It never fires for the desktop auto-update toggle. As a result, a query filteringsetting_key = 'autoInstallUpdates'returns nothing.src/renderer/src/lib/rendererBootstrap.ts(registerCohortContext) includeapp_version,app_channel,local_installation_count,has_launched_cloud, etc. — but not the auto-update setting.autoInstallUpdatesstate. Adoption of the setting is invisible.What exists today (partial / behavioral only)
The only related signals are emitted from
src/main/lib/updater.tsand reflectisAutoInstallEnabled()at the moment an update is detected/triggered, not the general population:comfy.desktop.app_update.available→auto_update_setting: 'on' | 'off'comfy.desktop.app_update.install_triggered→auto_update_setting: 'on' | 'off'These only cover users who actually received an update-available / triggered an install in the window, so they undercount and are biased toward out-of-date users. They are not a substitute for a population-wide state.
Proposed fix
Register the current setting as a PostHog person property at boot (and re-register on change) so adoption is queryable across the whole base:
auto_install_updates: settings.get('autoInstallUpdates') !== false(and likelyinstall_updates_on_startup) to the cohort registered inregisterCohortContext(rendererBootstrap.ts), viaregisterTelemetryProperties→ person$set.applySettingSet()/updater.notifyAutoUpdateChanged()inregisterSettingsHandlers.tsso the value stays current without waiting for the next boot.Once shipped, the on/off split is a trivial
argMax(person.properties.auto_install_updates, timestamp)perperson_id.Acceptance criteria
auto_install_updates(andinstall_updates_on_startup) are present as person properties on PostHog for v-next clients.Notes
Default is on (
autoInstallUpdates !== false; auto-checks/installs enabled unless opted out), so until this lands the practical proxy is "users whose latestapp_update.available.auto_update_settingisoff" = explicit opt-outs.