Gilles Vandenoostende

Hi, I'm Gilles Vandenoostende - designer, illustrator and digital busybody with a love of language, based in Ghent, Belgium.

“Banners, Google and Anguish” or “No random numbers please, we’re Google.”

We in the online advertising industry make banners. A lot of banners. They’re a necessary evil of online advertising and annoy us all on a regular basis, but they get results, and that’s all that matters in the long run.

We don’t publish these banners ourselves, instead relying on various Media Centrals to deploy and distribute our ads to the various publishers and eventually across your favourite websites on the intertubes.

Contrary to what you might think, most banner ads aren’t just randomly cobbled together pieces of Flash animation, engineered only to aggravate. There are strict rules and regulations that enforce a level of quality and police the potential disruptiveness of banners.

You can’t, for example, open pop-ups willy-nilly, or start playing sound without user interaction. The Media Centrals enforce these rules and guidelines by decompiling every banner and checking the code for malicious scripts and the presence of certain required snippets of code for the banner to work as it’s supposed to (Well, most of them do anyway. There are a couple of shady Media Centrals out there who’ll publish anything really, but we don’t use them).

Most of the time, this all works without a problem. Aside from a few annoyances that stem from the lack of a standardized “clicktag”, the Centrals don’t needlessly scrutinize our banners. Until a few days ago, that is.

One of these Media Centrals, who, for diplomatic reasons, will not be named, apparently uses Google’s adwords guidelines as a reference for checking banners. Nothing wrong with that, Google is, for the most part, a trustworthy and efficient entity. If only it wasn’t for the small fact that their employees don’t understand basic concepts of Flash development.

And so, for the last 4 days we’ve been involved in a longwinded and frustrating bit of back-and-forth regarding some of our banner ads. They claimed infractions where there weren’t any, and we retorted. Most of the infractions the Central claimed our banners were guilty of were absolute drivel and we were well on our way to winning the argument, when they suddenly pulled this hidden beauty out of the Google Advertising Policies:

“Random Numbers: Your ad may not include code that generates or uses random numbers.” (source: adwords.google.com)

For the record, here is the offending piece of code that caused the problem:

TweenLite.to(mc, 1, {height: 0, delay: Math.random()*.5});

All it did was to delay a certain animation with a random amount of time to create a more natural-seeming animation. It’s a piece of code that’s used all the time to create dynamic scripted animations in Flash banners, without incident.

To claim this as a security risk is seriously demonstrating a sound lack of judgment, both on accounts of the Central AND of Google. The rest of the policies in that document are all common sense standards, but that “random” clause seems strangely out of place.

The end result is a much duller animation and a lot of time lost. We’re still sorting this out with all the involved parties, but I hope Google takes notice and removes that silly clause from an otherwise impeccable policy.

9 Comments

Hello,

Had the same issue today. Math.random() * (max – min) + min; was rejected. I re-submitted using date.getMilliseconds()%(max – min) + min;

Fingers crossed, I’ll let you know if that worked!

Cheers,

JJ.

Posted by Jerome at July 22nd, 2009 at 6:33 am.

The policy of no random numbers, I would say, is more for consistency and quality assurance rather than a security issue.
If your code produces a random affect, then Google, or Central in this case, cannot ensure your advert will not break the end-users experience.

Completely understand from both points of view, as an advertiser you want to be able to produce an advert to sell the product/service to the end user, if that is via a unique, or time sensitive experience, then so be it.
Unfortunately, Google/Central has to put their name to the advert via the “Ads by Google”, or a similar tag line, therefore they don’t want to take any chances whereby an Advert might explode and leave a bad impression of Google Adverts in the end-users mind.

Posted by Daniel Love at August 24th, 2009 at 5:45 am.

I’m also experiencing the “random number” rejection message on loading my swf into AdWords, and through trial and error I believe I’ve narrowed it down to the use of the caurina Tweener class in – specifically the initial import command (import caurina.transitions.Tweener) at the top of my script. Even if I don’t actually call a property like addTween anywhere in the script, adWords will reject the ad.

I checked the Tweener.as file and found Math.random used ONCE in a PRIVATE function. Really? Is this what’s breaking my ad? I can’t believe Google would prevent flash dev using the gloriously useful caurina Tweener class. I use it for all kinds of non-ad work, in both AS2/3, and I’m flabbergasted that Google won’t let me use this powerful tool in banner ad work. Any ideas for a workaround that doesn’t involve abandoning caurina? Or worse, reverting to flashmxTween? (Or worse – timeline tweens – come on Google…)

Posted by Leland Hodgkins at March 9th, 2010 at 8:26 pm.

Hey Leland, thanks for commenting.

Yeah, it’s a bullshit measure, but if you like Tweener, you should check out TweenLite/TweenMax. It’s got a very similar API to Tweener, is also AS2/AS3 compatible, is smaller (4KB when compiled) AND outperforms Tweener.

Posted by Gillesv at April 8th, 2010 at 12:28 am.

Managed to find the problem, making a quick search in caurina/transitions/Tweener.as for “Math.random” and I found this line:

var randomDepth:Number = Math.floor(Math.random() * 999999);

Change to:

var randomDepth:Number = Math.floor(1 * 999999);

And it works…

Posted by Daniel Kawa at October 5th, 2010 at 8:05 am.

” The policy of no random numbers, I would say, is more for consistency and quality assurance rather than a security issue. ”

So a dice has more quality if we know the sequence it’s producing?
Weird point of view.

Anyway…
But I’d go for a random number table and pick a number by time.
Here’s one: http://stattrek.com/Tables/Random.aspx

Posted by Joeri at October 19th, 2010 at 1:46 am.

Just use some kind of seed Random device. i.e create an array of previously generated random numbers, and then pick the next one in sequence from the array each time a random number is needed.

http://lab.polygonal.de/?p=162

Posted by William Jane at August 17th, 2012 at 5:18 pm.

I use it whenever I needs to generate a star field. A few times actually. Kind of a bummer. I like the get milliseconds work around though. Good idea.

Posted by Brandon Engelman at July 23rd, 2013 at 11:20 pm.

Yeah it is somewhat problematic. But you can bypass the Math.random() code with the following code:

var date:Date = new Date(); //we use date to get different seeds

//seeds
var m_w:uint = date.getSeconds()+1; //must not be 0, so we add 1, that should work…
var m_z:uint = date.getMilliseconds()+1; //same here..
//Marsaglia’s MWC algorithm
function GetUint():uint
{
m_z = 36969 * (m_z & 65535) + (m_z >> 16);
m_w = 18000 * (m_w & 65535) + (m_w >> 16);
return (m_z << 16) + m_w;
}
function GetUniform():Number
{
var u:uint = GetUint();
return (u + 1) * 2.328306435454494e-10;
}

//100 random numbers between 0 and 1
for(var i=0; i<100; i++){
trace(GetUniform());
}

and thus replace your Math.random() command with GetUniform(). It worked for me and my banners got accepted by adwords. Look for more details on my site http://www.thingsiwish.nl/snowflake-banners/

Posted by Jeroen Thans at December 8th, 2014 at 9:57 pm.

Back to top