Time Zone Trick [SiteCatalyst]
Since joining Analytics Demystified, the most common email/comment I have received goes something like this:
“When are you going to get back to blogging about cool, advanced stuff you can do in SiteCatalyst?”
While in my new role, I am vendor-agnostic, I will do my best to keep sharing the SiteCatalyst tips & tricks I used to on my old blog. My hope is that as I work with clients using all web analytics vendors, I will branch out and share tips & tricks for all technologies. However, as I always tell people, the goal of my blog posts are to introduce concepts that can be applied to all web analytics tools…
Now on with a new tip/trick…
Dealing With Time of Day (Time Parting)
One of the analyses that I have done from time to time is Time Parting Analysis. Time Parting Analysis consists of looking at the time of the day (or day of week) that website success takes place in order to better understand its importance. While I don’t usually put a whole lot of stock into the time of day, there can be times where websites do much better/worse in the morning vs. evening. Knowing this can be used when planning advertising so you can “strike while the iron is hot,” so to speak.
If you think Time Parting might be important to your business, you should capture the time of day in some manner into variables in your web analytics tool. For example, if you use Omniture SiteCatalyst, you might use the Time Parting Plug-in to pass the time of day (in half-hour increments) to an eVar or sProp. Doing this allows you to look at a report that might resemble the one shown here:
As you can see, this report allows us to see what the action is taking place on our website down to the half-hour increment. If you are not already doing this type of analysis, it may be worthwhile since you can glean some new insights and use this data point for visitor segmentation.
Time Zone Hell!
The next problem you will encounter is that of multiple time zones. If you work at a global organization and have people focusing on business in various locales, the above report is pretty much useless to many of your internal customers. If they happen to be good at math and can calculate time zone differences in their head, then you’ll be ok, but most people have trouble interpreting web analytics reports without the added labor of doing on-the-fly time zone translation!
Want to see this problem in action? Take a closer look at the report above. Do you notice anything strange? If you look closely, most of the Visits and Form activity took place in the evening. People might like your product(s), but not so much that they are willing to spend their evenings looking at them! The reason the above report looks strange is because it is for an Australian website, but the time zone is Pacific Standard Time. If you are a web analyst in Australia, seeing your website success events in the Pacific Time Zone is not super-helpful!
So how do we fix this? All it takes is a bit of creativity and meta-data. Keeping in mind that there is a direct relationship between time zones, you can take the above report and apply meta-data to it to adjust for alternative time zones. If you are using Omniture SiteCatalyst as in the example above, this means using SAINT Classifications. By applying a different SAINT Classification for each time zone you care about, you can create new reports for each time zone. Here is an example of what the SAINT file might look like for a few additional cities:
As you can see here, we took the data that was already being collected (the Key column, which in this case is PST) and added meta-data for four additional cities. You can add as many cities as you want and each column you add will create a new report for that city time zone. Once you have done this, you can see a new version of the report above adjusted for each time zone. Now if we look at the same report above, but use the Sydney Time Zone classification report, we see a report like this:
You will notice that now we are seeing the same exact data as the first report, but now the times of the website successes are adjusted for the Sydney time zone. This makes the report look a bit more normal for the Australian web analyst as the success events are now shown as taking place during more realistic business hours. The best part of this solution is that anyone using the standard Time Parting plug-in Omniture provides can use the same SAINT Classification file. It just needs to be adjusted so the “Key” column is the time zone for which you are collected the data. If you are using the PST time zone, you can download the file I showed above. If you are in a different time zone, you can still download the file and adjust it as necessary.
As always, there are a few caveats with any “hack,” so here are mine:
- I take no responsibility for daylight savings time which can wreak havoc on time zone translations, but even in that worst case, your data will be an hour off…
- Time Parting reports can also be used to track Day of Week. This is harder to adjust for than is time zone unless you are time stamping using the actual date and are willing to have a massive, multi-year SAINT Classification file. This is not a bad approach, but is much more involved. Contact me if you’d like to explore this.
- It is possible to collect time zone data using different time zones for each report suite. For example, it may be better for you in the long run to have your Sydney data collected in the Sydney time zone and your London data in the London time zone, but I have often seen clients have issues with this and if you don’t start doing this from the onset, you can have issues going to it later. Please consult your account manager for more details.
So there you have it, a few thoughts on Time Parting and a fun trick to make it more useful if you do business in multiple time zones. Give it a whirl and let me know what you think…
If you have any questions or want to learn more, feel free to contact me for more information.