博文

Latency Histograms Need a Bucket Contract Before You Merge Them

Two applications both report a histogram called checkout_latency. One uses milliseconds, the other seconds. Or they share a unit but use different bucket boundaries. Adding the arrays by position produces a plausible chart with an undefined meaning. Before merging latency histograms, match the measurement, unit, population, time interval, aggregation temporality, and bucket layout. A bucket count is only meaningful together with the boundary and counting convention that produced it. Know whether a bucket is cumulative Prometheus metric types describes classic histogram buckets as cumulative counts with inclusive upper bounds. An observation of 150 ms contributes to both the 200 ms and 300 ms buckets. Summing all those buckets would count some observations repeatedly. The positive-infinity bucket represents the observation count. This article uses that classic, cumulative convention. Do not copy the array interpretation into every telemetry format. The OpenTelemetry metrics data mo...

Keep Test Events Out of Production Metrics with an Environment Contract

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...

Do Not Average Conversion Rates Without Their Denominators

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...

Do Not Sum Daily Unique Users into Weekly Active Users

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...

Track a Workflow Run, Not Just a User

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 HTTP Success Is Not an Analytics Event: Test Every Ingestion Boundary

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...

Mixpanel or SensorFlow? Choose the Analysis Workflow Before the Event Destination

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...