Hacker News Reader

Comment by jasode | Hacker News Reader

>The next generation of tracking tech relies on the backend transfer of data between a website and the ad platform, which is invisible to your own network.

But doesn't relying on the publisher's website log statistics instead of the end users' browsers introduce trust and "bad actors" problem? This has been a known "principal-agent" problem[1] for all the decades that 3rd-party ads have existed on the web.

I.e. Google getting onclick statistics from web browsers' Javascript and reporting to Google-owned "doubleclick.com" is different from the server logs of "JoeClickbaitContentFarm.com". Doesn't the contentcreator's website have an incentive to falsify the numbers to get higher payments from the ad network?

It doesn't seem like website self-reported server stats can fully replace end users browsers tracking. Instead, it augments it.

[1] https://en.wikipedia.org/wiki/Principal%E2%80%93agent_proble...

View on HN

I think OP comment is probably referencing more purchase & consumer data, rather than sell side impression data. E.g. we send non-profit donation data into FB to help optimize our fundraising advertising. And ads are transacted based on conversions a lot of the time, instead of raw impression or click data which I think can optimize for fraud like you say.

Though I haven't thought much about what you bring up or that principal, thanks for sharing.

Ultimately google can render ads through a middleman iframe they control, so even going back to a basic impression count without a bunch of JS controls and measurement they still have lots of tools especially since they have large amount of log in data on their domains only they can verify.

I remember when I was just learning the internet doing something like this. copy pasting html (before it was all rendered with JS) to edit things to make them my own. I used an adsense account to render mesothelioma keywords and hit refresh a bunch; got paid a small amount, my parents were impressed a 13 year old got checks from google ;) There's a ton more learning resources now, but the days of copy pasting basic website html is gone.

The data is sent from the advertiser to the ad platform, not from the publisher to the ad platform. The advertiser is incentivized to send accurate data for both performance optimization and for campaign measurement purposes.

Ad fraud is a real problem in the ecosystem, but the server-side APIs are actually more secure. You have a private signed backend endpoint rather than public JS that can be injected anywhere and fed fake data by a malicious party.

>The data is sent from the advertiser to the ad platform, not from the publisher to the ad platform.

Then we're talking about different things. This thread has packet filtering to prevent user behavior being sent to Google. For example, see recent thread about Google's click tracking: https://news.ycombinator.com/item?id=28672625

The key is that click choice data on Google's search results page is never seen by advertisers so your explanation of "next gen tracking is by advertisers calling APIs to ad networks" -- isn't relevant to that scenario.

Then another level of tracking underneath Google's visibility of click behavior on its own search page is the website (publisher/contentcreator) recipient of the click. Whether any advertisers see this downstream click statistic on an ad network depends on the particular website. E.g. a content creator website might have tracking that sends data to Google domain "googleanalytics.com" -- but no advertisers.

Couldn't this be at least partially solved by the advertising agency still embedding tracking code into the web page, and the tracking payloads are included in the web owner's reports back to the advertising agency?

The data could be safeguarded by a cryptographic signature, though there's some trust paths that would need to be solved.

Reply on news.ycombinator.com