How We Increased Mobile Conversion By 30%

By Kumar Padmanabhan, Director of Web Engineering (Art.com)

At Art.com, we don’t embrace new technologies just for the sake of embracing them. We look for opportunities in our portfolio of projects and programs to identify optimal technology solutions and enhancements for our services. When there’s a good fit with high-return potential for our customer experience and developer ergonomics, we introduce new technologies to our stack. This way, we’re able to incrementally update without having to overhaul our platform every few years. We used this approach in the redesign of our product details page, which now includes a visualization tool that lets customers view art in different frame styles (before they buy) and more.

One of the most critical additions we’ve made to our technology stack recently is our new web client platform which we built using Node.js. We also introduced JavaScript frameworks ReactJS and Flux to handle isomorphic and SEO-optimized execution of code on the server side. We’ve learned so much in doing so and wanted to share our success story with others who are perhaps considering a similar effort.

HOW WE WENT ABOUT IT

First, we identified the top three to four solutions for each technology layer in our stack. Second, we evaluated each technology solution against our needs, including performance, scalability, and developer ergonomics.

On top of our Node.js layer, we re-evaluated the client-side of JS Framework. We do have a homegrown JS Framework using MVC design patterns, which has served our needs but is a few years old. So we looked outside and considered Angular, React, Ember, and Backbone. We did a real-time use-case scenario proof of concept using all of these frameworks and ended up choosing React.JS.

Along with Node and React, we chose to use Fluxible based on its isomorphic capabilities which allow us to execute JavaScript and render server-side HTML to solve the SEO problem. Integrating Fluxible allowed us to maintain our existing SEO services and API interface which allowed us to continue to provide our product meta tags, keywords, and qualifiers without additional code changes.

For orchestration, we have considered using Promises, but decided to use Async.js primarily due to compliance with the existing ecosystems. The same holds true for dependency management. We considered Browserify and WebPack and decided to use Browserify for ease-of-use and developer ergonomics, although WebPack provides more features.

We did spend quite a bit of time discussing what kind of CSS framework we should use. We first considered Foundation.css and Pure.css initially, primarily due to ease-of-use and its being lightweight. However, as we started to build the HTML structure and components, we realized that it is better to build the responsive behavior in-house to achieve the desired responsive behavior without a bloated grid framework. For our pre-processing engine, we considered using LESS, SAAS, or Stylus. We decided to use Stylus due to its built-in functions and variables.

Last, but not least, we chose Bunyan as a logging tool in order to have visibility over errors (both application as well as system), but also wanted to measure how each component of our stack was performing. The logs are rotated every two hours and fed into Splunk, which provides dashboards to have visibility around server performance in terms of CPU and memory consumption.

OUR CHALLENGE

As with any big technology platform changes, we certainly run into the usual challenges of time, scope, and resources. Our biggest challenge was twofold: 1) we absolutely had to keep the roadmap schedule to run A/B testing to evaluate how the new product details page performed, and 2) from a technology perspective, we needed to stabilize the platform so that the business was not impacted during the holidays by the third week of November.

Additionally, we wanted to be absolutely sure that the data we gathered during the test period was statistically significant so that we confidently make business decisions. We configured and ran a few dummy A/B tests in production prior to the launch so that all the data we collected was correct and complete. This helped us during the test and as a result, we ended up conducting two A/B tests as opposed to one planned test.

THE RESULTS

Within the days of launch, we have collected volumes of data. We’ve analyzed the results by device (desktop, tablet, and mobile) in addition to regular KPI’s. The highlight? Our mobile conversion is up about 30% compared to the previous experience. Servicing revenue (from framing, and other art servicing options) from tablet traffic is up as well compared to that of the desktop experience.

However, the desktop metrics trailed in comparison to the old experience. With all the instrumented analytics, we quickly identified the potential cause as well as the resolution. To keep the business impact positive during holidays, the tablet and mobile users were shown the new experience whereas the desktop users continue to see the old experience. Given that the holiday period is now over, we’ve re-launched the A/B test with a few changes just for desktop and tablet.

From a technology standpoint, we wanted to be sure that the platform could handle peak traffic and sales during Black Friday, Cyber Monday, and throughout the holidays. We were happy to see that the memory utilization stayed pretty flat as did the CPU.

MEMORY UTILIZATION

CPU UTILIZATION

SUMMARY

We believe technology can make a profound impact on business when used in conjunction with the right opportunity. This initiative has proved that our strategy is working, and the team is confident in rolling out this same strategy for the rest of Art.com Inc.’s websites.

Questions or comments? Let us know.

[Image credit: Art.com]