You are currently browsing the category archive for the 'Web Analytics' category.

Twitter has just released a new useful guide covering the basics, best practices and case studies for using Twitter for business.
They are trying to stress that Twitter should be viewed as a tool for building relationships rather than a tool for broadcasting announcements, PR, etc. in their words:
“Instead of approaching Twitter as a place to broadcast information about your company, think of it as a place to build relationships.”
It is still a great vehicle to get coupons, deals and specials out, but the long term value will come for said relationships.
Another interesting subject they address is measuring the value of Twitter. 2 things are important in this regard:
- Twitter ( as other social media activities) links should be tagged and reported in web analytics tools using special tags embeded in the tiny URLs so they could be seamlessly rolled up along with all other measured media
- As an engagement tool, it brings to focus the tracking and value placed on brand engagement as part of the value of the web activities and interactions. Think about the value that can be assigned to a user reading branded messages several times a day.
For more information about best practices in using Twitter for business see our previous post on the subject: bulding the collaborative enterprise.
We’ve all dealt with requirements that were written by well-meaning, but
technology-confused procurement departments, or business users who believe that people still use the Mosaic Browser (my first graphical browser!). Few authors of quasi-technical requirements put much thought to the actual cost of implementing a modern, rich, dynamic web application on decade-old technology.
A purposely over-the-top hypothetical quote :
The application must support Microsoft Internet Explorer 5.0+, Netscape 4+ at a minimum graphical resolution of 800×600 pixels.
While you may at first chuckle at this obvious bit of anachronism, think back to the last system requirements you spec’ed out for a web application.
What browsers did you ask to support? Were you shocked when the development team told you you couldn’t have that cool AJAX drop-down because your browsers didn’t support it? Were you suprised when compromises had to be made to the look and feel, or flow of the application? How many users really use those old browsers, anyway? How many of your users do?
“They shoot browsers, don’t they?” — Jeremy Keith
Don’t know the answer? Don’t worry, it’s pretty common. A lot of businesses make requests for web-based applications without first doing internal due diligence to understand their target market. Sure, you can build a web application that settles for the lowest common denominator — but why sacrifice when you might not have to?
Understanding your users’ browsing platform should be one of the first steps to building requirements for projects that involve a significant IT spend on web application development, whether it be enhancements to existing applications, or greenfield development.
Here’s 4 reasons why skipping this important step of due diligence will cost you more money, or users, or attention:
- You’ll Be Too Conservative. Fearing that you’ll lose the 0.5% of users who may be on Internet Explorer 5.0, you’ll insist (against your CTO’s recommendation) that all users are important, and if it means sacrificing a few bells and whistles, so be it.
- You’ll Be Too Boring. You’ve heard about rich internet applications, Web 2.0, AJAX? If you’re trying to support these new technologies on browsers that are 5+ years old, forget it.
- You’ll Spend Too Much. The 80/20 rule will be in full effect when you realize late in the development cycle that no one tested with Netscape 7.2. “But it’s in the requirements document!” cries the project sponsor. Frantic testing will unveil the fact that half the functionality is broken or visually skewed. You fire the designer, and the project goes into a death march to the lowest common denominator.
- You’ll Be Unhappy with the Final Product. You’re building the web application to replace your mainframe claims processing system. Or your billing system. Or your financial forecasting package. And the final, boring mess will look exactly like what you had on your old green-screen system, except it’s different. Users are complaining that it’s not easy to use, and your CFO is now revisiting your ROI projections. Projects aren’t supposed to end like this… are they?
Fortunately, judicious use of web analytics and good old fashioned business analysis can provide you with concrete data to build a solid foundation of business cases and technical requirements. The chart below illustrates browser market share over the past 9 months:

Source: StatCounter Global Stats, April 2009
You can see that the bulk of market share goes to a very small percentage of very modern and powerful browsers. How can this information help you? In Part 2 of this series, we’ll explore how up-front legwork in web application development can lead to a happy outcome for all.

A just released survey of the top 40 e-commerce sites asked users to rate their satisfaction with the buying experience. In the results, the survey director notes “higher customer satisfaction ratings often translate into loyalty and purchase intent”.
It is amazing that we still need surveys to tell us that. Web usability started as an art and is now an established science that uses audience personas, usage stories and needs mapping to optimize site flow, calls to action and creating an engaging yet efficient experience tailored to each visitor.
Jacob Nielsen in recent studies found an improvement of 83% to 138% in KPI’s resulting from a web usability redesign. In about 12% of the cases, the increase was tenfold.
With every web initiative need to provide Return On Investment (ROI) justification, most sites and applications have huge potential for improvement and can easily justify usability upgrades.
How to build a strong ROI case
The common formula for the commerce site business potential is based on the simple concept of getting as many visitors as possible and converting them into paying customers.
Business = Visits x Conversion Rate X Average purchase amount (For each revenue stream on the site)
Let’s look at each of these 3 components that largely determine site performance: volume, conversion and purchase size and see where the usability comes in.
Volume: traffic is comprised of new traffic and repeat traffic (V = Vnew + Vrepeat). Attracting new visitors to the site can be expensive and the acquisition cost is often reduced from the total revenue generated. Repeat and loyal visitors are essential to profitability and any improvement in the repeat visitor rate has significant impact on the bottom line. Good user experience that contributes to customer satisfaction will increase the number of repeat visits and add traffic without the acquisition cost.
Conversion Rate: The other critical role of usability is to make sure each visitor is provided with their specific needs which are not always a direct purchase. In a previous post I looked at the new e-commerce paradigm that acknowledges the multiphase shopping experience and provides information, interaction and solutions for visitor in every phase of their purchasing decisions. User experience optimization can have a dramatic effect on converting a visitor to a customer.
Purchase Size: Amazon started product merchandizing, upsells and recommendations more than a decade ago but many companies still are not perfect at providing users with additional options and suggestions throughout the checkout process.
Therefore the impact of usability on the Business consists of the increase in repeat traffic (∆Vrepeat), the increase in conversion rate ∆CR and the increase in purchase size ∆PA or in a formula: B = (Vnew + (Vr + ∆Vr)) x (CR + ∆CR) x (PA + ∆PA)
Usability contributions to cost reduction and savings:
- Reduction in marketing spend for new customer acquisition. The same traffic goals can be achieved with more repeat traffic reducing marketing expenses for new traffic generation.
- Reduction in calls to phone support
Other factors to consider:
- The cost of doing nothing. Not improving usability can actually hurt the factors listed above as the market is not static. The overall web usability standards have increased with rich interfaces and Ajax style functionality. Sites that have not caught up, look dated and clumsy. The competition is not static either. If your site’s experience is inferior to the competition, traffic will move there.
- Social media and word of mouth quickly spread good experiences and bad one to an extremely wide audience.
And lastly, without good web analytics program and measurements, you may not know to identify the challenges of poor usability or the contributions of improvements so consider setting an analytics baseline prior to any substantial improvements.
The Holidays are here and with them all the yearly summaries and forecasts. It may be a good idea to go back a year and check how many oracles have seen this slowdown coming..
As I look ahead to 2009, I see a few clear trends for web technology areas that are providing value in these rough economic times and are maturing to the point that companies cannot ignore anymore.
Gartner published their list of strategic technology trends for 2009 a few weeks back. They highlight Cloud Computing, Web Oriented Architecture, Enterprise Mashups and Social Software and Social Networking.
Here are 5 additional web technology trends that will be important in 2009, in no particular order:
- Actionable Web Analytics as part of Enterprise BI and Dashboards.
Web Analytics in many organizations is still an orphan with no real parents. Every department looks at its data but rarely does it get a strategic priority as an indicator of business trends and business intelligence asset. Investment in web analytics allows for customer insights, marketing spend ROI, conversion optimization and can impact the bottom line. As companies invest in sophisticated BI and analytical dashboards, web based data that is not transactional is usually not there. Integrating web traffic and user interest data into these systems can result in new insights and better actionable data. - Phone Browser Compatibility
Mobile computing is booming. About 13M iPhones were sold so far, and the support for location and browser that both the Android, Blackberry and all Microsoft based smartphones are offering, the percentage of traffic to web sites coming from phones is already in the 3%-10% range and will only increase. These are not the early 00’s WAP/WML jokes but full HTML browsers. Still, these special browsers are very different from the full version used on PC’s and Laptops. Bandwidth is still a challenge and their support for Rich Applications such as Flash and Silverlight is lacking. If you have a fancy Flash based site, your users will most likely not see a thing. Companies that have ignored it so far will have to adjust their sites or redirect mobile traffic to a mirror mobile optimized site. - Location based services
Continuing from the previous point, these mobile devices have GPS included and location based applications can drastically impact the user experience. Either as an iPhone/Android application or websites, the ability to share location information and get back location specific data about local services, other people, events, sales or anything else adds a new dimension to mobile applications. - Increased reliance on open source infrastructure products and technologies
Free is always a powerful word. Strong and reliable open source environments allow companies to create a robust e-commerce infrastructure with little or no proprietary platforms. The excellent Apache OFBiz for example, provides strong open source modules for e-commerce, ERP, CRM and many others. Alfresco offers a great content management solution and multiple open source development environments are available. The case for Enterprise Open Source web environment is getting stronger every day. - Approaching Social Networking and Collaboration in a Strategic way
Everyone now realizes the power of social networks and is rushing to get in, establish a FaceBook page, a Twitter account and get’s their PR to sprawl the web to “engage” people. Internally, companies are haphazardly trying various collaboration methods. We see a maturity process happening through 2009 that will force companies to look at all their collaboration points in a strategic way and tie them to business goals and processes. This new approach will transform them from toys to tools and will establish their place and value in the new order.
During an informal forum recently, (whose members shall remain nameless to protect my sorry existence a few more years), analytics projects came up as a topic. The question was a simple one. All of the industry analysts and surveys said analytic products and projects would be hot and soak up the bulk of the meager discretionary funds availed a CIO by his grateful company. If true, why were things so quiet? Why no “thundering” successes?
My answer was to put forward the “typical” project plan of a hypothetical predictive analytics project as a straw man to explore the topic:
- First, spend $50 to $100K on product selection.
- Second, hire a contractor in the product selected and tell him you want a forecasting model for revenue and cost.
- The contractor says fine, I’ll set up default questions, by the way where is the data?
- The contractor is pointed to the users. He successively moves down the organization until he passes through the hands-on user actually driving the applications and reporting (ultimately fingering IT as the source of all data). On the way the contractor finds a fair amount of the data he needs in Excel spreadsheets and Access databases on the user’s PCs (at this point a CFO in the group hails me as Nostradamus because that is where his data resides).
- IT gets some extracts together containing the remaining data required that seems to meet the needs the contractor described (as far as they can tell, then IT hits the Staple’s Easy Button — got to get back to keeping the lights on and the mainline applications running!).
- Contractor puts the extracts in the analytics product, does some back testing with what ever data he has, makes some neat graphics and charts and declares victory.
- Senior management is thrilled, the application is quite cool and predicts last month spot on. Next month even looks close to the current Excel spreadsheet forecast.
- During the ensuing quarter, the cool charts and graphs look stranger and stranger until the model flames out with bizarre error messages.
- The conclusion is drawn that the technology is obviously not ready for prime time and that lazy CIO should have warned us. It’s his problem and he should fix it, isn’t that why we keep him around?
At this point there are a number of shaking heads and muffled chuckles; we have seen this passion play before. The problem is not any product’s fault or really any individual’s fault (it is that evil nobody again, the bane of my life). The problem lies in the project approach.
So what would a better approach be? The following straw man ensued from the discussion:
- First, in this case, skip the product selection. There are only two leading commercial products for predictive analytic modeling (SAS, SPSS). Flip a coin (if you have a three-headed coin look at an open source solution, R or ESS), maybe it’s already on your shelf, blow the dust off. Better yet, would a standard planning and budgeting package fit (Oracle/Hyperion)? The next step should give us that answer anyway, no need to rush to buy, vendors are always ready to sell you something (especially at month/quarter end – my, that big a discount!).
-
Use the money saved for a strategic look at the questions that will be asked of the model: What are the key performance indicators for the industry? Are there any internal benchmarks, industry benchmarks or measures? Will any external data be needed to ensure optimal (correct?) answers to the projected questions?
- Now take this information and do some data analysis (much like dumpster diving). The key is to find the correct data in a format that is properly governed and updated (no Excel or Access need apply). The key is accurate sustainability of all data inputs, remember our friend GIGO (I feel 20 years old all over again!). This should sound very much like a standard Data Quality and Governance Project (boring, but necessary evil to prevent future embarrassment to the guilty).
- Now that all of the data is dropped into a cozy data mart and supporting extracts are targeted there, set up all production jobs to keep everything fresh.
- This is also a great time to give that contractor or consultant the questions and analysis done earlier, so it will be at hand with a companion sustainable datamart. Now iterations begin – computation, aggregation, correlation, derivation, deviation, visualization, (Oh My!). The controlled environment holds everybody’s feet to the fire and provides excellent history to tune the model with.
- A reasonable model should result, enjoy!
No approach is perfect, and all have their risks, but this one has a better probability of success than most.
A visitor walking the demo floor at the recent Enterprise 2.0 conference would find it hard to define what all these companies and product offerings have in common and what qualifies them to be categorized as Enterprise 2.0 solution providers.
While vendors of organizational social networks are a clear fit, what is common to advanced search vendors, enterprise mashup providers, Content Management vendors and video broadcasting solutions?
It seems that the common thread is a shared vision of the future enterprise as a social, open and collaborative place where data, content, knowledge and expertise are more easily available and where productivity results from enhanced collaboration and information sharing.
We can categorize the solution areas based on what they allow the user to do:
Finding information and data across silos and systems is still the holy grail of today’s information systems. Our information workers are dependent on their access to information but the ever growing amount and complexity of the data makes it harder and harder.
Most basic Enterprise 2.0 products cover the first 4 levels. They include a basic search for content within the network, provide tools for creating new content, sharing, and collaboration using technologies like discussions, wiki’s, blogs, RSS, Public Profiles, and groups.
Products in this category include: Microsoft Sharepoint, SocialText, Telligent , Thoughfarmer and GroupSwim among many others.
The fifth level offers a unique opportunity to leverage the interactions, conversations and links to add context and intelligence. By using Tags or by auto detection of terms and traffic patterns, some of the solutions can help create a layer of relationships and meaning on top of the content and link together disparate pieces of content, data and people for a complete picture.
Products in this category include: OpenWater, Connectbeam, Inquira
The 6th level in our stack consists of tools that try to bring together and connect data from disparate systems and source and allow the user to connect them and create custom applications and views on demand. By using open standards and web services, these tools called Mashups attempt to simplify our search for information across multiple systems by allowing us to pull from them without creating a separate datamart as the baseline for data and correlation.
Mashups are a hot topic for enterprise portals and enterprise web 2.0 initiatives. IBM, Oracle and Micosoft are releasing mashup tools as well as a few smaller vendors like Jackbe and Serena
At the final level, we would all like to have a toolset that will allow us to discover ideas, bring important knowledge to our attention, alert us in real time to activities and trends we should be watching, feed us in real time information that is relevant to the tasks we are performing. No tools in this category yet but check again in a few months…
The ROI and game changing benefits of Enterprise web 2.0 internal implementations can go well beyond important outcomes like of employee involvement, morale and collaboration. It would come from harnessing the intelligence, context and knowledge within the organization (data, content and people) and outside sources to increase productivity, shorten development lifecycles, enhnace relationships make better decisions and inspire innovation.
This week, on one of our Web Analytics projects, we encountered a discrepancy in the Avg. Visit Duration calculation between a set of dashboard reports, and a set of ad hoc reports. We did some testing and research and discovered that the issue was actually a direct reflection on the fact that there are limited industry standards in web analytics. Visit duration is generally defined as the amount of time spent on the web site. It is measured by calculating the difference between the first time stamp in the visit, and the last time stamp in the visit.
One of the noticeable issues with this calculation is that last time stamp of the visit occurs when the user starts viewing the last page in their visit, not when they leave the page. The user could continue to dwell on the page, but that dwell time will not be counted as a part of the overall duration. This is because there is no way to determine how much time the user spent, since they send no additional requests back to the server.
This flaw is then exacerbated by the case of a single page view visit. When a visit includes a single page view (a bounce, in Google analytics terms) the result is a visit with duration = 0 because it contains only a single page view with a single time stamp. Many web analytics end users may consider this to be a bug, but it is a limitation associated with log data.
But, is duration = 0 really true? Isn’t it more like duration = unknown?
And then, how do we calculate Avg. Visit Duration? After some research and testing, we determined that the discrepancy due to the fact that formula for Avg. Visit Duration in the dashboard was:
- Total Time Spent/(Visits – Single Page Visits)
In other words, all of the visits with an “unknown” duration had been removed. Not a bad idea, but it needed to be declared in the documentation. As it stands, this formula violates the definition of “Average”.
But, in the ad hoc reporting sections of the product, the formula for Avg. Visit Duration was:
- Total Time Spent/Visits
The Web Analytics Association has released a standard definition of visit duration, and it includes a note that visits with a single page have a duration that cannot be calculated. But, the standard does not indicate how those visits should be handled in aggregate calculations. Therefore, it is still up to the software vendors, and in this case, we see both calculations in the same product!
We think assigning a value to an unknown is a bit deceptive, it masks the unknown. It would be preferable to make the volume of single page visits visible, and then Avg. Visit Duration of the remaining visits. If reports called attention to the single page visits, there would be more questions regarding their business value and how to improve it.





