How to Diagnose Conversion Problems Before Running a Test

Conversion rate optimisation should begin before anyone chooses a new headline, removes a field or opens an A/B-testing tool.

The pre-test job is diagnosis: define the digital task, identify who was eligible to complete it, validate how the flow is measured, locate the observed loss, collect evidence about possible causes and specify an intervention that can test a causal explanation.

This work ends when the team has a documented problem, evidence, a hypothesis, an intervention, an eligible population, a primary outcome, guardrails and an expected mechanism. Randomisation, sample size, statistical analysis, stopping, experiment validity and scaling belong in the separate CRO experimentation guide.

Conversion diagnosis is narrower than customer-journey mapping:

Journey mapping identifies broader customer tasks and service failures. Conversion diagnosis investigates a defined digital action, an eligible population and a measurable point of loss.

Use customer-journey mapping when the problem spans channels, customer goals, backstage processes or an end-to-end service. Use this process when a team can define the digital task precisely enough to investigate it.

1. Define the conversion event

A conversion is an event with a business or customer meaning. It is not merely any event the analytics platform labels as a key event.

State:

• the action completed;
• the point at which it is complete;
• whether it is provisional or final;
• whether duplicates, reversals, cancellations or fraudulent completions count;
• the customer value represented;
• the commercial value or cost represented, where relevant.

Examples include submitting a valid application, completing payment, booking an appointment, renewing a subscription or successfully creating an account. “Clicked submit” is not the same as “valid application received”. “Order confirmation page viewed” is not always the same as “payment settled”.

Do not optimise conversion rate without examining what the conversion represents. A higher completion rate can be harmful if it increases inappropriate applications, returns, cancellations, support demand, fraud or low-contribution orders.

2. Define eligibility

Eligibility identifies who could reasonably complete the event.

A visitor may be ineligible because the product is unavailable in their location, inventory is exhausted, the service is closed, the user lacks required documentation, the account is already complete or a technical dependency is unavailable.

Record the rules and the point at which eligibility is known. If eligibility can only be determined late in the flow, that itself may be a customer problem.

The eligible population should be stable enough that a rate change is not merely a change in who entered the denominator.

3. Define the denominator

A conversion rate is a fraction. Its meaning changes when the denominator changes.

Possible denominators include:

• eligible people exposed to the opportunity;
• eligible sessions that began the task;
• unique users reaching a defined step;
• valid attempts;
• accounts invited to act;
• applications that passed an initial requirement.

Choose the denominator that answers the decision. Then document deduplication, repeat attempts, session boundaries, cross-device behaviour, bots, internal traffic, consent effects and missing data.

A fall in conversion can be produced by better top-of-funnel reach bringing in a broader eligible audience. A rise can be produced by excluding difficult cases. Neither should be interpreted without the population definition.

4. Map the digital flow

Map the observable path from eligibility to completion. Include:

• entry points;
• required and optional steps;
• authentication;
• data entry and validation;
• external services such as payments or identity checks;
• error states;
• save-and-return behaviour;
• exits and alternative routes;
• confirmation and downstream acceptance.

Do not assume the designed flow is the flow people use. A funnel report is a visualisation of configured steps measured against recorded events, and a user who misses a step drops out of the funnel and is not counted in any later step. (1) Path analysis is a different instrument: it shows how recorded journeys differ from one another, for example between users who converted and users who did not. (2) Neither tool knows which route the organisation intended, and neither establishes that a deviation was caused by a design defect.

The map should show where the team can observe behaviour and where it cannot.

5. Validate instrumentation

Before diagnosing customer behaviour, test whether the measurement works.

For each event, verify:

• it fires at the intended point;
• it fires once when one occurrence is intended;
• required parameters are present;
• client-side and server-side events reconcile where both exist;
• errors and failed submissions are recorded;
• time zones and timestamps are consistent;
• consent states and blockers are understood;
• release changes did not alter event names or definitions;
• internal, automated and test traffic are excluded appropriately.

Know which category each event belongs to, because the categories carry different implementation obligations. Current platform documentation separates automatically collected events, enhanced measurement events, recommended events and custom events, and only the last two normally require the team to implement anything. (3) Parameters are a separate configuration step again, and have to be registered before they are available as custom dimensions or metrics. (4) Verify the result rather than assuming it: the platform provides a real-time debugging view in which collected events and their parameters can be inspected as they arrive. (5)

Successful transmission proves only that the platform received what it was configured to receive. It cannot confirm that the event definition matches the commercial or customer meaning the organisation intends. That judgement stays with the team.

One of the largest cosmetics groups I worked with had never reconciled its offline database with its several online ones. Every time a customer bought through a channel they had not used before, the system wrote a new person. The category tracking was worse: the file they sent us listing each customer’s most purchased category contained names that meant nothing to anybody. Nothing sinister was happening. They were simply counting everything wrongly, and they eventually paid a CRM supplier a great deal to sort it out. That is a commercial observation rather than a legal one, but no funnel built on that foundation would have told anyone the truth.

Instrumentation completeness should be tracked as an outcome of the diagnostic process. An attractive funnel built on missing events is not evidence.

6. Quantify where recorded loss occurs

Calculate progression and loss at each step using the defined eligible population. Report counts as well as rates. A 50% loss affecting 20 people may be less important than a 5% loss affecting 100,000.

Look for:

• abrupt step loss;
• repeated attempts;
• loops;
• long delays;
• validation failures;
• payment or authentication failure;
• abandonment after cost, eligibility or commitment becomes clear;
• downstream rejection after a nominal conversion.

Read the report carefully before believing it. Platform documentation warns that an apparent absence of a next action does not always mean the user left the funnel; it can simply mean the selected dimension did not change. (1)

Funnel analytics show where recorded loss occurs. They do not explain why it occurs.

7. Segment by meaningful context

Segment only where a difference could change the diagnosis or intervention.

Useful contexts may include:

• device, browser, operating system and app version;
• new versus returning users;
• authenticated versus unauthenticated state;
• source or campaign where it changes expectation;
• geography, language or eligibility condition;
• product, price, inventory or payment method;
• assistive-technology use where it can be measured responsibly;
• exposure to a release or technical dependency;
• customer lifecycle stage.

A French luxury house told me its main digital target was women over forty. That was its overall ideal customer, built on decades of boutique clientele. When we looked at who was actually completing purchases on the website, the two largest groups were women aged twenty-seven to forty and men aged twenty-five to thirty-five. Nobody had lied. The people who buy in a boutique and the people who buy on the site were simply not the same population, and every segment cut we ran before checking that was answering a question about the wrong audience. That is a commercial point rather than a legal one.

Avoid searching every available segment for an interesting difference. That creates false leads and post-hoc stories. Begin with plausible mechanisms and known implementation differences.

8. Inspect technical failures

Technical diagnosis should precede psychological explanation.

Review:

• application and server logs;
• client-side errors;
• failed network requests;
• latency and timeouts;
• payment and identity-provider responses;
• browser and device compatibility;
• form validation and state loss;
• broken deep links;
• authentication loops;
• release and feature-flag history;
• accessibility defects;
• third-party outages.

Reproduce failures under the conditions in which they occur. Aggregate dashboards can hide problems that affect one browser, language, payment method or assistive technology.

A technical error log can establish that a failure occurred. It cannot establish how customers interpreted the experience or what silent users did instead.

9. Collect qualitative evidence

Quantitative data locates patterns. Qualitative research helps explain actions, comprehension and context. Government service guidance treats understanding users and their needs as a continuing activity rather than a phase completed before build, and expects research to include people who do not use digital services confidently or at all. (6)

Usability research

Give participants realistic tasks that match the defined conversion. Observe what they do, where they hesitate, what they misunderstand and whether they can recover from errors.

Design the study as carefully as the interface. A review of usability measures across 180 published studies found that the choice of and reasoning about those measures often falls short of a valid and reliable account of usability, and identified weak treatment of long-term use, learning and retention, and of both small and large-scale tasks. (7) Separate work comparing commercial usability teams found that the number of problems uncovered was associated with the number and coverage of tasks rather than simply the number of participants, so adding people does not compensate for testing too narrow a set of tasks. (8)

Record participant characteristics, scenario, device, assistance and deviations rather than presenting a session as a universal customer truth.

Customer interviews

Interviews can reveal goals, constraints, vocabulary, expectations and remembered explanations. They cannot establish actual behaviour or prevalence by themselves.

Ask about specific recent events rather than hypothetical preference. Compare stated explanations with observed behaviour and system evidence. Classic psychological research argues that people may have little or no direct introspective access to higher-order cognitive processes, and that reports about those processes may instead reflect implicit causal theories or judgements about what plausibly caused a given response. (9) Treat an interview account accordingly: as evidence about how someone understood and now remembers an experience, rather than as a direct reading of why they behaved as they did.

Surveys

Surveys can collect stated attitudes from a larger sample, but question wording, timing, non-response and sampling determine what the result means.

Use surveys to estimate the distribution of a clearly defined reported experience, not to prove the causal effect of a proposed change. Publish the eligible sample, invitation method, response rate, question wording and exclusions.

Search and navigation analysis

Internal search terms, zero-result searches, refinements, backtracking and repeated navigation can reveal mismatches between customer language and the site’s information structure.

They do not establish that a new label or structure will improve completion. Search use is selected: people who search may differ from people who navigate silently or leave immediately.

Form analysis

Track field-level validation, correction, repeated focus, time, abandonment and downstream rejection. Review whether the field is necessary, whether its format is explained, and whether the organisation already holds the information.

A field associated with abandonment is not automatically the cause. It may be the point where cost, eligibility, effort or commitment becomes visible.

10. Review support and complaint evidence

Support contacts, complaints, chat transcripts and call reasons contain customer language and repeated failure patterns that analytics may not capture.

Classify them against the digital flow. Link issues to release, device, product and eligibility context where possible. Review silent failures too: support evidence over-represents people who chose and managed to contact the organisation.

Track whether a conversion change shifts workload into support or complaints. Removing explanatory content can shorten a form and increase downstream contacts; that is not an unqualified improvement.

11. Distinguish symptom from cause

Examples of symptoms include:

• abandonment rises at payment;
• mobile completion is lower;
• users repeatedly edit one field;
• a page attracts long dwell time;
• support contacts mention that something is not working.

Candidate causes might include technical failure, unexpected cost, missing information, inaccessible interaction, unclear eligibility, low trust, deliberate comparison or a mismatch between campaign promise and service reality.

Write several candidate explanations. Do not turn the first plausible story into the hypothesis.

12. Formulate candidate explanations

A useful explanation specifies a mechanism linking evidence to behaviour.

Weak:

The page is confusing.

Stronger:

Eligible mobile users cannot see the full validation message after the postcode field fails, so they repeat the same entry and abandon without knowing how to recover.

The stronger explanation identifies population, condition, observable mechanism and point of loss.

13. Identify evidence against each explanation

For every candidate, ask what would make it less likely.

Examples:

• If the issue is a browser defect, why is loss similar on unaffected browsers?
• If price surprise is the cause, why do interviews and support contacts not mention it?
• If the label is misunderstood, why do observed users complete the field correctly?
• If trust is the mechanism, why does the pattern begin before the trust information appears?

In fashion, making it easier to reach the basket worked, and so did sending people who arrived from an advertisement straight to a category page rather than a landing page. I assumed the mechanism was general. At a French automotive brand we ran the same treatment and bounce rates rose slightly instead of falling. Car buyers were not trying to move faster; they were trying to read and compare. We stopped the campaign and spent the effort on making the product detail pages easier to read, which improved both bounce and overall engagement. My point is commercial: a mechanism that survives in one category is not evidence about another.

Disconfirming evidence reduces the risk of collecting only observations that support a preferred design idea.

14. Triangulate evidence

No single source completes the diagnosis. Combine methods whose limitations differ.

• Funnel analytics. Show where recorded loss occurs. Cannot show why. Main risk: instrumentation error.
• Error logs. Show technical failure. Cannot show customer interpretation. Main risk: missing client-side failures.
• User research. Shows behaviour and comprehension in a defined setting. Cannot establish population prevalence. Main risk: test-context and task-coverage effects.
• Interviews. Reveal goals and stated explanations. Cannot establish actual behaviour or frequency. Main risk: recall and social-desirability bias.
• Surveys. Estimate stated attitudes at scale. Cannot establish causal effect. Main risk: question wording and non-response bias.
• Support contacts. Show repeated failures and customer language. Cannot show the experience of silent users. Main risk: complaint selection.
• Session recordings. Show observable interaction patterns. Cannot show motivation or representative prevalence. Main risk: privacy and selection issues.
• Experiments. Estimate the effect of a defined change. Cannot fully explain why. Main risk: scope and external-validity limits.

Triangulation does not mean that three weak signals become proof. It means comparing evidence generated through different methods and looking for convergence, contradiction and coverage gaps. Mixed-method research has long used triangulation for exactly this purpose, while noting that its value depends on how the methods complement and challenge one another rather than on combination alone. (10)

Heatmaps and session recordings

Treat heatmaps and session recordings as observational evidence. They can reveal repeated interaction patterns, dead clicks, scrolling, hesitation or recovery attempts. They cannot read motivation, establish representative prevalence or prove that a visual element caused abandonment.

They also carry a legal requirement that is frequently overlooked. Under current regulator guidance, logs or recordings of individual visitors and the actions they took fall outside the statistical-purposes exception unless obtained for security purposes, which means consent must normally be obtained before the technology is used. (11) Where a genuinely security-focused use is claimed, the narrow strictly-necessary route has to be satisfied on its own terms, and adding product analytics or user-experience research to the same tool removes reliance on that exception for the combined purpose. (11) The same guidance requires clear and comprehensive information about what the technologies do and what the consent covers, including telling users about any third parties and allowing them to access specific information about each one. (11)

Beyond the legal position, minimise capture, mask sensitive fields, control access and retention, and do not record authentication, payment or special-category information merely because the tool permits it.

15. Prioritise hypotheses

Assess each candidate using:

• customer severity;
• affected volume;
• commercial consequence;
• evidence strength;
• technical confidence;
• expected effect;
• implementation effort;
• reversibility;
• legal and ethical risk;
• measurement feasibility;
• dependency;
• opportunity cost.

Scoring acronyms can formalise judgement. They do not make it scientific. A score depends on estimates, weights and missing information. Keep the inputs visible and document any override.

Prioritise the problem and mechanism before polishing the intervention. Several interventions may test the same explanation with different risk and cost.

16. Define an intervention

An intervention is the controlled difference intended to alter the proposed mechanism.

Specify:

• exactly what changes;
• what remains constant;
• the eligible population;
• where and when exposure occurs;
• technical and content versions;
• dependencies;
• accessibility and privacy requirements;
• rollback conditions.

Avoid bundles that change copy, layout, price, navigation and eligibility at once unless the decision concerns the bundle as a whole. A broad redesign may estimate the effect of the package but reveal little about which mechanism mattered.

17. Define the expected mechanism

Use a hypothesis structure such as:

For [eligible population], changing [defined experience] is expected to affect [primary outcome] because [proposed mechanism]. We will consider the explanation supported if [evidence threshold], provided [guardrails] do not deteriorate.

Example:

For eligible mobile applicants who receive a postcode validation error, displaying the error beside the field and moving focus to it is expected to increase valid form completion because users will understand the required correction and can recover without searching the page. We will consider the explanation supported if valid completion improves under the pre-specified experiment decision rule, provided duplicate submissions, support contacts, accessibility defects and downstream rejection do not worsen.

The experiment tests the defined intervention and proposed mechanism within its scope. It does not prove a universal psychological law. Randomised evidence has to be interpreted within a wider body of knowledge, because randomisation alone does not settle questions of mechanism, transportability or what will happen in another population or setting. (12)

18. Define outcomes and guardrails

The primary outcome should represent successful completion, not a proxy chosen because it moves more often.

Track as relevant:

• instrumentation completeness;
• eligible population;
• task completion;
• failure and error rate;
• abandonment;
• time and effort;
• accessibility;
• customer support contacts;
• complaints;
• contribution where relevant;
• hypothesis throughput;
• proportion of hypotheses supported;
• repeated failure patterns.

Guardrails should cover customer welfare, accessibility, inappropriate completion, downstream quality, contribution, cancellations, returns, support and technical reliability.

For accessibility, WCAG 2.2 supplies testable success criteria and treats complete processes rather than isolated screens as the unit of conformance. It also states expressly that conformance does not address every user need, so automated checks should be supplemented with human evaluation and relevant user research. (13)

Some guardrails are legal obligations rather than internal preferences. In the United Kingdom, the Digital Markets, Competition and Consumers Act 2024 prohibits misleading actions, misleading omissions, aggressive practices and contraventions of professional diligence where they are likely to cause the average consumer to take a different transactional decision, and treats certain practices as unfair in all circumstances, including falsely stating that a product or particular terms are available only for a limited time in order to force an immediate decision. (14) The statute defines a transactional decision broadly enough to include clicking through a site, retaining a product or exercising a cancellation right, and where a trader could reasonably foresee that a group is especially vulnerable to a practice, the assessment is made against the average member of that group. (14) The regulator has published guidance explaining how it reads those provisions, while stating that the guidance illustrates how the law may apply and is not a definitive interpretation of it. (15)

None of that prescribes a diagnostic process, a research method or a testing methodology, and it sets no target conversion rate. It constrains the means by which a completion is obtained. A variant is not acceptable merely because it converted better.

Handover to experimentation

The diagnostic phase is complete when the test specification contains:

• documented problem;
• evidence and its limitations;
• causal hypothesis;
• defined intervention;
• eligible population;
• denominator;
• primary outcome;
• guardrails;
• expected mechanism;
• implementation dependencies;
• evidence that would count against the explanation;
• decision to be made after the result.

Pass that specification to the CRO experimentation process. That page should decide randomisation, sample size, analysis, stopping, interference, validity and scaling.

Where conversion work competes with acquisition, retention, pricing, customer experience, operations or measurement, use the wider marketing optimisation operating model to prioritise conversion work against other marketing decisions.

The marketing measurement framework should govern shared metric definitions. Use the martech stack audit where missing or duplicated technology is the actual constraint, the CAC methodology where acquisition cost is part of the decision, the acquisition-versus-retention framework for the broader economic trade-off, and the ethical digital-marketing checklist for campaign and data-use review.

Frequently asked questions

References

1. Google LLC. [GA4] Funnel exploration. Product help documentation. No reference number; help article identifier 9327974. No publication date and no last-updated date stated on the page. No beta, preview, deprecation or sunset notice displayed. Vendor documentation for the publisher’s own product, not an independent, regulatory or standards source. Not UK law. https://support.google.com/analytics/answer/9327974

2. Google LLC. [GA4] Path exploration. Product help documentation. No reference number; help article identifier 9317498. No publication date and no last-updated date stated on the page. No beta, preview, deprecation or sunset notice displayed. Vendor documentation for the publisher’s own product. It does not identify an intended or commercially preferred route. Not UK law. https://support.google.com/analytics/answer/9317498

3. Google LLC. Set up events. Developer documentation. No reference or version number. No publication date stated; page states last updated 9 June 2026. No beta, preview, deprecation or sunset notice displayed. Vendor implementation guidance, not independent evidence or a measurement standard. Not UK law. https://developers.google.com/analytics/devguides/collection/ga4/events

4. Google LLC. Set up event parameters. Developer documentation. No reference or version number. No publication date stated; page states last updated 3 June 2026. No beta, preview, deprecation or sunset notice displayed. Vendor implementation guidance. It does not validate whether a parameter captures the organisation’s intended business concept. Not UK law. https://developers.google.com/analytics/devguides/collection/ga4/event-parameters

5. Google LLC. Monitor events in DebugView. Product help documentation. No reference number; help article identifier 7201382. No publication date and no last-updated date stated on the page. No beta, preview, deprecation or sunset notice displayed. Vendor documentation. It confirms that data was received as configured, not that the configuration is correct. Not UK law. https://support.google.com/analytics/answer/7201382

6. Government Digital Service. 1. Understand users and their needs, GOV.UK Service Standard. Official UK government digital-service standard guidance. No reference number. Published 8 May 2019; live page, no separate last-updated date displayed. Not marked draft or under review. Issued for government services; it is guidance for public-service design, not UK law, and it does not prescribe a research method or establish that any intervention will increase conversion. https://www.gov.uk/service-manual/service-standard/point-1-understand-user-needs

7. Kasper Hornbæk. Current practice in measuring usability: Challenges to usability studies and research. Peer-reviewed review article covering 180 studies, International Journal of Human-Computer Studies, volume 64, issue 2, pages 79 to 102. DOI 10.1016/j.ijhcs.2005.06.002. Issue dated February 2006; no online-first date stated in the publisher record. No correction, erratum or retraction notice displayed. No commercial affiliation or funding statement displayed. Not UK law. https://www.sciencedirect.com/science/article/pii/S1071581905001138

8. Gitte Lindgaard and Jarinee Chattratichart. Usability testing: what have we overlooked?. Peer-reviewed conference paper, CHI ‘07: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, pages 1415 to 1424. DOI 10.1145/1240624.1240839. Published 29 April 2007; no separate online-first date shown. No correction, erratum or retraction notice appeared in the retrievable publisher record. No commercial affiliation or interested-party funding statement visible in that record. Not UK law. https://dl.acm.org/doi/10.1145/1240624.1240839

9. Richard E. Nisbett and Timothy D. Wilson. Telling More Than We Can Know: Verbal Reports on Mental Processes. Psychological Review, volume 84, number 3, May 1977, article beginning at page 231. Bibliographic details are taken from the printed article. A publisher-owned record could not be opened during verification: the publisher’s database refused automated access and the journal archive returned a security challenge. The following are therefore recorded as unverified: the digital object identifier, the canonical publisher URL, the publisher’s document-type label, any online-first date, and current correction, erratum, expression-of-concern or retraction status. The identifier commonly given is 10.1037/0033-295X.84.3.231, unconfirmed against a publisher record. Not UK law.

10. Todd D. Jick. Mixing Qualitative and Quantitative Methods: Triangulation in Action. Peer-reviewed methodological article, Administrative Science Quarterly, volume 24, issue 4, pages 602 to 611. DOI 10.2307/2392366. Issue dated December 1979; no original online-first date stated on the record. No correction, erratum or retraction notice displayed. No interested-party affiliation or funding statement exposed on the record. Not UK law. https://www.jstor.org/stable/2392366

11. Information Commissioner. Guidance on the use of storage and access technologies. Non-statutory UK regulator guidance. No reference or version number stated. First published 20 December 2024; finalised 29 April 2026 following consultations in December 2024 and July 2025, the latter covering changes made to the Privacy and Electronic Communications Regulations by the Data (Use and Access) Act 2025. Now final: the earlier draft notice retained in the update history is superseded and no chapter is shown as remaining under consultation. UK regulator guidance, not UK law, and not a substitute for legal advice on a particular technology or purpose. https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-the-use-of-storage-and-access-technologies/

12. Angus Deaton and Nancy Cartwright. Understanding and misunderstanding randomized controlled trials. Peer-reviewed methodological article, Social Science and Medicine, volume 210, pages 2 to 21. DOI 10.1016/j.socscimed.2017.12.005. Issue dated August 2018; no online-first date stated in the retrievable publisher record. No correction, erratum or retraction notice displayed in that record. No commercial affiliation or funding statement exposed. Not UK law. https://www.sciencedirect.com/science/article/pii/S0277953617307359

13. World Wide Web Consortium, Inc. Web Content Accessibility Guidelines (WCAG) 2.2. International technical standard published as a W3C Recommendation. Reference REC-WCAG22-20241212. Current Recommendation dated 12 December 2024, superseding the Recommendation of 5 October 2023; first public working draft 27 February 2020. No last-updated date is stated on the Recommendation itself. The associated errata page was last modified 2 July 2026 and its entries since December 2024 are classified as editorial; W3C states that a substantive correction would not become normative until a new Recommendation is published, and none is shown. Not UK law and not UK regulator guidance: it is an international standard, and conformance does not by itself establish compliance with UK equality or accessibility law. https://www.w3.org/TR/WCAG22/

14. Parliament of the United Kingdom. Digital Markets, Competition and Consumers Act 2024. Primary legislation, 2024 chapter 13. Royal Assent 24 May 2024. Sections 225 to 230 and 245 to 247, and Schedule 20, came into force on 6 April 2025 under regulation 2 of the Digital Markets, Competition and Consumers Act 2024 (Commencement No. 2) Regulations 2025, SI 2025/272. The consolidated text states that it is up to date with changes known to be in force on or before 28 July 2026. Section 260, concerning subscription cancellation, is not yet commenced and is not relied on here. UK law. https://www.legislation.gov.uk/ukpga/2024/13

15. Competition and Markets Authority. Unfair commercial practices. Non-statutory UK regulator guidance, reference CMA207. Published 4 April 2025; last updated 18 November 2025. Final; the preceding consultation draft of December 2024 is superseded. The guidance states that it illustrates how the law may apply, that its examples are not exhaustive, and that it is not a substitute for or a definitive interpretation of the law. UK regulator guidance, not UK law. https://www.gov.uk/government/publications/unfair-commercial-practices-cma207

Position as at 29 July 2026. Regulator guidance, technical standards, vendor documentation and the commencement position of individual statutory provisions all change, and one source above carries an explicit unverified-metadata note. Check the issuing body’s current page before relying on any normative statement in this article.