Measurement
Part of Measuring B2B social selling with four evidence levels kept apart
Four reconciliation checks to pass before releasing a B2B social selling dashboard
Four reconciliation checks for a B2B social selling dashboard in England, with sample figures, a stop rule and the exception file that backs each release.
A B2B social selling dashboard should not go out until its totals balance. Four reconciliation controls, run on every refresh, show whether the source records, the loaded rows and the exception file tell the same story. If they do not, release stops.
What to take away
- Run four controls on every refreshrecords received, records loaded, duplicate share and unmatched share.
- Keep failed rows in the denominator so a clean-looking rate cannot hide losses.
- Stop release when the totals do not balance or the source version is unknown.
- Send every unmatched case to an exception queue, never to an assumed category.
Why a refresh needs a release gate
A dashboard can look finished while its numbers drift from the source. A release gate catches the drift before anyone acts on it. It is a short set of controls at the top of the build log, with one fixed rule for what happens when they fail.
The UK government's Data Quality Framework defines quality in relation to intended use and calls for defects to be addressed at source. A missing account match therefore belongs in an exception queue, not under an assumed category. The same logic applies to key metrics: a formula only means something when the rows behind it are complete.
The four controls
Show the four controls together, because each covers a failure the others miss. A clean loaded rate can hide a high duplicate share, and a low duplicate share can hide unmatched accounts. Print all four at the top of the build log.
| Control | What it counts | Divided by | Note |
|---|---|---|---|
| Records received | Source rows for the refresh period | Not a rate | Authorised test rows excluded |
| Records loaded | Accepted rows | Records received | Failed rows stay in the denominator |
| Duplicate share | Quarantined duplicate rows | Records received | System-generated retries reported separately |
| Unmatched share | Rows lacking an approved account or contact match | Otherwise valid rows | Taken from the same extract |
Those figures must reconcile to the stored exception file. Stop release if the totals do not balance or the source version is unknown. A refresh that cannot say which source version it read cannot be reproduced, so it cannot be corrected later either.
A refresh worked through with sample figures
Take a refresh of 9,800 records received, with 9,506 accepted and 294 failed. These are sample figures, and no dashboard or connector was tested. Records loaded is 9,506 divided by 9,800, or 97 per cent, because the failed rows stay in the denominator.
- Count records received for the period, excluding authorised test rows. Here the count is 9,800.
- Divide the accepted rows by that count to get records loaded97 per cent.
- Divide quarantined duplicates by the same count. If 120 rows were quarantined as duplicates, the share is 120 divided by 9,800, or 1.2 per cent.
- Divide rows lacking an approved match by the otherwise valid rows from the same extract.
- Check that the failed and quarantined rows reconcile to the stored exception file. If they do not, stop the release.
Changing the divisor to accepted rows would hide the 294 failures altogether. One denominator for received, loaded and duplicates keeps the three figures comparable from one refresh to the next.
Reading a decision card against the controls
An operations card can show accepted hand-off rate: records accepted without identity, source or stage correction divided by all social-origin records submitted that calendar month. Sandbox records are excluded, and rejected duplicates stay in the denominator.
With sample figures, 1,200 social-origin records submitted in March and 60 rejected duplicates retained give an accepted hand-off rate of 1,140 divided by 1,200, or 95 per cent. Each card also states its required-field missing share: eligible rows missing at least one required field divided by all eligible rows in the current extract, excluding authorised tests.
A card that shows attributed value should print its model, eligible interactions, lookback window and extraction date, as the note on attribution methods explains. Do not call the result revenue impact, and test any outside average against a benchmark range first. A clean refresh still cannot turn activity into an outcome, a point the measurement mistakes article makes at length.
Tie the gate to the decision register
Each refresh serves a decision, so each gate needs an owner. For each audience, record the question, owner, decision date and permitted action, and keep daily fault-clearing separate from quarterly cohort review.
Decision register fields
- Audience
- Question
- Owner
- Decision date
- Permitted action
When a control fails, the register names who is told and which action is allowed, so the hold is a routine step rather than an argument. The measure definitions behind each card, and the four evidence levels they sit on, are covered separately. Failures beyond refresh totals appear in the risk scenarios.
Make the refresh reproducible
The Government Analysis Function's reproducible analytical pipeline guidance asks for peer review and an audit trail using version control software, preferably Git. Apply this in proportion: preserve raw extracts, review transformation code and record any manual override with a reason.
Version the data dictionary in the same repository as the transformation code and store a dated copy with each release. Any card then points to the definitions in force when it was built, and a late correction can be traced to the rule that produced the original figure.
Limit personal views before sign-off
Aggregate wherever the decision allows. ICO data minimisation guidance says to identify the minimum amount of personal data you need to fulfil your purpose. Seller names, private-message text and prospect details should not appear simply because a connector provides them.
If managers use individual activity to assess staff, the ICO's worker-monitoring guidance brings accuracy, necessity, transparency and challenge rights into the design. Obtain sign-off from your data protection officer before release. The note on data protection covers source mapping and objections.
Before you release a refresh
- Count records received, excluding authorised test rows.
- Work out records loaded, duplicate share and unmatched share on the same extract.
- Reconcile all four figures to the stored exception file.
- Confirm the source version and the definition version.
- Remove personal detail the decision does not need.
- Test a source record, an unmatched case, a late stage reversal and a changed definition.
Common questions
Why do failed rows stay in the denominator?
Records loaded is accepted rows divided by records received, so the denominator includes failed rows. Removing them would leave a rate that always looks healthy and would hide the loss at the source. In the sample refresh, the 294 failures sit inside the 9,800 received.
When should a release stop?
Stop release if the totals do not balance against the stored exception file or the source version is unknown. A missing account match goes to an exception queue, not under an assumed category, so it is counted and visible rather than quietly absorbed.
Who signs off personal views?
If managers use individual activity to assess staff, obtain sign-off from your data protection officer before release. Where the decision allows it, aggregate instead, so that seller names, private-message text and prospect details stay out of the view.
