Measurement
Landing page software metrics: define the event, population and denominator for each
Define landing page software metrics by event, population, denominator, period, source, missing data and owner before interpreting any result.
Mistake: Choosing the denominator after seeing results
The costliest mistake is selecting or changing a denominator after seeing the results.
The same metric label can then conceal a different calculation, so an apparent rise or fall may come from altered eligibility or counting rather than changed visitor behaviour. Fix the definition before collection and keep it stable across reports.
Write down the event, eligible population, numerator, denominator or unit, reporting period, Europe/London timezone, data source and query version, exclusions, missing-data treatment and owner. Keep these beside the result in a dashboard definition, so an unchanged label cannot disguise a changed calculation.
Mistake: Counting a click as a completed form
A click is not a completed form. If the numerator records a button press but the intended outcome is an accepted submission, it counts activity before validation and duplicate rules have been applied, making the rate answer a different question from whether a usable lead arrived.
Define completion as a submission accepted under stated validation and duplicate rules. Choose either eligible form starts or eligible page sessions as denominator, state why it fits the decision, and do not switch basis silently; a denominator check should expose any definition change.
Record bots, repeated sessions, blocked scripts, consent states and incomplete events rather than treating missing observations as completed or failed visits. Review the UK PECR requirements and the ICO's guide to PECR before interpreting gaps; visitor choice can limit measurement and should be reported, not casually estimated.
Mistake: Treating uptime as a completed visitor task
An endpoint responding successfully does not establish that a visitor completed the journey. Availability records whether a declared endpoint or journey met its technical condition at a scheduled observation; it cannot stand in for successful form completion, because the two events and populations differ.
For critical-task completion, count accepted synthetic form submissions reaching the nominated test destination, using scheduled test journeys for the named build as the population. Keep these records apart from genuine leads, then classify failures by page, validation, integration or notification stage.
| Measure | Recorded event | Population or unit |
|---|---|---|
| Availability | Declared endpoint or journey meets its technical condition at a scheduled observation | Scheduled observations |
| Critical-task completion | Accepted synthetic form submission reaches the nominated test destination | Scheduled test journeys for the named build |
| Form completion | Submission accepted under stated validation and duplicate rules | Eligible form starts or eligible page sessions, as chosen |
| Qualified lead | Record marked qualified under the stated version | Accepted submissions reviewed under the same rules |
State the observation location, sampling interval, expected response and planned exclusions for each technical check. For journey tests, retain the build and destination that identify the test; make the service standards explicit as events, clocks and evidence so a response check is not misreported as user success.
Availability vs completed journey
- Scheduled observation at declared endpoint
- Technical condition met or failed
- Server response is not visitor task
- Synthetic form submission reaches test destination
- Report failures by page, validation, integration, notification
- Keep test records separate from genuine leads
Mistake: Calling a lead qualified without a review rule
A record is not a qualified lead merely because someone has labelled it that way. Without a defined buyer-process status, eligibility criteria and evidence, the numerator depends on unstated judgement; different reviewers or changing practice can therefore produce unlike counts under an unchanged label.
Set the qualification rule and identify its owner or reviewer; retain decision time, evidence and reversal policy, and count only records assessed under that version. Use accepted submissions reviewed under the same rules as denominator, show unreviewed records separately, and record how duplicates were treated.
Mistake: Combining transactions, revenue and contribution
Transactions, revenue and net contribution are different measures, not interchangeable names for one outcome. Combining them hides different population and timing rules, so specify the finance-approved system of record and when an order enters, leaves or changes the counted set, including how cancellations, refunds and late updates are handled.
Finance should define the amount, currency, VAT treatment, recognition date and deductions, and state every inclusion and omission. Express the calculation clearly: net contribution = attributable recognised revenue - included variable costs - included refunds - other specified deductions. Keep the period rule attached to those choices, since cancellations, refunds and late updates may otherwise be treated inconsistently between reported periods.
This calculation is not return on investment, and it does not prove the landing page caused the result. Attribute financial outcomes only under approved record and period rules; a reported commercial result is not evidence of causal impact unless a separate impact design supports that claim.
Mistake: Treating attributed credit as causal impact
Platform-attributed conversion, one of several attribution methods, is credit assigned under a named product model, not proof that a landing page created an outcome. State the property, key event, eligible channels, model, lookback window, date basis and documentation date; platform rules explain credit allocation, not causal effect.
Show unattributed outcomes and paths that cannot be joined, rather than implying complete coverage. Keep attribution distinct from causal incrementality: observing a change over time does not establish that an intervention caused it, and any stronger causal claim needs a proportionate design and counterfactual assessed by a qualified evaluator.
Worked definitions for the remaining metrics
Here is the event, population and denominator written out for the finance and attribution measures discussed above.
- Transactions.Event: an order completed and recorded in the finance-approved system of record. Population: orders from landing page sessions in the period. Denominator for a conversion rate: eligible landing page sessions; for a count, no denominator.
- Revenue.Event: revenue recognised under the finance rules. Population: transactions in the counted set. Denominator: transactions for average order value, or eligible sessions for revenue per session.
- Net contribution.Event: the calculation above, applied to recognised revenue. Population: attributable transactions in the counted set. Denominator: transactions for contribution per order, or attributable recognised revenue for contribution as a share of revenue.
- Platform-attributed conversions.Event: the named key event credited by the stated model, for example a data-driven model in Google Analytics 4. Population: key events in that property, assigned to the landing page's channels, in the reporting period. Denominator: eligible sessions from those channels, with a stated lookback window; unattributed outcomes reported separately.
Not every landing page metric will be on this list, so apply the same sentence form to any other: one event, one population, one denominator, written down before the first report.
Mistake: Approving a target before checking the evidence
A threshold chosen before the measurement is stable can turn an incomplete or inconsistent record into a decision rule. The metric owner should approve the definition and query; the decision owner should set an action threshold only after the data-quality gate and intended response are clear.
Check the quality of the evidence, its limitations and uncertainty before approval. The UK Statistics Authority's standards for official statistics emphasise suitable sources and sound methods in that setting; use them as a prompt, not as a substitute for qualified statistical, measurement, finance and privacy review.
Keep quality and methodology information with the reported result, and make quality assurance part of approval rather than an afterthought. No target is supplied: use the organisation's records and qualified statistical, measurement, finance and privacy review, including a PECR review, before approving an action threshold. This keeps statistical quality, privacy and the decision rule in view together.
