Skip to main content

​
What it is

fit_completeness_rate is the share of the fit score’s 108 inputs that are live for your company, as a ratio between 0 and 1. Higher means the fit score can be drawn from more of the picture. It is the headline figure of the Customer fit module, which shows it as a percentage with the count beside it — for example, 36 of 108. It answers the question to ask before reading any fit score: how much of what the score should know does it actually know? A fit score built on a third of its inputs and one built on nearly all of them can show the same number and mean very different things. It also says what the fit score may be used for: It is published for your company as a whole, on the company and period object.

​
How it is calculated

Modelled. The count itself is fixed arithmetic: fit_completeness_rate = inputs live ÷ 108. The 108 inputs are counted a module at a time. Each module that feeds the fit score supplies a fixed number of them — Signals 18, Data model 12, Churn risk 5, and so on, with 9 reserved for later versions of the model. When a module is running for your company, all the inputs it feeds count as live; when it is not running, or is held back for a missing tool, none of them do. The Customer fit page lists every module and its count. If Data model, Signals, Data integrity, Segments and Customer value are running and nothing else is, 12 + 18 + 1 + 1 + 4 = 36 inputs are live, and the rate is 36 ÷ 108 = 0.333. Why it is called modelled. Every value Beacon publishes carries one of three words, and the word is set by which part of Beacon owns the value. Customer fit is one of the small, fixed set of parts that reason rather than calculate, so its values are modelled — this one included, even though the count behind it is plain arithmetic. Nothing in it is estimated, and the same modules running always give the same figure. See Definitions for the three words.

​
Where it comes from

No read interface or MCP tool serves this value yet. This table publishes its shape ahead of the doors. Because it is modelled, it is written into a CRM as a band — under 30%, 30% to 70%, or over 70% — rather than as an exact figure.
Where the choice is made. This value is not open by default on any door. The choice happens when a reader grant that reaches it is issued or widened, when you subscribe to events, or when you turn the CRM property on. Whoever makes it is shown who becomes able to see the value, and their yes is recorded.

​
How fresh it is

It moves as soon as a module that feeds the fit score starts or stops running for your company. Which reading stands for a period is not yet declared; until it is, read the value with its own computed_at. Both timestamps travel with it: the moment the value describes, and the moment Beacon last worked it out.

​
Currency and rounding

Neither applies. It is a ratio of two counts of inputs, with no unit and no currency.

​
What changes it

A module that feeds the fit score starting to run for you — usually because you connected the tool it needs — raises it. A module stopping, or being held back because a tool disconnected, lowers it. Nothing about your customers moves it: a company with a thousand customers and one with ten read the same if the same modules are running.

​
What it is not

  • Not the fit score. That says how well each customer fits. This says how much of the picture any fit score can be drawn from.
  • Not completeness for one customer. The fit model also defines how complete the score is for each customer — a customer missing from one of your tools has fewer inputs than the company figure. That figure is designed and not calculated yet.
  • Not data_completeness_rate. That asks whether the records Beacon expected from your tools arrived. This asks which modules are running.
  • Not a count of connected tools. One tool can switch on several modules, and a module can need more than one tool.
  • Not something you can set. It moves only as modules start and stop running.