% of users who have ad blockers enabled - capturing in adobe analytics | Adobe Higher Education
Skip to main content
D
DebanjanaBh1
Level 2
June 13, 2025
Respondido

% of users who have ad blockers enabled - capturing in adobe analytics

  • June 13, 2025
  • 2 respostas
  • 686 Visualizações

We would like to know what % of users have enabled ad blockers and capture that % in Adobe Analytics so that we know if they saw a particular script or not. Is there a way to track this is adobe analytics in a custom dimension (evar/prop)?

Melhor resposta por Vinay_Chauhan

As per my knowledge, there’s no native Adobe Analytics feature for detecting ad blockers. But it is possible to implement a custom detection and pass that info into an eVar or prop.

We could use a small inline detection script that tries to load a known “ad-like” file (like ads.js or something with a common ad-related name). If it fails to load, we mark the user as having an ad blocker.

Here’s the general approach:

  1. Place a dummy script or div element with a class name like ad-banner that ad blockers typically block.

  2. Use JavaScript to check if that element loaded or rendered.

  3. Based on that result, set a boolean or flag ('adblock_detected' = 'true'/'false') and pass it into Adobe using s.eVarXX = 'Ad Blocker Detected' or similar.

You can also directly check for a specific script/object being loaded. If your concern is whether a particular tool/script (e.g., chat, A/B testing, personalization) was loaded, check for its presence like:


var toolLoaded = typeof window.ToolName !== 'undefined' ? 'Loaded' : 'Blocked';
s.eVarXX = toolLoaded;

 

This only works for users who haven't blocked Adobe Analytics itself. If the tracking script is blocked entirely, you obviously won’t get any data back for those sessions — so the true number of ad blocker users is likely underreported.

Lastly, if you use tag managers (like Launch), make sure your detection runs early enough in the page lifecycle so you can pass that flag into your tracking calls without race conditions.

Hope that helps!

2 Respostas

Jennifer_Dungan
Community Advisor and Adobe Champion
Jennifer_DunganCommunity Advisor and Adobe Champion
Community Advisor and Adobe Champion
June 14, 2025

Sadly, this isn't quite so "clear cut"...

 

The problem is there are many ad blockers out there, as well as a lot of ad blockers also block analytics... 

 

So, if we are just talking about identifying people with ad blockers (of the people that aren't blocking analytics in general), we have to first figure out how to identify all the different types of ad blockers....

 

  • There are blockers that work based on filter rules (blocking requests that match specific patterns)
  • There are also ad blockers that work by manipulating your hosts files (blocking known domains, rather than targeting URL patterns)

 

Ad Blockers can also work as browser extensions, or stand alone programs... so this makes it additionally tough to properly identify them all.

 

Most ad blockers work on targeting specific patterns, so if this is good enough, then you can try leveraging this method to detect ad blockers:

 

https://www.detectadblock.com/

 

Essentially, you load a file called "targetingAds.js" into your page, then check if it actually loaded.

 

This webpage talks about sending the results to GA4, but you can just change up the implementation a bit and set up a dimension in Adobe instead.

 

This however, relies on the ad file to be served by your own webserver, so you need to have it deployed by your Devs or DevOps... and this won't detect Hosts based blockers (since the file won't be served from a known ad server).

 

 

 

So that said, one thing you mentioned stands out... you said " so that we know if they saw a particular script or not".... I am not sure what this script you are talking about does... but instead of injecting a new file specifically targeted towards ad pattern filters... is there something in this script that you can read to know if it was loaded?

 

For instance, a lot of scripts will create objects that can be read... If this script has something like that, you may be able to just natively read if the object was loaded on the site...

 

For instance, Viafoura Commenting sets an object called window.viafoura... so long as this object isn't subject to lazy loading, you can create a simple check like:

var scriptLoaded = false; if (window.viafoura){ scriptLoaded = true; }

 

However, if there is lazy loading involved, this solution won't work, as the object won't be available until the user scrolls down to where commenting appears.....

 

So, take a look at the Ad Block Detection method, but also consider if you are specifically looking for the presence of a particular script, you might want to investigate a more targeted approach.

Vinay_Chauhan
Community Advisor
Vinay_ChauhanCommunity AdvisorResposta
Community Advisor
June 16, 2025

As per my knowledge, there’s no native Adobe Analytics feature for detecting ad blockers. But it is possible to implement a custom detection and pass that info into an eVar or prop.

We could use a small inline detection script that tries to load a known “ad-like” file (like ads.js or something with a common ad-related name). If it fails to load, we mark the user as having an ad blocker.

Here’s the general approach:

  1. Place a dummy script or div element with a class name like ad-banner that ad blockers typically block.

  2. Use JavaScript to check if that element loaded or rendered.

  3. Based on that result, set a boolean or flag ('adblock_detected' = 'true'/'false') and pass it into Adobe using s.eVarXX = 'Ad Blocker Detected' or similar.

You can also directly check for a specific script/object being loaded. If your concern is whether a particular tool/script (e.g., chat, A/B testing, personalization) was loaded, check for its presence like:


var toolLoaded = typeof window.ToolName !== 'undefined' ? 'Loaded' : 'Blocked';
s.eVarXX = toolLoaded;

 

This only works for users who haven't blocked Adobe Analytics itself. If the tracking script is blocked entirely, you obviously won’t get any data back for those sessions — so the true number of ad blocker users is likely underreported.

Lastly, if you use tag managers (like Launch), make sure your detection runs early enough in the page lifecycle so you can pass that flag into your tracking calls without race conditions.

Hope that helps!

D
DebanjanaBh1Autor
Level 2
June 18, 2025

Hi @vinay_chauhan Our use case is to detect if ad blockers are blocking a specific script (eg. Target) within Launch. Can we use this approach that you suggested to detect if one particular script is blocked or not? We dont want the AA to get blocked. Also, in WebsDK how can we identify the Target script as there is no Target.JS script over there?

Vinay_Chauhan
Community Advisor
Vinay_ChauhanCommunity Advisor
Community Advisor
June 18, 2025

Hi @debanjanabh1 

Yes, this approach can be adapted for your use case, to detect if a specific script like Target is being blocked, without impacting Adobe Analytics itself.

Since you're using Web SDK, you won’t see a standalone 'target.js' file like in older implementations. Target is now delivered as part of the Web SDK payload, so it’s harder to detect just by looking for a script file. However, what you can do is check for specific Target-related objects or behaviors after the SDK has loaded.

For example, after Web SDK loads, if Target personalization is functioning, you can look for objects like:

if (window.alloy && alloy.getDecisioningCapabilities) {
// Likely that Target was loaded properly
} else {
// Possibly blocked or failed
}

Or, if you’re using personalized content decisions, check if expected elements were modified or if 'renderDecisions:true' produced any output. If no modifications happen and the page is in a test, that may suggest Target didn’t execute.

Once you've defined a logic that reliably detects when Target did not run (due to being blocked), you can set a flag like:

var targetStatus = 'loaded';
if (/* detection logic fails */) {
targetStatus = 'blocked';
}

And then pass that value into a custom eVar or prop in your Web SDK event call.

Key thing: make sure this detection runs before the analytics event fires, especially if you're using Launch, to ensure the value is picked up correctly in the payload.

Let me know if this helps!

Termos e condiçõesAccessibility statement

Loading footer...