Getting AdCall information in Custom template

[Klaas Müller]

Hi,

I would like to get information about the adCall in my custom template which I do not get via dfp macros. These are information like: js, u_audio, format, sz, submodel, u_sd, u_w, u_h, u_so, swipeable, region, u_tz, correlator, iu, hl, msid, net, support_transparent_background, caps, urll

It works pretty well on iOS. However it does not on Android. Here I do not get any information at all I try this by getting the adCall URL via javscript:

location.search

window.location

window.location.href

document.URL

document.location

document.location.href

document.documentURI

window.location.hash

Are there any limitations on the Admob/PlayServices webViews which do not allow me to read the url from the document/window on Android?

Best,

Klaas

[Andrew Brogdon (Mobile Ads SDK Team)]

This just isn't a use case we support.  The parameters of the url are considered internal to DFP, and used to provide the user with the correct ad for that particular moment.  They're not guaranteed to be suitable for anything else (or even there at all, really).  

Out of curiosity, what were you intending to use the information for?

-Andrew

[Klaas Müller]

Hi Andrew, 

thanks for the feedback. There are several use cases I would need the adCall paramater for. For the background, I have around 50 Android/iOS apps and mobile website where I place ads via the dfp adserver in. Nearly all apps have different developers. All ad templates need to be cross digital. Here are some samples I would need the adcall information for:

1. Enabling/Testing of the apps
   I created testbanners for the developers to check if they are shown correctly. Via dfp macro I can write the adUnit ID on the banner but not the adUnit plain name which they use when integrating the adcalls via SDK. It would be much easier to check if the banner that is displayed is on the right site in the app. (Out network has around 2000 mobile adUnits)
2. The parameter net gives you information weather you are on wifi or 3g. In the template I could use this to show a high resolution video/image for wifi and a low resolution video/image for non-wifi. It is much better handling this in a creative instead of lineitem
3. I could get SDK Version information to handle bugs in older SDKs from you
4. There are things like volume information of the device I would need for handling sound on video interstitials
5. I would like to create a mobile debug information layer so broken ads can be reported with adCall information like device type, SDK version, requested adSizes, and so on

There are plenty of things I would like to do. :) 

It is very very hard to create good looking and functional ads when haven hardly any information to use in native apps. Also supporting so many SDK integrations is not easy when these things are so limited. The workaround I used works fine on iOS, but not on Android

The way I use it at the moment is to catch all parameter from the url and use them in the template:

function getParameterByName(name) {

name = name.replace(/[\[]/, "\\[").replace(/[\]]/, "\\]");

var regex = new RegExp("[\\?&]" + name + "=([^&#]*)"),

results = regex.exec(location.search);

return results === null ? "" : decodeURIComponent(results[1].replace(/\+/g, " "));

}

var uri_js = getParameterByName('js');

var uri_u_audio = getParameterByName('u_audio');

var uri_format = getParameterByName('format');

var uri_sz = getParameterByName('sz');

var uri_net = getParameterByName('net');

...

Best,

Klaas

[Andrew Brogdon (Mobile Ads SDK Team)]

You clearly rank among our more ambitious developers.

As I mentioned in the earlier post, we consider all of those url parameters to be internal AdMob stuff, and that mindset affects how they are used and exposed.  We don't really want developers to rely on them because we need to retain the ability to rename them, change their functions, and so on as AdMob grows and evolves.  If someone gets used to peeking at "u_audio," for example, we can't change how that bit of the url works without breaking someone else's code.

That said, it's important for us to know what capabilities our developers desire from the SDK, so it's good to hear these things from you.  I'll add them to the list of suggestions from your other recent posts. :)

-Andrew

[Klaas Müller]

Hi Andrew,

I understand that you can not make all these parameters public for everyone when they change and so on. The main intense of using these would be for debugging ads that do not serve/look correcty. This would be for us as a saleshouse and the publisher who own the app. So at the moment I only want to pass the parameters to get details about the user where it occurred. Using the parameters in template in live ads is however very interesting in the future! :)

Can you do me the favor and check why I do not have access to the adcall url on android webview? The SDK is a blackbox and I can not look for myself. If you need a test template, it is nr 10079854.

Best,

Klaas

[Andrew Brogdon (Mobile Ads SDK Team)]

At the current time, the AdCall url is considered reserved for internal use.  It's not meant to be read by the ads themselves or retrieved from the WebView.

I understand that you're pushing the envelope with your creatives and doing other things that would benefit from additional targeting, and I've spoken with our engineers about ways we can meet these needs (MRAID capabilities, SDK versions, etc.) in the future. At the current time, though, this is the reality of the architecture.

-Andrew