Enhancing User Experience Through Ongoing Optimization

When someone starts talking about testing, one of any number of things can come to mind. There is testing that ensures the site looks the way that it is supposed to. Some testing is done to make sure a website functions as expected. You can even have tested to confirm that a piece of code produces the correct result every time. Recently, we have become very interested in a completely different kind of testing called A/B and multivariate testing.

A/B and multivariate testing are two flavors of the same type of testing where the intention is to find a user experience that most effectively meets some merchant goal. The process we follow is to create two or more versions of the same page within your site and present them to the customer to see which achieves your goals more effectively. It is one easy and cost-effective way to improve a merchant’s site usability and conversion.

“But where do I begin? What should I test?”

As a merchant, you may say, “This sounds great, but my site has thousands of pages. Which one do I optimize?” To answer this question, a merchant must ask one important question: “What is my most important business goal?” In eCommerce, the most common goal is to increase customer conversion rates by some amount or to increase average order value by some amount to ultimately drive more revenue. Some other common goals may be to increase customer retention, to increase customer satisfaction, or to fix some “problem” with your website.

Once you’ve identified your goal, the next step is to analyze any metrics you can get around that goal. For the purpose of demonstration, we have chosen to discuss the topic of conversion levels. We utilize Google Analytics (GA) or any other conversion tracking tools you may have set up to set up GA goals, track them, and measure their current conversion rates. We also analyze where users are abandoning the site and use this information to identify the most promising page or pages to implement our testing.

Before implementing an A/B test, the next important step is to come up with a hypothesis about why you think users are leaving your site on this page.

Some steps you can take to brainstorm options are

  • Research some user interface/user experience best practices.
  • Research colors, fonts, and wording that may enhance your site’s usability and experience.
  • Go to the problem page(s) and count the number of clicks it takes you to accomplish your goal. How many distinct pages have to load between when you enter the site and when you have completed your order?
  • Find someone in your company who does not regularly use the website and ask them to be overly literal, then try to explain to them step-by-step how to use the “problem page.” Do this again on a comparable page on a more prominent shopping website like Amazon or eBay to see how your user experience compares holds up.

After you follow these steps, document your hypothesis, what you plan to test and why/how you expect it to impact your conversion goal.

Once you have come up with a hypothesis, it’s time to implement the test. There are a few great tools to help you get started with A/B testing. Our tool of choice is Optimizely, which is a great online tool that allows us to change the layout of your page, colors, text, fonts; launch the test, then track the results. We are able to do all of this with only a very slight modification to the actual site’s code which means the time to implement the tool is very minimal compared to some other methods which can be expensive or time consuming to implement. It also has built in analytics and works with Google Analytics to track conversion and other more comprehensive metrics.

We will work with you to implement the test and allow you to see the different versions that will be displayed to different groups of customers. Once your test is running, it is important to let it run long enough to reach a statistically significant result. A good rule of thumb is to let the test run for at least two weeks and have at least 100 conversions. Optimizely will also let you know once a test has reached a statically significant result and will declare a winner.

If the test version has won, it’s time to implement those changes and document the results. It’s important to keep documentation of each test you’ve completed so that you can reference and utilize the data for future tests.

At this point, your test is complete but now that Optimizely is installed and you understand how to find and create candidates for testing, the amount of time to implement another test has been reduced. You can now begin to implement a more long term strategy for improving your conversion, working toward other goals, and continually making small but meaningful improvements to your site. Optimization is an ongoing practice that should be done repeatedly to keep your site as relevant, profitable and effective as possible. It is important to remember that not every test will be better than the original, but that is why testing is so important instead of making changes without information about how your specific group of customers will react.

How We Work with You

The Classy Llama User Experience team consists of expert designers and front-end developers who look forward to helping you improve your site’s user experience and increase conversion rates. We start with an initial review of your current site analytics and do some brainstorming around recommended areas of improvement. Goals are defined and a roadmap for testing is established before testing begins. Upon conclusion of each test, a detailed report including findings and recommendations will be delivered. Based on these test results, we will make adjustments and evaluate opportunities for future improvements.

For more information, email [email protected] or call (417) 866-8887.

Using PHP Native Password API with Magento

Overview

Despite efforts from the industry, corporate data leaks from web applications are happening with increasing frequency. A specific implication of these leaks is that they often expose customer password information, potentially compromising the customer’s account not only on the site where the leak occurred but possibly many others, as customers tend to reuse the same password on many different sites.

With this in mind, it is the duty of each merchant and developer to safeguard such customer information.

Magento addresses the security of customer passwords by using the industry standard pattern of storing passwords using a one-way hash. This mechanism does not provide a way to directly retrieve a password from its hash – the only sure way to “unhash” a hash is by brute force (trying every single possible value). Brute forcing is hopefully prohibitively expensive and time-consuming, which ensures the security of hashed passwords.

Problem

The effectiveness of Magento’s password hashing relies heavily on the choice of the hashing algorithm. Currently, Community Edition 1.9.1.0 uses MD5, and Enterprise Edition 1.14.1.0 uses SHA256.

While these hashing algorithms are widely used in the industry, they suffer a core design flaw which makes them unsuitable for securing information.

According to PHP password hashing recommendations:

Hashing algorithms such as MD5, SHA1 and SHA256 are designed to be very fast and efficient. With modern techniques and computer equipment, it has become trivial to “brute force” the output of these algorithms, in order to determine the original input.

Because of how quickly a modern computer can “reverse” these hashing algorithms, many security professionals strongly suggest against their use for password hashing.

Solution

Considering how many applications need to securely store passwords, PHP provides a native password hashing and verification API. This API allows developers to easily store and validate passwords without having to research, reimplement, and maintain the wide range of best practice details that are required to truly be secure.

Additionally, this native API is designed to evolve over time – as better hashing algorithms or other best practices are discovered, it can transparently improve its implementation without requiring developers to update code.

Technical details

Along with other best practices, such as constant time string comparisons, unique salt, etc, the PHP native password API uses the currently recommended bcrypt hashing algorithm. This is designed to change over time, so hash strings produced by the native API include all required information to verify the hash.

PHP native password API hash string example, from PHP password hashing FAQ.

Example of PHP native API hash string with breakdown

Because of this, a hash string created by the native API is always forward compatible with future versions of the verification API.

The PHP native password hashing API is available in the PHP core since version 5.5.0. Additionally, there is a pure PHP compatibility library for versions of PHP since 5.3.7. Due to a security issue in PHP versions 5.3.6 and below, merchants and developers should upgrade at least to 5.3.7.

Magento implementation

In order to improve its password hashing security, I have created a PHP native password hashing API Magento module. The module is compatible with both Commerce Edition and Open Source Edition and includes the native API compatibility library, making it compatible with PHP versions 5.3.7 and above.

This module adds three system configuration options, which can be found in System -> Configuration -> Customers -> Customer Configuration -> Password Options.

  • Use PHP Native Password Hashing: this setting fundamentally enables/disables the module. In order to “do no harm”, the module is disabled by default, so it is critical to set this value to Yes in order to upgrade Magento password hashing.
  • Password Hashing Cost: advanced users can adjust this value to possibly improve password hashing security at the cost of server CPU load. The default is appropriate for nearly all sites.
  • Rehash Legacy Passwords: this setting allows Magento to upgrade password hashes which were created using legacy hashing algorithms. When a customer or admin successfully authenticates using a password with an unsuitable hash, the password will be rehashed using the native API. In order to “do no harm”, this functionality is disabled by default, but it should be set to Yes to begin to retroactively upgrade the site’s password hash database.

Where to get it

This module is liberally licensed and freely available on GitHub: https://github.com/ericthehacker/magento-phpnativepasswords.

It can be easily installed using modman, as described in the installation instructions. As mentioned above, it’s critical to enable the module’s functionality in system configuration after installation.

As always, issues or contributions are welcome!

Contact Us