Top Ecommerce Blog Posts and Articles for January 2014

Here are a few hot articles to warm you up during this cold and snowy winter…

TOP PICK: How To Come Up With A Value Proposition When What You Sell ISN’T UniqueConversionXL
A must read for every online merchant.

31 Link Building Tactics Discovered From Competitive AnalysisMOZ
Lots of great examples here for building up links to your site.

Why online retailers should enclose the checkout processEconsultancy
An interesting read about cart design.

 

One Simple Tip to Avoid Confusion for Customers Using PayPal

paypal_zip

Ah, the dreaded the postal code returned from PayPal did not match the cart message in ShopSite…

It can be confusing, annoying, and ultimately result in lost sales…

What really happens?

When a customer enters a ship to zip / postal code in the shopping cart that does not match the ship to zip code saved in their PayPal account, this stock warning message appears in the shopping cart.

ShopSite then updates the zip / postal code in the cart with the actual value returned by PayPal (i.e. the actual zip code saved in their PayPal account as the shipping address). But this may not be obvious to your customer.

Note: Version 12 of ShopSite actually ignores the “plus 4″ part of the zip code in determining whether to warn the customers and send them back to the cart. So that potential snag has been eliminated. But not the typo, wrong zip, etc… that sometimes gets entered on the cart page.

The easy fix

Make a simple change to the text:
Preferences -> Store Text -> Shopping Cart

The entered Postal Code did not match the value returned from PayPal.

to something like:

The shipping Postal Code in PayPal was different from the postal code you entered in the cart. The correct Postal Code has now been updated to match PayPal. Please click “Check Out With PayPal” to complete your order.

You can expand on this to possibly include a link explaining the issue, that the zip code in PayPal must be the shipping destination in your store for the payment method to work, etc…

We see this question a lot from merchants. Luckily a little re-wording, and you may help many customers who run into this issue.

ShopSite and Global Variables

ShopSite templates often use global variables to store and display values, such as page types (page, product, cart, etc…), layout options (colors, widths, etc…), loop counters and more.

global_no_bgHere are a few important facts about variables and their usage within ShopSite templates:

1.  Variables may contain either numeric or string values.  When assigning a string variable, the value is enclosed by double-quotes.

2.  Variable VALUES are case-sensitive

“Page” and “page” are not considered the same

3.  Variable NAMES are not case-sensitive

[-- VAR.somename --] and [-- VAR.SomeName --] are considered the same

4.  Variables are set during the publish and remain active throughout generation.  Additionally, the value can change many times before the generation is finished.

5.  Variables are global and available to all objects within the scope of the publish, including loops and other include files.  One common variable found in ShopSite templates is [-- VAR.Type --].  This variable takes on different values during a store publish, such as “page”, “more”,  etc….  The variable is used to control output during the generation process.

Below is a quick illustration of the variables life-cycle during a publish.  The variable is declared in the [-- DEFINE PAGE --] section of the page template.  Its value is passed into the product loop and can be displayed, evaluated or updated by the product template.  If the value is changed in the product template, the new value is passed back to the page template upon completion of the product loop.  This is particularly important if the variable is used again in the page template after the product loop and requires its value to match the value originally assigned.

variable_flowTo overcome this, you would need to reset the variables value in the page template after the product loop.  Of course, using unique variable names whenever possible helps avoid this type of conflict altogether (especially with custom page/product loop counters).

Variables In Action (Example)

Let’s take a look at two global variables used to control the display of products on a page.  The goal is to create product rows, each having four columns.

[-- DEFINE PAGE --]

[-- VAR.Counter 0 --]
[-- VAR.Columns 4 --]

<table>
[-- LOOP PRODUCTS VAR.Columns --]
[-- VAR.Counter INC --]
<td>[-- PRODUCT --]</td>
[-- IF VAR.Counter EQ VAR.Columns --]
[-- VAR.Counter 0 --]
</tr><tr>
[-- END_IF --]
[-- END_LOOP PRODUCTS --]
</table>

[-- END_DEFINE PAGE --]

And now the explanation…

[-- VAR.Counter --] stores the counter value, which is initially set to zero.

[-- VAR.Columns --] stores the number of product columns we intend to display on each row of our page template.

[-- VAR.Counter INC --]

With each iteration of the loop, we increment the counter value by 1.

[-- IF VAR.Counter EQ VAR.Columns --]
[-- VAR.Counter 0 --]
</tr><tr>
[-- END_IF --]

When the counter value reaches our column count (4), the previous row is closed out and a new row is triggered.

 

How We Helped a Magento Store Quickly Handle Thousands of Orders

magento_logo

One of our ecommerce clients was recently featured on NBC’s Today Show in the Segment “Jill’s Steals and Deals”. The Today Show highlights a few products with very aggressive discounts, and generates tens of thousands of visitors in just a few minutes.

This particular client uses Magento for their ecommerce software. Magento presents many unique challenges in a high traffic event such as this. This is because Magento uses a lot of resources (CPU and Memory) as compared to other ecommerce solutions.

We’ve had other clients featured on events like this. The easiest to manage are those websites running ShopSite as their ecommerce solution. ShopSite scales really well, handling thousands of orders without consuming too many resources. This is not the case with Magento.

So, we had our work cut out for us…

What we started with

The client already had a managed dedicated server with us, so that was a good start. We already had APC enabled and tuned. APC caches code, which helps with load and faster page loads.

The server had 8 GB of RAM. The store was running Magento Community edition, and had a number of custom modules and a mobile site as well.

What we changed

We’ve done other events like this with Magento, and we’ve learned a lot over the years. We put that knowledge to good use…

  • We increased the RAM from 8 GB to 32 GB to handle the spike in traffic.
  • We enabled a Content Delivery Network (CDN) in Magento itself to off-load many files from the server.
  • We installed a Full Page Cache Module for Magento so page loads would be fast and use very few resources.
  • We tweaked the Apache webserver to handle more traffic, and adjusted KeepAlives for optimal resource management.
  • The “splash page” where NBC would link to from the Today Show website was 100% on the CDN. This is key so the initial surge does not hit the server. This means every image, css, js, and even the page itself must use the CDN URL so no resources load off of the server.

We opted to not add an additional server just for MySQL. Budget and time constraints made this option unavailable. Ideally though, this dual-server set up would provide the best solution to handle high levels of traffic.

Side note: The concept of “putting the site on a cloud solution” is often raised around events like these. It’s actually not a great idea, as cloud hosting has major issues with I/O load (drive speed). Sure, you can spin up additional resources, or add additional containers, but this adds complexity and programming to handle effectively. A properly configured dedicated server will outperform cloud hosting in most cases.

The morning of the event arrives

At about 8:48 AM ET, the segment aired on television. Just a minute later, we saw the CDN light up as the Today Show website was updated with the order links.

20-30 seconds after that, items were being placed in the cart. Thousands of visitors hit the cart and site, and we watched Apache handle 500-600 simultaneous events. The load on the server went up quite high (greater than 150) right away. Even with this high load, the server was still very responsive and doing well. Memory consumption was only around 20 GB, so no issues there.

However, MySQL was set for a maximum number of connections of 400. This was quickly reached, at which point things started to back up, and the load sky-rocketed to over 280. We adjusted MySQL to handle 600 connections, and with Apache already set for 800 max. simultaneous connections, we were back in business with just a one to two minute slowdown.

How much traffic was there?

In the first 45 minutes, over 10 Gigabytes of data was transferred out from the server and CDN. That is quite a lot. The site saw over 100,000 page views in just a few short hours.

hourly_traffic.png

In terms of orders, we saw a peak rate of 7 orders per second! The site received thousands of orders on the day the show aired. It was quite impressive to see this level of traffic and orders streaming in without any major issues.

The event was a success!

Key takeaways

The more RAM, the better

Having 32 GB of RAM for this event gave us plenty of room to handle the traffic spike. This seemed to be a good number for Magento.

Proper use of a CDN is crucial

Not only enabling the CDN in Magento itself, but constructing the initial splash page to run entirely on the CDN is a key factor in making sure the entry page is up 100% of the time. This saves the server for handling the cart and checkout without being burdened by the thousands of visitors hitting the initial linked page.

Server config must be tuned and monitored

Having Apache preset to handle 700-800 max children, having MySQL set to allow 500 or more concurrent connections, and allowing the load on the server to spike above 200 are all needed to avoid a bottleneck or services failing.

Along with this, your host must be vigilant and able to adjust parameters as needed to keep things running as smoothly as possible. Expect a slowdown when the initial surge hits.

If possible, split MySQL on to its own server

When heavy traffic hits a Magento site, the web server and database server compete for CPU resources. This causes the load to rise, things to get slow, etc…

Ideally, having MySQL on a separate server connected via a Gigabit private network would be the best solution. It would allow each piece of software to use the full resources of the server.

Planning and being able to react quickly are key

Most of all, make sure you have a plan beforehand that your host understands and supports. Your host must also be able to react when issues arise to keep things running.

If your host isn’t acting as your partner for a high traffic event, it’s probably time to find a new host.

2013 Small Business Ecommerce Holiday Stats

statsYou’ve probably seen the stats on how the big e-tailers performed this past 2013 holiday season. What hasn’t been covered is how the smaller ecommerce merchants did overall. Here is what we’ve seen this past holiday season…

First, the big stats

comScore released their overall numbers for 2013. They reported that for 2013 (for the 52-day period up through December 22) online stores saw a 10% increase in ecommerce spending.

comScore also reported on the big days like Cyber Monday, Black Friday, Thanksgiving, etc… We covered these days’ stats in a previous post about how small merchants fared for Black Friday and Cyber Monday 2013.

The best performing product categories according to comScore were Video Games, Apparel, Consumer Electronics, Computer Hardware, and Home & Garden.

MasterCard also reported on 2013 for the retail industry, seeing a 2.3 percent increase over 2012 for the holiday season.

Now for the smaller merchant stats

We took a look at a random sampling of 86 stores that had significant sales both in 2012 and 2013. This allows us to see how the same stores fared year over year. For the same 52-day period comScore looked at for 2012 and 2013, our merchants saw a revenue increase of 7.1%. They saw total number of orders up 3.2%, and average order value up 3.5%.

We also broke it down a bit more, looking at the top product categories for the holiday season. The best performing category was Media, followed by Hardware, Health & Beauty, Arts & Entertainment, and Sporting Goods.

If we look at a random sampling of stores in 2012 and 2013 (that are not the same year to year), we see a revenue increase of 27%. However, that is 297 stores tracked in 2013 vs. 229 stores in 2012.

Conclusions?

Small Merchants did better in 2013

The same merchants in 2013 saw revenue increase 7.1% over 2012. It’s a bit less than the 10% increase comScore reported, but it’s still a positive sign.

comScore is looking at the biggest online stores. So, it stands to reason that overall their sales might be a bit higher, as big online stores are gaining steam on the internet each year. Big e-tailers also overshadowed small merchants on the big days like Cyber Monday and Black Friday, likely due to their aggressive deals and big ad budgets.

However, when we look at the whole shopping season, small merchants gaining 7.1% is a strong indication that you can still compete and prosper against the big boys and girls on the Net.

What you sell matters

You see comScore saying the biggest categories in 2013 were Video games, Consumer electronics, and computer hardware. This is not the case for smaller merchants. Why?

You can’t go head to head selling Xbox consoles, Playstation games, and Dell computers.

However, categories such as Media (digital downloads like custom software, recipes, videos, etc…), Hardware, Health & Beauty, and Arts & Entertainment, allow smaller merchants to offer unique and specialty items that can’t be easily found elsewhere. These sectors saw strong growth in 2013.

Compare apples to apples

When looking at growth year over year, you either need to look at the same stores (or very similar stores), or use more precise computations to account for fewer or more stores in the sample. With these large companies putting out stats about the industry, what’s often missing is their methodology, so it’s tough to tell exactly what they are reporting.

Other sources have put some data out about small merchant sales, but the numbers don’t seem to make sense many times, and an explanation of exactly what they measured is almost always missing.

That’s why we look at the same stores from one year to the next, so we can see actual data from the same group of merchants, to get a more accurate representation of how things are progressing.

Ecommerce is still growing for all sizes of stores

Sure, big retailers online are getting the majority of the press, and Amazon seems to be the only destination for some shoppers, but small ecommerce stores still saw a 7.1% increase overall in revenue year over year. After a tough few years due to the economy, it seems both large and small merchants are seeing an upward trend that will hopefully continue throughout 2014.