Skip to main content

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

  1. Prioritise features - If most users use CycloneDX, we focus on CycloneDX improvements
  2. Fix real issues - Error tracking shows us what actually breaks in production
  3. Optimise performance - Understanding typical scan sises helps us optimise the right code paths
  4. Validate changes - After a release, we can see if error rates decrease
  5. 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)
We only collect:
  • 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 emits started 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 failed
  • timeout - Request timed out
  • ssl_error - SSL/TLS error
  • not_found - 404 response
  • rate_limited - 429 response
  • auth_error - 401/403 response
  • server_error - 5xx response
  • http_error - Other HTTP error
  • missing_dependency - Required library not installed
  • parse_error - JSON/response parsing failed
  • unknown - 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 name
  • error_category: Classified category
  • context: Command context
Note: Error messages and stack traces are never sent.

Implementation

Telemetry is implemented in packages/ai-finder/src/ai_finder_cli/telemetry.py. Key design decisions:
  1. Fail-closed: If the config file is unreadable or the telemetry library fails to initialise, telemetry is disabled.
  2. Lasy initialisation: The telemetry client is only created on first use, after checking all opt-out mechanisms.
  3. Graceful shutdown: Events are flushed on CLI exit via atexit.
  4. 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

Questions?

If you have questions about telemetry or privacy, please open an issue at https://github.com/scanoss/ai-finder/issues.