This site is now just an archive over the rise and fall of Flash. The domain flashmagazine.com is available for sale
Login | Register
Solving clickTAG in Flash9+

Solving clickTAG in Flash9+

I had a revelation today, and it makes me furious to the point of wall-climbing. I'm not going to mention names, but you know all that talk about how clickTAG doesn't work in Flash 9+? Complete sham.

First of all, since ad publishers are uniformly incapable of explaining the perceived "intricacies" of their magical clickTAG system outside of "Please copy this simple AS2 code into your application", i'll go through what clickTAG actually is, how i implement it, and a hilarious case of misinformation and unprofessional conduct indicative of certain elements of this industry.

Ready to know the AWESOME POWER of clickTAG? Drumroll. clickTAG is a flashvar containing the url to open. High tech! This URL points to a forwarding and tracking service, but beyond it being a valid URL it isn't your problem anymore. It might as well be http://www.google.com for all you should have to care. The important thing to take with you here is that no matter how badly the publisher wants you to think there is MAGIC involved that you don't understand, the tech is caveman simple, and the problem in 9/10 cases lies with the agency.

So how do we get this flashvar? In AS2, where near-every class was dynamic, flashvars were simply appended as properties to the root object. For instance, given the flashvar "foobar", you could access it with _root.foo, or if working on root level of the timeline, simply refer directly to foobar. For instance, here's a straight copy from a clickTAG guide:

on (release) {
	getURL(clickTAG, "_blank");
}

This is, hilariously, the ONLY available documentation if you Google for official info, and it neglects to explain what would happen if you were to actually paste this code into a nested button or MovieClip. This is where the clickTAG problem begins. It simply isn't specific enough. For instance, in the previous example, the variable name is clickTAG. This is however not really a standard. It might be ClickTag, it might be clickTAG, it might be clickTag, or any combination of cases. For AS3, which is case sensitive, this is a no-go. You might have a perfectly workable clickTag implementation only to have the publisher reject it as non-specifically "wrong", simply because their cases are nonstandard.

Our first problem then, is how do you get the right clickTAG variable, and from where. The stage and root objects of any relevant on-stage DisplayObject (Sprite, MovieClip) hold references to a LoaderInfo object, which in turn has a dynamic "parameters" object which is populated by the embed script. Thus, to get at "clickTAG", you'd typically use something like this.

private function onClick(e:MouseEvent):void{
	navigateToURL(new URLRequest(stage.loaderInfo.parameters.clickTAG));
}

With that out of the way, how can we make our solution case insensitive? The natural solution, i feel, is to for-in through the parameters object, toLowerCase each variable name and get any matching results, as such:

for (var i:String in li.parameters) {
	if (i.toLowerCase() == "clicktag") {
		url = li.parameters[ i ];
	}
}

From there on the rest becomes absolutely trivial.

  1. MouseEvent objects have a target property pointing to whatever the user clicked
  2. Whatever the user clicked is on stage
  3. The stage has a loaderInfo property
  4. And there we have our variables!

The result is a framework for a method we can call from wherever that will always know where the stage is, and will always know where to find the variables, and will always be case insensitive. In our implementation, this results in the following:

public function handleClick(mouseEvent:MouseEvent):void {
	var interactiveObject:InteractiveObject = mouseEvent.target as InteractiveObject;
	var li:LoaderInfo = LoaderInfo(interactiveObject.root.loaderInfo);
	var url:String;
	for (var i:String in li.parameters) {
		if (i.toLowerCase() == "clicktag") {
			url = li.parameters[ i ];
		}
	}
	if (url) {
		if (ExternalInterface.available) {
			ExternalInterface.call('window.open',url);
		}else {
			navigateToURL(new URLRequest(url),"_blank");
		}
	}else {
		if(ExternalInterface.available) ExternalInterface.call('console.log', "ClickTAG: Couldn't find a valid clicktag variable");
	}
}
myButton.addEventListener(MouseEvent.CLICK,handleClick);

Using ExternalInterface

There is some debate, apparently, as to whether navigateToURL with a_blank target is "reliable". It appears navigateToURL from older browsers may be misinterpreted as an automated popup and thus blocked regardless of user interaction. I have personally never encountered this issue, from testing with a multitude of browsers, so i'm taking this issue with a huge pinch of salt. Regardless, the accepted "fix" to this problem is to circumvent navigateToURL altogether and instead call the Javascript window.open through ExternalInterface. I'm not sold on this, but i've implemented it anyway primarily just in case.

A tale of escapades

Today i had a long, winding, pointless argument with a publisher. We supplied a set of AS3 banners using the above method, which were rejected. Out of professional curiosity, i see it as my responsibility to figure out where this process fails, and if there is something i can do about it. Immediately i get the standard company line, copied straight out of the aforementioned clickTAG guide; An AS2 code example. I inform them in return that our implemented code in effect follows this standard to a tee, and that our application is Flash 9 only, and thus incompatible with their code snippet. We do not deliver content in outdated technology, so the problem stands; How do we make this work? We both work for the same client; isn't it in our best interest to keep them happy? The response is a rewrite of the same nonsense, with no further details given; This is obviously a person on the other end with little idea what she's selling or how it works.

As this pointless exercise in "i'm right because i say so" goes on, i start doing more research; What possible method could they be using to validate these swfs? They're obviously not implementing them in a standard way, because the standard way is toilet training simple, and we are supplying several sets of embedded examples that show clickTAG operating as expected, so what could they be doing? We come across INMA's SWF clickTAG validator, which purports to judge whether a SWF has clickTAG properly implemented. Uploading our banners immediatly fails, but with the strange error message that clicktag is written as "ClickTag", not "clickTAG". Puzzling, since we don't actually have any ClickTag strings in our banners at all. Cristobal points out that my ClickTag utility has that very same camelcase name. Hmm!

So we make a new SWF, drop in the following.

var str:String = "clickTAG";

What do you know? This empty trojan SWF validates perfectly. After rapid-fire facepalms, we change the classname to clickTAG and retest our banners; They now validate perfectly.

In the meantime, the discussion with the publisher has rolled on; They have "tested the banners", with our ClickTag class, "in 3 different systems and it doesn't work". We send over new banners with the renamed class. Oh but now they "work perfectly"!

Mind. Blowing.

Publishers are lying to us because they know next to nothing about what they are selling. They force us to use ancient technology (five years now since Flash 8!) under the pretense of some magical system they operate, that they themselves don't know well enough to diagnose, and they don't have the courtesy to be honest about that.

Flash developers; You do not need to use Flash 8/AS2, no matter what they tell you. You don't. Don't let these dinosaurs drag us down. Their time has obviously passed.

 

Get new stories first

Click to follow us on Twitter!

 

Comments


Posted by jauger on 12/01 at 09:16 PM

“They force us to use ancient technology (five years now since Flash 8!) under the pretense of some magical system they operate, that they themselves don’t know well enough to diagnose, and they don’t have the courtesy to be honest about that.”

So true it hurts. Great article.


Posted by toby on 12/02 at 09:52 AM

I don’t think that is true. The reason why Flash 8 is still used widely in the advertising industry is reach, and the fact that many agencies still have designers producing their flash banners. And most of them don’t know ANY AS3.

And if you just had revelations about clickTAG, it makes me wonder how long you have been in this industry.

And it is hardly your choice whether to use AS3 or AS2 if you want to get paid for what you do. Don’t get me wrong: I hate AS2 just as much as the next person, but there are situations that still justify using it.

By the way: I do not work for a publisher, I work for an agency. And it is the agencies’ job to teach their media planners and customers the benefits of using AS3. If you don’t want to use AS2, don’t work in advertising.


Posted by Andreas Ronning on 12/02 at 02:16 PM

Toby, why so defensive? The entire point of this post is not to REVEAL clickTAG, but rather to debunk any absurd mysticism about this caveman rock-against-rock technology.

The defeatist attitude that AS2, a *five year dead standard*, is still around for the purposes of reach and lack of education is deeply saddening; This is company line bs. Unless you’re rolling out Flashlite content, there is literally no good reason.

If you don’t have the time and effort to learn the bare bones AS3 needed to roll out a banner, don’t work in advertising. It’s your JOB. You want to get paid? Learn your craft.

At our office, rolling out a basic clickTAG banner that triggers on stage click involves using a Banner.as base class, period, end of discussion. No further implementation needed. Designers are free to go bananas with animation tools and rudimentary scripting otherwise, and if we can help them by generalizing common issues into scripts that are more easily triggered, that gets put into Banner.as as well. We have had no complaints from our designers, who, by the way, barely knew any AS2 to begin with either.

It’s our duty as developers to overcome this hurdle and help others overcome it. A large segment of this industry is 5 years in the past because people are still rationalizing. To sit our asses down and RATIONALIZE such an ass-backwards situation is not helping anyone.

I strongly suggest you take another look at the most recent player version penetration numbers. A 99.6% figure for FP9 in mature markets does not signify a reach problem.


Posted by toby on 12/02 at 02:34 PM

Andreas, we work that way, too (templates and .as-files that we have been using for years). I am just saying that your original post was a little black & white (as was my response). And I do not trust penetration numbers, unless I have measured penetration myself ;)

I also think that developers have to know their AS3 (and know it well). But strictly seperating development and design does not work in every situation.

No offense, I think we are actually thinking along the same lines, I just wouldn’t put all the blame on the publishers. They have learned something, too, in the past years. Although there may be regional/national differences there…


Posted by Andreas Ronning on 12/02 at 03:05 PM

Wonderful, then all is good ;-) the, shall we say, rant-like nature of the article is probably heavily colored in by personal experiences, which have been repeatedly infuriating and blemished by stonewalling and seniority debates, so yes, probably somewhat due to regional differences. You could say it rings especially true for the Norwegian market.

We are all in this together, no? The goal must be to deliver the best possible up to date content, not be marred by what mounts to religious questions. About penetration stats; at least those are stats ;-) if we can’t base our market evaluations on stats right from the horse’s mouth, then we are a bit lost i reckon.


Posted by Spot on 12/07 at 03:08 PM

Reminds me of the discussion we had lately: http://bit.ly/5amrms - which lead to a solution: http://bit.ly/7JQQ20


Posted by jauger on 12/08 at 06:00 PM

Here’s a thing - since reading this, I’ve been in discussion with one of our ad publishers, who has indeed confirmed that using navigateToURL causes some versions of IE to block, seeing it as a pop-up. But here’s the rub - the automatically generated HTML code they’re using sets allowScriptAccess to “never”, thus blocking any ExternalInterface calls, and in one move scuppering the workaround you’ve suggested above.

Brilliant.

Any ideas people??


Posted by BradJohnson on 12/08 at 07:41 PM

Jauger is correct; there are indeed some pop-up blockers that don’t let you use anything but ‘onRelease’ to open a window from a swf. With standard ad banners, anything that reduces clickthrough rates is a problem.

This will change as clickthrough rates become less relevant, but with standard banners, where you only have 15 seconds and 40k to get your message across, there’s not usually enough actionscript to make much of a difference between AS2 and AS3.


Posted by stormfrog on 11/22 at 05:00 PM

Hi Andreas!

Thank you SOOO much for this. Ive been creating a bunch of flash banners in AS3 for a company and now Monster.com refuse to publish them becuase of said clickTAG missing.

First, I am very new at this so please bear with me. The code I borrowed from you seems to be working on one bannertest I tried but its not working on another I tried (that test seemed more serious also).

Anyways, would you please explain where to put that code? Ive created a transparent symbol button covering the top layer, the first frame in the timeline of that layer contains this code:


http://snipt.net/stormfrog/clicktag-that-doenst-work

I am guessing I am doing something seriously wrong but I dont know what. Ive never used actionscript before in flash.

Submit a comment

Only registered members can comment. Click here to login or here to register