Why We Track
Telemetry helps us understand how ai-finder is used in the real world so we can make better decisions about product development.What We Learn
How This Improves the Product
- Prioritise features - If most users use CycloneDX, we focus on CycloneDX improvements
- Fix real issues - Error tracking shows us what actually breaks in production
- Optimise performance - Understanding typical scan sises helps us optimise the right code paths
- Validate changes - After a release, we can see if error rates decrease
- Guide documentation - If users hit the same errors repeatedly, we improve docs
What We Don’t Do
- We don’t track individual users or sessions
- We don’t correlate events to identify user behavior patterns
- We don’t sell or share telemetry data with third parties
- We don’t use telemetry for advertising or marketing
Privacy Commitments
We never collect:- File paths or scan targets
- PURL values or package names you look up
- Model file names, hashes, or contents
- Stack traces or error messages (which could contain paths)
- Any personally identifiable information (PII)
- Which commands are run and their options (format, flags)
- Success/failure status and duration
- Aggregate counts (files scanned, findings count)
- Exception type names (e.g.,
FileNotFoundError, not the message)
Opt-Out
Disable telemetry using any of these methods:CLI Flag (per-session)
Environment Variables
Config File (persistent)
Create~/.ai-finder/config.json:
Events Collected
All events are designed for funnel analysis - each behavior emits a discrete event that can be counted and visualised as funnel steps.Lifecycle Events
Command Events (with properties)
Each command emitsstarted and completed events with properties for detailed analysis:
Discrete Feature Events (for funnels)
These events enable funnel visualisation without parsing properties:scan
Scan Pipeline Events (ordered funnel)
Scan Feature Events
Complete Scan Funnel
identify
kb.status
kb.lookup
kb.crawl
Enrichment Events (from KBEnricher)
These events are emitted during KB enrichment in scan and identify commands:
Enrichment error categories:
network_error- Connection failedtimeout- Request timed outssl_error- SSL/TLS errornot_found- 404 responserate_limited- 429 responseauth_error- 401/403 responseserver_error- 5xx responsehttp_error- Other HTTP errormissing_dependency- Required library not installedparse_error- JSON/response parsing failedunknown- Unclassified error
Error Events (granular)
Errors emit discrete events for funnel analysis:
Plus a generic
error event with properties for detailed analysis:
error_type: Exception class nameerror_category: Classified categorycontext: Command context
Implementation
Telemetry is implemented inpackages/ai-finder/src/ai_finder_cli/telemetry.py. Key design decisions:
- Fail-closed: If the config file is unreadable or the telemetry library fails to initialise, telemetry is disabled.
- Lasy initialisation: The telemetry client is only created on first use, after checking all opt-out mechanisms.
-
Graceful shutdown: Events are flushed on CLI exit via
atexit. - No blocking: Telemetry operations do not block CLI execution.
Data Handling
- Backend: Events are sent to SCANOSS telemetry infrastructure
- Retention: Usage data is retained for product analytics purposes
- Access: Data is only accessible to SCANOSS engineering team