Monthly Archives: January 2009

Whilst I’m on the subject of Google and trying to finish half-written drafts hanging over from last year, I thought I’d briefly mention the release of Analytics for Flash.

Aside from capturing all the obvious generic statistics you’d expect from a Flash tracking package – and by being fluidly compatible with the main JavaScript library is capable of outputting all the core functionality of the existing Analytics components – the metrics offered by Google Analytics for Flash can be particularly designed to offer interesting insight into other aspects of your users’ activity you may not first expect. For example, you can collect data that can help you gauge levels of usability or (kind of) the implementation of design success. Seemingly you can monitor the behaviour of the users’ interaction during their visit too – as well as the length of the visit itself.

It’s all technically possibly, with Google’s introduction of event tracking that can be fired from custom interactions – whether that be a button click or video view or anything else. Along with that, the event can carry a payload, later received by your Analytics dashboard for your interpretation. It sounds simple – but it’s capable of being very powerful.

Previously, tracking your Flash content would be in isolation. That is to say, you could fire a tracking event when a user accesses a page of Flash content, but from there you were blind to their progress until navigating again.

This payload though, not only could detail traffic to specific sections within a Flash application (although in turn, separate events could be created for those) but could return data specific to that user and session. For example, the total time the user has spent in a particular place, or the site as a whole.

Depending on how complex you wish to be (and how many stats you want to trawl though later) this could offer very valuable data. But that data need not only be of value to an agency or advertiser. Counts for clicks on specific buttons aren’t anything new when you want to find out how many people click a ‘News’ link first, or if anyone notices the ‘Help’ button. This can be far more granular – to the point, as above, where the data could be used to inform decisions on say, design or usability.

Take a standard Flash video player as a media component you’re used to seeing on a daily basis. You can easily picture the common control bar. But how many people actually use those ‘Rewind’ and ‘Fast forward’ buttons? Could the design be improved?

Admittedly with Flash video components, you’re unlikely to see those nowadays ;) – but that (as I’ve picked this example) is the result of user testing, something this kind of tracking can’t replace – Jesse Warden has a strong sense of this in his post about Flash Analytics.

Anyway, the custom events let you send as (overly-) complex amount of data as you wish. Flash of course can be used everywhere, deployed as widgets or embedded on blogs anywhere on the Web. These Analytics though, are part of your application itself. So you can track its usage outside of the original HTML page the previous iteration of Analytics would have restrained you to.

And it’s free! Check out the code repo.

Exactly how search engines deal with the content of Flash-based websites and information in SWF files has notoriously been a bit of a grey area for a long time. Historically, website creators had to battle with clients as to whether the aesthetic potential of Flash was enough a pay-off against their judgement of the importance of this new idea called ‘SEO’.

In July of last year, Adobe announced a collaboration with Google (1, 2) and Yahoo! to develop a new Flash Player technology specifically to enhance the search results of dynamic content in Flash – ultimately, to make the SWF searchable.

But it was unclear how it worked, what it actually did and what provisions the Flash developer or content creators would have to make.

Peter Elst aired his thoughts and agreed as I did, it looked like a ‘backup’ or intermediary solution. There also lacked a standard or recommended approach to deploying the content for this new technology – presuming this new platform hadn’t just become instantly intelligent to all possibly methods of delivery.

Adobe later published an FAQ, but still it wasn’t very technical, so a few developers started experimenting. After seeing Peter’s attempts, Ryan Stewart announced a Flex SEO Contest – an outright declaration that we’re confused but determined to find out what exposure our content has. As well as being a bit of fun. ;)

Dominic Gelineau constructed fourteen test cases, essentially finding every possible way you could contain a simple text string in a SWF file (see 1 – 7 here, 8 – 14 here). He used both static and dynamic TextFields, populated them in various ways, MXML components, standard Flash UI components, whether to use states, etc – covering all the bases across Flash and Flex.

Initially he concluded Google wasn’t really finding anything new, but in a later article for InsideRIA he listed his principle observations:

  1. Most of the content that was on the stage/timeline at compile time would be indexed even if it was outside the viewing area.
     
  2. The TextArea, Text, ViewStack and custom MXML component in Flex would get indexed if they were in the MXML (the Flex equivalent of being on the stage) but the Label component would not.
     
  3. Until October, SWF files embedded in the HTML using JavaScript (SWFObject, AC_RunActiveContent, etc) could not be found on Google.
     
  4. Again until October, anything related to the ActionScript 3 method addChild would not get indexed. As an example, adding a MovieClip from the library with static text in it using addChild method would not show up in Google’s search results. In the same way, using states in Flex wouldn’t work. My guess is that since states uses addChild in its MXML syntax, once compiled it would get converted to the addChild method in AS3.
     
  5. Finally, any content loaded externally from the embedded SWF file wouldn’t get indexed, but was clearly stated by Google.
     

Fortunately, Jim Corbett, Flash Player Engineer at Adobe offeres some much-need clarification, answering many of these questions at the Adobe MAX conference this year. The video can be found at Adobe TV, (I’m having problems embedding it with WordPress) – it’s lengthy, and gives a good insight into the Player’s search mechanics.

You can’t start a fire without a spark.