sensorflow

A staging build sends a synthetic checkout success to the production event destination. The payload is structurally valid, so the dashboard can count it as customer activity unless the pipeline has an explicit rule for that situation. A successful delivery has not proved that the event belongs in the report. Keep test and production analytics events separate through a contract covering origin, destination, allowed environment values and report eligibility. An environment label alone does not create isolation or prove where a record came from. 1. Describe the producer before you choose a filter OpenTelemetry's deployment environment convention defines deployment.environment.name and values such as staging and production. It also warns that this attribute does not change the service identity uniqueness rules. A familiar service name is therefore not enough to identify the intended environment. Its resources documentation describes attributes of the entity producing telemetry. T...

One channel converts at 50%, another at 10%. An average of 30% looks plausible until you discover that the first channel had ten eligible attempts and the second had ninety. The percentages alone have hidden the size of the populations they describe. For disjoint groups measured under the same contract, a pooled conversion rate is the sum of conversion counts divided by the sum of eligible counts. A simple average answers a different question: the average of the group rates when each group receives equal weight. 1. Keep counts beside every percentage Consider a fully synthetic example, not a customer result: Group A has 5 conversions from 10 eligible attempts: 50%. Group B has 9 conversions from 90 eligible attempts: 10%. The pooled rate is 14 conversions from 100 attempts: 14%. The equal-weight average of the two rates is 30%. Neither number is a mysterious software error. They use different weights. If the question is how the combined eligible population performed, 14% is the ap...

Monday has two active accounts. Tuesday has two. Wednesday has one. That does not tell you whether the three-day window contains two, three, four, or five distinct accounts. The missing information is overlap: did the same accounts return on different days? Weekly active users require deduplication over the whole weekly window, not addition of daily distinct counts. First fix the identity key, qualifying behavior, environment, timezone, and window. Then take the union of qualifying identities. A daily-count-only export generally cannot recover the exact union. This is a tutorial about a custom metric, not a reproduction of any vendor's default dashboard. Google's user metric documentation distinguishes total, active, new, and returning users; those labels are not interchangeable. Our example counts signed-in accounts that perform one explicitly selected action, not people inferred across devices. 1. Write the aggregation contract before the query For this fixture, an acti...

Two browser tabs, one account, two unfinished workflows. A user-level report can accidentally combine the start in one tab with the completion in the other. Workflow event tracking needs a unit smaller than a person: one explicitly identified run of the business process. This tutorial uses synthetic events and a small, runnable Node.js validator. It tests grouping, duplicate delivery, conflicting identifiers, and missing stages. It does not connect to an SDK, database, or production service, and the example numbers are not SensorFlow performance or customer results. What should identify a workflow run? A workflow run is one attempt to carry a particular business process from its defined start toward its defined outcome. Attach the same stable workflow_run_id to its stages. Scope it by project, preserve it across delivery retries, and use a different identifier for a genuinely new run. A user identifier answers who; a run identifier answers which process. For example, one account m...

An event upload can receive a successful HTTP response while the eventual report is still missing a row. That does not automatically prove data loss: validation, asynchronous processing, identity rules, deduplication, filters, and query time windows can all change the result. The useful question is which boundary has actually been verified. I maintain SensorFlow. This AI-assisted engineering note describes a test method, not a production benchmark or a claim that SensorFlow, PostHog, or another tool loses a particular share of events. The sample identifiers below are synthetic. What does an event capture response prove? An HTTP response proves only what that endpoint's documented contract says it proves. For example, HTTP 202 Accepted means the request was accepted for processing; completion is not guaranteed by that status. Even a 200 response can represent a capture boundary rather than a finished analytics query. Read the specific product's response and validation semant...

An engineer searching for a Mixpanel alternative may be solving one of two very different problems. The product team may need a better way to build and explain funnels. Or the data team may need events to land first in a ClickHouse database it operates. Those requirements can overlap, but they should not be collapsed into a “hosted versus open source” checkbox. Quick answer: Start with Mixpanel when product managers need a built-in interface to define funnels, apply filters, and explore behavior. Evaluate SensorFlow when the existing instrumentation uses compatible Sensors Data SDK traffic, the team wants the event receiver and raw ClickHouse rows under its own control, and SQL plus Apache Superset are acceptable working tools. SensorFlow is not a feature-for-feature replacement for Mixpanel. I maintain the SensorFlow project. This comparison uses public product documentation, not an independent benchmark or a customer case study. It describes a choice of workflow and responsibility...

Your signup dashboard rises after a button redesign, but the account database does not. The instrumentation may be counting a promise to do something as if the action had already succeeded. Before optimizing a conversion rate, separate the user's intent, the transport result, and the durable business outcome. I maintain SensorFlow. This AI-assisted tutorial describes a measurement contract and synthetic acceptance scenarios, not customer results or a built-in conversion engine. What should a conversion event prove? A conversion event should represent a named business state confirmed by the system responsible for it. A click proves an interaction occurred; an HTTP response proves only what that endpoint's contract says. Neither automatically proves that an account, order, or export completed. Consider three deliberately separate event names: signup_submitted , signup_accepted , and account_created . The first can describe a valid form entering the request path. The second ca...

A dashboard reports fewer sessions after an ingestion change, even though the number of events stays stable. Before interpreting that as more engagement, check whether the timeout, identity key, event order, or observation window changed. A session count is the result of a definition applied to events, not a direct count of people. I work on SensorFlow. This AI-assisted tutorial uses synthetic, offline fixtures and a small Node.js implementation; it is not a claim that SensorFlow implements this session model or that a client SDK has been tested end to end. Start with a testable definition An inactivity session groups qualifying events for a chosen actor key while consecutive event gaps remain below a specified threshold. The actor key, qualifying events, timestamp semantics, and equality at the threshold are part of the metric contract. Changing any of them can change the result without changing product behavior. Google Analytics documents a default inactivity timeout of 30 minute...

I maintain SensorFlow. This tutorial was drafted with AI assistance and checked with an offline synthetic fixture. It does not represent customer results or a built-in attribution feature. A visitor arrives from a tagged newsletter, visits an internal page, and returns later from a partner link. If every navigation overwrites a single source property, a later signup can lose the original entry evidence. Keeping only the first value has the opposite limitation: it cannot answer what brought the visitor back. Store separately named, explicitly scoped observations: an initial entry snapshot and a latest entry snapshot. Neither is automatically a person's lifetime acquisition source. Define identity scope, expiry, consent, and reset behavior before connecting these observations to conversion events. Name the observation before choosing an attribution model This example covers one synthetic browser scope and a supplied ordered sequence of external entry observations. It does not de...

I maintain SensorFlow. This tutorial was drafted with AI assistance and checked with the runnable synthetic fixture below. Feature adoption is not the number of feature events divided by your entire user base. For an account-level question, first define the accounts that were eligible to use the feature, then count how many of those accounts completed the qualifying action during a specified window. Keep the population rule, success event, and time boundary alongside the percentage. This tutorial uses a fixed eligibility snapshot taken at the start of the reporting window. It is one explicit measurement policy, not a universal definition of adoption. Start with a question that has a unit Suppose your product offers scheduled exports to selected workspaces. A product manager asks: “Of the customer accounts enabled for scheduled exports at the start of this week, how many completed an export this week?” The unit is an account, not a person, browser, or delivered event. Two employees...

A day-one retention report can fall simply because today's newest cohort has not had a complete opportunity to return. Treating that cohort as zero does not measure disengagement. It measures a mixture of behavior and unfinished observation. Separate complete return windows from pending windows before calculating a final rate. Record the starting event, return event, identity, timezone, cohort-entry policy, and completeness cutoff. Only then does “day one” describe a reproducible metric rather than a label on a chart. This is an engineering note from the SensorFlow maintainers, using synthetic event data and an independent offline calculation. It is not a benchmark, customer result, or a claim that a vendor's full retention engine has been reproduced. What does day-one retention mean here? In this tutorial, day-one retention is the fraction of accounts that complete their first signup on a UTC calendar date and trigger FeatureUsed on the immediately following UTC date. A c...