Quick answer
An ad blocker is browser software that stops ads and trackers from loading. Developers install them more than any other audience, so display advertising does not reach them, and the formats that do are part of the content.
Ad blocker
Definition67% of developers run an ad blocker (MarketingTech News, developer ad-blocking survey), and 64% of those say they block ads because they are intrusive (business.daily.dev/resources — why developers block most ads). The blockers work from shared filter lists that match ad networks, tracker domains and common ad markup, so a banner from a network is gone before the page finishes loading.
Also called: Ad blocking, Banner blindness.
How many developers block ads, and why?
67% of developers run an ad blocker (MarketingTech News, developer ad-blocking survey), far above the general population, and 64% of those say they block ads because they are intrusive (business.daily.dev/resources — why developers block most ads). The reasons they give are consistent: ads slow pages, track them across sites, and interrupt reading. Developers are also the audience most able to install, configure and keep a blocker, and the one most likely to use a browser that blocks trackers by default.
The practical consequence for a display campaign: the audience a network reports is several times the audience that can see the ad, and the developers who cannot see it are the senior ones you wanted most.
How do ad blockers work, and what gets through?
Blockers subscribe to shared filter lists (EasyList and its relatives) that match ad-serving domains, tracker domains and common ad markup: class names, container sizes, script URLs. A banner served by an ad network from its own domain into a standard slot matches on several counts and is removed before the page finishes loading. Anything that pattern-matches to an ad, including an honest promotion with an ad-like class name, can be caught.
What gets through is content served by the site itself: a post in a feed, in the same markup as every other post, from the same domain; a slot in a newsletter, which arrives by email where blockers do not run; sponsored articles; a logo in a bar that is part of the page design. The reader can still ignore it, which is why it has to be worth reading.
Common mistakes
- Buying display for a developer audience and believing the impression count.
- An ad-like class name on your own hero, hidden by a filter list.
- Client-side-only analytics on a site developers visit.
- An anti-adblock wall on a developer product's marketing site.
How developers experience it
- They installed the blocker years ago and forgot banners exist.
- They read a promoted post in a feed because it is in the reading path and labelled.
- They leave a site that asks them to whitelist it.
What should a developer marketer do about ad blockers?
- Stop making things they block. Buy placements that are part of the content, served by the platform.
- Check your own site. An element with a class like "hero-ad" or "promo-banner" can be hidden for most of your visitors by a filter list; test with a blocker on.
- Measure server-side. Client-side pixels and analytics are blocked too; send events from the backend.
- Do not fight it. Anti-adblock walls and "please whitelist us" prompts cost more trust than they recover with this audience.
The audience is telling you how it wants to be reached. The formats that work are the ones that respect that.
What does this mean for reporting?
Ask every platform how it counts an impression, and whether blocked impressions are excluded. On a display network the served count includes ads that were removed before render; on a platform that serves promoted posts in its own feed, a served post is a post that rendered. Compare channels on reads and conversions, not on served impressions, and expect your own client-side analytics to undercount developer visits for the same reason.
On daily.dev
How it works on daily.dev
In-Feed Ads on daily.dev are promoted posts served by the platform in the same card as every post and labelled Promoted. They are read as part of the feed, which is why developers see them when they see nothing else.
Explore my optionsWhat ad blockers remove and what they leave
| Capability | Blocked? | Why |
|---|---|---|
| Display banners from ad networks | Yes | Ad-serving domains and banner markup are on the filter lists |
| Promoted posts served by the platform in its own feed | Rarely | Same domain and markup as every other post |
| Newsletter slots | No | Email is outside the browser |
| Client-side pixels and analytics | Usually | Tracker domains are on the same lists |
| Your own elements named like ads | Sometimes | Class names such as "hero-ad" match generic rules |