HTML5 Storage and Analytics

One of the more powerful features in HTML5 is the ability to store data locally via the browser. Of course, browsers have had this functionality for a long time via cookies, but the HTML5 spec extends this concept even further, solving some additional web site use cases, and opening the door for the rapidly emerging mobile world.

Specifications
There are two mechanisms defined in the web storage spec: sessionstorage and localstorage. Sessionstorage allows for session-specific data to be stored, which can be helpful for maintaining state information that you may not want to extend into another visit. This even applies to sessions from the same visitor, within different tabs of the same browser. This is a better solution than cookies for scenarios where you want to keep transactions separate from one another. The spec notes this use case:

"For example, a user could be buying plane tickets in two different windows, using the same site. If the site used cookies to keep track of which ticket the user was buying, then as the user clicked from page to page in both windows, the ticket currently being purchased would "leak" from one window to the other, potentially causing the user to buy two tickets for the same flight without really noticing."

The localstorage mechanism, on the other hand, persists across sessions and visits.

How much storage?
The spec currently suggests a limit of 5MB per origin (domain) for this new storage. This may change as the spec continues to be revised. At 5MB, it's certainly much larger than the limit on cookies today.

Privacy
There's a decent sized section of the spec that speaks to "user tracking". There's clearly a strong concern about how this storage mechanism could be used to build user profiles and potentially track personal information. It looks like the working group developing this spec is taking privacy concerns very seriously, and are building in good safeguards.

Some thoughts
This storage would have been a great mechanism to have many years ago, but I'm not sure we were really ready for it. I think we've learned a lot over the years about privacy, and protecting personally identifiable information, and the time is much better now for such power.

The possibilities with this storage mechanism are fantastic. Google has already been making use of this functionality to help improve its apps. Apple has been a strong supporter of advancing the HTML5 spec in general.

But the rise of mobile computing has really made this mechanism important. Some very smart folks are already figuring out how to leverage localstorage to build apps that behave like a native app (eg, an iPhone or Android app), but are actually running in a browser. Check out Nextstop on your mobile device to see an example of what I mean. By pre-fetching and storing content, the experience becomes extremely rich when moving from view to view. It's quite amazing to experience it.

The Analytics connection
Analytics providers like Webtrends can obviously make use of the localstorage mechanism in creative ways. But the real thought-leadership will come with providing new analysis of usage of the storage functionality so website owners can better optimize their sites. More good opportunities for analytics providers and practitioners!

HTML5 rel=noreferrer and Analytics

Phillip Lenssen over at Blogoscoped notes this interesting HTML5 nugget from Mark Pilgrim's DiveIntoHTML5 site that suggests that there will be a new relation attribute (rel="noreferrer") for links that will force browsers to drop the referrer from the header when selecting links.

This is how Mark describes it in the semantics section of his site:

rel="noreferrer" “indicates that no referrer information is to be leaked when following the link.” No shipping browser currently supports this, but support was recently added to WebKit nightlies, so it will eventually be showing up in Safari, Google Chrome, and other WebKit-based browsers. [rel="noreferrer" test case]

This is an interesting use of rel in HTML, changing the behavior of the browser. Especially a default behavior like this that has been around since the stone age (early stone tablets had a referrer of course...).

The impact to the Analytics community could be quite far-reaching. Referrer information is obviously quite important to a lot of base reporting dimensions. We'll all be interested to see if this specification will actually make it into HTML5.

Nextstop Nicely Bridges Apps and HTML5

Robert Scoble has shared an interview with Carl and Adrian over at Nextstop. They have put together a slick iPhone app (and Android, etc) based on HTML5. The app looks fantastic.

What's slick about the app is how they've leveraged new browser functionality. They note what they've done via their blog...here's a synopsis of the cool stuff:

The technologies we're using include:

• ApplicationCache: We've built our application using Javascript to manage page transitions, so the core HTML, Javascript, and CSS is only loaded once. We're using the HTML5 ApplicationCache to speed startup time on subsequent loads by caching Javascript and CSS so that these resources are cached for subsequent application loads.


• Geolocation: We're utilizing Geolocation to get your current physical position in the browser to show nearby content.


• localStorage: As you browse the application, we try to prefetch content aggressively so that any time you click, the content needed for the next page has already been downloaded. This is possible because we store all prefetched content locally on the phone using the localStorage object. This also means that as you browse to content you've already seen, no additional network requests are needed because that content has already been stored.


• Google maps v3: Google has been working on a new version of the Maps API, specifically optimized for performance on mobile devices. We've found this to be a substantial improvement over Maps 2, and a reasonable alternative for a native maps implementation.


• iphone-photo-picker: One of the key capabilities of the iPhone that isn't yet available through the browser is access to the camera and local photo library. To bridge this gap, we've built (and are open sourcing) a small helper application that exposes a urlscheme (photopicker://) that can be called from any web application to invoke the camera or photo library, and then will POST the selected image to a URL you specify.

That last item is very cool. Extending standard functionality of mobile devices into the browser is a huge enabler for everyone. Well done guys.

As Marshall noted yesterday,

Could mobile web apps challenge the dominance of native apps on the iPhone? That's an active debate.

The good news for the analytics world is that the standard tagging tracking methodology for these high-performance mobile web apps is fairly well known. However, there is new work to be done as we figure out what's important to track as new APIs are exposed, and mobile web app owners become more proficient with them.