3 ms·

Hi HN! We've been working on our ad network for a couple years, but we just launched the 1.0 of our open source code, so it seems like a great time to do a Sho

Hi HN! We've been working on our ad network for a couple years, but we just launched the 1.0 of our open source code, so it seems like a great time to do a Show HN! We have more info on our 1.0 post here: https://www.ethicalads.io/blog/2022/08/going-v10-the-backstory-and-future-of-our-ad-network/ https://www.ethicalads.io/blog/2022/08/going-v10-the-backsto... A few years back, we were building Read the Docs, a documentation platform for open source. We had millions of monthly visitors and the obvious way to monetize was ads. However, we cared about the privacy of our visitors and we didn't want ad companies to track our users around the web. We went to a few ad networks and asked if we could proxy the ad traffic or even just run ads without cookies. They weren't willing to do what we wanted, so we built our own ad network. We decided to build a privacy-first ad network. We don't use any cookies, and target ads based on content. The code is all open source (https://github.com/readthedocs/ethical-ad-server https://github.com/readthedocs/ethical-ad-server), and we're slowly working to help fund open source projects. We only show developer-related ads on developer sites. No ads about a product whose site you visited last week and nothing off topic. Next, we built a crawler that indexes the sites on our network to help target our ads. Using an ML classifier (built with SpaCy), it can tell if a page is about data science or about full stack development. This allows advertisers to target the niche they are focused on and ensure the ads perform well, without doing any user tracking. We're pretty excited about the future ability of our ML to improve ad targeting without any information about the user. The coolest thing is that our business gets better as we understand the content we're serving ads on better, instead of "learning" more about our users by harvesting more data about them. We've been a true network beyond just ads on Read the Docs for a couple years and we now have ~130 publishers. We gross just under $60k per month in ad revenue of which 70% goes to publishers. Most of our publishers are small sites or open source projects so to send them ~$40k/mo feels great. Do you have a developer site that you're looking to monetize? Or are you an advertiser trying to reach developers? Or are you just curious about privacy and advertising? Happy to answer any questions! (If you just want to play around with our ad client, you can try it out here: https://jsbin.com/roniviv/edit?html,output https://jsbin.com/roniviv/edit?html,output -- docs here: https://ethical-ad-client.readthedocs.io/en/latest/ https://ethical-ad-client.readthedocs.io/en/latest/)

webmobdev 4y ago
If your ad doesn't run any javascript code, doesn't place any cookie, doesn't do any kind of tracking, and is relevant to the content many wouldn't mind unblocking it in their adblocker. Especially if it is served from the same domain host the content is on. What kind of ads you serve also matter - small text ads (like Google Adsense / Adwords ads used to be a decade or two ago) was actually interesting when it was relevant to the subject content. Tiny tidbits of text are easy to scan and read or skip. I can also somewhat tolerate still-image banner ads as long as it is a few kbs lightweight and doesn't draw too much attention to itself. I absolutely abhor animated gifs, video, pop-up etc. ads of any kind. "Interrupt ads" (those placed in between the content) are also very irritating.
- ericholscher 4y ago
  Thanks -- We actually maintain an exclude list of OSS ads that you can use with your ad blocker of choice: https://ads-for-open-source.readthedocs.io/en/latest/index.html https://ads-for-open-source.readthedocs.io/en/latest/index.h... Of note, we do run our own javascript client on the pages. Our users can opt into hitting our backend API instead of running JS code, but many just use our client directly. We currently serve the ads on our own domain. We could implement the ability for our publishers to proxy the ad views to our domain (this is generally called "ad cloaking"), but it hasn't felt like the right thing to do. We are also on the Acceptable Ads non-tracking list, so our domains are unblocked for people who choose that in their ad blocker. If we use a publishers domain, they will be unblocked for some period of time, but then their domain gets added to the ad blockers, and we lose this Acceptable Ads traffic.
  - webmobdev 4y ago
    I feel ad proxying and server side rendering would be a better fit for the brand identity you are trying to create. Why does one need javascript to serve some text or image, along side some content? One of the common reasons for blocking ads is they slowdown websites by using more resources and thus also reduce battery life. It also introduces another barrier to trust you more - how do I know that the Javascript code is not doing something unwanted (like browser fingerprinting, introducing some annoying animation etc.) - after all, it would be a pain to keep reviewing your javascript code and would be easier to just block it.

webmobdev 4y ago

If your ad doesn't run any javascript code, doesn't place any cookie, doesn't do any kind of tracking, and is relevant to the content many wouldn't mind unblocking it in their adblocker. Especially if it is served from the same domain host the content is on. What kind of ads you serve also matter - small text ads (like Google Adsense / Adwords ads used to be a decade or two ago) was actually interesting when it was relevant to the subject content. Tiny tidbits of text are easy to scan and read or skip. I can also somewhat tolerate still-image banner ads as long as it is a few kbs lightweight and doesn't draw too much attention to itself. I absolutely abhor animated gifs, video, pop-up etc. ads of any kind. "Interrupt ads" (those placed in between the content) are also very irritating.

ericholscher 4y ago
Thanks -- We actually maintain an exclude list of OSS ads that you can use with your ad blocker of choice: https://ads-for-open-source.readthedocs.io/en/latest/index.html https://ads-for-open-source.readthedocs.io/en/latest/index.h... Of note, we do run our own javascript client on the pages. Our users can opt into hitting our backend API instead of running JS code, but many just use our client directly. We currently serve the ads on our own domain. We could implement the ability for our publishers to proxy the ad views to our domain (this is generally called "ad cloaking"), but it hasn't felt like the right thing to do. We are also on the Acceptable Ads non-tracking list, so our domains are unblocked for people who choose that in their ad blocker. If we use a publishers domain, they will be unblocked for some period of time, but then their domain gets added to the ad blockers, and we lose this Acceptable Ads traffic.
- webmobdev 4y ago
  I feel ad proxying and server side rendering would be a better fit for the brand identity you are trying to create. Why does one need javascript to serve some text or image, along side some content? One of the common reasons for blocking ads is they slowdown websites by using more resources and thus also reduce battery life. It also introduces another barrier to trust you more - how do I know that the Javascript code is not doing something unwanted (like browser fingerprinting, introducing some annoying animation etc.) - after all, it would be a pain to keep reviewing your javascript code and would be easier to just block it.