DEV Community: SensorFlow

Why Yesterday's Event Report Changed Today: A Snapshot Test for Late Arrivals

SensorFlow — Mon, 19 Oct 2026 16:56:32 +0000

A dashboard can show a higher count for yesterday without either query being wrong. An event may have happened yesterday, arrived after the first report ran, and been included in a later run. To investigate, keep event time, arrival time, and the report's as-of cutoff separate.

This AI-generated engineering note is published from the SensorFlow project account. Its synthetic code was executed locally, and the linked documentation was checked. The example is synthetic JavaScript. It is not an SDK, pipeline, or production reliability test, and it does not claim that any named analytics product loses events.

A report needs two boundaries

The event-time window answers which day an action belongs to. The as-of cutoff answers which records were available to that particular report run. For this example, both are explicit UTC instants. A record occurring at 23:59Z but arriving at 00:10Z belongs to the earlier day, yet a snapshot made at 00:05Z cannot include it.

Apache Beam's time model distinguishes event time from processing time and discusses watermarks as estimates of completeness. The idea is useful even when no Beam runner is involved: a clock passing midnight does not prove that every event for the day has arrived.

Run a small snapshot test

Save this as snapshot.mjs, then run node snapshot.mjs. The rows are made-up records, not captured customer data.

import assert from 'node:assert/strict';

const rows = [
  { id: 'a', occurred: '2026-10-14T10:00:00Z', arrived: '2026-10-14T10:01:00Z' },
  { id: 'b', occurred: '2026-10-14T23:59:00Z', arrived: '2026-10-15T00:10:00Z' },
  { id: 'c', occurred: '2026-10-15T00:02:00Z', arrived: '2026-10-15T00:03:00Z' }
];

function instant(value) {
  assert.match(value, /Z$/);
  const time = Date.parse(value);
  assert.ok(Number.isFinite(time));
  return time;
}

function dailyCount(input, asOf) {
  const cutoff = instant(asOf);
  const start = instant('2026-10-14T00:00:00Z');
  const end = instant('2026-10-15T00:00:00Z');
  const seen = new Map();
  for (const event of input) {
    const arrived = instant(event.arrived);
    const occurred = instant(event.occurred);
    if (arrived >= cutoff || occurred < start || occurred >= end) continue;
    if (seen.has(event.id)) assert.equal(seen.get(event.id), occurred);
    else seen.set(event.id, occurred);
  }
  return seen.size;
}

assert.equal(dailyCount(rows, '2026-10-15T00:05:00Z'), 1);
assert.equal(dailyCount(rows, '2026-10-15T00:11:00Z'), 2);
assert.equal(dailyCount([...rows, rows[0]], '2026-10-15T00:11:00Z'), 2);
assert.equal(dailyCount(rows, '2026-10-15T00:10:00Z'), 1);
assert.equal(dailyCount([...rows].reverse(), '2026-10-15T00:11:00Z'), 2);
assert.throws(() => dailyCount([...rows, { ...rows[0], occurred: '2026-10-14T11:00:00Z' }], '2026-10-15T00:11:00Z'));
console.log('PASS: six synthetic snapshot checks');

The first snapshot counts only a. The later one counts a and late arrival b. Event c belongs to the next UTC day. A repeated a does not increase the logical count, while a conflicting occurrence time for the same ID is rejected by this teaching rule. The cutoff uses a half-open interval: a row arriving at the cutoff is excluded.

This example assumes the ID is stable and unique in its intended scope. A real system needs a scoped event key, conflict handling, versioned event definitions, and a defined arrival timestamp. It also needs the business's chosen calendar timezone. JavaScript Date stores instants; local and UTC calendar interpretations differ, while Date.parse can be unreliable for nonstandard strings. The explicit Z strings here avoid machine-local date parsing. The test uses Node's strict assertions.

Explain revisions instead of hiding them

A useful daily report records its date window, timezone, as-of cutoff, and whether it is provisional. When a count changes, compare the two snapshots by event ID: which rows arrived later, which were duplicates, and which changed definition or were rejected? That makes “late data” a testable explanation rather than a guess.

The six checks above verify only the synthetic rule. They do not establish a universal wait period, an exactly-once delivery guarantee, or end-to-end event completeness. A real acceptance test must compare application outcomes, capture attempts, receiver responses, stored rows, and report filters under one declared contract.

Event Timestamps Need Units, Not Guesswork

SensorFlow — Mon, 19 Oct 2026 01:04:33 +0000

An event can have a valid name, a stable identifier, and a timestamp that lands decades outside the reporting period. The request may still be valid JSON. A successful HTTP response would not tell you whether the timestamp meant seconds or milliseconds.

Event timestamp validation should start with a declared unit, not a guess based on the number of digits. This tutorial builds a small, offline Node.js check for that boundary. All inputs are synthetic; no live SDK or analytics backend is required.

1. Make the unit part of the contract

Require either a field with a defined unit, such as occurred_at_ms, or a versioned source contract that explicitly declares the unit. Convert once at that boundary, then validate the normalized value. Do not silently infer seconds or milliseconds from the magnitude of an unfamiliar input.

JavaScript's Date representation uses milliseconds since the Unix epoch. That does not mean every system producing a numeric timestamp uses milliseconds. Your adapter needs to know the producer's contract before it constructs a Date.

For a concrete boundary, this example accepts a numeric value and the separate unit s or ms. A real API could instead fix the unit in its schema; clients would not need to send redundant metadata on every event.

The contract deliberately rejects numeric strings and fractional values. That is an example policy, not a claim that fractional-second formats are inherently invalid. If a source uses them, define precision and rounding in its own adapter rather than allowing accidental coercion here.

2. Run an explicit conversion check

Save the following as timestamp-check.cjs, then run node timestamp-check.cjs. It needs only Node's built-in assertion module, with no packages, account, or network access.

The fixture uses a fixed UTC acceptance window: the start of 2026 inclusive through the start of 2027 exclusive. This is a repeatable teaching boundary, not a suggested retention or backfill policy. Historical imports need a window that matches their actual contract.

const assert = require('node:assert/strict');

const START = Date.UTC(2026, 0, 1);
const END = Date.UTC(2027, 0, 1);

function normalizeEventTime(value, unit) {
  if (unit !== 's' && unit !== 'ms') {
    throw new TypeError('unit must be s or ms');
  }
  if (!Number.isSafeInteger(value)) {
    throw new TypeError('time must be a numeric safe integer');
  }
  const ms = unit === 's' ? value * 1000 : value;
  if (!Number.isSafeInteger(ms)) {
    throw new RangeError('normalized time is not a safe integer');
  }
  if (ms < START || ms >= END) {
    throw new RangeError('time is outside the fixture window');
  }
  return ms;
}

const checks = [
  ['milliseconds unchanged', () =>
    assert.equal(normalizeEventTime(START + 123, 'ms'), START + 123)],
  ['seconds converted once', () =>
    assert.equal(normalizeEventTime(START / 1000, 's'), START)],
  ['lower bound included', () =>
    assert.equal(normalizeEventTime(START, 'ms'), START)],
  ['last millisecond included', () =>
    assert.equal(normalizeEventTime(END - 1, 'ms'), END - 1)],
  ['before window rejected', () =>
    assert.throws(() => normalizeEventTime(START - 1, 'ms'), RangeError)],
  ['upper bound excluded', () =>
    assert.throws(() => normalizeEventTime(END, 'ms'), RangeError)],
  ['seconds mislabeled ms', () =>
    assert.throws(() => normalizeEventTime(START / 1000, 'ms'), RangeError)],
  ['milliseconds mislabeled s', () =>
    assert.throws(() => normalizeEventTime(START, 's'), RangeError)],
  ['string rejected', () =>
    assert.throws(() => normalizeEventTime(String(START), 'ms'), TypeError)],
  ['null rejected', () =>
    assert.throws(() => normalizeEventTime(null, 'ms'), TypeError)],
  ['fraction rejected', () =>
    assert.throws(() => normalizeEventTime(START / 1000 + 0.5, 's'), TypeError)],
  ['NaN rejected', () =>
    assert.throws(() => normalizeEventTime(NaN, 'ms'), TypeError)],
  ['Infinity rejected', () =>
    assert.throws(() => normalizeEventTime(Infinity, 'ms'), TypeError)],
  ['unknown unit rejected', () =>
    assert.throws(() => normalizeEventTime(START, 'minutes'), TypeError)],
  ['unsafe integer rejected', () =>
    assert.throws(() => normalizeEventTime(2 ** 53, 'ms'), TypeError)],
  ['JSON non-finite round trip rejected', () => {
    const received = JSON.parse(JSON.stringify({ time: NaN }));
    assert.equal(received.time, null);
    assert.throws(() => normalizeEventTime(received.time, 'ms'), TypeError);
  }],
];

for (const [name, check] of checks) {
  check();
  console.log(`PASS: ${name}`);
}
console.log(`${checks.length} checks passed`);
console.log(new Date(normalizeEventTime(START / 1000, 's')).toISOString());

The expected final lines are 16 checks passed and 2026-01-01T00:00:00.000Z. The assertion behavior is documented in Node's assertion module. The checks exercise our example policy; they do not certify an SDK integration or production ingestion service.

Notice the two integer checks. Number.isSafeInteger checks the input without turning a numeric string into a number. Checking again after multiplication protects the normalized result, not just the original value.

The two mislabeled-unit cases fail because the converted result is outside this fixture's window. That is useful defense in depth, not a universal unit detector: an input can have the wrong meaning and still fit a broad window. The producer's declared contract remains essential.

3. Keep validation separate from display and transport

An ISO string is a useful inspection aid. toISOString emits UTC with a Z suffix, which avoids depending on the machine's local display timezone. It does not verify the device clock or prove when an action happened.

Validate on both sides of serialization. JSON.stringify converts NaN and Infinity to null; an undefined property on an object is omitted. The final test demonstrates why validating only the in-memory producer value is not the same as checking what a receiver sees.

Keep distinct fields for event occurrence and receipt. An offline client can report an earlier action after reconnecting. Replacing its occurrence time with receipt time changes the meaning of time-based reports; preserving it does not eliminate clock skew either.

For a real ingestion system, define separate policies for:

Unknown or unsupported units: reject or quarantine with a reason.
Events outside the allowed range: distinguish historical replay from malformed input.
Future-looking device clocks: use an explicit tolerance rather than silent correction.
Invalid records: retain only the diagnostic fields permitted by your privacy and retention rules.

Do not turn a validation failure into a zero timestamp or today's date. Both are plausible-looking values that can hide the original problem.

4. Test the source boundary before changing old data

For a browser producer, inspect the value immediately before serialization and the parsed request at the receiving boundary. For a server adapter, test the upstream contract and the normalized result independently. For a historical import, use the source's documented period rather than this tutorial's 2026 window.

Before a migration, add a fixture with one known timestamp and its exact expected UTC instant. Preserve the source, schema version, and declared unit in whatever minimal diagnostic context your policy allows. A repaired dataset should be reproducible from a documented transformation, not from another round of digit guessing.

The acceptance criterion is narrow: declared unit, correct conversion, permitted precision, and an explicit time range. It says nothing about whether the business action was genuine, the identity was correct, or the event was delivered exactly once. Test those properties separately.

Start with one timestamp from each producer and add the boundary tests to that producer's contract checks. A green count is useful only when the accepted meaning is written down beside it.

Affiliation and AI disclosure: this account is maintained by the SensorFlow team. This article and its synthetic checks were AI-assisted; the fixture was executed locally. This is an independent validation exercise, not a production SDK test.

Missing, Null, and Empty Are Different Event Properties

SensorFlow — Thu, 15 Oct 2026 14:41:16 +0000

Affiliation: this account is maintained by the SensorFlow team. This tutorial was drafted with AI assistance; its synthetic JavaScript fixture was executed locally. It is a standalone validation exercise, not a product capability claim or a production test.

An event arrives without campaign_id. A convenience fallback turns it into direct, and a chart now reports a business conclusion that the event never established. A missing property, an explicit null, an empty string, and a real identifier should not collapse into the same value simply because they are all inconvenient to group.

Event property validation should establish two separate facts: whether the property exists, and whether its value satisfies a documented contract. Only after those checks should a reporting rule assign a business meaning. A transport success response does not answer either question.

1. Write down what each state means

For a synthetic SignupCompleted event, this exercise uses the following policy:

Absent campaign_id: campaign context was not supplied.
Explicit null: the sender supplied an explicit no-value marker.
Empty or whitespace-only string: a supplied identifier violates this contract.
A nonblank string: syntactically valid campaign identifier.
Any other type: invalid campaign identifier.

These are deliberately narrow labels. Explicit null does not prove consent was denied, and absence does not prove traffic was direct. If your source can distinguish “not applicable,” “not collected,” and “collection failed,” define separate reviewed fields or states. Do not reconstruct that evidence later from a generic null.

The JSON Schema null reference distinguishes a null value from an absent property. Its object reference also separates declared properties, required properties, and additional-property rules. Listing a property under properties alone does not make it required.

Our example accepts an absent or null campaign value but records its state. It requires an account identifier. That is a policy choice for this exercise, not a universal analytics schema.

2. Validate before choosing defaults

Save the complete example as property-contract.cjs and run node property-contract.cjs with a current Node.js installation. There are no dependencies or network calls. Every identifier below is synthetic.

const assert = require('node:assert/strict');

function fieldState(object, key) {
  if (!Object.hasOwn(object, key)) return 'absent';
  const value = object[key];
  if (value === null) return 'explicit_null';
  if (typeof value !== 'string') return 'invalid_type';
  return value.trim() === '' ? 'empty' : 'value';
}

function validate(event) {
  if (event === null || typeof event !== 'object' || Array.isArray(event)) {
    throw new Error('event must be an object');
  }
  const allowed = new Set(['event', 'account_id', 'campaign_id']);
  for (const key of Object.keys(event)) {
    if (!allowed.has(key)) throw new Error(`unexpected field: ${key}`);
  }
  if (!Object.hasOwn(event, 'event') || event.event !== 'SignupCompleted') {
    throw new Error('unexpected event');
  }
  if (fieldState(event, 'account_id') !== 'value') {
    throw new Error('account_id must be a nonblank own string property');
  }
  const campaign = fieldState(event, 'campaign_id');
  if (campaign === 'empty' || campaign === 'invalid_type') {
    throw new Error(`invalid campaign_id: ${campaign}`);
  }
  return { account_id: event.account_id, campaign_state: campaign };
}

const base = { event: 'SignupCompleted', account_id: 'synthetic-account-a' };
const valid = [base, { ...base, campaign_id: null },
  { ...base, campaign_id: 'synthetic-summer' }];
assert.deepEqual(valid.map(e => validate(e).campaign_state),
  ['absent', 'explicit_null', 'value']);
assert.throws(() => validate({ ...base, campaign_id: '' }));
assert.throws(() => validate({ ...base, campaign_id: '  ' }));
assert.throws(() => validate({ ...base, campaign_id: 0 }));
assert.throws(() => validate({ ...base, campaign_id: false }));
assert.throws(() => validate({ ...base, campaign_id: undefined }));
assert.throws(() => validate({ ...base, account_id: null }));
assert.throws(() => validate({ ...base, account_id: '' }));
assert.throws(() => validate({ event: 'SignupCompleted' }));
assert.throws(() => validate({ ...base, event: 'SignupClicked' }));
assert.throws(() => validate({ ...base, campain_id: 'typo' }));
assert.throws(() => validate([]));
assert.equal(fieldState(Object.create({ campaign_id: 'inherited' }), 'campaign_id'), 'absent');
assert.equal(validate(JSON.parse(JSON.stringify({ ...base, campaign_id: undefined })))
  .campaign_state, 'absent');
assert.equal(validate(JSON.parse(JSON.stringify({ ...base, campaign_id: null })))
  .campaign_state, 'explicit_null');
console.log(valid.map(validate));
console.log('PASS: 15 synthetic acceptance checks');

The three accepted samples retain three different campaign states. An empty string, wrong type, misspelled extra field, missing account, or wrong event name fails loudly instead of becoming a plausible-looking chart category.

The validator does not silently trim and rewrite the identifier. Whitespace-only strings fail, while other nonblank strings remain unchanged. A production contract may impose additional length or character restrictions; add them explicitly with matching tests.

3. Test the value that actually crosses the wire

One assertion is intentionally surprising: an own property containing JavaScript undefined fails this validator before serialization, but becomes absent after a JSON round trip. That is not a contradiction. These are two different objects at two different boundaries.

MDN documents JSON.stringify's conversion rules: undefined-valued object properties are omitted; array elements behave differently. A sender-side object inspection therefore cannot replace checking the serialized request and the parsed receiver-side event.

Test both boundaries when your application builds a payload in JavaScript. This does not mean every SDK uses JSON.stringify directly; SDK transformations, batching, and encoding must be verified separately. The fixture is not an SDK transport payload or a receiver integration test.

The helper uses Object.hasOwn rather than truthiness or prototype-chain membership. That keeps absent fields separate from present nulls and avoids treating inherited properties as collected data. It is not a substitute for parsing untrusted input safely or for application authorization.

4. Decide where strictness belongs

Rejecting unexpected fields helps expose the typo campain_id. It can also reject a legitimate new field during a rolling client deployment. This example chooses a closed, version-specific contract to make the failure observable; it does not recommend abruptly applying that policy to every production event.

For production, decide how old and new producer versions coexist before tightening the receiver. A quarantine path, a versioned schema, and error counters may be more appropriate than dropping a whole batch. Preserve enough safe diagnostic context to investigate, but do not copy arbitrary personal data into validation logs.

The fixture uses Node's strict assertion module so a broken expectation stops the run. Its tests verify the listed rules, not semantic truth. A nonblank account ID can still identify the wrong account; a well-formed campaign ID can still have incorrect attribution. Those need trusted business context and integration tests.

5. Keep unknown data visible in the report

After validation, report missing context separately from known campaign values. If you later group absent and explicit-null states into a single “unknown” display category, preserve the original state for investigation. Do not rename “unknown” to “direct” unless separate attribution evidence supports that interpretation.

For a practical review, check one valid value, one absent field, one explicit null, one empty value, one wrong type, and one misspelled property. Compare the in-memory event, serialized request, parsed event, and final reporting category. A small fixture with a stated contract is more useful than a chart whose defaults quietly invent meaning.

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.