Today, CSS preprocessors are a standard for web development. One of the main advantages of preprocessors is that they enable you to use variables. This helps you to avoid copying and pasting code, and it simplifies development and refactoring.
We use preprocessors to store colors, font preferences, layout details — mostly everything we use in CSS. But preprocessor variables have some limitations.
In other words, six out of 10 “add-to-cart” actions on eCommerce sites do not result in sales!
To alleviate this situation, eCommerce marketers need to understand their users’ behavior better. They need to know the following:
Why do users abandon carts?
What measures can be taken to prevent cart abandonment?
What really makes user return to an eCommerce site and checkout an abandoned cart?
How can window shoppers be converted into customers?
VWO ran a survey with online shoppers, gaining critical insights on common cart abandonment issues. The respondents, more than 1000 in number, lay in the age group of 18 to 65 years and belong to the US territory.
Note: This report does not claim to represent the full picture of the state of cart abandonment worldwide. It attempts at providing answers to some of the most important issues regarding cart recovery, and eCommerce optimization as a whole.
Here are the key findings from the report:
Why Do Shoppers Abandon Carts?
The biggest reason users don’t complete the purchase process is “hidden item costs.” Not showing the total bill amount upfront doesn’t sit well with them.
One-fourth of the respondents will not checkout if they encounter “unexpected shipping cost.” Other crucial concerns for users include “having to create a new account for checkout” and “payment security.”
eCommerce sites can reduce cart abandonment by providing the estimated cost of shipping and additional taxes on the product description page itself.
If Shoppers Choose to Buy the Product They Abandoned, How Would They Do It?
About a quarter of respondents (22%) would buy the product they initially abandoned from another website if offered a better deal.
This user preference was followed by “buying the product from a physical store” and “buying from a more trustworthy website.”
Interestingly, a total of 41% respondents would go on to purchase the product from a different site.
eCommerce sites can display popular trust seals and employ social proof to nudge users towards completing a purchase.
What Convinces Shoppers To Buy From an Unfamiliar Website?
A user’s perception of a new website is influenced greatly by the experiences of other shoppers with that website. 30% users would buy products from an unfamiliar website based on the customer reviews presented there.
Trust seals prove to be the second biggest factor, followed by “a deal too good to pass.”
eCommerce sites should encourage users to write reviews for the products they’ve bought. After users complete a purchase, they can be targeted with emails, soliciting product reviews. They can also be provided with incentives, if required.
Do Shoppers Add Products to Cart Without the Intention of Buying? If Yes, Why?
Almost half (45%) of the users that add a product to their cart without willing to buy it, do that to know its final price. Users want to be aware of all the costs which might show up at the checkout page, such as shipping cost and taxes.
35% use the add-to-cart function as a wishlist. 10% users hope to get a discount on the product later.
This again emphasizes the importance of providing transparency in the product cost.
What Motivates Shoppers to Buy the Product They Abandoned?
A whopping 58% respondents said that emails and ads, which offer a discount on an abandoned product, brings them back to the website. This proves the effectiveness of retargeting in reducing cart abandonment.
Applying the scarcity principle to retargeted emails/ads also works with some shoppers. 9% respondents said that they return to buy a product if it’s going out of stock.
Do Shoppers Abandon a Purchase When Their Bank Rejects the Transaction?
25% respondents said that they’ve abandoned a purchase at least once because of the bank rejecting the transactions.
eCommerce sites need to offer multiple payment options to users. The mode of payment can include digital wallets and cash on delivery service.
What Motivates Window Shoppers To Make a Purchase?
99% users who don’t actively look for products to buy admit that time-bound offers encourage them to make a purchase.
Almost half of the respondents (48%) will buy a product if offered a limited-time discount, even when they’re just window shopping.
eCommerce sites should run time-based offers (promoting urgency) to attract window shoppers.
Which Part of the Checkout Process Frustrates Online Shoppers the Most?
Nothing frustrates shoppers more than filling a piece of information twice — 32% respondents admitted to this.
A close second was “too many form fields” having the votes from 26% respondents. 14% said “not being able to change/modify order” is what they hate the most in a checkout process.
eCommerce sites must ensure that their checkout process has minimum friction. They should ask only the most relevant and necessary details from users. Here are a few other actionable tips to optimize web forms.
Do Online Shoppers Abandon Carts If They’re Asked for Personal Information?
Almost 60% respondents have at least once abandoned a purchase because the website asked them for information they didn’t want to share.
34% respondents admitted having abandoned a purchase when they were asked to provide their social security number. Other information points consist of gender type, phone number and date of birth.
eCommerce sites should ask users for only that information which they’ll be actively using.
Cart abandonment is still a major bane to eCommerce businesses. This report attempts to shed light on the common factors why shoppers abandon a cart, and how eCommerce marketers can overcome them. The key strategies to alleviate cart abandonment include retargeting, employing scarcity and urgency principles, maintaining transparency in prices, and minimizing form-friction.
What Do You Think
How useful did you find our report? Do you want any additional questions to be included in our next survey? Tell us in the comments section below.
Things often come full circle in software engineering. The web in particular started with servers delivering content down to the client. Recently, with the creation of modern web frameworks such as AngularJS and Ember, we’ve seen a push to render on the client and only use a server for an API. We’re now seeing a possible return or, rather, more of a combination of both architectures happening.
It is a way to create reusable front-end components. Plain and simple, that is the goal of React.
What Makes It Different?
React is often described as the “V” in an MVC application. But it does the V quite differently than other MV* frameworks. It’s different from things like Handlebars, Underscore templates and AngularJS templates. React operates on the concept of a “virtual DOM.” It maintains this virtual DOM in memory, and any time a change is made to the DOM, React does a quick diff of the changes, batches them all into one update and hits the actual DOM all at once.
React exposes a method called React.renderToString(). This method enables you to pass in a component, which in turn renders it and any child components it uses, and simply returns a string. You can then take that string of HTML and simply send it down to the client.
React.render attaches your <HelloWorld> component to the body. Naturally, that could be any element there. This causes the component’s render method to fire, and the result is added to the DOM inside the <body> tag.
With a React component, whatever you pass in as attributes — say, <HelloWorld message="world" /> — you have access to in the component’s this.props. So, in the <HelloWorld> component, this.props.message is world. Also, look a bit closer at the JSX part of the code:
You’ll notice first that you have to wrap the HTML in parentheses. Secondly, this.props.message is wrapped in braces. The braces give you access to the component via this.
Each component also has access to its “state.” With React, each component manages its state with a few simple API methods, getState and setState, as well as getInitialState for when the component first loads. Whenever the state changes, the render method simply re-renders the component. For example:
var Search = React.createClass(
<input type="text" onChange=this.changeSearch />
<span>You are searching for: this.state.search</span>
var text = event.target.value;
React.render(<Search />, document.body);
In this example, the getInitialState function simply returns an object literal containing the initial state of the component.
The render function returns JSX for our elements — so, an input and a span, both wrapped in a div. Keep in mind that only one element can ever be returned in JSX as a parent. In other words, you can’t return <div></div><div></div>; you can only return one element with multiple children.
Notice the onChange=this.changeSearch. This tells the component to fire the changeSearch function when the change event fires on the input.
The changeSearch function receives the event fired from the DOM event and can grab the current text of the input. Then, we call setState and pass in the text. This causes render to fire again, and the this.state.search will reflect the new change.
Many other APIs in React are available to work with, but at a high level, what we did above is as easy as it gets for creating a simple React component.
With React, we can build “isomorphic” apps.
i·so·mor·phic: “corresponding or similar in form and relations”
This has already become a buzzword in 2015. Basically, it just means that we get to use the same code on the client and on the server.
This approach has many benefits.
Eliminate the FOUC
With AngularJS, Ember (for now) and SPA-type architecture, when a user first hits the page, all of the assets have to download. With SPA applications, this can take a second, and most users these days expect a loading time of less than two seconds. While content is loading, the page is unrendered. This is called the “flash of unstyled content” (FOUC). One benefit of an isomorphic approach to building applications is that you get the speed benefits of rendering on the server, and you can still render components after the page loads on the client.
The job of an isomorphic app is not to replace the traditional server API, but merely to help eliminate FOUC and to give users the better, faster experience that they are growing accustomed to.
One big benefit is being able to use the same code on the client and on the server. Simply create your components, and they will work in both places. In most systems, such as Rails6, ASP.NET MVC7, you will typically have erb or cshtml views for rendering on the server. You then have to have client-side templates, such as Handlebars or Hogan.js, which often duplicate logic. With React, the same components work in both places.
Server rendering allows you to send down the barebones HTML that a client needs to display a website. You can then enhance the experience or render more components in the client.
Delivering a nice experience to a user on a flip phone in Africa, as well as an enhanced experience to a user on a 15-inch MacBook Pro with Retina Display, hooked up to the new 4K monitor, is normally a rather tedious task.
React goes above and beyond just sharing components. When you render React components on the server and ship the HTML down to the client, React on the client side notices that the HTML already exists. It simply attaches event handlers to the existing elements, and you’re ready to go.
This means that you can ship down only the HTML needed to render the page; then, any additional things can be pulled in and rendered on the client as needed. You get the benefit of fast page loading by server rendering, and you can reuse the components.
Creating An Isomorphic Express App
Express138 is one of the most popular Node.js web servers. Getting up and running with rendering React with Express is very easy.
Adding React rendering to an Express app takes just a few steps. First, add node-jsx and react to your project with this:
That’s it for the server code. Let’s look at what’s necessary on the client side.
For React .jsx files, you’ll just need to configure your webpack.config file a bit in order to compile all of your jsx components.
Getting started with Webpack is easy:
npm install webpack -g # Install webpack globally
npm install jsx-loader --save # Install the jsx loader for webpack
Next, create a webpack.config.js file.
var path = require("path");
module.exports = [
test: /.jsx$/, loader: "jsx-loader?harmony"
// You can now require('file') instead of require('file.coffee')
extensions: ["", ".js", ".jsx"],
Let’s break this down:
This is the main file that will load your other files using CommonJS’ require syntax by default.
The module object is where you set up “loaders.” A loader simply enables you to test for a file extension and then pass that file through a loader. Many loaders exist for things like CSS, Sass, HTML, CoffeeScript and JSX. Here, we just have the one, jsx-loader?harmony. You can append options as a “query string” to the loader’s name. Here, ?harmony enables us to use ECMAScript 6 syntax in our modules. The test tells Webpack to pass any file with .jsx at the end to jsx-loader.
In resolve we see a few other options. First, extensions tells Webpack to omit the extensions of certain file types when we require files. This allows us just to do require("./file"), rather than require("./file.js"). We’re also going to set a root, which is simply the root of where our files will be required from. Finally, we’ll allow Webpack to pull modules from the node_modules directory with the modulesDirectories option. This enables us to install something like Handlebars with npm install handlebars and simply require("handlebars"), as you would in a Node.js app.
var React = require("react"),
App = React.createFactory(require("components/app"));
if (typeof window !== "undefined")
window.onload = function()
We’re going to check that we’re in the browser with the typeof window !== "undefined". Then, we’ll attach to the onload event of the window, and we’ll call React.render and pass in our App(). The second argument we need here is a DOM element to mount to. This needs to be the same element in which we rendered the React markup on the server — in this case, the #content element.
React is one of the first of what are sure to be many frameworks that enable this type of behavior. Ember’s developers are already working on isomorphic-style applications as well. Seeing how this all works out is definitely going to be fun!