Carpet Shop: A New Architecture
This here are two fundamental reasons for our initial investment in rearchitecting the Carpet Shop: speed and speed.
- Page speed: A good website is snappy. There is infinite literature on slowness negatively impacting engagement and conversions metrics. Why does the speed of websites matter?
- Development speed: in order to implement and try out a bunch of new ideas, including UI changes and features work, the frontend work needs to be efficient.
Changes
The architecture of the webshop was set up ~10 years ago with the popular technologies available those days:
- The data is stored in a WordPress-like custom CMS with a MySQL DB (product metadata) and images in the filesystem.
- The requests are served via PHP talking to the database, often several times for a single request
- The frontend almost fully static HTML + CSS with minimal JS.
We have reworked the system in a way that a modern, reactive frontend (built with TypeScript, Vue and Tailwind) talks to the same CMS backend. In the new setup however the frontend receives all the data about the available products (which is still tiny compared to the capacities of the low-end smartphones). Thus the navigation and exploration experience is significantly faster — the results are ready in an instance, while the images load asynchronously.
| Old architecture | Vue + Typescript + Tailwind CSS |
|---|---|
 |  |
 |  |
User visible changes
- on mobile, filter is hidden behind a button, so user immediately sees the carpets
- much faster and more responsive
- showing price
Other changes
- unfortunately, we also optimized the ads at roughly the same time, which makes time-based comparison not very useful
- summer break near the launch, again making time-based comparison pretty useless
Hypothesis
Our main goal at this point was to overhaul the infra, create a framework for future experimentation and establish a stable baseline. There is no A/B experiments at the moment.
Nevertheless, we had the following hypotheses:
- people tend to interact more with the page (avg. session length increases)
- the difference between mobile and desktop decreases (avg. session length, #pages)
- people discover the filter and interact with it at least as much as with the baseline
Analysis
Setup: compare 4 weeks (July 18—Aug 14) with the previous 4 weeks (June 20—July 17). Note that ads setup changed on July 8th. Additionally, we look into two groups of traffic:
- where the landing page is the browsing experience (ie /filter1or /shop2), which is ~25% of all website traffic
- where the user gets to the browsing experience, which is 65% of the users visiting the website
Topline metrics
Observations:
- huge drop in bounce rate, especially on desktop, although it’s unclear why desktop bounce rate went down
- one hypothesis is that it’s us who skewed the desktop metrics while we were playing & understanding what needs to be done?
- maybe slightly longer sessions on mobile overall
- session length drop is most likely us working on this
- definitely fewer page views in the experiment
Events
Observations:
- overall, people seem to be more likely to browse in the new UI, in all slices (initial scroll rate, time in Browser view)
- fewer product page views across the board, but more time spent on the ProductViewer on mobile ➝ why?
- more interaction with the filters
Conclusions
- people appear to be less confused about the product browser page (significant drop in bounce rate), more interaction and more time spent on it, more filter usage
- however shorter sessions overall, b/c fewer product page visits
- on the other hand, more time spent on the individual product pages on average
- desktop is still performing way better than mobile