Transparency data

Methodology and quality statement: BIST digital service performance indicators

Published 6 October 2026

1. Introduction 

The Department for Business, Innovation, Science and Trade (BIST) digital performance indicators publication provides management information on the performance and usage of digital services delivered by BIST. These services support businesses, investors and government stakeholders through a range of transactional and informational offers, including:

• registrations
• applications
• information services
• tools
• digital engagement products

The publication presents a range of indicators aligned to the Government Digital Service (GDS) Service Standard 10, which requires services to define success measures and monitor performance.

These include measures of service usage (users and sessions), user satisfaction, transactions and completion rates. The indicators are intended to support understanding of service performance and trends over time, providing evidence on service usage, user experience and outcomes to help assess whether services are meeting user needs and delivering intended benefits 

Owing to differences in service purpose, audience and measurement methodology, the indicators should primarily be used to understand trends within individual services rather than to compare performance between services. 

This document describes the methodology used to produce the published indicators, the quality assurance processes applied prior to publication and limitations that users should consider when interpreting the data. It should be read alongside the published data tables and service-specific metric definitions.

2. Data sources

This publication combines data from 2 primary sources.

Metrics are extracted from reporting datasets derived from Google Analytics 4 (GA4) or from the operational systems that support individual services. These datasets provide the source data used to calculate the published indicators and are subject to validation and quality assurance checks before publication.

2.1 GA4

GA4 is used to measure how users interact with digital services. Analytics tracking is implemented across participating services to collect information on website and service usage, including metrics such as users, sessions and engagement.

These measures help provide an understanding of how services are being accessed and used. As GA4 relies on website analytics tracking, figures may be affected by factors such as cookie consent decisions, browser privacy settings and ad blockers. 

2.2 Backend operational systems

These are used where the metric relates to information generated or recorded directly by the service, such as registrations, applications, submissions or user feedback. These systems provide the authoritative source for service outcomes and are used where a service can directly record whether a transaction or outcome has occurred.

Unlike web analytics data, these measures are derived from the operation of the service itself and are not affected by web analytics limitations such as cookie consent preferences. 

3. Metric methodology

3.1 Total users, cumulative users and total sessions 

Definition 

Total users measures the number of unique users who accessed a service during the reporting period. 

Cumulative users represents the total number of unique users observed since June 2025. Users are deduplicated across the full reporting period. 

Total sessions measures the number of visits made to a service during the reporting period. A single user may generate multiple sessions. 

Figures are derived from GA4 and are reported at service level.  

Data collection 

User and session data are collected through GA4 tracking implemented across participating digital services.  

Figures are extracted from service-level reporting datasets derived from GA4. Data is processed through a standard reporting pipeline, and metrics are calculated using a consistent methodology across services to support comparability and consistency of reporting 

Activity is recorded when users interact with service webpages and digital products. 

Calculation 

Users are reported using the GA4 user metric. Users are reported using the GA4 user metric. This metric is intended to count unique users within the reporting period and removes duplicate activity from the same user where this can be identified by GA4. Figures are reported monthly, meaning a user is counted once within a given reporting month but may be counted again in subsequent months if they return to the service. Users accessing a service from multiple devices or browsers may be counted as more than one user due to the limitations of web analytics tracking. 

Cumulative users represent the total number of unique users recorded since June 2025. Users are deduplicated across the entire period, meaning an individual who accesses a service in multiple months is counted only once in the cumulative total 

Sessions are reported using the GA4 session metric and represent visits to a service during the reporting period. A single user may generate multiple sessions if they visit the service on more than one occasion. Figures are reported monthly. 

Validation 

Before publication: 

• data extracts are checked for completeness
• reporting periods are validated to ensure all days are represented
• figures are reviewed for unexpected month-on-month changes
• figures are checked against the equivalent metrics reported directly in GA4 to confirm that data extraction and calculation processes have operated as expected 
• where known issues with analytics tracking have occurred, the potential impact on reported figures is assessed and any material issues are documented 

Quality considerations and limitations 

Users and sessions are based on web analytics data and are subject to the limitations of GA4. 

These limitations include: 

• users declining analytics cookies
• browser privacy settings and ad blockers
• implementation changes to analytics tracking

As a result, user and session figures should be understood as an indicator of service usage rather than an exact count of individuals.

3.2 User satisfaction

Definition 

User satisfaction measures the percentage of survey respondents who reported a positive experience when using a service. For this publication, a positive response is defined as a user selecting ‘Satisfied’ (4)* or ‘Very satisfied’ (5)* on a 5-point satisfaction scale. 

Data collection 

User satisfaction data is collected through service feedback mechanisms deployed within individual digital services. The point at which feedback is requested varies by service and is reflected in the published satisfaction measure definition for each service. 

Calculation 

User satisfaction is calculated as: 

(Number of responses rated 4 or 5) ÷ (Total responses received) × 100 

Results are published as percentages alongside the number of responses received. 

Validation 

Before publication: 

• survey response volumes are checked for completeness. Survey response data is reviewed to identify any unexpected gaps or anomalies in collection 
• satisfaction percentages and response volumes are checked against source reports to confirm calculations have been applied correctly 
• significant changes in satisfaction scores or response volumes are reviewed with service teams to determine whether they reflect genuine changes in user feedback or potential data quality issues

Quality considerations and limitations 

User satisfaction measures are based only on users who choose to provide feedback and may not be representative of all service users. Response volumes vary considerably between services and can affect the reliability of comparisons. 

Response volumes are published alongside user satisfaction percentages and should be considered when interpreting results. Lower response volumes may result in greater variability in reported satisfaction rates and may make results more sensitive to individual responses 

User satisfaction measures should therefore be interpreted alongside the published response count and used primarily to understand trends within a service over time rather than to compare services directly. 

As with any online feedback mechanism, responses may occasionally include non-genuine or automated submissions. Survey volumes and response patterns are reviewed as part of the validation process, although it may not always be possible to identify all anomalous responses

3.3 Transactions 

Definition 

The transactions indicator measures the volume of completed or meaningful user actions recorded by each digital service during the reporting period. The definition of a transaction varies by service, reflecting the different purposes and user journeys across BIST digital services. 

For services classified as transactional, the metric generally represents a completed service transaction recorded in a backend system, such as a submitted application, form, contact request, registration or recorded interaction. 

For services classified as informational, the metric represents a defined engagement action that indicates meaningful use of the service, such as viewing information pages, launching a tool, viewing a dataset or interacting with an AI-enabled feature. 

Data collection 

Transaction data is sourced from one of the following: 

• backend service systems, where the service records completed submissions, registrations, applications, reports or interactions
• GA4, where the transaction definition is based on tracked user behaviour, such as page views, events, clicks, sessions or engagement thresholds

Figures are aggregated monthly at service level. Each service has a specific transaction definition, which is published alongside the data to aid interpretation. Because transaction definitions vary across services, figures should not be interpreted as directly comparable between services without considering the published definition. 

Validation 

For backend data sources, transaction counts are extracted from the relevant operational or service reporting datasets and aggregated to the reporting period. Where services use GA4, transaction counts are derived from predefined event, page-view or session-based logic agreed with the relevant service team. 

Before publication, figures are reviewed by the Performance Analysis team. Validation checks include: 

• confirming that data is available for the full reporting period
• checking that extracts have run successfully
• reviewing month-on-month movements for unexpected changes
• checking that metric definitions have been applied consistently
• reconciling figures against source dashboards, operational reports or service-level reporting where available
• confirming any unusual movements or data quality issues with service teams where needed

Quality considerations and limitations 

Transaction metrics are intended to provide a consistent indicator of service use, but users should note that the definition of a transaction differs by service. For some services, a transaction reflects a completed operational process, such as an application or form submission. For others, particularly informational services, the transaction reflects a defined engagement action rather than a formal completed transaction. 

GA4-based measures are subject to the usual limitations of web analytics data, including the impact of cookie consent, browser settings, tracking implementation and users accessing services across multiple devices or sessions. Backend measures may also be affected by service-specific recording practices, system changes or operational definitions. 

For this reason, transaction figures are best used to understand trends within a service over time, rather than to make direct comparisons between different services.

3.4 Completion rate 

Definition 

Completion rate measures the proportion of users or sessions that progress from a defined starting point to a defined successful outcome. 

As digital services differ significantly in purpose and user journey, the specific definition of a completion varies by service and is published alongside each metric. 

Completion rates are calculated as: 

Completion Rate = Completed journeys or actions ÷ Started journeys or opportunities × 100 

Examples include completed applications, completed registrations and defined engagement outcomes. 

Data collection 

Completion metrics are collected using on of the following: 

• backend operational systems that record journey starts and successful submissions 
• GA4, where start and completion events are defined through agreed tracking and measurement frameworks

The start and end points used to calculate completion are service-specific and are documented within the publication. 

Validation 

Before publication: 

• start and end volumes are checked for completeness
• completion rates are checked against the underlying start and completion volumes to confirm calculations have been applied correctly
• unusual month-on-month movements are investigated
• service teams are consulted where unexpected changes are identified
• definitions are reviewed to ensure consistency with agreed service measurement approaches

Quality considerations and limitations 

Completion rates should be interpreted in the context of the service-specific definition. 

Not all completion rates represent the successful completion of a transactional process. For some services, completion reflects a meaningful engagement action such as viewing information, launching a tool or clicking a recommended link. 

GA4-based completion measures are subject to the limitations of web analytics data, including cookie consent, browser settings, tracking implementation and user behaviour across multiple sessions or devices. 

Completion rates based on small numbers of starts may be volatile and sensitive to individual user actions. Services with low volumes should therefore be interpreted with caution. 

Completion rates are intended primarily to support understanding of performance trends within a service over time and should not be used to compare services directly without considering the underlying definition.

4. Comparability of metrics 

The indicators included in this publication serve different purposes and are derived from different collection methods. Users should exercise caution when making comparisons between services, as differences in service design, audience, transaction volumes and measurement approaches may affect reported performance. In most cases, the indicators are best used to understand trends within a service over time rather than to compare performance between services.