Professor Tom Davenport of Babson College will be speaking today (10am PST) on a topic he's written on previously, Competing on Analytics Paper. The subtitle for the presentation is, "Move Faster, Accomplish More, and Avoid Mistakes by Learning From The Best". Could be interesting.
The Juice Analytics folks will be covering the event.
Filed in: analytics
Technorati Tags: analytics
Tuesday, October 31, 2006
Tuesday, October 17, 2006
Tracking Ajax
As we know, many Web 2.0 implementations require some new tricks from our analytics packages. As Eric P and others have written, the old-guard measure of "hit" (or something like it) is possibly making a comeback as we ponder how to measure (or what to measure) in this more dynamic world we are in now.
Enter Ajax
One of the more interesting Web 2.0 application types to tackle is Ajax implementations. Built on the idea that you don't have to refresh the entire page to present updated information to the visitor, Ajax is really gaining some steam in the industry. And rightfully so...it's really quite powerful, very efficient, and is a great example of a "rich" user experience. The basic idea is that instead of a link rendering a new page request, a link only fetches a smaller amount of content that is displayed back to the visitor quickly. To confuse things a bit, this content can come in a variety of formats (XML, HTML, JSON, etc.), and can be requested a number of different ways (XMLHttpRequest, IFrame, etc.). From an analytics perspective, it doesn't really matter. What's important is that the visitor has taken some action, and we likely want to know what the action was (and sometimes we want to know what was inside the response too...I'll get to that in another post).
A major issue we face then is how to treat pages vs. the (many) potential requests that follow on the page. These secondary (and subsequent) requests are not pageviews in the traditional sense. So, what do we call these non-pageviews? What do we track, and how? Of course, it depends on your needs, but let's dive into an example to see how others are thinking about it.
Example: Microsoft
One of the more important properties on the internet is working on a new soon-to-be-released Ajax facelift. The very smart folks over at Microsoft have a major redesign in the works that is very impressive, and a offer us very heavy example of Ajax from which to learn. If you go to the current Microsoft Homepage, you'll see an example of Ajax in the tab interface about 2/3rds of the page down (in the center). If you hover over the "Latest releases" menu heading, you'll see some new text and a new image appear. The images are dynamically returned back to the browser in an Ajax call. Side note: if you stay hovered over one of the menu headings for a second, a tracking hit is sent...but only one time per menu item to avoid overkill on mouse hover tracking.
However, if you want to find out more about Windows Vista, you might click on the upper left navigation "Windows" link, then click "Windows Vista". Three pageviews altogether.
Now try this. Go to the new Microsoft "preview" site, which features some new Ajax look-and-feel. Now if you want to find out about Windows Vista, you might use the "Microsoft Site Guide" menu on the upper right, selecting "Products & Related Technologies". This makes an Ajax request, but instead of refreshing the page, presents you with a new pop-up window over the top of the page. Now select "Windows", and the window is updated with more dynamic information. Now select "Windows Vista" and you are sent to a new page. Two pageviews with two extra requests.
You could argue that the pop-up menu looks like a page, and you might want to track it as a pageview. But you can also suggest that since you were still technically on the homepage, it should be tracked as a separate type of request. For sure the third click, which simply rendered new data in the menu was different than a full page request.
Tracking Ajax Requests
In order to track these requests differently, we have defined different event "types" via a new parameter. In this case, the parameter is WT.dl, with values to describe a pageview or an ajax request (or a mouseover, or an RSS feed view, or a "start" of a video...you get the idea). Within the analytics tool (WebTrends - no great surprise there ;-), we simply leverage the powerful analytics reporting (or new Marketing Lab Warehouse) to track these events independently (or together if needed). Pageviews remain as pageviews. Other requests are defined appropriately and tracked as needed to provide accurate reporting.
This type of tracking leverages the client to send the request to the analytics tool (I'll call it Asynchronous Client Tracking of AJAX, or ACTAjax - ok, this is why I'm not in Marketing :-) There are other methods for collecting data though that might become necessary when you don't want the client to send the data (security, privacy or the scenario just doesn't allow it), or when the client isn't a traditional browser (tracking API requests, RSS feeds, some mobile devices, etc.). For these reasons, you may also want to have other collection strategies ready (server-side requests, traditional logfile analysis, etc.). I'll talk more about these types of requests in a subsequent post.
More Info
An excellent team of speakers is putting together a series of great presentations for our upcoming Marketing Performance In Action conference in Orlando (Oct 24-25). Our own Clay Moore will be speaking with Brant Barton (co-founder and VP of Business Development at Bazaarvoice) will be speaking about tracking Web 2.0 technologies (Optimizing Your Web 2.0 Programs with WebTrends) in their session on Wednesday.
I'll be at the MPIA conference as well - if you're going to be there, please drop me a line (elbpdx @ gmail) and let's be sure to connect!
Otherwise, if you have any best practices, or other excellent ideas...feel free to leave a comment here!
Filed in: analytics, ajax
Technorati Tags: analytics, ajax
Enter Ajax
One of the more interesting Web 2.0 application types to tackle is Ajax implementations. Built on the idea that you don't have to refresh the entire page to present updated information to the visitor, Ajax is really gaining some steam in the industry. And rightfully so...it's really quite powerful, very efficient, and is a great example of a "rich" user experience. The basic idea is that instead of a link rendering a new page request, a link only fetches a smaller amount of content that is displayed back to the visitor quickly. To confuse things a bit, this content can come in a variety of formats (XML, HTML, JSON, etc.), and can be requested a number of different ways (XMLHttpRequest, IFrame, etc.). From an analytics perspective, it doesn't really matter. What's important is that the visitor has taken some action, and we likely want to know what the action was (and sometimes we want to know what was inside the response too...I'll get to that in another post).
A major issue we face then is how to treat pages vs. the (many) potential requests that follow on the page. These secondary (and subsequent) requests are not pageviews in the traditional sense. So, what do we call these non-pageviews? What do we track, and how? Of course, it depends on your needs, but let's dive into an example to see how others are thinking about it.
Example: Microsoft
One of the more important properties on the internet is working on a new soon-to-be-released Ajax facelift. The very smart folks over at Microsoft have a major redesign in the works that is very impressive, and a offer us very heavy example of Ajax from which to learn. If you go to the current Microsoft Homepage, you'll see an example of Ajax in the tab interface about 2/3rds of the page down (in the center). If you hover over the "Latest releases" menu heading, you'll see some new text and a new image appear. The images are dynamically returned back to the browser in an Ajax call. Side note: if you stay hovered over one of the menu headings for a second, a tracking hit is sent...but only one time per menu item to avoid overkill on mouse hover tracking.
However, if you want to find out more about Windows Vista, you might click on the upper left navigation "Windows" link, then click "Windows Vista". Three pageviews altogether.
Now try this. Go to the new Microsoft "preview" site, which features some new Ajax look-and-feel. Now if you want to find out about Windows Vista, you might use the "Microsoft Site Guide" menu on the upper right, selecting "Products & Related Technologies". This makes an Ajax request, but instead of refreshing the page, presents you with a new pop-up window over the top of the page. Now select "Windows", and the window is updated with more dynamic information. Now select "Windows Vista" and you are sent to a new page. Two pageviews with two extra requests.
You could argue that the pop-up menu looks like a page, and you might want to track it as a pageview. But you can also suggest that since you were still technically on the homepage, it should be tracked as a separate type of request. For sure the third click, which simply rendered new data in the menu was different than a full page request.
Tracking Ajax Requests
In order to track these requests differently, we have defined different event "types" via a new parameter. In this case, the parameter is WT.dl, with values to describe a pageview or an ajax request (or a mouseover, or an RSS feed view, or a "start" of a video...you get the idea). Within the analytics tool (WebTrends - no great surprise there ;-), we simply leverage the powerful analytics reporting (or new Marketing Lab Warehouse) to track these events independently (or together if needed). Pageviews remain as pageviews. Other requests are defined appropriately and tracked as needed to provide accurate reporting.
This type of tracking leverages the client to send the request to the analytics tool (I'll call it Asynchronous Client Tracking of AJAX, or ACTAjax - ok, this is why I'm not in Marketing :-) There are other methods for collecting data though that might become necessary when you don't want the client to send the data (security, privacy or the scenario just doesn't allow it), or when the client isn't a traditional browser (tracking API requests, RSS feeds, some mobile devices, etc.). For these reasons, you may also want to have other collection strategies ready (server-side requests, traditional logfile analysis, etc.). I'll talk more about these types of requests in a subsequent post.
More Info
An excellent team of speakers is putting together a series of great presentations for our upcoming Marketing Performance In Action conference in Orlando (Oct 24-25). Our own Clay Moore will be speaking with Brant Barton (co-founder and VP of Business Development at Bazaarvoice) will be speaking about tracking Web 2.0 technologies (Optimizing Your Web 2.0 Programs with WebTrends) in their session on Wednesday.
I'll be at the MPIA conference as well - if you're going to be there, please drop me a line (elbpdx @ gmail) and let's be sure to connect!
Otherwise, if you have any best practices, or other excellent ideas...feel free to leave a comment here!
Filed in: analytics, ajax
Technorati Tags: analytics, ajax
powered by performancing firefox
Thursday, October 05, 2006
Non-Profit Startup Analysis
I wanted to share the final results of an entrepreneurial non-profit effort to benefit Schoolhouse Supplies here in Portland. As I mentioned previously, the general idea was to offer school supplies online so parents could avoid some of the tedious back-to-school shopping in the fall, and benefit a great organization in the process.
What made this effort different than other online stores is:
1) The proceeds benefit Schoolhouse Supplies - a non-profit "free" store for teachers
2) The list of supplies were customized, based on the exact needs of the teachers
3) The supplies were distributed (by volunteers) directly to the child's classroom
4) The online store was built by volunteers (many thanks to Nate M and David M!)
5) The online store featured some .NET, a little JAX (we didn't have time for the Asynchronous part, but it was close, and we'll get it for next year ;-), the fabulous salesforce.com as a backend, AuctionPay for credit card processing, and of course, WebTrends for some slick analytics.
Our original goal this year was to pilot the program at one elementary school and one middle school. It became obvious very early on that the middle school wasn't going to fit with our model. This program works well for elementary schools because most of the supplies are "shared" in the classroom. That is, the students bring the supplies, and they are all combined together, and the teacher uses them throughout the year as needed. In middle school the students hang on to their supplies (in lockers and VERY heavy backpacks!). So, we stuck with one elementary school.
The elementary school we chose has a population of less than 500 students. For this pilot year, I was hoping we'd get a total of 50 orders so we could figure out the flow of the online application, and whether the logistics of delivering the supplies worked. I was very anxious to hear the feedback from the parents on the idea.
Ok, so, how'd we do?
8 Weeks Online Accepting Orders
129 Total Supplies Sets Ordered
$3,482 in Orders
85 Total Families Ordered
8 Middle School Students Volunteered 4+ Hours Each to Distribute Supplies
In short, it was a great success. We surpassed all of our goals, and got some absolutely terrific feedback from parents and teachers. Sweet!
Of course, I've got to include some analytics! Over the 8 weeks, we had a total of 305 visits. One of the lessons learned is that parents are generally not thinking about school supplies over the summer. We tend to wait until the last week or two before school starts to worry about supplies. We had a deadline to buy the supplies, so we had to cut off the ordering early. A couple of parents sent out an email blast to other parents near the end, and we saw a nice uptick the last few weeks.
The ordering process had essentially 6 steps after the Welcome page: Parents had to choose the class the child was entering; enter the student's name; review the "cart" (if a parent had more than one child in the school, this is where they could add their other child(ren)); enter checkout information; verify/approve the order, then receive confirmation. Of the 305 total visits , 86 of them converted. 28.2% conversion! Very nice.
We did not attempt to optimize the site for search engines as we weren't focused in this area at all. We assumed that only individuals who heard about the site from our limited communications and word of mouth (buzz!) would visit the site. But of course, a few folks found us via searches, so it's good to capture what was on their mind (search phrase) when they arrived for planning for next year.
All in all, it was a great pilot. It was a terrific win for teachers, parents, and Schoolhouse Supplies (and therefore a win for many students in need). Many pieces had to come together to make this work well, and thanks to many folks (Nate, David, Nick, Courtney, Liz, Kara, Simone and her amigos) for giving this effort its positive spirit! Also, thanks to WebTrends and the Salesforce Foundation for offering free services for this non-profit startup.
Our current plan is to roll this out to more schools next year and figure out some scaling issues (mostly on the distribution side...the technology is already set to scale world-wide! :-) After next year, I anticipate it can grow very quickly.
Filed in: analytics, salesforce.com, nonprofit, web+analytics
Technorati Tags: analytics, salesforce.com, nonprofit, web+analytics
What made this effort different than other online stores is:
1) The proceeds benefit Schoolhouse Supplies - a non-profit "free" store for teachers
2) The list of supplies were customized, based on the exact needs of the teachers
3) The supplies were distributed (by volunteers) directly to the child's classroom
4) The online store was built by volunteers (many thanks to Nate M and David M!)
5) The online store featured some .NET, a little JAX (we didn't have time for the Asynchronous part, but it was close, and we'll get it for next year ;-), the fabulous salesforce.com as a backend, AuctionPay for credit card processing, and of course, WebTrends for some slick analytics.
Our original goal this year was to pilot the program at one elementary school and one middle school. It became obvious very early on that the middle school wasn't going to fit with our model. This program works well for elementary schools because most of the supplies are "shared" in the classroom. That is, the students bring the supplies, and they are all combined together, and the teacher uses them throughout the year as needed. In middle school the students hang on to their supplies (in lockers and VERY heavy backpacks!). So, we stuck with one elementary school.
The elementary school we chose has a population of less than 500 students. For this pilot year, I was hoping we'd get a total of 50 orders so we could figure out the flow of the online application, and whether the logistics of delivering the supplies worked. I was very anxious to hear the feedback from the parents on the idea.
Ok, so, how'd we do?
8 Weeks Online Accepting Orders
129 Total Supplies Sets Ordered
$3,482 in Orders
85 Total Families Ordered
8 Middle School Students Volunteered 4+ Hours Each to Distribute Supplies
In short, it was a great success. We surpassed all of our goals, and got some absolutely terrific feedback from parents and teachers. Sweet!
Of course, I've got to include some analytics! Over the 8 weeks, we had a total of 305 visits. One of the lessons learned is that parents are generally not thinking about school supplies over the summer. We tend to wait until the last week or two before school starts to worry about supplies. We had a deadline to buy the supplies, so we had to cut off the ordering early. A couple of parents sent out an email blast to other parents near the end, and we saw a nice uptick the last few weeks.
The ordering process had essentially 6 steps after the Welcome page: Parents had to choose the class the child was entering; enter the student's name; review the "cart" (if a parent had more than one child in the school, this is where they could add their other child(ren)); enter checkout information; verify/approve the order, then receive confirmation. Of the 305 total visits , 86 of them converted. 28.2% conversion! Very nice.
We did not attempt to optimize the site for search engines as we weren't focused in this area at all. We assumed that only individuals who heard about the site from our limited communications and word of mouth (buzz!) would visit the site. But of course, a few folks found us via searches, so it's good to capture what was on their mind (search phrase) when they arrived for planning for next year.All in all, it was a great pilot. It was a terrific win for teachers, parents, and Schoolhouse Supplies (and therefore a win for many students in need). Many pieces had to come together to make this work well, and thanks to many folks (Nate, David, Nick, Courtney, Liz, Kara, Simone and her amigos) for giving this effort its positive spirit! Also, thanks to WebTrends and the Salesforce Foundation for offering free services for this non-profit startup.
Our current plan is to roll this out to more schools next year and figure out some scaling issues (mostly on the distribution side...the technology is already set to scale world-wide! :-) After next year, I anticipate it can grow very quickly.
Filed in: analytics, salesforce.com, nonprofit, web+analytics
Technorati Tags: analytics, salesforce.com, nonprofit, web+analytics
Subscribe to:
Posts (Atom)