Forecast models

Pipemetry’s projection is deliberately boring arithmetic wrapped around one swappable part.

The roll-up never changes

For any as-of day:

projection = closed-won so far this quarter
           + Σ over open deals of ( P(win) × the deal's amount on that day )

Two things about this formula are fixed no matter which model you pick:

• The amount is the amount as of that day. Pipemetry reconstructs each deal’s state from its event log rather than reading today’s value, so a projection dated six weeks ago uses the amounts and stages that were true six weeks ago.
• There is no separate “time left in the quarter” multiplier. Where you are in the quarter is handled inside the probability, by conditioning on it — not by scaling the answer afterwards.

The only part that varies between models is P(win).

What is never an input

The win probability is never derived from a rep-entered probability field or from the CRM’s forecast category. Those are opinions about the outcome, and feeding them into a model that predicts the outcome would make the forecast look better than it is. They are explicitly forbidden as model inputs.

The four models

Model	What P(win) is
Cohort heuristic	The by-dollar historical win rate of the deal’s cohort (its stage, and where it is in the quarter)
Stage-weighted pipeline	A win rate per stage, and nothing else
Logistic deal score (ML)	A calibrated logistic regression over leak-free as-of-day features
Ensemble blend	A weighted average of member models’ probabilities

Which models are fitted to your data today

Only the cohort heuristic and the logistic deal score have a job that replays your own history and pins a per-workspace table. The ensemble has no table of its own — it inherits whichever of those two your workspace has already built. The stage-weighted model serves a shipped default table, the same for every workspace. Each section below says so.

Cohort heuristic — the default

The cold-start default for every workspace. For each open deal it looks up the by-dollar win rate of that deal’s cohort: its stage, bucketed by where the deal sits in the quarter (early = days 1–30, mid = 31–60, late = 61+).

Thin cohorts are the classic failure mode of this method — three deals in a bucket produce a wild rate. Pipemetry handles that with empirical-Bayes shrinkage toward a parent:

rate = (n × cohort_rate + k × parent_rate) / (n + k)

where n is the cohort’s sample size and the parent chain runs stage × day-bucket → stage → workspace-global. A small cohort is pulled toward the broader rate; a large one is left alone. The per-deal explanation lists the raw rate, the shrunk rate, the cohort size, and which parent was used, so you can redo the arithmetic by hand.

Where the rates come from. A nightly job replays your workspace’s own completed fiscal quarters — up to four of them — reconstructs every open deal’s state at sampled days inside each quarter, labels it with what actually happened by quarter end, and materialises a by-dollar rate table from that. Only completed quarters are used, so every label is realised rather than guessed.

If your workspace has no history yet, the job pins nothing and Pipemetry serves a shared default table instead of a table with no signal in it. Today’s per-tenant table conditions on stage and day-bucket; a segment dimension is not built yet.

Stage-weighted pipeline

The classic “weighted pipeline” method every sales leader already knows, and Salesforce’s default. P(win) is a win rate looked up from the deal’s stage — full stop. It does not condition on day-in-quarter or segment, and that is the point: one hand-checkable rate per stage that anybody can eyeball.

These rates are not yet built from your history

Unlike the cohort model above, this one currently serves a shipped default rate table — the same stage rates for every workspace, not your own replayed history. A per-tenant stage table is not built yet. Read this model as “the standard weighted-pipeline method, on standard rates”: useful as a transparent sanity check against the cohort number, not as a second opinion drawn from your data.

Logistic deal score (ML)

Win/loss framed as binary classification over leak-free as-of-day features, fit with a regularised logistic regression, then calibrated on a deterministically held-out fold — never on the rows the weights were fit on, because in-sample calibration inflates apparent quality. Calibration is what makes the scores addable: only calibrated probabilities can be summed into a dollar total that means anything.

Its per-deal explanation is the per-feature coefficient × value contribution.

Where the weights come from. Like the cohort model, a nightly job fits this one on your workspace’s own replayed history and pins the result. Until that has run and produced something worth pinning, the model serves a shipped default instead of weights fitted to you.

This model is registered and available, but it is not the default. Per-tenant machine learning needs real signal to be worth switching to, so Pipemetry starts everyone on the deterministic cohort model and leaves ML as an opt-in choice.

Ensemble blend

Runs several member models over the same feature vectors and returns a weight-normalised average of their per-deal probabilities. The shipped default blends the cohort heuristic and the logistic deal score at equal weight, and the per-member contributions are shown alongside the result.

Where the members come from. Each member is built from your workspace’s own pinned artifact for that model whenever one exists — the same table or weights you would get by selecting that model on its own. Once the nightly jobs have run, the ensemble is therefore a blend of two models fitted to your history rather than two shipped defaults.

The fallback is per member and silent: a member whose job has not pinned anything yet uses its shipped default while the other still uses yours, so a half-built workspace gets a blend of its own cohort rates and the standard ML weights. Every per-deal explanation names the member and the exact artifact version it ran on, which is how you tell which side of that fallback a member was on.

Before your first nightly build

A workspace with nothing pinned yet gets the shipped default for both members — the same blend of two standard models every workspace starts on. Nothing about the blend is tailored to you until those jobs have pinned something.

Choosing a model — a Pro feature

On the Pro plan a model picker sits in the app’s top bar and applies your choice across Dashboard, Trend and Forecast. The catalog it reads is org-admin-gated, and passing an explicit model to the forecast, trend or /v1/forecast endpoints requires the same Pro entitlement.

On Starter, the projection still works — you get your workspace’s active default model everywhere, you just cannot switch between models or compare them.

The p10–p90 confidence band around the projection is likewise part of the Pro plan. It is a seeded Monte-Carlo simulation over each open deal’s win/lose outcome, so it is reproducible: the same deals and probabilities always produce the same band. It never moves the headline number — the projection stays the deterministic Σ(p × amount), and the band only shows the spread around it.

Reproducibility

Every estimator is a pure function: no database reads, no clock, no network. Each one is pinned to a content-addressed artifact, so the same inputs and the same artifact always produce the same probabilities, and changing a parameter — the shrinkage k, the source quarters — is a new artifact version by construction rather than a silent change to numbers you already saw.

For the ensemble, the set of artifacts that fixes the numbers is the blend’s own — which members, at which weights — plus one per member. That is why each member’s version is printed next to every deal: the blend’s own version does not move when a member’s table is rebuilt, but the member’s does.

Related

• Accuracy and backtesting — how to check whether the model is actually right on your data.