Re: SOX Requirements RE: ACTION-216 - Financial Reporting "Exceptions"

Tamir,

So to be clear people don't publish there "secret sauce" on how they
identify and remove click fraud, or to be more politically correct "low
quality" clicks.  So your question is - do UIDs fix his problem.
Obviously not knowing the secret sauce I can't specifically answer HOW
they help, but I can say they are part of the solution.  With clicks
selling for real values in whole dollars and even upwards of tens of
dollars, you need to make sure that, for instance, the same user can't
create a charge for more than one click.  This presupposes that you can
identify "same user".  You may also need to know who someone isn't, as you
wouldn't want someone who financially benefits from the click to do the
clicking.  The more data you have, the better job of determining the
quality of the click.  Now I use click here as an example, but the same
really holds true for ad views as well; it is just a question of scale.
So yes cookies are deleted and some folks have no cookies, but all this
can be used to create heuristics that build confidence.  If you don't log
IP and you don't log cookies this confidence is pretty hard to come by.

-Brooks 



-- 

Brooks Dobbs, CIPP | Chief Privacy Officer | KBM Group | Part of the
Wunderman Network
(Tel) 678 580 2683 | (Mob) 678 492 1662 | kbmg.com
brooks.dobbs@kbmg.com



This email – including attachments – may contain confidential information.
If you are not the intended recipient,
 do not copy, distribute or act on it. Instead, notify the sender
immediately and delete the message.



On 8/21/12 2:45 PM, "Tamir Israel" <tisrael@cippic.ca> wrote:

>Hi Brooks,
>
>Sorry for getting back to this so late.
>
>I'm wondering, if it's overt attempts at defrauding that are the case
>study, does UID really take care of this problem? How hard would it be
>to go the extra step and add in random UIDs into [time], [ad], [event]
>based on prior/future logs if the scenario you're referring to comes up?
>
>Conversely, on the fraud detection flip side (where the server is trying
>to prevent gaming of its systems) how does this work with users who
>regularly delete UID cookies?
>
>Thanks again,
>Tamir
>
>On 7/30/2012 10:48 AM, Dobbs, Brooks wrote:
>> Maybe it is helpful to back up and look at what contractually is being
>> sold (CPM as an example).  It is NOT impressions; it is a subset of
>> impressions and it is confidence in this subset.  It is impressions
>>which
>> have been filtered for quality, where a large part of the filtration
>> occurs on IP address (and other data as well).
>>
>> Allow me to digress into a story. HypotheticallyŠ in 1995 I knew someone
>> who wrote a really bad PERL based adserver for the online newspaper
>>where
>> he worked.  One Friday before he left for the weekend, he failed to make
>> sure there was enough disk space for logging to make it through till
>> Monday morning.  Predictably, sometime late Sunday evening we ran out of
>> disk space.  Knowing the ads at that time where just in simple rotation,
>> he "fixed" the problem by copying Saturday evening's logs, adding 86,400
>> seconds to each event, and appended this to what I actually had for
>> Sunday.  Okay before you act horrified at the crime perpetrated here,
>>know
>> that we made about $10-15 in ad revenue from 15 clients for the entire
>> weekend so billing may have been off by pennies.
>>
>> The point here is that sites don¹t use homegrown PERL logs anymore and
>>we
>> aren't talking $10, but the core data is the same.  Now we use reputable
>> 3rd parties who participate in audits that look at things like IP
>> addresses, cookies and UA combos to make sure no one cooked the books or
>> has even broken terms of contracts like going beyond frequency caps or
>> delivering campaigns to wrongly targeted GEO codes.  Writing down things
>> like IP address, cookie, referring URL etc may not prevent sophisticated
>> log editing but they do raise the likelihood of getting caught by
>>auditors
>> (or clients with their own logs).  If all that is written down is:
>>
>> [time], [ad], [event]
>> 12:01:33, Ad ABC, Impression
>> 12:03:44, Ad ABC, Impression
>> 12:07:55, Ad ABC, Impression
>> Š
>>
>> There is not much to audit, not much to convince anyone that no one
>> "printed" events and not much to prove that all events were "quality" in
>> terms of what was contracted for.
>>
>>
>> -Brooks
>>

Received on Tuesday, 21 August 2012 21:02:22 UTC