Answer in brief
Do not start with a new design. First find where the purchase breaks down: before product selection, in the cart, during payment or after checkout. Then separate a genuine store problem from a measurement problem. The same chart showing plenty of visits and few purchases can require very different.
1. Separate three different problems first
Before discussing conversion, reconcile the store, payment provider and analytics. Are orders being created? Which are actually paid? Which were cancelled or refunded? Which appear in the report? Record the period, time zone, currency and order status used for the comparison.
An order being created, a payment being confirmed and a purchase appearing in analytics are different checks. This matters particularly for payment on delivery. Do not change the definition of success between reporting periods.
| What you observe | What to check first | What you cannot yet conclude |
|---|---|---|
| Analytics shows no purchases, but the store has orders | Event collection and data inclusion rules | “The store needs rebuilding” |
| There are no orders or checkout attempts | Traffic, the offer and product selection | “The payment provider is responsible” |
| Checkout starts but does not finish | Forms, shipping, payment and errors | “Everyone considers the price too high” |
| Money was received, but the team cannot see the order | Payment confirmation and order transfer | “The customer changed their mind” |
| Orders exist, but cancellations or returns are common | Stock, descriptions, fulfilment and return reasons | “More purchases already mean more profit” |
Keep a few concrete examples with dates and order identifiers. A screenshot of an aggregate chart is not enough to locate the break. Remove personal information from any public report.
2. Check that analytics is actually recording purchases
GA4 provides separate events for product views, carts, checkout, purchases and refunds. These need to be implemented correctly; pageview tracking alone is insufficient. 1
We suggest agreeing a short measurement map with the developer. The names below are GA4 events, not ready-to-paste code or a requirement to use that particular analytics system.
| GA4 event | Meaning | What to reproduce during verification |
|---|---|---|
| view_item | Product view | Open an actual product page |
| add_to_cart | Cart addition | Check the selected size and colour |
| begin_checkout | Checkout begins | Start checkout from the cart |
| add_shipping_info | Shipping information submitted | Check that the address is accepted |
| add_payment_info | Payment information submitted | Do not count this as payment success |
| purchase | Purchase | Reconcile it with the defined order status |
| refund | Money refunded | Check its connection to the original purchase |
Google defines the events; the final column is our verification plan. 1 For a purchase, inspect transaction_id , items, value and currency against the event specification. 2 Keep one order's identifier stable, and verify that reopening its confirmation does not double-count the result.
Do not force two systems to match at any cost. Shopify, for example, documents how cookie consent and ad blockers affect collection of some session-based data. 4 Explain differences before changing collection, and do not bypass privacy protections to improve a chart.
Do not send names, email addresses, phone numbers or other identifying information to GA4, including in URLs and event parameters. 12 Use safe test data and the analytics system's debugging facilities for verification.
3. Locate the transition that needs investigating
Visitors, sessions, events and orders often get mixed together. Choose the counting unit before analysing a funnel. Shopify explicitly distinguishes orders from sessions with a completed purchase: one session can contain several orders. 3
For this example, use 2,000 comparable store sessions . The funnel is closed and sequential: each later step counts only after the previous step in the same session, and a session counts once per step. Repeated events are not added together. Purchases through shortcut routes are investigated separately.
| Stage | Sessions | Share of previous stage | Share of all 2,000 sessions |
|---|---|---|---|
| Store entry | 2,000 | — | 100% |
| Product viewed | 1,200 | 60% | 60% |
| Product added to cart | 120 | 10% | 6% |
| Checkout started | 80 | 66.7% | 4% |
| Purchase meeting the agreed criterion | 20 | 25% | 1% |
Calculate a transition as sessions at the next stage / sessions at the previous stage × 100% . For the overall share, use the original 2,000. Do not divide events by people and present it as the same metric.
Here, 120 of the 1,200 product-view sessions reached the cart. Investigate size selection, availability, the offer and measurement. Twenty of 80 checkout sessions finished; examine shipping and payment. The table does not establish either cause.
Do not label the other 1,980 sessions “lost customers”. We do not know how many visitors intended to buy immediately. If your report is user-based, follow its definitions and align the denominators rather than copying these figures.
4. Compare incoming traffic with the offer
Take several main landing pages and follow the route from a specific advertisement or post. Do the product, price, image, available size and conditions match? Does an advertisement for a jacket lead to that jacket, rather than an unrelated collection?
Segment the investigation by device, source, delivery country, language and landing page. These are suggested analytical views, not a requirement to produce dozens of reports. Start with the segment that changed and compare it with a genuinely comparable period.
Consider an illustrative case: a style article brings more magazine visits while store orders remain unchanged. A lower purchase share across that combined audience does not establish that checkout deteriorated. Examine visitors to shopping pages separately.
Before increasing advertising expenditure, check whether the advertised variant is available and the destination is served. A different button cannot resolve an offer that the arriving shopper cannot use.
5. Audit the clothing product page: sizing, fit and stock
Baymard's research shows participants using sizing information to choose clothing, while photographs on people provide context for fit and scale. 7 8 This supports examining those elements, not promising a particular sales increase.
Our approach is to answer actual shopping questions rather than require the same number of photographs for every product. Use the following criteria for an internal review.
| Shopper's question | What to inspect | Evidence that the information is ready |
|---|---|---|
| Will this size fit? | Measurements, units and measuring instructions | Body and garment measurements are distinguished |
| How does it fit? | Worn photographs, length and silhouette | The model's worn size is stated when known |
| What is the material? | Composition, texture and care | The description belongs to this product |
| Is my variant available? | Size and colour combination | An unavailable variant cannot be ordered unnoticed |
| What does this price include? | Contents and the selected variant | Images, title and cart remain consistent |
| How do delivery and returns work? | Delivery, exchange and return conditions | Information is available before payment and matches operations |
Test colour switching separately. Does an available size remain selected? Do the photographs update correctly? Does the interface display stock that is not actually available? Ask a colleague to complete this without guidance from the site's designer.
When measurements are missing, obtain them from the product team. Do not invent centimetres to fill a chart. Artificial scarcity and unsupported reviews are not substitutes for a clear, accurate offer.
6. Follow checkout and payment all the way through
Test more than a successful order. Start in the provider's authorised test environment. Stripe, for example, documents simulated successful payments, declines and authentication without moving real money. 6
Choose one product, delivery option and payment method. Once the baseline route is clear, add failure scenarios. This is a proposed test plan, not a claim that testing has already taken place.
| Scenario | Expected behaviour | What to record |
|---|---|---|
| Successful test purchase | One correct order and clear confirmation | ID, value, currency and statuses |
| Address outside the delivery area | Clear explanation before a payment attempt | Screen and message text |
| Invalid required field | The affected field and correction are identified | Reproduction steps |
| Declined payment or cancelled authentication | No false “paid” status | Safe error code and order status |
| Back navigation or page refresh | Consistent cart and order state | Action sequence and outcome |
| Delayed confirmation or repeated click | An observable intermediate state, without uncontrolled duplicates | Event timeline |
W3C recommends clear success and error notifications with guidance on correction. 9 A red outline without explanatory text is therefore insufficient for our acceptance check.
Establish when the shopper sees the final amount and available delivery. Also test a discount code, guest checkout where provided, and return from an external payment window. One successful test does not validate every payment method or country.
7. Test the mobile journey, not just a speed score
Open the product, select a size, bring up the form keyboard and return from payment. Does a banner, chat widget or sticky bar obscure an essential action? Can the error be found without searching the whole page? Can text be enlarged while the purchase remains usable?
For technical checks, Core Web Vitals targets are LCP ≤ 2.5 seconds, INP ≤ 200 ms and CLS ≤ 0.1 , assessed at the 75th percentile with mobile and desktop separated. 10 These are not conversion benchmarks or sales promises.
CrUX field data is not available for every page: eligibility and data-sufficiency requirements apply. 11 Missing field data does not mean poor speed. Treat a laboratory test as a diagnostic snapshot under stated conditions, not the experience of the whole audience.
Prioritise the affected product and checkout pages, not just the homepage. Record the device, browser, connection conditions and action. “The interface freezes during size selection” is a more actionable task than “make the site faster”.
8. Did the completed order reach the team?
For external payments, Shopify describes situations in which payment succeeded but its confirmation was not communicated correctly to the store. 5 An absent order in the expected list does not always mean the shopper abandoned it.
We recommend following the chain: order record → payment confirmation → agreed status → staff task → customer message. An email notification should not be your only evidence that an order exists.
Assign ownership of discrepancies. Check how the team detects a record without notification, late confirmation or failed CRM transfer. Do not manually change a financial status without checking the source records and following the agreed process.
For enquiry-led stores, apply the same logic to forms. Google provides generate_lead for a generated enquiry. 13 A messenger click does not prove that a message was received. Follow a test enquiry to the employee and measure the subsequent sale separately.
9. Separate fixing a defect from testing a hypothesis
A reproduced failure does not need to wait for an A/B test before being recognised as a failure. It does need a repeat test after the fix. “Different wording will increase sales” is a separate hypothesis requiring outcome evaluation.
| Priority | Evidence | Action | Completion criterion |
|---|---|---|---|
| First: purchase blocker | A reproducible failure | Fix the form, payment or availability issue | The previously failing route passes a repeat test |
| Next: reliable measurement | Events conflict with explainable order statuses | Correct the data-collection map | Control orders can be traced correctly |
| Then: missing information | Measurements or conditions are absent | Add verified information | It is available at the relevant decision point |
| Afterwards: improvement hypothesis | An observation exists, but causation is unproved | Test the change with a comparable audience | Main outcome and side effects have been evaluated |
A work item should state the observation, evidence, expected behaviour, owner and verification. “Improve UX” defines neither the work nor its acceptance criteria.
10. Evaluate changes without inventing uplift
Suppose the share of sessions with a purchase changes from 1% to 1.5%. This is an increase of 0.5 percentage points, or 50% relative to the starting value , not 50 percentage points. Correct arithmetic still does not prove that a website change caused it.
Record concurrent changes to advertising, pricing, assortment, stock and delivery. Compare equivalent periods and segments. For an A/B test, define the main metric, allocation, evidence requirements and stopping condition in advance. Do not stop at the first favourable result.
With few purchases, prioritise reproduced failures and careful observation rather than declaring a winner after a handful of orders. There is no universal rule that seven days is sufficient. When causation cannot be isolated, say that a difference was observed after the change, with other influences unresolved.
Monitor cancellations, returns and team workload as well as purchases. A discount or faster-delivery promise may change order counts without making the result profitable or operationally achievable.
11. When a redesign is justified
We suggest considering a systematic redesign when the investigation reveals connected obstacles across navigation, product pages and checkout that cannot sensibly be corrected locally. Support the decision with observations, a proposed journey and a way to evaluate it before full release.
A redesign does not independently fix incorrect stock, unsuitable traffic or a missing server-side payment confirmation. If a platform limitation is involved, return to “Building a clothing store: Tilda, Shopify or custom development?” For budgeting, use “How much does a clothing ecommerce website cost? Launch and the first year”.
The purpose here is different: identify the problem before choosing an expensive solution. Sometimes a corrected form and accurate product information are sufficient. Sometimes several journeys need rebuilding. Let the investigation determine the scope.
13. Where a store owner should begin
Collect the affected page, period, traffic source, definition of a successful purchase and a few anonymised examples. Follow the order journey and record the first confirmed break. Then assign either a correction or a hypothesis test, according to the evidence.
A useful diagnosis is not a hundred generic tips. It explains what is broken, what is still unknown and what to check next.
Discuss a customer-journey review with VITON13, from the clothing product page to a confirmed order received by the team. Share access only through an agreed secure process, never through public comments or article content.
Practical checklist
- 1. Separate three different problems first
- 2. Check that analytics is actually recording purchases
- 3. Locate the transition that needs investigating
- 4. Compare incoming traffic with the offer
- 5. Audit the clothing product page: sizing, fit and stock
- 6. Follow checkout and payment all the way through
Questions and answers
Why does the store get visits but no orders?
Visit counts alone cannot establish the reason. Reconcile orders with analytics, then follow product selection, shipping, payment and delivery of the order to the team. Investigate a reproducible journey before prescribing a complete redesign.
What conversion rate should a clothing store achieve?
Do not diagnose the store using one borrowed number. Define the counting unit, successful status, data source, period and audience first. Comparable internal segments and verified explanations are more useful for making a decision.
Should I increase advertising to generate sales?
Treat that as a separate hypothesis. First check that the offer is available to the intended audience, checkout works and the outcome is measured. Otherwise, more unsuccessful attempts may look like progress.
Should I switch platforms immediately?
No. Reproduce the limitation and assess a local correction first. Discuss migration when the required journey cannot be maintained acceptably, not because one report looks weak.
Will a discount or free shipping solve the problem?
Offer them only with a checked calculation and clear conditions. Assess costs, cancellations and fulfilment as well as purchase counts. Neither is a substitute for repairing a broken checkout.