Zara launched their new website on 2nd Sept, including the ability to buy online for the first time. It was launched across multiple countries with alternative language versions available in some countries. There have been numerous reviews of the website published, some related to the products available on the website or providing an overview of functionality and usability with some less positive ones relating to website functionality and SEO. I take a different approach here, looking at what is being measured on the website, what additional tagging would be useful and how the data could be used to understand and improve website performance.
Note that I do not work with Zara so all comments made are without a discussion of business requirements and without access to the web analytics configuration or the actual data. Instead this review should highlight how web analytics should be implemented for a retail website and more importantly, provide some examples of how the information can then be used to make business decisions.
Zara is using Google Analytics for its web analytics tool although there has only been a basic implementation with the generic page tag (using the new asynchronous code at least) included on each page. There is no customisation of the tagging, no events or custom variables are being tracked and page names are defaulting to the Zara URL structure in use. I have to admit that I have not made a purchase to confirm the ecommerce code is in place on the order confirmation page but I assume that there would be a similar basic implementation of this code.
I could be wrong here, Zara might have invested in a web analytics department who are doing some very clever things with the configuration and are using the data to generate some great insights. However given my experience with other clients, as only basic tagging has been implemented, I suspect that at best they have tasked someone with pulling out some numbers to be used in their weekly reporting. They will be able to get basic web metrics from GA and that is all they require given (slight guess here) their lack of resources and engagement with web analytics as a powerful tool for driving business performance.
The main issues
Due to the limited nature of the web analytics tagging on the Zara website, there would be some serious barriers to extracting useful insights from the web analytics data. For starters, all of the websites, irrelevant of the country and language, are on the same domain and are being tracked using the same GA account number. All of the data is therefore being combined making it difficult to understand performance within a single website.
Just as serious is a lack of a user friendly and meaningful page naming convention, always a vital factor in any web analytics implementation. Zara is using standard page tags and therefore defaulting to the URL as the basis for page names. This can be fine, however they are using IBM WebSphere Commerce as their website platform which has an incredibly ugly URL structure. Page names are therefore excessively long, are difficult to reference back against the actual page viewed and do not follow a hierarchical structure.
And that’s just the problems with the tags that are implemented. Numerous elements of the Zara website do not refresh the page when used and these elements are not being tracked at all. This includes some of the most important interactions with the website and stages of the purchase process. Elements of the website not being tracked include:
- Adding a product to basket
- The first stage of the checkout process where the visitor either logs in or creates an account
- The shopping guide
- All interaction within the magazine, catalogue and Lookbook
- Most features on the product pages including selecting alternative images or clicking for more product information
With these website elements not being tracked, there are vital business questions which cannot be answered such as:
- We are going to spend £XXX per month on creating an online magazine, is it being viewed and are the viewers then more likely to go on and purchase – i.e. what is the ROI of producing an online magazine (or catalogue or the Lookbook)?
- Which products are visitors most interested in – what do they think is hot right now? Given the strategy for Zara of a quick turnaround on products based on latest hot styles, this information could be vital leads directly to the real business question of What products and styles should we be ordering from our designers and manufacturers to maximise sales?
- What is the value of lost sales due to requiring visitors to register or login before they can make a purchase compared to the value of lost sales through carts being created and then abandoned without being viewed? – i.e. Which area of the website should I invest my money and resources into improving first to maximise the uplift in revenue as a results of these improvements?
What can be done in the configuration
So given all these issues and assuming that Zara can’t get an improved web analytics implementation in the near future, what can they do? Is all lost or is there still value in their web analytics data? By spending some time configuring Google Analytics in the admin console, they will gain access to a reasonable amount of useful data to work with in understanding the performance of their websites. This configuration includes:
Separate the data for different websites
The first task is to split the data up into profiles for different countries and then further into profiles for the individual language websites per countries. As nearly all page names appear to either follow this structure /webapp/wcs/stores/servlet/product/<country name>/<language>/zara-sales/<actual page name> or to contain the parameter storeId (with the value of this parameter consistent within each website), the pages relevant to each country and website can be identified. Two “Include” filters should be set up for each profile so that just data relating to either that country or website is included within the profile. This would give Zara the following structure although note that each grouping may contain multiple profiles.
Rename the pages
As can be seen in the page name structure given earlier, most of the length within a page name is generic across multiple pages with only two or three structures in use (based on my limited investigations). Therefore this section of the page name can be removed using either a “Search and Replace” or an “Advanced” filter. Additionally, all page names should be converted to lower case using the “Lowercase” filter and key characters which are currently escaped transferred into readable characters.
Following the implementation of these filters, a page name such as
would be converted into
- /11073/10170/shiny quilted coat with hood
Page names would immediately be more readable and thus useful within the organisation.
A very clever use of “Advanced” filters would even be able tocreate page names indicating which pages are product pages. This is possible as (I believe) product page URLs are the only ones to contain two sets of numbers directly prior to the product name. These filters would add the term “/product” at the start of these page names – this would prove to be useful in interpreting the web analytics data.
Exclude internal traffic
This step should be just a matter of fact but a filter needs to be set up, normally done using the “Predefined Exclude traffic from the IP addresses” filter, to exclude all internal IP addresses from the profiles used for primary reporting and analysis. This is so data is not contaminated by the website being accessed repeatedly by staff checking on features or products. A profile should be retained that does not contain this filter so a complete data set can be reviewed if necessary.
Track Internal Search
It is easy to track internal search using Google Analytics as long as a URL parameter is used to identify the search term. This is the case here with the parameter being searchTerm. The configuration is easy to set up within GA through editing the Main Website Profile Information section as seen below. For a bonus, rename these pages “/Search Results” using a “Search and Replace” filter.
Other query parameters should be stripped out of page names within this section of the admin console ensuring the storeId parameter is retained and that nothing else is removed that may be of use.
Create relevant goals reflecting conversion points on the website
The key goal of course for an ecommerce website is a purchase being made. However I would recommend setting up not one but two goals for this event, using the order confirmation page for the Goal URL. The reason for two goals for the same conversion event is to allow you to set up two funnels that lead to a purchase being made. The first is the standard ecommerce funnel:
- Get to Product (assuming that product pages have been identified and renamed as such)
- View Basket (this is a substitute for Create Basket as adding to basket is not being tracked)
- Commence Checkout (can’t identify this correctly as the login/register page is not tracked so use the Shipping page instead)
- Place Order (which is the page defined as the goal)
The second funnel for the Order Confirmation goal covers the pages within the checkout process – Basket, Shipping, Payment and Confirmation.
Other goals that Zara should be setting up are:
- One for each of the other stages of the ecommerce funnel – Get to Product, View Basket and Commence Checkout
- Click through to Newsletter Subscription page (can’t base this on Newsletter Subscription confirmation as this is one of the few URL that doesn’t contain a country identifier)
- Submit Contact Us form (creating a funnel with accessing the Contact Us form as the only step)
- View key website features – Lookbook, magazine, catalogue, video (adds to the flexibility of understanding behaviour around these website features)
- Access Store Finder (to start linking impact of online investment with offline purchases)
To be continued…
This post appears to be getting a bit lengthy for my liking so will split it into two parts. Please return next week for the thrilling conclusion of this review of web analytics for the new Zara.com website. It will contain:
- Insights that can be extracted with the current level of implementation if this recommended configuration was set-up and how these insights would be used to impact business decisions
- A list of additional website features and interactions which I believe should be tracked and how this could be done
- How this additional tagging would add to the business information available through Zara’s web analytics data and again some business decisions that could be influenced by this newly available information
- Finally, I am going to point out a few sections/features/elements of the new Zara website that I would highly recommend testing to see if an uplift in performance can be easily achieved
Hopefully a lot of what I have written in part 1 here and will publish next week in part 2 is useful to other e-retailers, as a guide to what they could/should be doing with their web analytics. If you would like to have a chat about how to get more value from web analytics, please contact us using any of this variety of methods.