Methodology

Every metric carries a bound, not a guess

A rate computed from a handful of events is not the same as one computed from a million, and a dashboard that prints 100.0% for both is lying by omission. Drengr never shows a bare point estimate for a rate. Each one is a Wilson score interval at 95% confidence — the same interval a statistician would compute by hand — rendered next to the number so you can see how much the data actually supports.

• 2 successful checkouts out of 2 is not “100% conversion.” It is a point estimate of 100% with a 95% interval of roughly [34%, 100%]. We show the interval.
• As your sample grows, the interval tightens on its own. Nothing is hand-tuned; the width is a function of the count.
• Counts and sums that are exact (installs, event totals) are labelled exact. Rates that are estimated are labelled Wilson 95%. The label tells you which kind of number you are looking at.

The point is honesty about uncertainty. A wide interval is not a bug to hide — it is the truthful answer when the data is thin.

Your users' raw data never becomes readable to us

Drengr's SDK classifies every captured field on the device, before anything is sent, into one of three dispositions:

• Drop — credentials and card numbers (passwords, API keys, bearer tokens, PANs validated by the Luhn checksum, PEM private keys). Replaced by a placeholder and never stored, never even encrypted. They are worthless as analytics and dangerous to keep.
• Seal — personal data the way your team may legitimately need it, but we must not: emails, phone numbers (including E.164), names, SSNs, IBANs (validated by the ISO-7064 mod-97 checksum), MAC and IP addresses, device IDs, crypto wallet addresses, and any unrecognised free-text. The raw value is encrypted on-device with a key we do not hold; only a same-typed placeholder travels in the clear.
• Keep — the business signal that makes analytics possible: statuses, amounts, currencies, quantities, event names, product and order IDs. Plaintext, so the discovery engine can name events from it.

The default is seal: a field is only kept in the clear if it is credential-free and either a non-PII number/boolean or an explicitly allow-listed business field. Everything else is sealed. This posture favours recall over precision on purpose — over-sealing costs you a data point, under-sealing costs a user their privacy, and only one of those is acceptable. The same classifier runs across our JavaScript, Android, iOS, and Flutter SDKs. See the Security page for how the binaries themselves are built and signed.

Cross-tenant benchmarks: the k-anonymity mechanism, published

Comparing your app to “apps like yours” is only useful if it can never leak a single participant's numbers. The rule in one line: we share the pattern, never the participant. Concretely:

• Minimum cohort size (k-anonymity). A peer group is never shown unless it contains at least k = 5distinct organisations. Below that threshold, the comparison simply does not render — no “based on a few apps” hand-wave.
• Coarse buckets before raw quartiles. At the minimum cohort size, exact quartiles would beindividual orgs' values. So below a higher population threshold we publish only a coarse tier (a bucket), not a raw percentile, and your position is expressed as a peer percentile with a stated direction (higher-is-better vs lower-is-better), computed over peers excluding your own app.
• Diversity guard. A cohort where a single organisation dominates the sample is not anonymous in practice, so a homogeneity check gates publication in addition to the raw count.
• Per-org clamping.Any one organisation's contribution to a pooled statistic is bounded, so a single outlier — or a bad actor — cannot swing or reconstruct the aggregate.

Today most pools are still below k and therefore show nothing — that is the honest state of a young network, and we would rather show an empty benchmark than a fabricated one.

On the roadmap: differential privacy

k-anonymity plus clamping is the floor, not the ceiling. The planned next step is a differentially private benchmark: a single, central, budget-tracked noised release over clamped per-org values (one release per window, to avoid the averaging attack a per-request mechanism invites), gated on billed-organisation identity to defeat sign-up farms. When it ships, the privacy budget and mechanism will be documented here — not buried. We would rather tell you the mechanism than ask you to trust the brand.

Detection suggests; you decide

Drengr figures out what kind of app you have — commerce, gaming, media, social, and so on — from the shape of your event vocabulary, so your metrics are framed by the model built for how apps like yours actually work, not a generic funnel with your logo on it. Two honesty rules govern it:

• No fake confidence. Detection never emits a confidence percentage. It reports a signal_strength of strong, moderate, or weak — each gated by an auditable rule over the observed counts, not a hand-wavy score.
• It suggests; it never asserts. A detected kind is a suggestion shown for you to confirm or override. It is never silently written back or auto-applied. Your dashboard only ever reflects a kind a human chose.

What we deliberately do not do

• We do not print a precise-looking number the data cannot support. If the sample is thin, you see a wide interval or nothing.
• We do not send your users' raw personal data to our servers to compute a metric. It is sealed on the device first.
• We do not auto-assign your app a category and quietly reshape your analytics around it. You confirm the model.
• We do not show a peer benchmark that could expose an individual participant. Below the cohort and diversity thresholds, it does not render.

If you find a place where a number on your dashboard is not backed by the discipline described here, that is a bug and we want to hear about it — the whole product exists to not tell that particular lie.