The basic premise of the article is that since “the web” accounts for less overall bandwidth traffic on the internet, that internet users are abandoning the traditional web for other types of interaction (e.g., apps and such).

The core issue is the basic premise is completely off the mark. It shows how easy it is to distort data by using the right visualization. Let’s look at the graph of data that is the core problem. The graph shows that the portion of bandwidth dedicated to video traffic video has grown tremendously, overtaking “web” traffic by a tidy amount.

The issue with this visualization is multi-fold:

1) It is an overall percentage based chart. While the percentage of the overall bandwidth dedicated to “the web” has decreased, the overall pie has increase significantly. If we map out the total overall estimated traffic for the web you can see it has grown by about 100 times what it was in 2000.

Wow! That looks much different, right?

2) The graph equates overall size with actual consumption. Not all media is created equal. While video files are much larger, the impact of the data is well overstated. If I spend 5 minutes reading a blog post and another 30 seconds watching a short video, the blog post will have arguably engaged me more. However, would appear much larger if you charted it out. Look at the following chart…

Do you see Blog on there? It’s on there I promise, it’s just super small. This is a case of measuring the wrong piece of data. We should be looking at actual engagement rather than overall file size.

3) What is “The Web” anyway? This is a question of how the taxonomy is set up. While a majority of content might be video, I’m sure a great portion of that comes via the browser via sites like YouTube and Hulu. There are a number of set-top boxes out there that can stream internet content, but these are the vast minority.

Also, one wonders where music falls on this graph. Is that “The Web”? Certainly the bandwidth taken up by podcasts and streaming media services like Pandora should have shown up somewhere. They are conspicuously absent.

So what’s the deal? Certainly internet traffic is growing exponentially. Where is this traffic coming from if “the web” isn’t suffering? The population growth can’t explain it and people don’t suddenly have additional hours of free time they didn’t have before.

The truth is “the web” isn’t being replaced, but traditional media delivery methods are. Traditional media has been hit hard by the move to the internet. Newspaper and magazine subscriptions are down across the board (yes, including Wired).

But probably more significant is the growth of online video as an alternative to TV. Even the finales of American Idol manage to only pull in a small portion of what the audiences TV used to pull in. Just as people have abandoned their landlines to move to just having mobile phones as their main phone, younger demographics are dumping their TVs, in favor of a PC or mobile viewing devices. And who could blame them? With the availability of content and the convenience of all in one device, a TV seems redundant.

That’s not to say traditional media is dead or being completely replaced by online activity either. For example, after some mid-decade stalling, movie box office receipts are higher than they’ve ever been and continue to trend up. The front-porch newspaper and magazines might be close to dead, but truly savvy media organizations (The New York Times, The Economist, even Wired Magazine) are sure to exist in some format for many years to come thanks to their mobile, audio and web presence. How we interact with these brands may be different, but they are likely to remain. Look at what Wired managed to do with an simple online article.

From time to time content developers have to deal with systems that do not allow them to add meta tags to their pages. Some portal based systems do not even access the main page content until after the HTML document head has been rendered. Or perhaps you’re working with a content management system that does not allow you access to the main page templates where you would usually place meta data content.

However, if you’re able to enter JavaScript in the page content areas you do control, you can still add meta data to the page. JavaScript has a DOM or Document Object Model. This DOM gives you access to the content of the HTML document. Not only can you scan content, but you can also add content to the DOM.

In the following example we are adding a tag called test2 (called DCSext.test2 so the WebTrends tag will pick it up) with a value of “test good”. The following code creates a JavaScript parameter with the two values. It then accesses the DOM via the head and adds the meta data tags to the document.

<script type="text/javascript">
var meta;
if (document.createElement && (meta = document.createElement('meta')))
{
meta.name = "DCSext.test2";
meta.content = "test good";
document.getElementsByTagName('head').item(0).appendChild(meta);
}
</script>

Since the WebTrends base tag access the meta tag DOM directly, it will read the new meta data and send it to your SmartSource Data Collector. This strategy is an easy way to tackle some of the common pain you have when you cannot fully control the page creation.

The phone’s browser is based on the WebKit Open Source Project’s platform.  This is the same platform used by the Safari and Chrome browsers.

Google Chrome has effectively leapfrogged of Opera, but is far from unseating Safari, Firefox or Internet Explorer.

It’s worth noting that I am seeing Google Chrome actually dropping in market share. It’s not significant, but it suggests a lot of users played with it and decided to go back to their primary browser. Once Google adds what many users consider necessary features (let’s face it, despite the fanfare, it’s very bare bones right now), it will be interesting to see if it can be a real competitor.

See the WebTrends press release.

Post edited based on additional clarification from visitors.

A report from Monday, showing Google Chrome Traffic.

One of the most difficult issues faced by analytics professionals using tag based data collection is the tracking of online video. Adobe Flash and Microsoft Silverlight are fairly simple to track once you understand the concept of inserting data collection calls at certain points in the media timeline.

Things are much more difficult when tracking other types of embedded players. Many organizations standardized on Windows Media, QuickTime or Real Media years ago and do not have the option of changing to Flash based media players.

There’s not much to be done for organizations linking directly to media content unless you want to just analyze the initial click, analyze the streaming server log files or set up the streaming server to send data based on the media conditions. Neither option is very scalable or easy to deal with.

For organizations that embedded the media on their pages they do have additional options. All of the common media players do have JavaScript object hooks that can be used to access the player and the data. The example I provide below works with Windows Internet Explorer using Windows Media Player 7 or higher. Version 7 has been around since 2000, so this should catch almost all user using Internet Explorer. Firefox 3, Opera and Safari implement the Window Media Player slightly differently, so I will need to update this script using a completely different methodology. That will come later.

You can view my Media Player test page here

Lets dive down into the code a little:

<OBJECT ID=”MediaPlayer” width=”320″ height=”240″ CLASSID=”CLSID:6BF52A52-394A-11d3-B153-00C04F79FAA6″ type=”application/x-oleobject”>
<PARAM NAME=”URL” VALUE=”http://www.mediacollege.com/video/format/windows-media/streaming/videofilename.wmv”>
<PARAM NAME=”SendPlayStateChangeEvents” VALUE=”True”>
<PARAM NAME=”AutoStart” VALUE=”False”>
<!– BEGIN PLUG-IN HTML FOR FIREFOX–>
<embed type=”application/x-mplayer2″ pluginspage = “http://www.microsoft.com/Windows/MediaPlayer/” src=”http://www.mediacollege.com/video/format/windows-media/streaming/videofilename.wmv” align=”middle”
width=176 height=144 defaultframe=”rightFrame” showstatusbar=true></embed>

<!– END PLUG-IN HTML FOR FIREFOX–>
</OBJECT>

This is the standard code for embedding Windows Media Player content in a page. Note that the ID is “MediaPlayer”. This identifies our player to the JavaScript. If you want to reuse this code you will need to either change the JavaScript references or change to a standard id of “MediaPlayer”. Since there’s not really an advantage to naming each Media Player instance something different (unless you have more than one on a page), this will not be an issue for most users.

//Sets state to. This means we can detect plays
state = 0;

This JavaScript code sets a value of 0. The point of doing this is initiate a gatekeeper value to ensure multiple requests are not sent to the data collector without our permission. We will be looking at the next elements out of order.

<SCRIPT LANGUAGE=“JavaScript” FOR=“MediaPlayer” EVENT=“playStateChange(NewState)”>
switch (NewState){

// Play
case 3:

//Grabs video title
VideoTitle = document.MediaPlayer.currentMedia.getItemInfo(‘Title’);

This is the “play” state for the media clip. When a user starts to play
a clip this action is kicked off. The first thing we do is grab the
media title. If there is no media title, it will grab the filename.

// checks to see if state is not equal to one. If it is not equal to one, a Multitrack
call is executed and state is set to one
// The reason for setting the state is to ensure that multiple (incorrect) plays are not
sent to the data collector
if (state < 1) {
dcsMultiTrack(‘DCS.dcsuri’,'/Video ‘ + VideoTitle + ‘ Play’,'WT.ti’,'Video: ‘ +
VideoTitle + ‘ Play’,'WT.clip_t’,'Windows Media’,'WT.clip_ev’,'v’,'WT.clip_n’,VideoTitle);

// place event here and set state to 1 so it cannot occur again
state = 1;
}
break;

This next block of code checks to see if we have a value of 0 for the media player state we set before. If we do, an event is sent to the WebTrends data collection server and the state is set to 1. We set the state to one because the Media Player may hit the play state a number of times during a clip. If a user pauses the content or fast forwards, we could have a number of media request that I consider to be invalid.

The request to the WebTrends server includes standard metrics and parameters including our video title.

//8 MediaEnded Media item has completed playback.
case 8:
//fire event and set state back to 0. Additional plays will now be detected.
dcsMultiTrack(‘DCS.dcsuri’,'/Video ‘ + VideoTitle + ‘ Finish’,'WT.ti’,'Video: ‘ +
VideoTitle + ‘ Finish’,'WT.clip_t’,'Windows Media’,'WT.clip_ev’,'f’,'WT.clip_n’,VideoTitle);

//Sets state back to 0. We can now track replays.
state = 0;
break;

This block of code is executed when the media has completed playing. It also set the state back to 0 so any additional media plays will be captured.

So now we have “plays” and “completions” without a whole lot of fuss. Pretty cool, right?

But what if we want to dig a little deeper? What if we want to know if a user hit a certain milestone? Did the user get 25% through the clip? 50%? Knowing the clip fall off rate is very important when judging online video content. Are your clips too long? Are there key points where you are losing viewers? Without that data you are left without the insight you really need. Let’s grab that extra data.

//Set function to ping the player for status
function CheckPlayer() {
window.setInterval(“checkPlayerDCS()”,100);
}

//Set function to ping the player for status
function checkPlayerDCS() {

This bit of code sets up a Media Player checker. Since there is no event when a user hits 25%
of a clip we need to actively check the state of the player to get the data.

window.setTimeout(“CheckPlayer()”,1000);

This bit of code simply kicks off the checker.

VideoPercent = parseInt(document.MediaPlayer.controls.currentPosition / document.MediaPlayer.currentMedia.duration*100);

Now we need to do a little bit of math. We need to calculate the percentage complete. This can be achieved by taking the current position dividing it by the full duration of the clip and multiplying by 100 so we have a whole number percentage base.

// checks to see if state is equal to one. If so, a Multitrack call is executed and state is
set to two.
// The reason for setting the state is to ensure that multiple (incorrect) plays are not sent
to the data collector
if (VideoPercent > 24 && state == “1″) {
dcsMultiTrack(‘DCS.dcsuri’,'/Video ‘ + VideoTitle + ‘ Play 25 percent’,'WT.ti’,'Video: ‘ +
VideoTitle + ‘ Play 25 percent’,'WT.clip_t’,'Windows Media’,'WT.clip_ev’,’25 percent’,
‘WT.clip_n’,VideoTitle);
// place event here and set state to 2 so it cannot occur again
state = 2;
}

The next bit of code checks to see if we are already in the play state (i.e., 1).  We need to do this because sometimes this code can step on the play function firing. This way we can keep the events in the right order.

If we are in the play state and we are above 25% completed an event is fired. The state is changed again to make sure the media is not fired again. We repeat this a few more times to capture 50% and 75%. You can do this as many times as you like, keeping in mind that these server requests do count as page views. I suggest you don’t go too crazy with them.

Let’s look at the result using HTTP Watch:

HTTP Watch Output

If you look at the results you can see that five requests fire when I play the clip.  The first one fires when I play the clip, the second one when it hits 25%, the third one when it hits 50%, the forth one when it hits 75% and the last one when the clip finishes playing.

As I stated earlier in this post, this can be adapted to other embedded formats and browsers.  It just takes a bit of time to figure out the proper way of calling the data based on the platform.  I will be posting more trackers once I have time to go through all of the different possible iterations.

Straight from AVG:

First of all, I would like to let all of you know that the update has
already been released for all free users on Friday evening… That means, that the millions of free users should get updated within the next few days and you should see a significant decrease in
the SafeSearch requests…

Update for the Pro version (the paid product) will be released as soon as the QA for this is finished, which should be July 9th at the latest. Based on the QA results over the weekend, we expect that we should be able to release the update even sooner.

For paid users who have the SafeSurf component active (on by default), all pages are scanned upon receipt, as it was before. The web page content is scanned by a ‘transparent proxy’ and thus all exploits and malicious code get detected, irrespective of where the page comes
from, how it was opened or which program downloads the page content. This is the core of the real-time protection.  This has not changed but this part has no effect on webmasters or analytics as this is really scanning the page on the client only upon receipt – so only if the
user has already decided to visit the page…

The SafeSearch component was modified so that it now relies purely on a database approach. A black-list (database of known bad sites/URLs) similar to the anti-virus detection database is distributed to all users, allowing the SafeSearch component to mark known bad sites in
search results. However, no other scanning is currently being performed by the SafeSearch component. That means no visits to websites unless the user really clicks on a link. The black-list (bad site database) is based on our internal research and on the real-time
results of the SafeSurf component that are reported back to our systems by users who chose to participate in our prevalence reporting system (this is an opt-in feature of AVG8).

As a result, there should be no additional visits to websites that have not been initiated by the end user.

This is very good progress from AVG.  The question that is still outstanding is if the product still requests noscript analytics calls.  This could and probably has led to double counting of page views for websites where the user actually did visit the content.  I have requested an update from AVG on this specific issue.  I will let you know what I find out.

Highlights of the new release include:

• Calculated measures – Available via Custom Reports or even ad-hoc.
• Web 2.0 Reports – A nice new set of report for users that allow them to capture data on new technologies easily.
• Improved user administration – User roles make setting up hundreds of users a breeze.  This is a huge improvement.
• Enhanced language support (especially important for customers that use double byte character)

Over the next few weeks I will be diving into this new functionality in detail, offering tips and tricks.  Enjoy the release!