What is a visit? When is a visitor a returning visitor? When is a page view a new visit for a returning visitor?

These questions and others need to be addressed when designing a web analytics solution, whether it be for the Internet, or the Mobile web.

What complicates it further is the lack of standards, and the different interpretations by different vendors. So what’s being done on the mobile web? How are others defining these terms? Without Javascript, how do we calculate time on page and other metrics?

When we first began development of Mobilytics, there was only one other product out there and it required the installation of a server. Without the ability to see the application, there was no way to really understand how they define visits, visitors, pageviews, referrers, etc…

Since then, Bango has released their current version, and AdMob has announced theirs. Unfortunately the Bango solution does not work like a traditional analytics package. In order to track your entire site, you need to use their special links. This makes viewing the page path of a visit impossible. It also means you need to re-code your site with Bango Links to do it. (Again, If I am wrong, someone please tell me how I can easily put Bango Analytics on my mobile site that has 50 pages.) But I bit the bullet and spent some time actually changing the links on our test mobile web site to bango links so I could compare (details and results to be released).

But even with their Bango Links, how do they define a visit? If I click on an ad somewhere and end up on a site, then I have started a visit. Well what happens if I click on a link on the site and go to a different page? Assuming that page is being tracked, would I be considered a new visit? It appears they have defined this as a page visit, and a visitor as a unique visitor. But if that’s the case, then how can unique devices be 20% higher than unique visitors?

(I’ll let the team at Bango answer that one. What I am trying to show is how the lack of standards and defined terms make it difficult to understand the data.)

AdMob Analytics on the other hand appears to be more like what we have built. Unfortunately it is only in private beta, and I doubt they will let me in. I’d ask one of their beta testers, but we have not found any yet.

So due to the lack of standards, and the lack of established precedence, we have defined these parameters.

While I am sure that the other vendors will make their own decisions, I am publicly posting the details for discussion. One thing we are big on here is transparency. Customers have been kept in the dark for too long by ad networks and analytics vendors. The purpose of analytics is to understand the your visitors. How can you do that if you don’t understand how the tracking is is done?

Comments are welcome and encouraged from both users and vendors (yes Bango, Amethon & AdMob, you’re getting Google Alerts when we mention you. Please feel free to chime in. Let’s get a discussion going.)

So here goes. The first parameter we needed to define what what we consider a Visitor. Well that one is pretty easy.

• A Visitor is someone who comes to the mobile site from the same Mobile Carrier Account. This means that they could theoretically take the SIM chip from their phone, and put it into a different one, and we would still consider them the same Visitor. Therefore, we need to track the phone model at the Visit level, not the Visitor level.

Defining Visit got a little more complicated for a number of reasons.

• A Visit is a Visitor who has not been to the site in the last 10 minutes. This was our first big decision. On the wired web, I could be idle on a page for 15 minutes reading before clicking to another page. I would consider that the same visit. The mobile web is different. If there is 10 minute between page views, then you are a really slow reader, or it’s a new visit. While we have set this at 10 minutes, it is customizable depending on your site type. If a site is a single page and wants to change it to a 5 minute window, it can be done.

Well, when we started getting real data, we realized that there were exceptions to this that needed to be addressed. Imagine this:

• A visitor clicks on an ad and arrives at your site. This visitor has not been to the site before. This is a New Visitor and a New Visit.
• They then leave the site and go somewhere else.
• They then click on a link from that site back to yours.
• It has only been 4 minutes since the last time they were on your site.

Is this a new visit?

Well with Mobilytics we need to track that 2nd referrer. Don’t you want to know that you got a visitor from there? The visitor had already left your site, and now they are back. So YES, we consider this a new visit. So if you see the same visitor with multiple visits within a 10 minute window, this is why. Surprisingly, this happens. We’ve seen it, and verified it. Same visitor, 2 different referrers, same 10 minute window.

Well here’s where it gets even more interesting. Imagine this:

• Visitor clicks on an AdMob pay per click ad and is sent to your site.
• Visitor goes back
• Visitor clicks on an AdMob pay per click ad and is sent to your site.
• Visitor goes back
• Visitor clicks on an AdMob pay per click ad and is sent to your site.
• Visitor goes back
• Visitor clicks on an AdMob pay per click ad and is sent to your site.

Well. NOT surprisingly, we have seen this also. it’s usually called CLICK FRAUD. It’s my understanding that companies like AdMob credit the advertisers for this. Armed with Mobilytics, our customers now have the ability to verify if that is the case. We will also be sharing any suspicious activity with AdMob in an effort to help them weed out publishers that might be cheating.

As for the metrics, Mobilytics will consider these separate visits.  There is no legitimate reason why the same person is clicking on an ad from the same campaign and going to the same page of the mobile site every 30 seconds, so we need to track every ad click since referrer is done at the visit level, and not the page view.

So now we come to the next question:

Without JavaScript, how do we know how long each page view is?

• Time on Page is calculated from the Start time of the pageview to the start time of the next pageview. If the case of a single pageview visit, and for the last page of a visit, we default to 30 seconds.

One of the reasons there is so little info on the mobile web, is that is is hard to track properly without JavaScript and cookies. So we do the best we can. When comparing our method with traditional Internet web analytics solutions, we found that many of them don’t assign any time to the last page. Well that’s not accurate!

If the average visitor spends 1 minute on the last page, and I get 10,000 visits per month, we are talking about under reporting the total visit time by 166 hours! With the mobile web, the average page view will be shorter. So we use 30 seconds. If a visitor comes to your site, then leaves, that visit was not ZERO seconds long.  There are many mobile sites that are only a few pages. We need to assign some value.

So what is a return visitor vs a new visitor?

We need to be perfectly clear on this one. Until such time that every single handset and carrier in the world supports cookies, and embedded unique id and/or Javascript, this number will not be correct.

• A return visitor is someone who has been to your site before.

There are two times we need to know this. The first is within the same visit. While this is difficult, it is easier than the other which is when a visitor returns the next day or a month later. While some mobile analytics products don’t even bother to identify return visitors (or multi page view visits for that matter), we felt that it was better to provide this information when available. This metric should be looked at for trending and for other info, but should not be assumed to be true. The actual number is higher than stated. As new handsets are released, this number becomes more accurate. It’s just a matter of time before we can certify it as accurate as on the wired web.

The key here is that for those visitors who return, you can see how often they visit, as well as average page view, revenue, etc. The number of visitors that support this are more than enough for a statistical sampling.

The last thing I am going to discuss in this post is referrer.

• The referrer is the WEB SITE and PAGE that the visitor came from when they landed on your site.

This one is pretty straight forward. Currently we do not include query string parameters in the referring page. There are just too many different ones. Sometime in the next few months we will be making this an option though. If you want to treat each one as a different page, then you will be able to.

One thing to  be aware of is that without javascript, the referrer has to come from the server and not the browser. While we have yet to see a situation where the referrer was not recorded, I’m sure it is possible.

Well that’s enough for today.  In another post  we’ll define carrier, unique device, goals, and others.

I welcome any feedback.

Bookmark It

Hide Sites

According to a post on hit search, comScore has purchased M:Metrics for $44.3 miillion plus options.

comScore, Inc. (Nasdaq: SCOR), a leader in measuring the digital world, today announced the acquisition of M:Metrics, Inc., the recognized leader in mobile measurement. The acquisition makes comScore the immediate leader in measuring the emerging and strategically important mobile Internet market and adds to comScore’s leading position in measuring PC-based Internet usage. The transaction involves a cash payment of $44.3 million and the issuance of approximately 50,000 options to purchase shares of comScore common stock to certain M:Metrics unvested option holders.

M:Metrics provides high level data on the mobile industry.

M:Metrics offers three primary measurement products: – MobiLens(TM), a syndicated monthly online survey that captures overall mobile phone usage, including device information, data usage, media consumption and demographic characteristics of a representative sample of more than 40,000 mobile device users.  MobiLens is available in the U.S., U.K., Germany, France, Spain, and Italy. – MeterDirect(TM), the industry’s first on-device meter that passively measures the mobile Internet behavior and media consumption of more than 4,000 existing Smartphone panelists. The M:Metrics metering technology is compatible with more than 280 device models. MeterDirect is currently available in the U.S. and U.K. – M:Ad(TM), the first competitive tracking service for mobile advertising that continuously monitors clickable display advertising from a broad representative set of mobile Web destinations to reveal leading advertisers across a variety of market segments.  M:Ad is currently available in the U.S. and U.K.

The full post is here on hit search. Congrats to the folks at M:Metrics!

Bookmark It

Hide Sites

I’m sitting here with 3 LCD screens in front of me with database queries, spreadsheets and browser windows open trying to determine how accurate Mobilytics is.

Let’s forget about mobile for a minute and just talk about web analytics in general. Before factoring in the complexities of mobile, I wanted to get a reference point where I could say that Mobilytics was correctly tracking a regular Internet web site.

Since we are not using JavaScript, this would be a great test of the accuracy of our server side snippet code in general.

So I decided to compare Mobilytics to a few web analytics products out there which I will not name. I will say that one of them is Google Analytics though. The problem with Google is that I can’t drill down to individual visits to compare page view by page view.

So here’s what I came up with. NO WEB ANALYTICS PRODUCT WILL EVER BE RIGHT!

It’s just not possible. There are too many opportunities for minor issues to impact the data. The real question is, how would you know if it was right anyway? And how good is good enough?

Here I am on a Sunday morning comparing my raw log files and database queries side by side with 2 other web analytics products. I placed each product’s tracking code on the same Internet web site, so you would expect them to match up.

Not the case. And I’m not just talking about general numbers and percentages. I am auditing individual page views one at a time. While I can understand the occasional duplicate appearing, or the time on the page being off,  how is it that I have visitors in my data that don’t show up at all in this other vendor’s product?  The one particular visit that led me to blog about this is coming from the U.S. on CabelVision using Firefox. So why would it not be appearing in the other product?

One thing I can think of is that Web Analytics rely on JavaScript and Cookies. Maybe this visitor turned them off? Well since we are using server side tracking code, we have the complete HTTP headers and other info so I can easily check. (doing this now), be right back…

Ok so here’s what I found. Clear evidence of a visitor who came through a referral link on a blog, and is not a crawler or search bot of any type. While I can’t tell in this case if they have cookies turned off, you would think with Firefox that would not be the case. But let’s assume it is. Wouldn’t we at least register a visit?  Not only did I lose a visitor, I lost a referrer, a page view, and I would never have even known. What if I am an advertiser and I am paying to attract visitors? Is it ok for one to be completely missing?

Who else is reviewing logs and comparing vendors to see how accurate they are? Now I wonder  how often this happens? I’m only reviewing a 1  hour period on a single day.

On mobile we can’t rely on cookies and Javascript, why does the wired web take them for granted? I guess the same way we need to discard data sometimes in order to maintain the integrity of the data, the web vendors do also. It just seems to me that there is no reason you can’t use an image tag and Javascript.

And just to be clear, I don’t even know if this is the reason the visitor was missing. I will be looking further though.

So the simple conclusion I have drawn from hours of comparisons in general is that putting the numbers side by side will NEVER match up exactly. At some point they will vary. But there’s no real way the average user would know anyway.

I’m looking forward to putting a few of the mobile products side by side and seeing how we stack up. The quality and accuracy of the reporting is the single most important thing we are focusing on, and that is what will make Mobilytics the leading third party analytics and tracking solution for mobile content. Why else would I be comparing single page views and HTTP headers on a beautiful Spring Sunday?

Bookmark It

Hide Sites

I finally got a chance to read through a post on the Bango blog by their CEO Ray Anderson regarding the still somewhat unknown Novarra transcoding SNAFU. Ray has commented on an interview at Mobile Marketing Magazine with Novarra’s COO.

Ms Rangarajan, as COO of Novarra is at best badly mis-informed or at worst blatantly transcoding the truth in her interview with the Magazine.

I completely agree with Ray on this one. For those of you not aware of this issue, here’s what’s going on. There are a number of mobile carriers using Novarra’s transcoding technology which allows ordinary Internet web sites to be adapted for mobile handsets. They are not the first transcoder on the web, but I believe they are the first that completely hides the information about the actual phone and browser it is being viewed on.

When Vodafone UK launched the Novarra transcoder on the now infamous 7/7/07 , to enable desktop optimised websites to render better on mobile, the result was outcry from thousands of content providers large and small that their sites could no longer be seen, were corrupted, or were destroyed.

http://uk.techcrunch.com/2007/09/21/vodafone-in-mobile-web-storm/ Advertisers on mobile sites found their ads were no longer viewed. People selling mobile content had a surge in customer complaints - content that was sold did not work (the phone type was unknown) or simply not delivered. Vodafone UK had not forseen the problem, but reacted very quickly to create a “whitelist” of sites that would bypass the transcoder - and this patch is still in place. Organizations like the BBC, CNN, SKY, Facebook, Flickr and others had service restored within a few days. The problem remains however that sites are “adapted” or corrupted unless the website owner knows how to get themselves added to the whitelist. Estimates of the financial losses to website owners in the UK range from hundreds of thousands of pounds upwards.

Those of us that are techies know that Novarra had to go out of their way to hide the original user agent information. There is no question in my mind that this was done intentionally. While we can identify the visitors from Novarra gateways with Mobilytics, we do not have any info on the phone model, capabilities or other identifying information. According to Novarra’s COO:

“The problem only arose on mobile sites that were not .wap or .mobi. - but there were a lot of people who didn’t address their mobile sites as .wap or .mobi. They addressed them as .com, because in the world they were used to, it wasn’t possible for their regular website to be rendered on a phone. “

Ray’s reply:

Er, yes. I have no idea what a “.wap” site is, but of course most sites will be .com, .net, .de or .co.uk or whatever. They will be in peoples bookmarks, sent to users in messages etc., why should a person have to change their site address to stop Novarra breaking their site?

This is crazy! They are transcoding mobile web sites that are already built to render perfectly on mobile phone. Mobile developers have painstakingly built these sites to render properly depending on what size screen a phone has and it’s capabilities. Novarra is completely stripping that information. At a minimum all they need to do is look at the headers and not transcode a site that has the proper doc type. They claim to not transcode .mobi or .wap (I’ve never heard of this one either Ray.), but that’s not good enough. While Novarra would like to claim that one very loud voice is causing industry backlash, this is simply not true. Also, without the Analytics that Ray and I provide, many content providers probably don’t even know this is happening! This issue needs to be publicized outside the tech community. Big brands and small site alike who have spent time and money tailoring their content need to speak up and let the Carriers that use Novarra’s technology know what’s going on. We are not asking them to stop rendering Internet Web Sites on Mobile, we are asking them the stop rendering Mobile Web Sites as Internet Web Sites for Mobile. If we can write code to identify thousands of phones, why can’t the transcoders simply not transcode mobile web sites? If the site is .mobi compliant, then don’t transcode it! It’s that simple. Better yet, here’s a simple fix that can be put in place in less than an hour. If you see this, add the site to the whitelist and don’t transcode it! <!DOCTYPE html PUBLIC “-//WAPFORUM//DTD XHTML Mobile 1.0//EN”

"http://www.wapforum.org/DTD/xhtml-mobile10.dtd">

Even simpler is this: IF THE DOCTYPE CONTAINS THE WORD MOBILE THEN WHITELIST (Novarra, translate to whatever development language used. I put the pseudocode in the public domain.)

Bookmark It

Hide Sites

1

Bookmark It

Hide Sites

I

Bookmark It

Hide Sites