A common question from SiteCatalyst users and developers deals with detecting the version of Adobe Flash Player that visitors have installed in their browsers. This information can be useful in determining what version of Flash your applications should require. There are a few different ways to capture the user’s Flash Player version, and I think there is some confusion about the best methods for doing this.

What I have always recommended is to use one of the many scripts available for free, and to put the output into a Custom Traffic (s.prop) and/or Custom Conversion (eVar) variable on the pages of your site.

Five minutes ago, I searched for “flash version detection” in Google and came up with a number of viable options; Adobe even offers a Flash Detection Kit, which includes complete instructions and examples for detecting the Flash version using either Flash itself or JavaScript.

The Adobe example includes a function, GetSwfVer(), which returns the Flash version number. This can easily be placed into a SiteCatalyst variable by applying the script to your page code and then setting something like:

s.prop31=GetSwfVer();

or

s.eVar17=GetSwfVer();

Other Flash detection scripts work similarly; once the function has got the Flash version number in a variable or as the result of a function call, putting this data into a SiteCatalyst variable is as easy as setting the SiteCatalyst variable equal to the variable or function name.

Keep in mind that traffic and pathing metrics (primarily Page Views, Visits, Visitors) are available or can be enabled on Custom Traffic reports, whereas conversion metrics (Orders, Revenue, custom events, etc.) will be the stars of the show if you use Custom Conversion reports for Flash detection. Make sure to pass the Flash version into the desired type of variable; certainly, if you have spare variables, you can pass this data into both types.

This question—how to track Flash version number—provides a great example of how common scripts available on the Internet can be used in conjunction with a SiteCatalyst implementation to meet reporting needs. The solution I described above doesn’t require an Omniture plug-in or hours on the phone with ClientCare. You don’t need to be an Omniture certified implementation professional. All you need is a little bit of JavaScript savvy and your favorite search engine. That isn’t to say that you definitely won’t run into questions, concerns, or problems, but the point is that there are some really cool/powerful things you can do independently by combining your own code (or code publicly available for use) and your SiteCatalyst implementation.

As always, feel free to leave comments, e-mail me (omniturecare@omniture.com), or contact me via Twitter (@OmnitureCare) with questions or ideas for future blog posts!

4 comments
Sam Potts
Sam Potts

Ben, We've done a similar implementaion using SWFObject: var version = deconcept.SWFObjectUtil.getPlayerVersion(); which returns an array of version: var flashVersion = version['major'] +"."+ version['minor'] +"."+ version['rev']; Cheers Sam

Sam Potts
Sam Potts

We have done a similar implementation but using SWFObject also... //Get flash version using SWFObject (prop27) try { var version = deconcept.SWFObjectUtil.getPlayerVersion(); var flashVersion = "None"; if (version!="undefined") { if(version['major'] > 0) flashVersion = version['major'] +"."+ version['minor'] +"."+ version['rev']; else flashVersion = "None (or Disabled)"; } s.prop27=flashVersion; } catch (e) { s.prop27="Browser Error"; }

Ben Gaines
Ben Gaines

That's awesome, Jason! This is exactly what I'm talking about—you saw a reporting need, you figured out a way to do it, you made it happen. Sometimes a plug-in is the way to go, but sometimes your particular need can be met (and managed) just as easily (or more easily) using something home-baked. Great work.