What is self-hosted event tracking?
A complete system needs more than a database. It needs client or server SDKs, an authenticated receiving endpoint, event validation, identity rules, durable storage, query models, dashboards, access control, retention policies, monitoring, and a recovery plan. SensorFlow implements one opinionated route: Sensors Data SDKs → Go ingestion service → ClickHouse → Apache Superset.
What components do you need?
| Layer | Responsibility | SensorFlow choice | Operational risk |
|---|---|---|---|
| Instrumentation | Capture named events, identities, properties, and timestamps | Official Sensors Data SDKs | Schema drift and inconsistent identity |
| Ingestion | Accept, validate, decode, limit, and report failures | Go collector | Loss or duplication during retries |
| Storage | Retain raw events and support analytical scans | ClickHouse | Partitioning, capacity, backups |
| Analysis | Define metrics and inspect raw data | ClickHouse SQL | Metric definitions can diverge |
| Presentation | Explore data and publish dashboards | Apache Superset | Permissions and dashboard maintenance |
When does self-hosting make sense?
Choose it when control is a requirement
Self-hosting is rational when event-level data must remain in a specific environment, analysts need direct SQL access, infrastructure teams already operate ClickHouse, or an existing SDK deployment makes changing the receiving boundary cheaper than replacing every client integration.
Avoid it when the team wants a turnkey product
Do not self-host merely because source code is available. A hosted service may be better when the team lacks database operations capacity, needs vendor support and service guarantees, or expects built-in session replay, feature flags, experimentation, surveys, and polished no-code workflows.
How should you validate an event pipeline?
- Send a uniquely named test event with a known user ID and timestamp.
- Check the HTTP response and collector logs; a successful response alone does not prove persistence.
- Query the raw ClickHouse row and verify identity, property types, event time, and receive time.
- Run the same SQL through the BI connection and confirm the dashboard result.
- Test malformed payloads, retries, delayed events, duplicates, and a restore from backup before production.
SELECT event, count() AS events,
uniqExact(distinct_id) AS users
FROM sensors.event
WHERE time >= now() - INTERVAL 7 DAY
GROUP BY event
ORDER BY events DESC;How does SensorFlow compare with broader platforms?
SensorFlow is intentionally narrower than a full product engineering suite. It focuses on a visible event path, ClickHouse storage, SQL, and Superset dashboards. PostHog offers a wider integrated surface including product analytics, session replay, feature flags, experiments, and surveys. Matomo is often a stronger fit for website traffic, acquisition, and privacy-oriented web analytics. The right choice depends on the workflow, not a universal ranking.
Frequently asked questions
Does self-hosted mean no data leaves my network?
Only if every dependency is configured that way. Review SDK endpoints, error reporting, CDN assets, authentication, backups, alerting, and BI integrations. Self-hosted describes deployment control; it is not by itself a compliance guarantee.
Does ClickHouse replace an analytics product?
No. ClickHouse is the analytical database. Teams still need collection, identity rules, data quality checks, metric definitions, permissions, dashboards, and operational processes.
What is the smallest safe migration?
Start with one test application and a small event set. Verify the collector, raw database row, and BI query before using dual write or a limited traffic cohort. Keep the old path until a representative business cycle has been checked.