Why Google Analytics for Flash

Since I was involved in the initial development, I’ll attempt to give some context as to why you’d want to utilize Google Analytics for Flash. A lot of people have a need for metrics of their Flash files. Originally, the only way to track things in Flash was to create your own back-end solution. For a lot of people, this was a ton of work and/or beyond their capability. So, they had no clue who was seeing their content, and in what context (did someone host their SWF on another site, embed in a blog, launch from the desktop, etc.). All of these user metrics help drive how some people create content, and without those metrics, they cannot make educated decisions.

Then along came Mochi (not to be confused with MochiKit, the JavaScript library). It allowed you to easily track how your SWF was being viewed without no coding on your end. I don’t remember the GUI used to show those metrics, but bottom line, the metrics weren’t very fine grained, nor put into the context of an application.  At the time, though, no one knew any better, and it was great.  Mochiads has matured a lot today.

Every single software argument over design elements is all based on opinion. Until you do user testing, no one is technically “right” or “wrong”. For web applications, the poor man’s way of doing this is to implement Google Analytics. From this, you can determine how many times a user clicks on a button, how often they go to a certain section, how long they stay there, etc. This helps the designer make more educated designs (mostly) about their content. Users don’t seem to be using the help link. Why is that? Is it because they can’t see it (next to ads and thus banner blindness), because it’s small compared to the rest of the GUI buttons and out of the way, or perhaps the help content isn’t any good? While Google Analytics may not necessarily answer those questions, at least you start asking the right ones based on factual user metric data. While not a replacement for user testing, any testing is good.

Then along came the death of the page view as a metric. Once web applications started to get better metrics to measure them, we needed something similar for Flash. The problem was, Flash was even more advanced and interactive than a lot of the AJAX sites; we needed something more. We needed a simple way to create a hierarchy of user events we cared about, and needed a GUI capable of showing them.  Simple so even the existing agencies could easily integrate metrics, yet verbose enough so the Enterprise Flex apps could construe value from it as well.

Enter Google Analytics. It already had a great GUI for showing tons of metrics in a nice succinct format. Why not extend that for use in Flash applications? Combined with the Google Analytics team innovating, it was a great time to add a feature that allowed a more in-depth ability to create more than just a “page view” but an actual event with real meaning; meaning and context you pre-define, and code into your application whether during development or postmortem.

For example, at the time, I was working for an internet video company, and we were really curious how our users were using our various video players.  If you look on the web today, there are a lot of changes in video players.  Ever since Flash empowered you to create your own controls vs. being locked into what Real/Microsoft/Apple fed you, people have really innovated the video player concept.  While you could customize some of the players with your controls, even in Flash, can control the players via JavaScript, nothing comes close to the integration & responsiveness (*ahem* sometimes…) you get with Flash.  There are key points, chapter controls, ad dots, user comments,

This is also a problem, though.  With all of this innovation, you have absolutely no idea how a user uses your player.  I tried and failed to get budgets for user testing, so figured at the very least, I could track events with meaning.  Such as, “on the small skinned player, does the user ever press fullscreen” or “how often are they time-shifting the video”, and “how often are they using our menu”.  Most importantly, “how often does the video get to actually finish for progressive, or are they leaving mid-play?”  That last one is the kicker because clients would pay for what their users downloaded.  So if you only watch 20 seconds of a video, yet they download 2 minutes worth because of their fast connection, you still pay for the 2 minutes of bandwidth cost.  This is one facet to help in making better purchasing decisions on whether to switch to streaming video or not.

All of these questions and more really drove a lot of the design recommendations we gave clients and designed for.  Without having tested data, it made it challenging to really know if what we designed was right.

Now, design agencies have been using the traditional metric trackers for Flash sites for a long time.  The majority of which either use an fscommand or ExternalInterface call to JavaScript, which in turn sends the magic string on its way.  One key difference here is Google Analytics is free.

The main key difference, however, is the ability to create events.  An event is made up of categories, actions, labels, and an optional value.  So, instead of using the old page view tracker you can now go:

ga.trackEvent ( “BlueVideoPlayer”, “Play”, “Latest News 12.11.2008”);


ga.trackEvent ( “MyWidget”, “Choose Song”, “DJ Fixx – Major Malfunction”, 128);

The blue video player had it’s playlist item clicked to see the latest news video for today.  The widget had the user choose a song, DJ Fixx‘ Major Malfunction at the 128 kb quality.  You’ll then have these organized for you with metrics attached in Google Analytics a day or so later.

With larger sized Flex projects, or even Flash ones, the need is clearly there.  How are people utilizing my embedded widget?  Is it used differently when embedded on different sites?  For consumer facing Flex apps, you can take this to the nth degree, and really track how your users are using your various components, and in what ways.  Since applications are dynamic, instead of tracking if a user ever actually goes to a screen, you can track how they interact with that page when there.

This in addition the data Google Analytics already gives you.

Hopefully you can start thinking of valuable insights you’d like to learn about your Flash content now that you have the ability to track the things you wish to track, WHEN you wish to track then, all with 1 line of code and some fore-thought into the events you’d like to track.

20 Replies to “Why Google Analytics for Flash”

  1. I’ve just had a closer look, and the Google Analytics class for AS3 (well, Google Analytics in general) is pretty cool – and more flexible than I thought. Now I just have to find a suitable AS3 project to start playing with…

  2. I understand your point and for us using GA for our HTML and Flash is a big plus, but GA has always been an ExternalInterface call away. I guess I wanted more of a product like this. I don’t know, metrics specific to Flash or something.

    I still find stand alone ActionScript 3 mode(whitout javascript) useful in some situation and the upcomming version for AIR (it’s in the project road map) very cool. I guess there is more coming.

  3. Zedia, it’s not about ExternalInterface. It’s about recording events vs. recording page views.

    The existing tracker only recorded “someone saw this page” as far as Flash goes. The new stuff allows you to organize your events into Categories, Actions, and Labels with values. That’s 3 levels of hierarchies and a settable value to play with, all of which Google Analytics will parse and graph for you.

    Check out the docs; when you see the call, you’ll get it.

  4. I already knew about events. But Event Tracking and GA for Flash are two different things.

    You can track event in a simple HTML page, it is part of the overall GA API. So tracking events is just an ExternalInterface call away too even without the Google Analytics for Flash.

  5. Yes and no. Yes, from a programming perspective it’s just an ExternalInterface call. However, three things.

    First, having an ActionScript API for it, even if just 1 method call, is helpful. You get strong-typing in ActionScript 3, code-hinting in FlashDevelop / FDT / FlexBuilder, and people don’t have to use the ExternalInterface call.

    Second, this allows Google to extend it in the future. Many of the original Flash / Flex developers involved really really wanted NO caps on the amount of events you could send. Additionally, while the GET request that GA sends is small, it’d be cooler to have AMF, or at the very least, sending bytes instead of strings. Additionally, there wasn’t an easy way at the time to send “time of event”. Also, the requests right now are immediately sent; there’s no batching. Lastly, there is no offline support, such as for AIR applications allowing a local SharedObject cache to build, and sent once your online again… hence again the need for batch calls and time stamps.

    Third, this allows others such as the Flex team to build automation API’s on top of this. Using ExternalInterface as the basis could work, yes, but it’d be a mess. You need a nice API layer on top of the work the Google Analytics, or open source contributors, are doing.

  6. “It allowed you to easily track how your SWF was being viewed without no coding on your end.”
    Double negation: so you have to do some coding?

  7. @Bla Back in the day, MochiAds had a component in Flash that you configured via the Property Panel I think; been awhile. That’s what I meant by no coding; instead of writing ActionScript, you just configured a drag and drop component.

    @TargetStat We’re not just tracking events here; we’re tracking meaningful events. Things you’ve thought ahead of time that you’d like to get a better understanding of how your users are using your app. Tracking every event doesn’t really give you as much meaningful data as tracking events you intentionally put in there.

  8. Jester, sure I agree, you will want to track most important events manually so that they appear in GA reports exactly as you want them.

    However if you also want detailed statistical data about what gets clicked most, etc. in your application then you have to spend too much time making your application analytics friendly (something that you get for free for plain html pages).

    This is TargetStat add-on will help solve by making tracking requests automatically.

  9. I’ve recently implemented the GA for Flash – Flex component in a site I just completed (http://hummingbirdbaby.com.au) and I’ve found it excellent.

    It’s obviously not a huge site, but it only took a couple of hours to implement the event tracking and pageviews that were of importance and now the stats just keep rolling in.

    Now if only I could get the ecommerce tracking working. Any of you had any luck with this?

    Reading the docs all you need to do is:


    Sounds easy! But no sales stats appear. I’ve posted some q’s but got no answers yet.

Comments are closed.