A com­mon ques­tion from Site­Cat­a­lyst users and devel­op­ers deals with detect­ing the ver­sion of Adobe Flash Player that vis­i­tors have installed in their browsers. This infor­ma­tion can be use­ful in deter­min­ing what ver­sion of Flash your appli­ca­tions should require. There are a few dif­fer­ent ways to cap­ture the user’s Flash Player ver­sion, and I think there is some con­fu­sion about the best meth­ods for doing this.

What I have always rec­om­mended is to use one of the many scripts avail­able for free, and to put the out­put into a Cus­tom Traf­fic (s.prop) and/or Cus­tom Con­ver­sion (eVar) vari­able on the pages of your site.

Five min­utes ago, I searched for “flash ver­sion detec­tion” in Google and came up with a num­ber of viable options; Adobe even offers a Flash Detec­tion Kit, which includes com­plete instruc­tions and exam­ples for detect­ing the Flash ver­sion using either Flash itself or JavaScript.

The Adobe exam­ple includes a func­tion, GetSwfVer(), which returns the Flash ver­sion num­ber. This can eas­ily be placed into a Site­Cat­a­lyst vari­able by apply­ing the script to your page code and then set­ting some­thing like:

s.prop31=GetSwfVer();

or

s.eVar17=GetSwfVer();

Other Flash detec­tion scripts work sim­i­larly; once the func­tion has got the Flash ver­sion num­ber in a vari­able or as the result of a func­tion call, putting this data into a Site­Cat­a­lyst vari­able is as easy as set­ting the Site­Cat­a­lyst vari­able equal to the vari­able or func­tion name.

Keep in mind that traf­fic and pathing met­rics (pri­mar­ily Page Views, Vis­its, Vis­i­tors) are avail­able or can be enabled on Cus­tom Traf­fic reports, whereas con­ver­sion met­rics (Orders, Rev­enue, cus­tom events, etc.) will be the stars of the show if you use Cus­tom Con­ver­sion reports for Flash detec­tion. Make sure to pass the Flash ver­sion into the desired type of vari­able; cer­tainly, if you have spare vari­ables, you can pass this data into both types.

This question—how to track Flash ver­sion number—provides a great exam­ple of how com­mon scripts avail­able on the Inter­net can be used in con­junc­tion with a Site­Cat­a­lyst imple­men­ta­tion to meet report­ing needs. The solu­tion I described above doesn’t require an Omni­ture plug-in or hours on the phone with Client­Care. You don’t need to be an Omni­ture cer­ti­fied imple­men­ta­tion pro­fes­sional. All you need is a lit­tle bit of JavaScript savvy and your favorite search engine. That isn’t to say that you def­i­nitely won’t run into ques­tions, con­cerns, or prob­lems, but the point is that there are some really cool/powerful things you can do inde­pen­dently by com­bin­ing your own code (or code pub­licly avail­able for use) and your Site­Cat­a­lyst implementation.

As always, feel free to leave com­ments, e-mail me (omniturecare@​omniture.​com), or con­tact me via Twit­ter (@OmnitureCare) with ques­tions 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.