Problem

Coder currently collects template insights data (IDE usage per user, user activity hours, etc.) without ability to disable or anonymize collection. This is a compliance hurdle for some customers as these metrics constitute personalized workplace monitoring.

Business impact: See Slack

Proposed Solution

Option 1: Disable collection

Add deployment flag to completely disable template insights collection:

coder server --disable-template-insights

Behavior:

• No template insights data collected or stored
• Template insights UI shows "feature disabled" message
• Existing data persists but isn't updated
• Prometheus metrics continue to work

Option 2: Anonymize collection (slightly preferred by current customer)

Add deployment flag to anonymize user-identifiable data:

coder server --anonymize-template-insights

Behavior:

• User identifiers hashed/pseudonymized before storage
• Aggregate metrics still available (total hours, IDE distribution)
• Individual user tracking prevented
• Template-level insights remain without user attribution

Customer feedback: Anonymization achieves compliance while preserving data value

Scope

Data affected:

• IDE usage per user
• User activity hours
• Developer usage/hourly metrics
• Other user-attributable activity metrics

Data NOT affected:

• Template parameters (separate database storage)
• Prometheus metrics
• Audit logs

Implementation Requirements

Configuration:

• Follow existing flag pattern (similar to --disable-owner-workspace-access)
• Support CLI arg, env var, and config file
• Default: false (collection enabled for backward compatibility)

UI/UX:

• Show appropriate messaging when feature disabled
• Indicate privacy mode when anonymized

Questions

1. Which option (disable vs anonymize) is simpler to implement?
2. Should we implement both or just one initially?
3. What happens to existing insights data when flag is enabled?