[1] https://www.nytimes.com/2009/09/13/business/media/13note.htm...
[2] https://www.washingtonpost.com/news/the-switch/wp/2014/01/04...
[1] https://www.nytimes.com/2009/09/13/business/media/13note.htm...
[2] https://www.washingtonpost.com/news/the-switch/wp/2014/01/04...
That will be a very easy target for faking impressions...
What you are proposing is AMP Ads and is universally hated by advertisers and publishers.
* Buying a low-value ad (like a banner) and cramming a high-value ad (like a video) in there, and lying to the ad server about the visibility, sound, etc, using JavaScript. Sandboxing is typically stymied by a number of cross-domain limitations in real-browsers we can detect server-side.
* Buying installs for a older/hacked browser (or browser extensions) that has been scripted up to load the ads. People would embed these in screen-savers making real users visit these ad pages when the pc owner was unlikely to be around. They won't have the protection real browsers have, and so can trivially modify the network profile.
* Making a headless browser call ads on pages. These pages "look" valid, and you can visit them to see the ads, but the headless browser has collected cookies from various shopping sites, and uses a number of home/DSL proxy services to obscure detection. For any single impression, they look indistinguishable from legitimate traffic.
These are detected in different ways: JavaScript helps some for the first two, but in the second it's mostly that you're looking for bugs in the implementation (and it's just JavaScript gives you a wider search area). Usually these things are "home grown", so if you've got a wide view of the industry, and can change your scripts frequently, you can "detect" them being built in real-time.
However that last one is tricky, and outside of bugs[1], you're left with timing attacks which I won't enumerate because their obscurity is the strongest protection for continued utility, but in general they work on the principle of leaking some identifying data in HTTP and DNS responses, and relying on the fact that that headless browser needs to call lots of ads to pay for the electricity and Internet that it uses, so we get lots of opportunities for a collision.
My original goal was avoiding ad blockers: By having the publisher render the ad themselves, it doesn't look obviously an ad, and as long as the publisher doesn't make the page itself an ad farm, users do not tend to block with custom CSS (that might end up in popular blocking tools). It seems to work okay- we've been operational for over five years at this point, and I've not seen one of the publisher domains or CSS show up in ublock.
But for it to really work you would need to store a cookie to correctly redirect the user.
I like your idea of rendering the ads on the server side, but I would hope they would have super low responsive times. Or at least low timeout on your side.
That ofc means the common practice of advertisers pasting a JavaScript snippet, the network doing a review process, then rendering that snippet as an advertisement on some property would not be allowed on this Ad Network.
What do u think of images rendered on the backend?
Reducing this data collection and turning to simpler methods like images increases fraud, which decreases the amount honest publishers would earn (likely hugely). So it's definitely doable, but tends to not make much economic sense at large scale.