Tag Archives: url

Manually clicking through different browsers as they run your development code, either locally or remotely, is a quick way to validate that code. It allows you to visually inspect that things are as you intended them to be from a layout and functionality point of view. However, it’s not a solution for testing the full breadth of your site’s code base on the assortment of browsers and device types available to your customers.

Security of a WordPress (or any) website is a multi-faceted problem. The most important step anyone can take to make sure that a site is secure is to keep in mind that no single process or method is sufficient to ensure nothing bad happens. But there are things you can do to help. One of them is to be on the watch, in the code you write and the code from others you deploy, for functions that can have negative consequences.

Our traffic bounces all over the place. We have social. We have email. We have paid ads. There’s more sites, platforms, and networks than we could possibly hope to run our campaigns on. How do we keep track of it all? How do we know what’s working and what’s not? We use UTM codes. What’s a UTM? UTM stands for Urchin tracking parameters. They’re little pieces of data that we add to our URLs in order to see where different traffic comes from. They were introduced way back with an analytics tool called Urchin, the tool that was bought by…

We know that Google’s Mobile-First Index is coming. As is the norm with Google, we’re just not sure when. The latest reports from SMX Advanced in Seattle back in June saw Gary Illyes quoting early 2018 as the rollout date, but we can expect a fairly soft roll out on this one. It’s also likely that Google will be providing webmasters with a lot of guidance as this is a huge move with the potential to cause havoc to a lot of great websites if they get it wrong. With that timeline in mind, there are things you can be…

For the past few months, I’ve been building a software-as-a-service (SaaS) application, and throughout the development process I’ve realized what a powerful tool Slack (or team chat in general) can be to monitor user and application behavior. After a bit of integration, it’s provided a real-time view into our application that previously didn’t exist, and it’s been so invaluable that I couldn’t help but write up this show-and-tell.
It all started with a visit to a small startup in Denver, Colorado.

AdWords can be an incredibly powerful platform for growing your business, but the truth is that most businesses are wasting thousands of dollars every month due to poor account management. If you feel like you could be generating more revenue from AdWords, chances are that you’re making some of these ten common mistakes that are inhibiting your performance. In this post I will be showing you ten common AdWords mistakes that I’ve seen literally hundreds of advertisers make. And, more importantly, I’m going to show you exactly how to fix them, so you can take next steps towards creating an…

Apple taught us, “There’s an app for that.” And we believed it. Why wouldn’t we? But time has passed since 2009. Our mobile users have gotten more mature and are starting to weigh having space for new photos against installing your big fat e-commerce app. Meanwhile, mobile browsers have also improved. New APIs are being supported, and they will bring native app-like functionality to the mobile browser.
We can now access video and audio and use WebRTC to build a live video-chat web apps directly in the browser, no native app or plugin required.

If you were planning to race your car, you would want to make sure it could handle the road, right?

Imagine racing a car that is not ready for the surprises of the road. A road that is going to require you to twist and turn constantly, and react quickly to the elements.

You would find yourself on the side of the road in no time.

A well-outfitted car, on the other hand, is able to handle the onslaught of the road and, when the dust settles, reach the finish line.

Well, think of your website like the car and conversion optimization like the race. Too many companies jump into conversion optimization without preparing their website for the demands that come with testing.

Get the Technical Optimizer’s Checklist

Download and print off this checklist for your technical team. Check off each item and get prepared for smooth A/B testing ahead!

By entering your email, you’ll receive bi-weekly WiderFunnel Blog updates and other resources to help you become an optimization champion.

But proper technical preparation can mean a world of difference when you are trying to develop tests quickly, and with as few QA issues as possible. In the long-run, this leads to a better testing rhythm that yields results and insights.

With 2017 just around the corner, now is a good time to look ‘under the hood’ of your website and make sure it is testing-ready for the New Year. To make sure you have built your website to stand the tests to come, pun intended.

In order to test properly, and validate the great hypotheses you have, your site must be flexible and able to withstand changes on the fly.

With the help of the WiderFunnel web development team, I have put together a shortlist to help you get your website testing-ready. Follow these foundational steps and you’ll soon be racing through your testing roadmap with ease.

To make these digestible for your website’s mechanics, I have broken them down to three categories: back-end, front-end, and testing best practices.

Back-end setup a.k.a. ‘Under the hood’

Many websites were not built with conversion optimization in mind. So, it makes sense for you to revisit the building blocks of your website and make some key changes on the back-end that will make it much easier for you to test.

1) URL Structure

Just as having a fine-tuned transmission for your vehicle is important, so is having a well-written URL structure for your website. Good URL structure equals easier URL targeting. (‘Targeting’ is the feature you use to tell your testing tool where your tests will run on your website.) This makes targeting your tests much simpler and reduces the possibility of including the wrong pages in a test.

Let’s look at an example of two different URL targeting options that you might use. One is a RegEx, which in JavaScript is used for text-based pattern matching. The other is Substring match, which in this case is the category name with two slashes on each side.

RegEx Example

Products to include:

www.test.com/ab82

www.test.com/F42

www.test.com/september/sale98

Products to exclude:

www.test.com/F4255

Targeting:

RegEx: (ab82|F42|sale98)

Substring Example

Products to include:

www.test.com/products/engines/brandengine/

www.test.com/products/engines/v6turbo

www.test.com/products/sale/september/engines/v8

Products to exclude:

www.test.com/products/sale/september/wheel/alloy

Targeting:

Substring: /engines/

In the first example, the company assigned URLs for their product pages based on their in-house product numbers. While writing a targeting rule based on RegEx is not difficult (if you know JavaScript), it is still time consuming. In fact, the targeting on the first example is wrong. Tell us why in the comments!

On the other hand, the second example shows a company that structured all of their product URLs and categories. Targeting in this case uses a match for the substring “/engines/” and allows you to exclude other categories, such as ‘wheels’. Proper URL structure means smoother and faster testing.

2) Website load time or ‘Time to first paint’

‘Time to first paint‘ refers to the initial load of your page, or the moment your user sees that something is happening. Of course, today, people have very short attention spans and can get frustrated with slow load times. And when you are testing, ‘time to first paint’ can become even more of a concern with things like FOOC and even slower load times.

So, how do you reduce your website’s time to first paint? Glad you asked:

Within the HTML of your page:

Move any JavaScript that influences content below the fold to the bottom of the body, and make these sections load asynchronously (meaning these sections will execute after the code above it). This includes any external functionality that your development team is bringing from outside the basic HTML and CSS such as interactive calendars, sliders, etc.

Within the head tag, move the code snippet of your testing tool as high as you can―the higher the better.

Minify* your JS and CSS files so that they load into your visitor’s browser faster. Then, bring all JS and CSS into a single file for each type. This will allow your user’s browser to pull content from two files instead of having to refer to too many files for the instructions it needs. The difference is reading from 15 different documents or two condensed ones.

Use sprites for all your images. Loading in a sprite means you’re loading multiple images one time into the DOM*, as opposed to loading each image individually. If you did the latter, the DOM would have to load each image separately, slowing load time.

Load all of your images in sprites.

While these strategies are not exhaustive, if you do all of the above, you’ll be well on your way to reducing your site load time.

3) Make it easy to differentiate between logged-in and logged-out users

Many websites have logged-in and logged-out states. However, few websites make it easy to differentiate between these states in the browser. This can be problematic when you are testing, if you want to customize experiences for both sets of users.

The WiderFunnel development team recommends using a cookie or JavaScript method that returns True or False. E.g. when a user is logged-in, it would return ‘True’, and when a user is logged-out, ‘False’.

This will make it easier for you to customize experiences and implement variations for both sets of users. Not doing so will make the process more difficult for your testing tool and your developers. This strategy is particularly useful if you have an e-commerce website, which may have different views and sections for logged-in versus logged-out users.

4) Reduce clunkiness a.k.a. avoid complex elements

Here, I am referring to reducing the number of special elements and functionalities that you add to your website. Examples might include date-picking calendars, images brought in from social media, or an interactive slider.

This calendar widget might look nice, but is it valuable enough to merit inclusion?

While elements like these can be cool, they are difficult to work with when developing tests. For example, let’s say you want to test a modal on one of your pages, and have decided to use an external library which contains the code for the modal (among other things). By using an external library, you are adding extra code that makes your website more clunky. The better bet would be to create the modal yourself.

Front-end setup

The front-end of your website is not just the visuals that you see, but the code that executes behind the scenes in your user’s browser. The changes below are web development best practices that will help you increase the speed of developing tests, and reduce stress on you and your team.

1) Breakpoints – Keep ’em simple speed racer!

Assuming your website is responsive, it will respond to changes in screen sizes. Each point at which the layout of the page changes visually is known as a breakpoint. The most common breakpoints are:

Mobile – 320 pixels and 420 pixels

Desktop and Tablet – 768px, 992px, 1024px and 1200px

Each point at which the layout of your page changes visually is known as a ‘breakpoint’.

Making your website accessible to as many devices as possible is important. However, too many breakpoints can make it difficult to support your site going forward.

When you are testing, more breakpoints means you will need to spend more time QA-ing each major change to make sure it is compatible in each of the various breakpoints. The same applies to non-testing changes or additions you make to your website in the future.

Spending a few minutes looking under to hood at your analytics will give you an idea of the top devices and their breakpoints that are important for your users.

2) Stop using images in place of text in your UI

Let’s say your website works in the many breakpoints and browsers you wish to target. However, you’re using images for your footer and main calls-to-action.

Problem 1: Your site may respond to each breakpoint, but the images you are using may blur.

Problem 2: If you need to add a link to your footer or change the text of your call-to-action, you have to create an entirely new image.

Avoid blurry calls-to-action: Use buttons, not images.

Use buttons instead of images for your calls-to-action, use SVGs instead of icons, use code to create UI elements instead of images. Only use images for content or UI that may be too technically difficult or impossible to write in code.

3) Keep your HTML and CSS simple:

Keep it simple: Stop putting CSS within your HTML. Use div tags sparingly. Pledge to not put everything in tables. Simplicity will save you in the long run!

Putting CSS in a separate file keeps your HTML clean, and you will know exactly where to look when you need to make CSS changes. Reducing the number of div tags, which are used to create sections in code, also cleans up your HTML.

These are general coding best practices, but they will also ensure you are able to create test variations faster by decreasing the time needed to read the code.

Tables, on the other hand, are just bad news when you are testing. They may make it easy to organize elements, but they increase the chance of something breaking when you are replacing elements using your testing tool. Use a table when you want to display information in a table. Avoid using tables when you want to lay out information while hiding borders.

Bonus tip: Avoid using iFrames* unless absolutely necessary. Putting a page within a page is difficult: don’t do it.

4) Have a standard for naming classes and IDs

Classes and IDs are the attributes you add to HTML tags to organize them. Once you have added Classes and IDs in your HTML, you can use these in your CSS as selectors, in order to make changes to groups of tags using the attributed Class or ID.

You should implement a company-wide standard for your HTML tags and their attributes. Add in standardized attribute names for Classes and IDs, even for list tags. Most importantly, do not use the same class names for elements that are unrelated!

Example:

Looking at the above example, let’s say I am having a sale on apples and want to make all apple-related text red to bring attention to apples. I can do that, by targeting the “wf-apples” class!

Not only is this a great decision for your website, it also makes targeting easier during tests. It’s like directions when you’re driving: you want to be able to tell the difference between the second and third right instead of just saying “Turn right”.

Technical testing ‘best practices’ for when you hit the road

We have written several articles on testing best practices, including one on the technical barriers to A/B testing. Below are a couple of extra tips that will improve your current testing flow without requiring you to make changes to your website.

1) If you can edit in CSS, then do it

Above is an animation that WiderFunnel Developer Thomas Davis created. One tab shows you the code written as a stylesheet in CSS. The tab on the right shows the same animation written in JavaScript.

JavaScript is 4-wheel drive. Don’t turn it on unless you absolutely need to, ‘cause you’re going to get a lot more power than you need. CSS effects are smoother, easier to work with, and execute faster when you launch a test variation.

2) Don’t pull content from other pages while testing

When you are creating a variation, you want to avoid bringing in unnecessary elements from external pages. This approach requires more time in development and may not be worth. You have already spent time reducing the clunkiness of your code, and bringing in external content will reverse that.

The important question when you are running a test is the ‘why’ behind it, and the ‘what’ you want to get out of it. Sometimes, it is ok to test advanced elements to get an idea of whether your customers respond to them. My colleague Natasha expanded on this tactic in her article “Your growth strategy and the true potential of A/B testing”.

3) Finally, a short list of do’s and dont’s for your technical team

Don’t just override CSS or add CSS to an element, put it in the variation CSS file (don’t use !important)

Don’t just write code that acts as a ‘band-aid’ over the current code. Solve the problem, so there aren’t bugs that come up for unforeseen situations.

Do keep refactoring

Do use naming conventions

Don’t use animations: You don’t know how they will render in other browsers

Glossary

DOM: The Document Object Model (DOM) is a cross-platform and language-independent convention for representing and interacting with objects in HTML, XHTML, and XML documents

iFrame: The iframe tag specifices and inline frame. An inline frame is used to embed another document within the current HTML document

Minification of files makes them smaller in size and therefore reduces the amount of time needed for downloading them.

What types of problems does your development team tackle when testing? Are there any strategies that make testing easier from a technical standpoint that are missing from this article? Let us know in the comments!

The common wisdom for most companies that set out to build an app is to build a native Android or iOS app, as well as a supporting website. Although there are some good reasons for that, not enough people know about the major advantages of web apps. Web apps can replace all of the functions of native apps and websites at once. They are coming more and more to the fore these days, but still not enough people are familiar with them or adopting them.

Shopping Cart and Conversion Optimization platforms together have been making lives simpler for eCommerce business owners. With its latest release, VWO adds Demandware to its kitty of third-party app integrations to allow easy configuration of VWO SmartCode on Demandware stores. In addition, eCommerce stores using Demandware can also track their store revenue and configure custom URLs to run tests.

Using the plug-in, Demandware users can now directly add their preferred type of VWO SmartCode (Asynchronous or Synchronous) to all pages on their shopping website and get cracking with their A/B testing campaign. The plug-in also allows eCommerce websites to track revenue conversions in their preferred format, using different combinations of tax and shipping charges along with the actual value of each order.

A key outcome of this integration is that businesses running Demandware can enable custom URL tracking. This tracking allows running test campaigns on SEO-friendly URLs that don’t have a common pattern. In a typical eCommerce store, URLs are often morphed to match frequent search queries. However, the changing nature of these URLs makes it difficult for marketing platforms to recognize their page types. VWO’s custom URL tracking allows users to easily classify URLs into different categories such as Product Page, Category Page, or Checkout Page, and then run test campaigns on a specific group of pages together.

How Does it Work?

Installing the VWO code on your Demandware store is a one-minute process. Simply download the VWO plug-in and import it into your Demandware studio. Now, follow these simple steps to configure the VWO cartridge for your store with your preferred settings.

In simple words, there is no need to individually add the VWO code to all pages on your Demandware store. The VWO plug-in does all that for you in no time! Also, don’t forget to configure your revenue tracking with VWO and enable custom URLS for running targeted campaigns.