Change the click method

[OleSan]

Click is the only thing we haven't really had a discussion on. The current one isn't a very standard way to do this, so I had a look at what IAB recommends in their HTML document.

http://www.iab.net/media/file/HTML5DAv101.pdf page 11.

It seems like a much better way to do this by using anchor tags to be honest. And by doing it the way IAB recommends it will probably be easier to get support for this from the big third party ad systems like AdForm and Doubleclick as well.

They recommend something like this:

HTML:

<a id="clickArea" target="_blank"></a>

Javascript:

var clickArea = document.getElementById("clickArea");
clickArea.href = clickTag;

By using the keywords clickTag it should also make it possible to set the clickTag within the system that publishes the ad, and not hardcode it inside the creative. It just looks more solid than what we use now. What do you guys think? I know for FINN we need to update apps etc to add support for this, but in the long run it should be better.

[leftieFriele]

I seem to remember there being issues with native applications not being able to act on regular links and that is why the current specification is the way it is. It's important to remember that web based ads aren't only viewed in web browsers, but web views inside native apps and many other scenarios.

[OleSan]

In discussions with IOS development at FINN, it seems like it is easier to implement for anchor tag than listening for JS events like today.

[leftieFriele]

If they say it's easier it is then I have no objections and like you say what we have is a bit weird.

[sveisvei]

Well, there was reasoning behind it at the time - I was not involved, but think it was limitations at the time. I think the main issue was how the Webview class was initiated, with e.g. local content. My proposed solution is to have a "safe" domain, and all other navigation outside this domain is classified as navigation/clickTag. There has to be some safeguards to not trap navigation in child-frames etc.

We have to set new targets/plattforms and do another round of research.

[OleSan]

Our iOS-app has support for anchor tag since december 2014. AdTech had added support for it as well. We've done some tests with other medias in INMA, and I'll get through all that data next week. I'll update this issue with that data, there might be issues in other delivery systems.

[OleSan]

iOS-team seems to have a solution for the click problem that required 'new_window'. Any suggestings for how we can move on from this? The way IAB has it in their draft isn't too bad.

HTML:

<a id="clickArea" target="_blank"></a>

Javascript:

var clickArea = document.getElementById("clickArea");
clickArea.href = clickTag;

[OleSan]

No ad delivery system has the same method for handling click in HTML, so we should probably rewrite this whole section until there is one way all systems agree on.

For click handling, check with the host site or media agency what system the HTML creative will run on. Each system has a different way to handle click in HTML creatives.

If we do this something like this, each site has to have specs on how click is handled in their systems. Or we could link to different vendors and their documentation. I fear that documentation is confusing though.

My comment before this with doing the same as IAB won't work so well, as that won't work in any ad delivery system at the moment. I haven't seen anyone supporting clickTag yet in HTML. Hopefully it will be like that in the long run.

[gadgetgnome]

As a representative of production agencies I second this, with refering to host site and media agency. Different media agencies have different deals with the ad delivery systems that affects KB-limits and also rules for CDN loading. So producing for AdForm for media agency A is different than for media agency B (unfortunately).