android-analytics-logginglisted

# Android Analytics, Logging, and Observability ## Core Principles - Instrument intent, not noise. - Logs are for debugging and operations; analytics are for product understanding. - Never leak secrets, tokens, raw personal data, or sensitive payloads. - Centralize telemetry contracts so naming stays consistent. - Track user-relevant flows and operationally important failures. --- ## Separate the Concerns | Concern | Purpose | |---|---| | Logging | developer/debug/operator visibility | | Analytics | product usage and funnel understanding | | Crash reporting | fatal and non-fatal failure monitoring | | Metrics | rates, latency, counts, health signals | Do not use one tool to imitate all four concerns. --- ## Event Design Analytics events should be: - stable - human-readable - intentionally named - low-cardinality where possible Good examples: - `note_created` - `login_succeeded` - `paywall_shown` - `sync_failed` Bad examples: - `button_clicked` - `screen_event_7` - raw dynamic strings as event names Prefer fixed event names with structured properties. --- ## Event Properties Good properties are small, explicit, and analysis-friendly: ```kotlin data class AnalyticsEvent( val name: String, val properties: Map<String, String> ) ``` Good property examples: - `source = settings` - `result = success` - `permission = camera` - `network_state = offline` Avoid: - full user-entered text - access tokens - email addresses unless policy explicitly allows and requi