DEV Community: SensorFlow

Design Events That Answer Product Questions: A Practical Tracking Plan

SensorFlow — Thu, 01 Oct 2026 06:43:59 +0000

When someone asks why signup conversion dropped, a generic button_click event rarely answers the question. The team needs to agree on where the journey starts, what counts as completion, how users are counted, and how failures and retries are represented.

An event tracking plan records those agreements before instrumentation. It connects a business question to event names, trigger conditions, identity rules, properties and acceptance tests. A working collector cannot resolve a disagreement about what an event means.

This guide uses a fictional SaaS signup flow. The examples are teaching fixtures, not customer results. I work on SensorFlow, a self-hosted event analytics project; the design method below applies independently of the analytics tool you choose. AI assisted the preparation of this article, and its references and product claims were checked before publication.

Start with a question you can calculate

Instead of asking for "signup conversion," write a more precise question:

Of the distinct visitors who opened the signup page during a calendar day in our reporting timezone, how many completed account creation within 24 hours of their first qualifying page visit?

This defines the starting population, completion condition, identity unit, reporting timezone and conversion window. You still need to define how an anonymous visitor maps to an account, and whether repeated visits restart the window. Those decisions belong in the metric definition.

Amplitude's event selection guide works back from the questions a product team wants to answer. Capturing more interactions does not automatically produce a better measurement plan. Autocapture can help explore interface behavior, but a click or form submission is not proof that an account was created. PostHog documents automatic capture and custom events separately; custom business events let you express the outcome your system can actually confirm.

Define a small event contract

For each event, write down the following fields. The table describes a suggested contract, rather than a required schema for any vendor.

Field	Question to resolve	Signup example
Event name	What action or state occurred?	`signup_submitted`, `account_created`
Trigger	At what exact point is it emitted?	Emit `account_created` after the account transaction commits
Source	Which component owns that state?	Browser for intent; backend for confirmed creation
Identity	Which stable identifier is used?	Anonymous visitor before signup; account ID after creation
Time	When did it occur, and which timezone does the report use?	Preserve occurrence time and define the reporting timezone
Required properties	Which dimensions are essential?	`signup_method`, `app_version`
Optional properties	How is missing context represented?	Missing `campaign_id` is unknown, not silently "direct"
Retry rule	Can one operation produce multiple events?	Reuse a stable operation ID and define deduplication
Owner and version	Who approves a changed meaning?	Product and engineering owners, plus a contract version

Snowplow's tracking design documentation combines event purpose, trigger conditions and data structures in event specifications. Amplitude's tracking plan documentation also records sources, descriptions and property rules. Both are useful references when turning a short product request into something an engineer can implement and a tester can verify.

Keep names stable and put context in properties

Avoid separate event names such as signup_from_ad and signup_from_email when the action is the same. A stable signup_submitted event with a signup_source property is easier to extend when another channel appears. Segment's tracking plan guidance similarly advises against dynamic event names and property keys.

Choose a naming convention and apply it consistently. Title Case or snake_case can both work; the problem is a team alternating between them without a defined mapping. Give each property a type, allowed values, and a rule for missing data. Keep email addresses, phone numbers and full form contents out of a generic analytics payload unless a separately reviewed use case requires them.

Do not merge intent and outcome just to reduce the event count. signup_submitted means a user tried. account_created means the business state changed. If both become a vague signup, a validation error can look like a successful conversion.

Some tools provide recommended events, such as those described in Google Analytics' event guide. Define your own business meaning first, then map it to each destination. Similar event names do not guarantee equivalent semantics across tools.

Instrument at the agreed trigger

For a project already using the official Sensors Data JavaScript SDK, a custom intent event could have this shape after SDK initialization:

// Record the attempt. This is not proof of account creation.
sensors.track('signup_submitted', {
  signup_method: 'email',
  signup_source: 'website',
  contract_version: '1',
});

This is an instrumentation fragment, not a standalone application or a live ingestion test. Initialize the SDK, identity handling and destination for your own environment; SensorFlow's SDK integration guide provides project-specific setup references. Consult the official documentation for your exact SDK version.

Let the component that can confirm the final business state own the success event. An HTTP 200 response might only mean a request was accepted. If the browser and backend both emit account_created, define how they are reconciled, and where a stable operation ID is generated. A property called operation_id does not create deduplication by itself: the receiving and analytical layers must use it according to the contract.

Test the contract, then test the metric

Prepare a small set of non-sensitive fixtures with expected event sequences:

An anonymous visitor opens the signup page and leaves. Expect the start event and no creation event.
Form validation fails. Specify whether signup_submitted means every submit attempt or only a valid request; expect no creation event in either case.
An account is created. Expect one confirmed creation with the correct property types.
A network failure causes a retry. Check how the same operation is counted, not just how many requests were sent.
A visitor signs in or continues on another device. Verify the documented anonymous-to-account mapping instead of assuming two tools merge identities identically.

Check raw records against the contract first. Then recalculate the metric using the same identity, timezone, window and retry rules as the report. Receiving an event and calculating an interpretable conversion rate are separate acceptance criteria.

Keep expected and actual results with the release record. Those fixtures become regression tests when the SDK, application workflow or analytics destination changes.

Choose an analytics system against the contract

An open-source or self-hosted analytics system should be evaluated against the events and questions your team needs. Check whether it receives your existing instrumentation, exposes raw records, explains identity and time behavior, and provides the analyses your users need. Also account for the deployment, access control, monitoring and upgrade work your team will own.

SensorFlow is one option for teams retaining an existing Sensors Data SDK while controlling the event data pipeline. The open-source repository supports deployment and demonstration data; real SDK ingestion requires license activation. It is a focused self-hosted path rather than a feature-equivalent replacement for a mature all-in-one analytics suite, and it has no official affiliation with Sensors Data.

Start by writing one event contract and checking these five fixtures. Once the team can explain the result by hand, it has a concrete basis for selecting an analytics system and reviewing its reports.

Your Demo Dashboard Is Not a Funnel: Auditing Synthetic Events in ClickHouse

SensorFlow — Thu, 01 Oct 2026 04:49:25 +0000

A newly installed analytics stack can show a convincing sequence of "app open → product view → add to cart → purchase" before it has ingested a single real user event. That is useful for testing whether the database and dashboard start, but it is not evidence of conversion. Four non-empty bars may represent four disjoint groups of users.

This is a practical audit of SensorFlow's public demo-data generator. SensorFlow is an independent, open-source, self-hosted event pipeline built around an existing Sensors Data SDK integration, a Go receiver, ClickHouse, and Apache Superset. It does not claim to replace every feature of a full product-analytics suite. Its installation deliberately shows synthetic data first; live SDK ingestion requires a separate license activation. That boundary makes the demo a useful example of why a chart needs a data-contract check.

Does a four-stage dashboard prove a conversion funnel?

No. Stage counts answer "did these event names occur?" A user funnel answers "did the same identified user perform these events in the required order, within the chosen time window?" Counts, distinct-user counts, user overlap, and ordered conversion are four different measures.

For a real funnel, define the identity key, the start and end events, a time window, timezone, duplicate handling, and whether anonymous and logged-in IDs are merged. Without those decisions, a percentage can look precise while measuring the wrong thing.

Inspect the generator before interpreting the chart

The current demo SQL inserts rows from numbers(240). It selects the event name with number % 12, and the demo user with number % 48. Because 48 is divisible by 12, each demo-user-* stays in one event category throughout this generated batch. A demo user is not walking through four stages.

The script also spaces event timestamps three hours apart and assigns sample revenue to purchase rows. Its is_first_day value is part of the synthetic generator, not a production calculation after identity stitching. These fields are good for rendering example charts, not for validating business conversion or GMV.

The underlying ClickHouse table is sensors.event, with time, event, distinct_id, and app_id. The demo rows are marked app_id = 'sensorflow-demo'. If you have installed the bundled demo, first compare event rows with distinct users:

SELECT
    event,
    count() AS event_rows,
    uniqExact(distinct_id) AS users
FROM sensors.event
WHERE app_id = 'sensorflow-demo'
GROUP BY event
ORDER BY event;

On a fresh import of one batch from the current generator, this returns 100 app-open rows from 20 IDs, 80 product-view rows from 16 IDs, 40 add-to-cart rows from 8 IDs, and 20 purchase rows from 4 IDs. Those numbers come from the generator, not from measured customer behavior. Existing installations or changed scripts may produce different results.

Test whether the viewers and buyers are even the same people

Before reporting 4 / 16 = 25% as a conversion rate, ask whether a single distinct_id appears in both groups:

WITH per_user AS
(
    SELECT
        distinct_id,
        countIf(event = 'demo_product_view') > 0 AS viewed,
        countIf(event = 'demo_purchase') > 0 AS purchased
    FROM sensors.event
    WHERE app_id = 'sensorflow-demo'
    GROUP BY distinct_id
)
SELECT
    countIf(viewed) AS view_users,
    countIf(purchased) AS purchase_users,
    countIf(viewed AND purchased) AS both_users
FROM per_user;

Recreating the published generator's 240 rows with ClickHouse Local produced 16 / 4 / 0: sixteen viewers, four buyers, and zero IDs in both sets. Therefore 4 / 16 is not a view-to-purchase conversion rate for this demo. Even a non-zero overlap would establish only that the events occurred for the same ID, not that they happened in the right order.

The query uses ClickHouse's documented countIf aggregate combinator and uniqExact. Exact distinct counts are useful when checking a small test set; ClickHouse notes that uniqExact can consume more memory than approximate alternatives as cardinality grows. Do not infer production query performance from this 240-row sample.

What a production funnel must add

First, choose a stable identity rule. Decide whether distinct_id represents a logged-in account, an anonymous browser ID, or a merged identity. Cross-device behavior and login transitions can change the denominator.

Second, enforce sequence and time. A user who purchases before the product-view event must not count as a view-to-purchase conversion under an ordered definition. ClickHouse documents windowFunnel for ordered chains inside a sliding window. Its window units depend on the timestamp argument; SensorFlow's time column is DateTime64(3), so do not paste a seconds-based example into a millisecond conversion without testing it against your ClickHouse version.

Third, isolate environments and reconcile the dashboard. Filter out sensorflow-demo, staging traffic, and test accounts when calculating production KPIs. A Superset bar chart should use the same event names, identity rule, date boundaries, and filters as a SQL check against raw events.

Finally, test the real pipeline with a small, manually checkable set of SDK events. Confirm the client request, receiver response, ClickHouse row, and Superset metric separately. SensorFlow's SDK integration notes describe the receiver URL and compatibility boundaries. The README makes clear that installing the demo does not start live ingestion; activating it is a separate licensed step.

A five-step acceptance test

Read the demo or seed-data generator; determine whether it represents a real user journey at all.
Compare raw rows and distinct IDs for every event stage.
Check overlap between stages before calculating any conversion percentage.
Add ordered-event, time-window, identity, and deduplication rules to the real-event test.
Match the dashboard filters to the SQL query and exclude synthetic traffic from production reports.

The takeaway is not that synthetic dashboards are bad. They are excellent smoke tests for installation and visualization. The mistake is treating their stage distribution as evidence that real users converted. SensorFlow's transparent ClickHouse path lets a team inspect raw events and define its own metrics, but it also leaves that metric design and infrastructure operation with the team. If your organization needs a ready-made, no-SQL product-analytics interface instead, evaluate one on that basis.

SensorFlow vs Countly in 2026: Analytics Application or SDK-to-ClickHouse Pipeline?

SensorFlow — Tue, 29 Sep 2026 08:00:00 +0000

Countly and SensorFlow both matter to teams that want to operate analytics infrastructure, but they solve different starting problems. Countly is an analytics application with its own SDKs, event collection, reporting interface, and engagement features. SensorFlow is a narrower ingestion path for compatible existing Sensors Data SDK events: Go receiver → team-owned ClickHouse → SQL or Apache Superset.

Short answer: Start with Countly if you need an integrated web, mobile, or desktop analytics product and can instrument with Countly SDKs. Test SensorFlow if you already use Sensors Data SDK, want to keep that instrumentation, and specifically need events in your own ClickHouse. Neither choice removes the need to check edition terms, actual payload compatibility, privacy duties, and operational cost.

This comparison uses the projects' public documentation checked in September 2026. It is not a benchmark, legal opinion, or price quote. SensorFlow is independent of Countly and Sensors Data.

First decide what you are replacing

Countly's public server README describes mobile, web, and desktop collection, sessions, views, events, dashboards, APIs, and plugins. Countly supplies its own SDKs across Lite, Flex, and Enterprise. A team adopting it can instrument an app with a Countly SDK and use Countly's reporting interface. It is not merely a pageview counter.

SensorFlow starts from another constraint: an application already sends events through a compatible Sensors Data SDK and the team does not want to rewrite every client just to change where data lands. The SensorFlow repository documents this route:

Existing Sensors Data SDK clients send requests to a Go ingestion service.
The service writes event rows to the team's ClickHouse.
Analysts query ClickHouse directly or build Apache Superset dashboards.

The repository offers a license-free demo with sample data and Superset dashboards. Real SDK ingestion requires a SensorFlow license. SensorFlow is not a replacement for Countly's built-in analytics and engagement UI, nor a promise that every Sensors Data SDK version or payload mode works automatically.

Countly's write API can accept data from other sources, but that is not the same as accepting Sensors Data SDK wire requests. Pointing an existing SDK server URL at Countly's collector is not a demonstrated migration; it would require an adapter or re-instrumentation and identity testing. Countly SDK calls likewise are not Sensors Data SDK calls that SensorFlow can ingest as-is.

Compare the edition you would actually run

Countly Lite is self-hosted and includes core event collection and dashboards. Countly's current feature matrix lists dashboards, event management, and mobile/web/desktop analytics for Lite. The same matrix marks funnels, retention, cohorts, and user profiles for Flex/Enterprise, not Lite. It would be misleading either to say “Countly has no funnels” or to promise that Lite includes them. Check the exact version and plan you are evaluating; packaging can change.

Countly's server license states AGPL-3.0 with modified Section 7 and branding restrictions. The official licensing FAQ explains an important nuance: organizations can use Lite internally and track their own paid apps, but offering Countly as a service to customers, giving those customers dashboard access for their apps, or rebranding it has different licensing requirements. Do not reduce this to “all commercial use is forbidden,” and read the current terms for your deployment. SensorFlow's public repository uses Apache-2.0, while its real SDK-ingestion path depends on a separately supplied license.

A compact decision matrix

SDK boundary: Countly uses Countly SDKs or its documented write API. SensorFlow is built around compatible existing Sensors Data SDK traffic.
Data store: Countly's server architecture uses MongoDB. SensorFlow's event rows go to your ClickHouse.
Reporting: Countly supplies a product interface. SensorFlow supplies SQL/Superset workflow; your team owns metric definitions.
Advanced analysis: Countly's current matrix lists built-in funnels and retention for Flex/Enterprise. With SensorFlow, you must implement those definitions in SQL or another analysis layer.
Activation: Countly Lite has public source with its stated license conditions. SensorFlow's public demo works without a license; real ingestion does not.

Raw data and operational trade-offs

Countly can be self-hosted, and its architecture documentation says stored raw data can be retrieved through REST APIs or MongoDB commands. It would be wrong to imply that only SensorFlow permits raw-data access. The real distinction is whether you prefer Countly's MongoDB model and application workflows or need events to land directly in an existing ClickHouse environment.

ClickHouse is not automatically faster or cheaper for your workload. SensorFlow puts analytical work on the operator: event schema, identity stitching, deduplication, time zones, retention, backups, access control, and SQL definitions. Countly supplies more application functionality out of the box, but requires its own deployment, SDK, and edition decisions. Test on your own representative event volume and business questions before ranking reliability or total cost.

A useful proof of concept

Ask one question: “Of users who started registration, how many completed it within 24 hours?” Agree on event names, stable user identity, time zone, window, and denominator before comparing dashboards.

Countly path: Instrument a staging app with the relevant Countly SDK. Send registration-start and registration-complete events. Check that their properties appear in Countly's UI or read API. If you need a built-in funnel, verify your chosen edition includes one; do not assume Lite does.
SensorFlow path: Launch the demo, inspect sample rows, then activate licensed ingestion for a meaningful test. Send events from your actual Sensors Data SDK version. Query the resulting ClickHouse rows and verify event name, identity, timestamp, and property types. An HTTP success alone does not prove correct storage.
Recovery path: In a test environment, interrupt the store and inspect retries, duplicates, buffering, and restore behavior. A one-event demo is not a production reliability claim.
Analyst path: Have the person who will own the metric answer the registration question. Count the work required to build and maintain the answer, not only the time required to start containers.

The SensorFlow quick start documents the demo-first and activation sequence.

Decision

Choose Countly when you want a self-hostable analytics application across web, mobile, or desktop, a built-in reporting workflow, and can adopt Countly instrumentation. Evaluate the Lite versus Flex/Enterprise boundary if funnels, retention, profiles, or engagement features are decisive.

Evaluate SensorFlow when retaining compatible Sensors Data SDK events and landing them directly in owned ClickHouse are the hard requirements, and a SQL/Superset workflow plus licensed ingestion are acceptable. If you need Countly's integrated UI or a production ingestion path without a separate license, SensorFlow is a poor fit.

The right question is not “Which has more features?” It is “Which preserves the instrumentation we have, stores data where we need it, and gives our team a reporting workflow it can actually operate?”

SensorFlow vs Umami in 2026: Website Analytics or SDK-to-ClickHouse?

SensorFlow — Mon, 28 Sep 2026 08:00:00 +0000

Umami and SensorFlow both let a team operate analytics infrastructure, but they solve different starting problems. Umami is a self-hostable web analytics application with its own tracker and reporting interface. SensorFlow is a narrower route for compatible existing Sensors Data SDK events to reach a team-owned ClickHouse database, with SQL and Apache Superset used for analysis.

Short answer: Choose Umami first if you want to add website analytics, events, campaigns, and conversion reporting without building a SQL-first workflow. Evaluate SensorFlow if you already have Sensors Data SDK instrumentation and the main requirement is to land those events in your own ClickHouse. Umami is an MIT-licensed open-source project. SensorFlow publishes Apache-2.0 source and a license-free demo, but real SDK ingestion requires a SensorFlow license.

This comparison uses public documentation as of September 2026. It is not a benchmark, pricing quote, or claim that one product is generally better.

Start with the event source, not the dashboard

Umami's normal website setup is to add a website, install its tracker, and read the resulting reports. Its documentation covers traffic sources, visitor behavior, conversions, and revenue. It also documents custom events, funnels, and retention; describing Umami as pageviews only would be wrong. The event-tracking guide shows HTML data attributes and JavaScript calls.

For a site with the Umami tracker installed, a named event with properties can be sent like this:

umami.track('signup_completed', { plan: 'pro', step: 3 });

That call is appropriate for Umami's instrumentation model. It is not a drop-in replacement for a Sensors Data SDK call. Umami also documents a POST /api/send endpoint, but that endpoint has its own payload shape, website ID, and User-Agent requirement. Pointing an existing Sensors Data SDK server URL at it would not translate the protocol. A migration needs an adapter or client-side changes, plus identity testing.

SensorFlow's starting point is different: retain compatible SDK instrumentation and change the receiver. The public repository documents this path:

Sensors Data SDK events → SensorFlow Go ingestion → ClickHouse → SQL / Superset

The README separates a license-free demo from licensed real ingestion. The demo starts supporting services, sample events, and Superset dashboards. To process actual SDK traffic, a team must obtain and activate a license and test its exact SDK versions and payloads. No blanket compatibility claim is justified.

Where the systems differ

Instrumentation. Umami uses its own website tracker, JavaScript calls, or documented API. SensorFlow is evaluated as a receiver for compatible Sensors Data SDK requests. If you have no existing Sensors Data SDK dependency, that SensorFlow advantage may be irrelevant.

Storage. Umami's current installation guide specifies PostgreSQL and offers Docker Compose, a prebuilt image, or source installation. SensorFlow writes event rows to ClickHouse. This is an architectural distinction, not proof that either database wins on speed or cost.

Analysis interface. Umami offers a built-in analytics interface. Its funnel documentation describes ordered URL or event steps and conversion windows, and its retention documentation describes cohorts of returning visitors. SensorFlow uses ClickHouse SQL and Superset dashboards; it does not offer an equivalent native product-analytics interface. Check feature availability in the Umami version and deployment you actually select.

Terms. Umami's repository has a public MIT license. SensorFlow's repository is Apache-2.0, but its real SDK ingestion path requires a separate license. Treat the cost and support terms as part of the decision, not as a footnote.

When Umami is the better first test

For a website team that needs traffic sources, campaigns, custom events, funnels, and retention in one interface, Umami is a more direct workflow. Install its tracker on a staging site, send an event, and ask the actual marketer or analyst to answer a question in the UI. Adding a SQL-first architecture may create work without value if the real need is a usable analytics application.

Self-hosting does not remove operations. The team still needs HTTPS, access control, PostgreSQL backups, upgrades, tracker delivery, and consent handling appropriate to its own jurisdiction and data. Privacy-focused product design is not a universal legal exemption.

When SensorFlow is worth a proof of concept

Suppose a team has many Sensors Data SDK calls and cannot rewrite clients all at once. It wants the event rows in a ClickHouse database it operates and has people who can own SQL metrics. Then SensorFlow's receiver boundary is worth testing: can traffic from the actual SDK versions arrive in ClickHouse with the expected identity, timestamp, and property types?

That is narrower than replacing Umami. Superset can visualize a funnel or retention query, but the team must define the identities, steps, windows, and denominators, maintain the SQL, and explain the metric to users. Owning raw rows also means owning schema changes, sensitive-property handling, retention, permissions, backups, and incidents.

The SensorFlow quick start lets a developer launch the demo first, then activate licensed ingestion. If the requirement is a fully usable no-license self-hosted collection path, Umami's public terms may fit better. If the requirement is existing Sensors Data SDK traffic in ClickHouse, test SensorFlow's licensed path before deciding whether the migration value justifies it.

A useful evaluation for both

List current SDKs, event names, properties, and anonymous-to-authenticated identity transitions. Do not assume instrumentation compatibility from a feature list.
Define what a registration means, the time zone, and the funnel window before opening a dashboard.
For Umami, install the tracker on a non-production page, send a custom event, and confirm the event and properties in its reporting interface. A JavaScript call alone is not proof of storage.
For SensorFlow, start the demo and inspect sample ClickHouse rows. If real ingestion is needed, activate the license, send one event from the actual SDK, and query it back. Check event name, distinct ID, timestamp, and property types.
Let the intended users answer the same business question. Compare the product-manager workflow in Umami with the SQL/Superset workflow the team would maintain in SensorFlow.
In a test environment, exercise database outage, retries, duplicates, backup restore, and credential rotation. An HTTP success response is not a reconciliation report.

Do not generalize a small test into a throughput or cost ranking. Measure a representative volume and operational workload before making a production decision.

Decision

Choose Umami when the main task is adding a self-hostable website analytics application with its own instrumentation and reports. Evaluate SensorFlow when retaining compatible Sensors Data SDK traffic and landing it in owned ClickHouse are the actual constraints, and the team accepts licensed ingestion and a SQL/Superset workflow. They can coexist as separate website and product-event pipelines, but that adds governance work rather than eliminating it.

SensorFlow is an independent project. It is not affiliated with, endorsed by, or certified by Umami or Sensors Data.

I Built an Open-Source, Self-Hosted Alternative to PostHog on ClickHouse

SensorFlow — Sun, 27 Sep 2026 21:54:50 +0000

Per-event pricing can make analytics costs rise with traffic. I built an alternative: SensorFlow — an open-source, self-hosted event analytics stack from collection to SQL and BI, with data staying on your own servers.

Website: https://sensorflow.site/
GitHub: https://github.com/data-analyze-bi/sensorflow (Apache-2.0)
Live demo: https://superset.sensorflow.site

The problem with per-event pricing

Managed analytics charges by event volume. The more successful your product, the bigger the bill — growth gets taxed. Self-hosting flips the model: you pay for servers, not for success.

Architecture

Deliberately boring:

SDK → Go collector → ClickHouse → SQL / Apache Superset

Collect: Go ingestion service, wire-compatible with Sensors Data SDKs — existing SDK instrumentation may be reused after checking SDK version, encryption, identity, property types, and timestamps.
Store: ClickHouse, built for analytical queries (funnels, retention) at scale.
Analyze: Raw SQL when you want control, Superset dashboards when you want clicks.

Run ./install.sh for the local demo, then obtain a license and run ./activate.sh to enable real SDK ingestion. No Kubernetes required.

SensorFlow vs PostHog

	SensorFlow	PostHog
Deployment	Self-hosted only	Cloud or self-hosted
Query model	SQL-first, ClickHouse-native	Product UI-first
Pricing	Annual license, $699/yr list price	Usage-based
Suite extras	None (no replay/flags)	Replay, flags, experiments

PostHog is the broader suite. SensorFlow is the narrower, SQL-first option for teams that want ClickHouse and full ownership of their stack.

Pricing

Annual license starts at $699/yr list price, with the first order currently discounted to $349. It is not billed per event. The first month is free. You bring the servers.

Try it

Play with the live demo for five minutes, then run it locally. If it's useful, a star helps: https://github.com/data-analyze-bi/sensorflow

Independent open-source project, not affiliated with Sensors Data.

SensorFlow vs Plausible in 2026: Two Very Different Ways to Own Analytics

SensorFlow — Sun, 27 Sep 2026 08:00:00 +0000

Both Plausible and SensorFlow can put analytics data on infrastructure you operate. Both involve ClickHouse. That is where the easy equivalence ends. Plausible is a privacy-first web analytics product with a tracking script, goals, and a purpose-built dashboard. SensorFlow is a narrower ingestion route for compatible, already-deployed Sensors Data SDK events: SDK → Go receiver → your ClickHouse → Apache Superset.

Short answer: If your problem is “I need readable website traffic and conversion reports,” start with Plausible. If your problem is “I already have Sensors Data SDK instrumentation and need to test landing its events in my own ClickHouse,” evaluate SensorFlow. Do not choose SensorFlow because someone says Plausible cannot self-host or cannot access raw ClickHouse data: Plausible's own repository documents both. And do not assume SensorFlow's open-source demo means production SDK ingestion is free: its getting-started guide separates demo deployment from licensed activation.

This comparison is based on vendor documentation available in September 2026. It contains no speed, cost, or privacy-compliance benchmark.

The first distinction is the event contract

Plausible's official Events API accepts POST /api/event with fields including domain, name, and url. Its JavaScript tracker can collect pageviews and custom events, and custom properties give those events context. That is a useful model for website teams. The dashboard organizes traffic sources, pages, goals, and conversions without asking an analyst to write SQL.

SensorFlow's documented starting point is different: existing Sensors Data SDK calls. It attempts to receive compatible SDK payloads through a Go service and write resulting events into ClickHouse. Its core value is preserving a tested subset of existing instrumentation while changing the server-side destination. That does not make its receiver a drop-in Plausible Events API endpoint. Nor does Plausible's Events API mean it automatically understands a Sensors Data SDK payload. A migration between the two needs an explicit payload mapping, identity decision, and verification of timestamps and properties.

Consider a practical example: a product already has mobile and web SDK calls for SignupStarted and SignupCompleted, including a stable account identifier. If the team wants the original events for joins and custom SQL, it should test the SensorFlow path with its exact SDK version. If a marketing team chiefly needs privacy-oriented website acquisition and goal reports, it may be faster to instrument Plausible's tracker and use its interface. The event contract, not the word “open source,” decides the implementation work.

Plausible also uses ClickHouse

It would be misleading to frame this as “Plausible's closed database versus SensorFlow's ClickHouse.” Plausible's repository states that its self-hosted Community Edition uses ClickHouse for analytics and PostgreSQL for other application data. It also explicitly says self-hosting allows direct access to raw data in ClickHouse. Its Community Edition deployment repository provides a Docker Compose route.

The more useful contrast is data model and default workflow. Plausible's ClickHouse supports Plausible's web analytics product; users normally work in its dashboard and API. SensorFlow's target is a team-operated event store whose rows are queried with ClickHouse SQL and visualized in Superset. If your organization wants to own metric definitions and join events to other warehouse data, that SQL-first approach may suit it. If the organization wants a finished, simple reporting interface, operating ClickHouse alone does not provide one.

Decision	Plausible	SensorFlow
Primary task	Website and conversion analytics	Compatible Sensors Data SDK event ingestion into ClickHouse
Cloud option	Managed Plausible Cloud	Self-hosted project; check current commercial license terms for ingestion
Self-host option	Plausible Community Edition	Docker-based demo and licensed real-ingestion path
Analytics store	ClickHouse in self-hosted CE; PostgreSQL for application data	Team-operated ClickHouse
Default interface	Plausible dashboard, goals, reports, APIs	ClickHouse SQL and Apache Superset
Existing Sensors Data SDK	Requires integration or mapping to Plausible's event model	The principal compatibility use case, subject to testing
Built-in funnel UI	Available in eligible managed plans, not Plausible CE	No equivalent built-in no-code UI; model it in SQL/Superset
Raw-data access	Plausible CE allows direct ClickHouse access; Cloud has export/API options	Direct ClickHouse queries are the normal workflow

The Plausible README distinguishes Cloud from CE. In particular, it lists marketing funnels, ecommerce revenue goals, SSO, and Sites API among premium features absent from CE. Its funnel documentation labels the feature as a Business-plan feature. This edition boundary matters, but it is not a claim that SensorFlow has a better ready-made funnel: it does not.

Privacy is not a one-word score

Plausible's product is intentionally privacy-first and designed around cookie-free website measurement. Its repository describes how it avoids storing personal data and persistent visitor identifiers. The Events API documentation adds an operational nuance: User-Agent and client IP information are used to derive unique visitor counts, and a misconfigured server-side X-Forwarded-For can silently drop an event even if the API returns HTTP 202. A production implementation should follow Plausible's exact guidance rather than equate “202” with a verified stored event.

SensorFlow can retain event identifiers and properties sent by an existing SDK in a ClickHouse database operated by the customer. That can enable deeper event-level analysis, but it also puts more privacy, consent, access-control, retention, and deletion responsibility on the operator. It would be wrong to market that as inherently more privacy-preserving than Plausible. The two systems are deliberately optimizing different analytics models.

The license and operations boundary

Plausible CE is AGPL-licensed and self-hostable without a Plausible subscription, while Plausible Cloud is a paid managed service. CE operators still pay for compute, storage, backups, maintenance, and incident response. Cloud includes a managed product and features based on the chosen plan.

SensorFlow's README documents an install-first workflow: supporting services and sample dashboards can run before a license is purchased, but receiving real Sensors Data SDK traffic requires a license and activation. This is a material difference from saying “clone the repository and all production ingestion works for free.” Evaluate the license alongside infrastructure and engineering costs.

Do not confuse running a demo with a production validation. For SensorFlow, inspect the sample events, then activate an appropriate license and send a real event from the SDK version you actually use. For Plausible, verify the chosen deployment edition, track an event with its documented API or tracker, create the required goal, and confirm that it appears in the dashboard. For both, test proxies, bot filtering, retries, backups, and access to the stored data.

A fair proof of concept

Choose one concrete question such as “How many visitors reach signup, and what properties distinguish the people who complete it?” Then:

Write down the source events and identities. Website sessions and authenticated product users are not interchangeable units.
Track the same business outcome in both tools. In Plausible, use its documented custom event and goal configuration. In SensorFlow, send a compatible SDK event and query the resulting ClickHouse row.
Check actual data arrival. Inspect Plausible's dropped-event header where relevant, and query ClickHouse directly for SensorFlow. Do not stop at an HTTP success response.
Ask the intended users to answer the question. A marketer may prefer Plausible's ready-made dashboard; a data engineer may prefer raw rows and SQL. Neither preference is universal.
Record setup and maintenance work, product entitlements, and the cost of changing existing SDK code. Do not compare a managed Plausible Cloud plan against an unoperated SensorFlow demo as though they provide the same service.

Which should you choose?

Use Plausible when you want privacy-first website analytics with a focused dashboard and tracker. Its Community Edition is a real self-hosted option with ClickHouse and raw-data access, although the CE feature set differs from paid Cloud plans.

Test SensorFlow when you already have compatible Sensors Data SDK instrumentation, explicitly want that event stream in your own ClickHouse, and have the engineering capacity to define and operate the analyses. Its narrower scope and licensed real-ingestion boundary should be stated upfront. If you need a mature out-of-the-box website analytics application, Plausible is usually the better starting point.

SensorFlow is an independent project. It is not affiliated with, endorsed by, or certified by Plausible or Sensors Data.

SensorFlow vs Matomo in 2026: Event Pipeline or Web Analytics?

SensorFlow — Sat, 26 Sep 2026 12:50:05 +0000

Matomo and SensorFlow are both relevant when a team wants to run analytics on its own infrastructure. They are not substitutes for the same job. Matomo is a mature web analytics application with tracking, reports, dashboards, and a self-hosted edition. SensorFlow is a narrower path for teams that already send compatible Sensors Data SDK events and want those events in their own ClickHouse, queried through SQL and Apache Superset.

Short answer: Pick Matomo if you need a ready-to-use website analytics interface, visitor reports, campaigns, goals, and event tracking. Evaluate SensorFlow if your starting point is existing Sensors Data SDK instrumentation and your desired destination is ClickHouse. SensorFlow's demo stack can be run before purchase, but activating real SDK ingestion requires a SensorFlow license. Neither tool should be presented as a free, feature-equivalent replacement for the other.

This comparison uses public documentation as of September 2026. It is not a performance benchmark or a claim that one product is universally better.

What are you actually replacing?

The useful question is not merely whether both projects can be self-hosted. Ask where the boundary you need to change sits.

If your team currently looks at website acquisition, visits, content performance, campaigns, and conversion goals, the boundary is probably the analytics application. Matomo already provides that application, plus an official event-tracking workflow. Its on-premise installation guide says the self-hosted edition is free to download. The event-tracking guide describes the interaction data it can collect.

If your team already has Sensors Data SDK calls across web, mobile, or backend code, the boundary may instead be the event receiver. SensorFlow's documented flow is compatible SDK traffic → Go ingestion → ClickHouse → Superset. The objective is to test a server-side destination change without rewriting all instrumentation at once. See the SensorFlow repository and getting-started guide for the actual deployment and license steps.

That narrower scope matters. SensorFlow does not turn Superset into Matomo's visitor interface, and Matomo does not natively make an existing Sensors Data SDK send its events to ClickHouse. A team can build additional integrations, but that work belongs in the comparison.

Side-by-side: where each tool fits

Decision	Matomo	SensorFlow
Primary job	Web analytics application with built-in reports and tracking	Server-side path from compatible Sensors Data SDK events to ClickHouse
Self-hosting	Official On-Premise edition	Docker-based stack and self-operated ingestion
Typical storage	MySQL or MariaDB for Matomo On-Premise	ClickHouse for event rows
Analysis interface	Matomo reports and dashboards	ClickHouse SQL and Apache Superset
Raw-data access	API export; on-premise users can also read the underlying database	Direct ClickHouse queries are the normal workflow
Existing Sensors Data SDK	A separate migration/integration exercise	The principal compatibility use case, subject to testing
Funnels	Check plan or on-premise plugin entitlement	Model in SQL and present in Superset; not a comparable no-code UI
Real ingestion terms	Depend on hosting, plan, and plugins	Demo before activation; real SDK ingestion requires a license

Matomo's system requirements name PHP and MySQL/MariaDB for its on-premise application. This is an architectural difference, not evidence that one database is faster. Capacity, operational cost, and query performance must be measured on your workload.

Matomo is not just page views

It would be inaccurate to dismiss Matomo as a simple traffic counter. Its current feature page includes event tracking, ecommerce tracking, segmentation, dashboards, API access, and reporting features. Matomo's event-tracking documentation covers interactions such as clicks, videos, downloads, and forms. For many website teams, those built-in workflows are the reason to choose it: an analyst can navigate a product interface without first maintaining a catalog of SQL queries.

It would also be inaccurate to say that only SensorFlow provides access to raw data. Matomo documents both HTTP API export and direct read-only access to its MySQL database for on-premise installations. If your requirement is simply to extract your own events, Matomo On-Premise deserves a fair evaluation. The sharper distinction is where raw rows live by default and how the team expects to work with them. SensorFlow is designed around ClickHouse as the event store; Matomo's application and schema are designed around Matomo's reports.

Some advanced Matomo features depend on a plan or premium plugin. The current on-premise pricing page places Funnels in a paid bundle rather than the free Community feature set. Verify the current bundle, support terms, and deployment model on Matomo's pricing page before making a purchase decision.

SensorFlow is not a complete Matomo replacement

The SensorFlow README makes a two-stage distinction: the installer starts supporting services, demo events, and a Superset dashboard without a license; real Sensors Data SDK ingestion starts only after a license is installed and activation is run. Calling the entire production ingestion path free would hide a material requirement.

After activation, the attraction for a SQL-oriented team is that the event receiver writes to a ClickHouse database the team operates. Engineers can inspect event rows, verify property types, define metrics, and join with other data using their own SQL. Superset can present dashboards, but it does not automatically supply Matomo's reporting vocabulary or workflow. The team owns metric definitions, dashboard quality, retention, backup, security, and upgrades.

The compatibility claim must stay narrow. Working with compatible Sensors Data SDK traffic does not establish parity for every SDK generation, encrypted payload, visual tracking mode, identity rule, or plugin. A proof of concept should use the exact SDK versions and event payloads already deployed.

A concrete evaluation

Start with one business question: “Of the people who clicked sign-up this week, how many finished registration?” Run the same decision workflow in each candidate system.

Inventory current instrumentation. Record event names, properties, user identifiers, SDK versions, and destinations. If the application uses Matomo's tracker rather than Sensors Data SDKs, SensorFlow's compatibility advantage may be irrelevant.
Define the event contract. Specify whether “sign-up” means a click, submitted form, created account, or verified account. Neither product can fix an ambiguous definition.
Deploy in non-production. Follow Matomo's installation guide and SensorFlow's getting-started guide. Keep test tokens, database credentials, and network ports private.
Send identifiable test events. Include a unique test user and non-sensitive properties. Confirm both the HTTP response and the stored record or report; an accepted request alone does not prove retention.
Reconcile counts and identities. Compare event counts by day, environment, and event name. Check anonymous-to-authenticated transitions and time zones. Treat divergence as a finding, not a rounding error.
Let intended users answer the question. Ask a marketer or product manager to find the answer in Matomo, and ask the intended SQL/Superset owner to produce and explain the query. The working experience matters.
Test failure and recovery. Stop the database in a test environment, rotate a token, restore from backup, and see whether lost or delayed events can be diagnosed before production use.

A small demo verifies a path; it does not predict production throughput or total cost. Measure representative volume, query mix, retention, and operations effort before selecting a winner.

When should you choose each?

Matomo is the more direct choice for a website team that wants a complete analytics interface now. Reports, goals, campaigns, and event tracking already live in the same application. Its on-premise option allows self-hosting, and the free Community tier may cover the required core features. Teams can later evaluate paid plugins and support.

SensorFlow is worth a proof of concept when compatible Sensors Data SDK events already exist, ClickHouse is the desired event store, and the team can operate SQL and infrastructure. The first milestone is to start the demo, inspect sample events, activate licensed ingestion if the real path is needed, then send one event from the actual SDK and query it back. Expand gradually only after identity and property types check out.

Matomo should not be characterized as lacking events or raw-data access. SensorFlow should not be characterized as a complete or freely activated Matomo replacement. Choose based on the boundary you need to change and on who will operate and use the system.

SensorFlow is an independent project. It is not affiliated with, endorsed by, or certified by Matomo or Sensors Data.

SensorFlow vs GrowingIO in 2026: Analytics Product or Self-Hosted Event Pipeline?

SensorFlow — Fri, 25 Sep 2026 03:27:53 +0000

GrowingIO and SensorFlow address different parts of event analytics. GrowingIO offers collection SDKs and product-analysis workflows, including documented automatic collection and funnel analysis. SensorFlow is a narrower self-hosted pipeline for compatible Sensors Data SDK events: Go collector → your ClickHouse → SQL and Apache Superset.

Short answer: Evaluate GrowingIO if product and growth teams need ready-made analysis workflows and automatic collection. Evaluate SensorFlow if you already use a Sensors Data SDK, need raw events in your own ClickHouse, and have the engineering capacity to operate the stack. An existing GrowingIO SDK integration is not a drop-in input for SensorFlow.

The important differences

Question	SensorFlow	GrowingIO
Main scope	Self-hosted collection and event storage	Collection and product-analysis workflows
Client migration path	Verified standard Sensors Data SDK event requests	GrowingIO SDKs and platform configuration
Automatic collection	Do not assume feature parity	Documented for supported SDK versions
Funnels	Define semantics and write ClickHouse SQL, then visualize in Superset	Documented funnel-analysis workflow
Raw ClickHouse rows	Query the team's own database	Confirm access and export terms for the specific plan
Operations	The deploying team	Depends on the purchased and deployment arrangement

GrowingIO's automatic collection documentation describes supported page and element events. Its funnel documentation describes conversion windows and breakdowns. Those are product capabilities SensorFlow should not claim to match with an out-of-the-box interface. GrowingIO also documents an analysis-result export API, so a blanket claim that its data cannot be exported would be inaccurate.

Why a GrowingIO SDK cannot simply point at SensorFlow

SensorFlow's intended ingestion path is:

Verified Sensors Data SDK event request
                 ↓
           Go collector
                 ↓
       Your ClickHouse
                 ↓
         SQL / Superset

Changing an SDK's server URL only works if the destination understands that SDK's request format and semantics. SensorFlow does not document support for the GrowingIO SDK protocol. Request framing, identity fields, retries, and automatically collected event meanings need a separate migration design. If your analytics relies heavily on GrowingIO's automatic or visual event collection, plan to rebuild and verify those events; they do not appear automatically when you replace the receiving server.

The migration boundary is different for an app already using a Sensors Data SDK. Test the actual SDK version and payloads against SensorFlow in a non-production environment, verify collector logs, and query the resulting ClickHouse rows before shifting traffic. Extensions, identity merges, and unusual event types still require explicit tests. The SensorFlow repository contains deployment and verification materials. Demo dashboards can start before activation; receiving real events requires a license.

What owning the event table buys you

With events in your ClickHouse instance, you can inspect individual rows instead of relying only on an aggregate chart. After sending a uniquely named test event to an activated collector:

SELECT time, event, distinct_id
FROM sensors.event
WHERE event = 'integration_test'
ORDER BY time DESC
LIMIT 10;

Then compare daily event and user counts:

SELECT toDate(time) AS event_date, event,
       count() AS events, uniqExact(distinct_id) AS users
FROM sensors.event
WHERE time >= now() - INTERVAL 7 DAY
GROUP BY event_date, event
ORDER BY event_date DESC, events DESC;

These queries validate the SensorFlow table, not equivalence with a GrowingIO report. Funnels, retention, identity stitching, and “active user” definitions remain your team's responsibility. So do ClickHouse capacity, backups, access control, HTTPS, monitoring, and upgrades.

A useful proof of concept

Collection coverage: Inventory five business-critical events, including any auto-collected or visually configured events. Confirm each candidate produces the same business meaning, not merely a similar count.
Metric reproduction: Ask the people who use the analysis to build a signup funnel, next-day retention, and channel conversion. Record discrepancies and the amount of SQL support required.
Operations and rollback: Test collector or ClickHouse downtime, payload rejection, and license-processing errors. Define rollout and rollback conditions before sending production traffic.

GrowingIO is the better fit when a ready-to-use product-analysis interface and collection workflows matter more than owning a particular event-storage path. SensorFlow is worth testing when the team already has SQL, Docker, and ClickHouse expertise—particularly if Sensors Data SDK instrumentation is in place and control of raw events is the primary requirement. For a GrowingIO-SDK-heavy application, SensorFlow is not a low-effort replacement.

SensorFlow is an independent project and is not affiliated with or endorsed by GrowingIO or Sensors Data. Features, deployment terms, and data-access rights for any commercial plan should be verified against current vendor documentation and the actual agreement.

SensorFlow vs PostHog in 2026: Which Fits Your Stack?

SensorFlow — Thu, 24 Sep 2026 14:20:14 +0000

SensorFlow vs PostHog in 2026: Which Fits Your Stack?

SensorFlow and PostHog can both appear in a search for self-hosted event analytics, but they are not equivalent products. PostHog is an integrated product-engineering platform. SensorFlow is a narrower event-data path for teams that want compatible Sensors Data SDK traffic to flow through a Go collector into their own ClickHouse and Apache Superset.

Quick answer: Choose PostHog when product analytics, session replay, feature flags, experiments, and a unified product interface matter more than assembling your own data workflow. Evaluate SensorFlow when retaining existing Sensors Data SDK instrumentation, owning raw ClickHouse events, and defining metrics in SQL are the primary requirements.

The practical difference

Decision area	SensorFlow	PostHog
Primary scope	Self-hosted event ingestion and analytics data path	Integrated product analytics and product-engineering suite
Typical flow	Sensors Data SDK → Go → ClickHouse → Superset	PostHog SDKs/events → PostHog analytics surfaces
Product analytics UI	Superset dashboards and SQL workflows	Native trends, funnels, retention, paths, stickiness, and lifecycle insights
Session replay	Not a core built-in capability	Officially documented product capability
Feature flags and experiments	Not a core built-in capability	Integrated with the product suite
Raw-data workflow	Direct ClickHouse access is central	Product UI and supported query surfaces are central
Operational model	Team operates the components	Cloud and self-hosting options must be evaluated against current official guidance
Best fit	Data and engineering teams with existing compatible SDK traffic	Product, growth, and engineering teams seeking an integrated workflow

PostHog's current product analytics documentation describes trends, funnels, retention, paths, stickiness, and lifecycle insights. It also connects those events to session replay, feature flags, and experiments. That breadth is a real advantage for teams that want to move from observing a conversion change to inspecting sessions or controlling a rollout in one product.

Official reference: https://posthog.com/docs/product-analytics

Where PostHog is the stronger choice

PostHog is usually the stronger candidate when product managers and growth teams need to explore behavior without waiting for a new SQL query. Native analytics concepts reduce the amount of dashboard modeling required before a team can inspect funnels or retention.

It is also the clearer choice when replay, flags, and experiments are requirements rather than optional adjacent tools. SensorFlow should not claim parity in those areas. Reconstructing them with SQL and a BI layer would not provide the same workflow or product experience.

Teams should still read PostHog's current deployment and licensing documentation instead of relying on old comparison posts. “Source available,” “open source,” “self-hostable,” and “all features under one license” are different claims, and deployment recommendations can change over time.

Self-hosting reference: https://posthog.com/docs/self-host

Where SensorFlow is meaningfully different

SensorFlow starts with a specific migration problem: a team already sends events through official Sensors Data SDKs and wants to change the server-side destination before rewriting every client integration.

Its public architecture is intentionally simple:

Compatible Sensors Data SDK traffic
              ↓
          Go collector
              ↓
          ClickHouse
              ↓
     SQL + Apache Superset

For this audience, direct ownership of the ClickHouse rows is not an export feature; it is the normal operating model. Engineers can inspect event schemas, query raw records, join events with internal data, and decide how dashboards are calculated.

That flexibility comes with responsibility. The team must operate HTTPS, authentication, ClickHouse storage, backups, monitoring, upgrades, and metric definitions. SensorFlow is not the easier choice for every organization merely because its component list is smaller.

Project source: https://github.com/data-analyze-bi/sensorFlow

Is SensorFlow a PostHog replacement?

Not in the general sense. It can replace a narrower portion of an event pipeline for teams whose main objective is self-hosted collection, ClickHouse storage, and SQL-driven analysis. It does not replace PostHog's complete product analytics interface, session replay, feature-flag, or experimentation workflows.

The phrase “PostHog alternative” is only useful after the required scope is stated. If the scope is “an integrated product stack,” SensorFlow is not feature-equivalent. If the scope is “a transparent event path into our own ClickHouse,” SensorFlow may be a relevant alternative to evaluate.

Migration and validation considerations

Whichever system a team selects, a production decision should use real events rather than a feature checklist. A useful proof of concept should verify:

SDK request compatibility and retry behavior.
Anonymous and authenticated identity handling.
Timestamp, numeric, boolean, array, and nested-property semantics.
Event-count reconciliation between old and new destinations.
Query latency on representative retention and funnel workloads.
Backup, restore, monitoring, and upgrade procedures.
Access control and handling of sensitive properties.

SensorFlow's compatibility claims should be tested against the exact Sensors Data SDK versions and extensions in use. Encryption plugins, visual tracking, autocapture variants, and identity behavior should not be assumed compatible without evidence.

Total cost is more than hosting

A self-hosted stack has infrastructure costs, but engineering time is often the more important variable. SensorFlow requires people who can operate Docker, ClickHouse, SQL, and a BI layer. PostHog's broader stack can also require meaningful operational work when self-hosted, while its hosted offering changes that responsibility.

Compare the full operating model: software terms, compute and storage, backups, upgrades, incident response, analyst time, product-manager autonomy, and the cost of maintaining metric definitions. Avoid unsourced performance or price claims; measure the workload that resembles your own product.

Who should choose which?

Choose PostHog first when an integrated product analytics experience is the goal; product teams need native funnels and retention; session replay is required; or feature flags and experiments should share the same events and identities.

Evaluate SensorFlow first when a team already uses compatible Sensors Data SDK traffic; raw ClickHouse ownership is mandatory; SQL and Superset are accepted working tools; and the migration should begin at the server-side ingestion boundary.

Choose neither without a proof of concept when identity rules are complex, regulatory constraints are strict, event volume is large, or critical SDK extensions are involved. Those conditions require measured compatibility and operational testing.

Verdict

PostHog is the more complete product-engineering platform. SensorFlow is the more focused data-path option. The correct choice depends on whether the team wants an integrated product workflow or a transparent, self-operated route from existing compatible SDK events into ClickHouse.

SensorFlow is an independent project and is not affiliated with or endorsed by PostHog or Sensors Data.

How to Validate Event Data in ClickHouse and Superset

SensorFlow — Fri, 18 Sep 2026 18:05:51 +0000

An analytics migration is not complete when an ingestion endpoint returns HTTP 200. That response proves only that one request reached one service. It does not prove that the event was decoded correctly, stored with the intended types, associated with the right identity, interpreted in the right time zone, or counted consistently in a dashboard.

The safer approach is to validate the pipeline in layers: transport, raw storage, semantic fields, aggregate queries, and dashboard output. This article presents a repeatable checklist for teams using ClickHouse and Apache Superset. SensorFlow is used as an Apache-2.0 implementation example, but the method applies to other self-hosted event pipelines.

Direct answer: Validate event data at three minimum checkpoints: confirm the ingestion response and service logs, query the exact raw event in ClickHouse, then reproduce the intended metric in Superset. A successful request is necessary, but only agreement across all three layers shows that the event is usable for analysis.

Why a 200 response is not enough

An event can pass through the network while still becoming analytically wrong. A decoder may accept the payload but drop an unsupported property. A timestamp can be interpreted in the wrong time zone. A numeric value can arrive as a string. A retry can create a duplicate. An identity transition can split one person into two users.

These errors are especially dangerous because dashboards may still look plausible. The total can be close enough that nobody notices until a business decision depends on a segment, funnel, or retention calculation.

ClickHouse describes itself as a column-oriented SQL database for online analytical processing. Its official documentation explains the database behavior that should guide schema and query design. Apache Superset is a separate exploration and visualization layer; its official introduction covers SQL exploration, datasets, charts, and dashboards. Neither component can infer your event semantics automatically.

The five-layer validation model

Layer	Question	Evidence
Transport	Did the endpoint receive and accept the request?	HTTP response, request ID, ingestion log
Storage	Is the exact event present in ClickHouse?	Raw-row query using a unique test marker
Semantics	Are identity, time, name, and properties correct?	Field-by-field comparison with the sent payload
Aggregation	Does SQL produce the expected count and distinct users?	Saved validation query with a narrow time range
Presentation	Does Superset show the same result?	Dataset SQL, filters, time zone, and chart output

Each layer should be checked independently. If a chart is wrong, starting with the chart often wastes time; first locate the raw event, then move upward through the query and dataset configuration.

Step 1: Create an identifiable test event

Do not begin with anonymous production traffic. Send one event that can be found without ambiguity. Use a name such as integration_test and include a unique run identifier, test environment, client platform, SDK version, and a known test user.

The test should contain representative property types:

a string such as plan_name;
an integer such as item_count;
a decimal if the protocol supports one;
a Boolean such as is_trial;
a timestamp with an explicit offset;
an array or nested value only if the receiving protocol claims to support it.

Record the payload before sending it. That payload becomes the expected result for the semantic comparison. Never include real personal data in a migration test when synthetic identifiers are sufficient.

Step 2: Verify transport and decoding

Capture the HTTP status, response body, request time, destination URL, and any request identifier returned by the service. Then inspect the ingestion log for the same run identifier.

A useful transport check answers four separate questions:

Did the request reach the intended environment?
Did authentication or signature validation pass?
Did the decoder recognize the event format?
Did the storage operation complete rather than enter a retry or dead-letter path?

Treat parsing warnings as failures until reviewed. Silently discarded properties are data loss even when the top-level event is stored.

SensorFlow focuses on this receiving boundary: a Go service accepts a compatible standard event upload flow and writes events to ClickHouse for SQL inspection. It is an independent project and is not affiliated with or endorsed by Sensors Data. Compatibility must be verified for the SDK versions, plugins, encryption settings, and upload modes used by a specific deployment.

Step 3: Find the raw event in ClickHouse

Query the narrowest possible time range and filter by the unique run identifier. Adapt database, table, and column names to the deployed schema:

SELECT
    event,
    distinct_id,
    event_time,
    received_at,
    properties
FROM sensors.event
WHERE event = 'integration_test'
  AND properties['validation_run'] = '2026-09-17-a'
ORDER BY received_at DESC
LIMIT 10;

The expected result is usually one row. Zero rows indicate a transport-to-storage problem. Multiple rows may be legitimate retries, but they require an explicit deduplication policy rather than an assumption.

For production schemas based on the MergeTree family, study ClickHouse's MergeTree documentation. The sorting key, partition strategy, and common filters determine how much data a query reads. A validation query that works on a tiny test table can become expensive if the production table design does not match the access pattern.

Quotable rule: Keep the raw event layer queryable. When a metric is disputed, the team should be able to move from a dashboard number to its SQL definition and then to the underlying events without relying on a closed transformation.

Step 4: Compare semantic fields

Finding the row is only the beginning. Compare the stored record with the original payload field by field.

Event name

Check exact spelling and case. Decide whether the system normalizes names and document that behavior. SignUp, signup, and sign_up should not accidentally become three business events.

Identity

Inspect anonymous ID, login ID, device ID, and any identity association event. A successful login transition should not unexpectedly split pre-login and post-login behavior. Define whether counts use events, devices, anonymous IDs, account IDs, or a resolved person ID.

Time

Store enough information to distinguish client occurrence time from server receipt time. Verify time zone conversion and test around midnight, daylight-saving transitions where relevant, delayed uploads, and offline queues.

Property types

Confirm that numeric, Boolean, date, string, and collection values preserve their intended types. A property that changes from 42 to "42" can break filters, sorting, ranges, and aggregations without making the event disappear.

Environment and source

Test and production traffic must be distinguishable. Record platform, application version, SDK version, and ingestion source where possible so failures can be isolated without inspecting individual users.

Step 5: Run aggregate reconciliation queries

After a single event is correct, send a small deterministic batch. For example, send ten events for three synthetic users with known properties. Then calculate the result directly in ClickHouse:

SELECT
    event,
    count() AS event_count,
    uniqExact(distinct_id) AS exact_users
FROM sensors.event
WHERE event = 'integration_test'
  AND properties['validation_run'] = '2026-09-17-b'
GROUP BY event;

For a validation batch, exact functions make expectations easier to reason about. Production queries may use other functions based on the required accuracy and cost; make that choice explicit in the metric definition.

Also run negative checks:

SELECT
    countIf(distinct_id = '') AS missing_identity,
    countIf(event_time IS NULL) AS missing_event_time,
    countIf(received_at < event_time - INTERVAL 1 DAY) AS suspicious_future_time
FROM sensors.event
WHERE properties['validation_run'] = '2026-09-17-b';

Adjust the conditions to the actual schema and business rules. The purpose is not to copy universal SQL, but to turn assumptions into executable tests.

Step 6: Reproduce the metric in Superset

Connect Superset to the validated database using the project's documented driver and security configuration. Superset's database connection documentation lists supported connection patterns and points to database-specific requirements.

Start in SQL Lab, run the same aggregate query, and compare the result with the ClickHouse client. Only after the results agree should you save a dataset and build a chart. Superset's data exploration documentation explains the workflow from datasets to charts.

When results differ, inspect:

dataset SQL or virtual-dataset transformations;
dashboard and chart filters;
time column selection and time grain;
database and application time zones;
cache state;
row-level security and user permissions;
distinct-count function and identity field;
hidden test-environment filters.

Save the validation query next to the metric definition. A screenshot alone is weak evidence because it omits filters, SQL, and data freshness.

Step 7: Validate retries, duplicates, and failure paths

Happy-path testing is incomplete. Repeat the same request, interrupt the receiver during a small batch, and test malformed payloads in an isolated environment.

Document the expected behavior for each case:

Scenario	Expected behavior
Identical retry	Stored once or explicitly identified as duplicate
Temporary database failure	Retried with bounded backoff or placed in a recoverable queue
Invalid required field	Rejected with a diagnosable error
Unsupported optional property	Rejected or recorded according to documented policy, not silently lost
Receiver restart	No unexplained accepted-but-missing events
Delayed mobile upload	Original occurrence time retained and delay measurable

The implementation may choose different guarantees, but operators need to know whether delivery is at-most-once, at-least-once, or effectively-once after deduplication.

Step 8: Use dual-write or sampled reconciliation during migration

When replacing an existing receiver, avoid switching all traffic based on one successful test. Use dual-write, proxy mirroring, or a controlled traffic percentage where the client and infrastructure allow it.

Compare both paths over fixed windows:

total events by event name;
distinct identities using the same definition;
property presence and type distribution;
event-time delay distribution;
duplicate rate;
rejection and retry counts;
a few business-critical funnel steps.

Do not expect every total to match without analysis. Different ingestion cutoffs, bot rules, late-event handling, identity resolution, and deduplication can produce legitimate differences. The goal is to explain the differences, not force cosmetic equality.

A release gate for event pipelines

Before increasing traffic, require evidence for each item:

[ ] A unique test event appears exactly as expected in raw storage.
[ ] Identity transitions match the documented model.
[ ] Client time and receipt time are both understood.
[ ] Representative property types survive decoding and storage.
[ ] A deterministic batch produces the expected event and user counts.
[ ] ClickHouse and Superset return the same result for the validation query.
[ ] Filters, time zone, cache, and permissions are recorded.
[ ] Retry, duplicate, invalid payload, and restart behavior are tested.
[ ] Rollback steps and owners are documented.
[ ] Backups and restore procedures have been exercised for production data.

This checklist should be versioned with the deployment. Re-run it when the SDK, receiver, schema, database, driver, or dashboard definition changes.

Where SensorFlow fits

SensorFlow provides a public Apache-2.0 implementation of the path used in this guide: compatible SDK event ingestion, a Go receiving service, ClickHouse storage, and Apache Superset for SQL exploration and dashboards. The repository exposes deployment files and code so teams can inspect the data path rather than relying only on marketing claims.

It is best suited to engineering teams that want self-hosted data and are comfortable operating Docker, ClickHouse, and SQL-based analytics. It is not a drop-in replacement for every feature in a broad product analytics suite. Teams needing turnkey session replay, experimentation, feature flags, or extensive no-code analysis should compare more complete platforms as well.

The detailed ClickHouse and Superset implementation guide covers the architecture and operational boundaries. Teams migrating an existing compatible SDK path can also use the receiver-boundary migration guide.

Frequently asked questions

Should an SDK write directly to ClickHouse?

Generally, no. A receiving service should handle authentication, protocol decoding, validation, rate limits, retries, and error reporting. Exposing the database directly to untrusted clients expands security risk and makes protocol evolution harder.

Is one matching event enough to approve a migration?

No. One event validates the basic path. Approval should also cover a deterministic batch, identity transitions, property types, delayed events, duplicates, failures, aggregate SQL, and dashboard reconciliation.

Can Superset calculate funnels and retention?

Superset can visualize SQL-derived funnel and retention results, but the team normally defines the model and query semantics. It does not automatically supply every specialized product-analytics workflow.

Why keep both event time and receipt time?

The two timestamps answer different questions. Event time represents when the action occurred on the client; receipt time shows when the platform observed it. Their difference helps identify offline uploads, network delays, clock problems, and processing backlogs.

What is the most important migration metric?

There is no universal single metric. Start with unexplained event loss, identity consistency, critical-property validity, duplicate behavior, and agreement on business-critical counts. Choose thresholds before the traffic increase.

Start with one event, then prove the whole path

Reliable analytics comes from traceability, not from a green endpoint alone. Create one identifiable event, inspect its raw row, verify its semantics, reconcile a known batch, and reproduce the query in Superset. Then test failure behavior and compare old and new paths under controlled traffic.

To apply the checklist to a transparent reference implementation, review the SensorFlow deployment and validation documentation and inspect the source before sending production data.

Choosing an Event Analytics Stack Without a Feature Checklist

SensorFlow — Mon, 14 Sep 2026 13:11:32 +0000

Analytics comparisons often collapse into feature checklists. That is rarely how engineering teams experience the decision. The harder questions are migration cost, data ownership, metric governance, operational responsibility, and whether non-technical users need a purpose-built interface.

This article compares categories rather than declaring a universal winner.

Full product analytics suites

Sensors Analytics and Alibaba Cloud Quick Tracking represent the integrated commercial category. Public documentation shows broad collection, governance, and analysis workflows. Sensors Analytics, for example, documents coded tracking, visual auto-tracking, event analysis, funnels, retention, and paths.

PostHog follows a similarly broad product approach internationally, connecting trends, funnels, retention, and paths with session replay, feature flags, and experiments. These suites fit teams that value ready-made workflows and want product or growth users to answer common questions without building every metric in SQL.

The trade-offs to evaluate are procurement or hosting cost, migration, data residency, customization boundaries, and the operational model.

Lightweight web analytics

Umami and Plausible are optimized for a different job: understandable, privacy-conscious website analytics. For teams mainly asking where traffic came from and which pages or goals perform well, a compact web analytics tool may be the best answer.

That simplicity should not be confused with multi-platform product event analytics. Identity across web, mobile, mini-program, and backend events introduces a different set of requirements.

Open-source platforms with built-in analysis

ClkLog presents a self-hosted platform with multi-platform collection, ClickHouse or Doris storage, and built-in analysis screens. Its public materials separate community capabilities from professional and CDP offerings, so teams should compare the exact edition while considering the Java, Kafka, and supporting infrastructure footprint.

SensorFlow's narrower boundary

SensorFlow deliberately focuses on an inspectable data path:

Official Sensors Data SDK upload flow → Go ingestion → ClickHouse → Apache Superset

For teams already using the standard upload flow of official Sensors Data SDKs, this creates a backend-first evaluation path. They can test ingestion, identity, property types, timestamps, and queries before deciding whether to replace every client integration.

Raw events remain in ClickHouse controlled by the operator. Metrics can be expressed and reviewed in SQL, while Superset provides exploration, charts, and dashboards. This is useful when analytics must join internal business data or when teams want metric logic to remain inspectable.

The boundary matters: SensorFlow is not a feature-for-feature replacement for PostHog, Sensors Analytics, or ClkLog. It does not currently claim mature no-code funnels, session replay, experimentation, feature flags, or visual auto-tracking. Self-hosting also makes the operator responsible for TLS, authentication, monitoring, backups, capacity, upgrades, and compliance.

Five questions to ask

Is the goal website traffic reporting or multi-platform product events?
Do product users need no-code analysis, or can the team work in SQL?
Must raw events remain inside controlled infrastructure?
How expensive would replacing existing client SDKs be?
How much operational responsibility is acceptable in exchange for control?

Choose a lightweight tool when the problem is lightweight. Choose an integrated suite when workflow breadth matters most. Evaluate SensorFlow when the priority is a backend-first migration, ClickHouse ownership, and SQL-defined analysis.

SensorFlow is an independent open-source project and is not affiliated with, endorsed by, or certified by the vendors mentioned here. Compatibility must be validated against actual SDK versions and event samples.

Source: https://github.com/data-analyze-bi/sensorFlow
Documentation: https://sensorflow.site/docs
Read-only Superset demo: https://superset.sensorflow.site/

Moving product analytics safely: start with the ingestion boundary

SensorFlow — Mon, 14 Sep 2026 07:09:09 +0000

Replacing an analytics system is rarely a dashboard decision. The risky part is the event-ingestion boundary: web, Android, iOS, mini-program, and backend clients often emit events on different release cycles, with years of naming conventions and identity edge cases.

SensorFlow is an open-source, self-hosted stack designed for a narrow, inspectable transition:

SDK event upload → Go ingestion service → ClickHouse → Apache Superset

For teams already using the standard upload flow of official Sensors Data SDKs, the practical question becomes whether ingestion and storage can move into infrastructure they control without rewriting every client integration at once.

What the stack makes visible

SensorFlow processes incoming events in Go, stores them in ClickHouse, and makes them available to Apache Superset. That gives operators a direct path to inspect raw records, define metrics in SQL, and build dashboards against their own database.

The point is not to hide analytics behind another hosted layer. It is to make event data operate like the rest of the data stack: reviewable schema changes, inspectable queries, and access controls that fit existing infrastructure.

The operational boundary still matters

Self-hosting is not a shortcut around operations. Docker Compose is appropriate for evaluation, while production requires HTTPS, unique credentials, access controls, monitoring, backups, restore tests, and capacity planning.

SensorFlow also has deliberate scope limits. It is not a feature-for-feature replacement for broad product-analytics suites: session replay, experiments, feature flags, and broad no-code workflows are not provided today. It is intended for engineering teams with existing multi-platform instrumentation, a need for data ownership, and the willingness to operate ClickHouse.

Evaluate the ingestion boundary

I’m one of the maintainers. Feedback on ingestion compatibility, ClickHouse schema choices, deployment reliability, and production validation would be especially useful.