RSS 2.0
  • Home
  • About
  • MBA Guide
  • Print Ad Blog
  •  

    Use Events To Track Progress

    April 30th, 2010

    Conversion, however that is defined for a site, is always the reason the site exists.  For me, a conversion is a visitor viewing at least 2 pages.  If I can do that then I know that I have engaged the person enough to look around the site a bit more.  You probably have some other definition of a successful conversion on your site.

    A fairly common conversion point for a website is account creation or e-mail capture (e-mail sign-up).  The most common way to look at how successful the sign-up process is is by using a fallout report.  A nice funnel that shows how many you started with and how many fell out at each step.  The bottom of the funnel is the total number of people that made it through the process.  This is a great way to look at things but there are two very different ways of doing it.

    The first way is based on pages viewed.  This is a very common way to look at fallout.  People that made it from Page A to Page B to Page C.  This works nicely in a very straightforward way.  It gives you a nice view of the total performance of that site path.  Unfortunately, at least in some WA tools, that is about all you can get at with the basic reporting capabilities.  The problem with this is that you might be missing some huge cake scraps, or golden nuggets, of information by looking at the data in aggregate.

    Setting a success event on each of these pages will provide a much greater degree of flexibility.  For instance you could very easily look at campaign tracking codes and see how many of each event was set for each tracking code.  This might give you information that you simply didn’t have before.

    Say, for example, that you had both display advertising and paid search campaigns pushing traffic to your site.  In all likelihood you know what the conversion is off of each of these tracking codes but you might not know how many of your email sign-ups are coming from each campaign.   It is very easy to start setting a success event on the sign-up confirmed page so that now you can get a count of that event by campaign tracking code.  Perhaps you find out that your paid search converts better but they don’t come and sign up for email.  This might cause you to change the messaging that you are doing in paid search (perhaps message email strong to drive sign-ups or message something else since e-mail sign-up just didn’t work).

    Similarly, if you had a 2-step process, and set a success event on each page, you would be able to see if one type of campaign had huge sign-up issues.  Perhaps you would learn that you want to create a different on-site expirence for that type of campaign to drive up sign-ups.

    Another thing that is great about using events is that they are easy to trend across time whereas fallout reports based on page views can be a bit more difficult or time consuming to generate.  The downside is that you probably have a limited number of events, so use them wisely.

    What type of conversion goal do you have for your website?

    This has been a Thought From The Cake Scraps.



    Should ‘Visit’ Metric Be Updated?

    September 15th, 2008

    Interruption is a way of life here in America. I remember reading somewhere that in Japan if a person is working by themselves they are not as likely to be interrupted because it is assumed that they are in thought whereas in America if you are working by yourself it means you are available because it is assumed you are not busy. Not sure if that is true or not, but I know that if I see someone at their desk I will talk to them if I need them. I always ask if they have time, but I still ask because – in famous final words fashion – it will only take a second.

    How does this relate to web analytics? It relates because of the definition of a visit. If you are new to web analytics, you may wonder “What is a visit?”.  Web Trends Live has an excellent glossary of terms which is where I pulled this definition from:

    Visit: A visit is an interaction a unique visitor has with a website over a specified period of time or activity. In most cases, if a visitor has left a site or has not executed a click within 30 minutes, the visit session will terminate.

    My question is, is this the correct length of time? Should it be longer than 30 min because of how many distractions/interruptions we have in a day? I read a great interview at FastCompany.com about how often people get interrupted at work. The average time between switching tasks was 3 minutes and 5 seconds. That is a lot of moving around. It took an average of 23 minutes and 15 seconds to get back to something they switched from.

    This would give credence to the 30 minute rule that is laid out for us, but I still have to wonder if it is correct. I think that with tab browsing people are more likely to have a longer lag time between looking at one page and looking at another. I think that since the onset of ‘restore session’ – when you open up a browser that you previously exited with multiple tabs active – lag times between activity have increased. ‘Fires’ come up at work and need to be handled, e-mails come in, the phones ring, etc. The reality is that while a person may be idle for 30 min they would say that it was one visit. This begs the question of who defines a visit, the web site or the viewer?

    My main concern is that this time frame may skew some data that looks at visits by a visitor for a given period of time. Perhaps you will get data that says people visit your site multiple times in one day – probably considered a good thing – when really you just can’t keep a visitors attention and they keep having a 30 min or more delay in between their activity. This would actually then be a bad thing because you are not keeping the viewer involved which may discourage them from coming back.

    Clearly an industry needs standards and, honestly, web analysts are lucky to have any standards at all in a field that changes so quickly while being so young. That said, hanging on to old standards just for the sake of standards isn’t such a great policy either. It doesn’t need to change today, but it is something to keep thinking about as browsing habits evolve.