Différents publics et méthodes de mesure peuvent donner des taux de blocage de publicité différents. La division d'un pourcentage publié par un autre ne permet pas d'identifier la précision avec laquelle les gens déclarent leur comportement.
Lire les Docs documentation publicitaire liste 32% de ses utilisateurs comme utilisant un bloqueur d'annonces. C'est une revendication au sujet de cet éditeur. Ce n'est pas une mesure de chaque développeur ou un nouveau taux de 2026 collecté.
Our previous article compared it with a 72.3% figure attributed to the raw Stack Overflow 2018 survey and described the result as a 2.3-times gap between what people said and did. That interpretation required the same population and comparable observations. We did not establish those conditions.
La population est avant le pourcentage
Une plate-forme de documentation observe son propre public et sa mise en oeuvre. La même catégorie d'emploi ne rend pas ces personnes interchangeables, et une enquête au niveau de la personne n'est pas nécessairement comparable à un taux de détection basé sur la visite ou l'impression.
Les appareils, les navigateurs, la géographie, le consentement, les méthodes de détection et les visites qui peuvent être observées peuvent tous changer le résultat. Un éditeur peut également servir de publicité que certaines configurations de blocage permettent. Un seul pourcentage ne saisit pas ces conditions.
Les Rapport sur le dépassement de la pile 2018 is a historical survey. In this pass we did not rerun the raw-response calculation behind the previously cited 72.3%. It should therefore not be used here as verified evidence of current developer-wide blocking or a self-reporting error.
Ce qu'un éditeur devrait mesurer à la place
Définissez le résultat dont vous avez besoin : utilisateurs avec un bloqueur détecté, pagesviews sans demande de publicité, impressions admissibles, impressions remplies ou revenus publicitaires. Ce sont des dénominateurs différents et ne peuvent être substitués silencieusement.
Enregistrez la fenêtre d'observation, l'implémentation, le traitement du consentement et les limites de détection. Une demande de publicité défaillante peut refléter un bloqueur, mais elle peut également refléter une défaillance du réseau ou une autre configuration.
Comparez les observations répétées du même site et de la même méthode avant d'emprunter un taux à un autre public. Gardez l'incertitude visible lorsque le trafic est trop petit ou la mesure manque certaines visites.
Ce que nous avons enlevé
La première allégation selon laquelle le blocage mesuré des développeurs doit s'inscrire dans une bande universelle de 25 à 33 % a été supprimée. Des exemples de plusieurs éditeurs ne définissent pas un taux d'occupation à l'échelle de l'ensemble. Nous avons également supprimé l'affirmation selon laquelle aucun chiffre actuel n'existe nulle part.
Pour la planification des revenus, les gains réels et le trafic correspondant sont plus utiles qu'un taux de blocage présumé d'un autre site. Outil RPM calcule cette relation sans en déduire la raison qu'une annonce a ou n'a pas rendue. explication de l'échantillonnage explique pourquoi la définition de l'auditoire est importante.
Correction, 19 octobre 2026: les conclusions comportementales et universelles ont été retirées. Le 32% reste attribué à son éditeur et limité à son public déclaré; cet article ne présente pas un nouveau taux indépendant.
Demander quelle population le taux décrit
Un sondage peut demander si une personne utilise un bloqueur de publicité sur un appareil. Un éditeur peut observer si une demande de page particulière a produit un signal particulier. Ces questions peuvent être en désaccord sans que personne ne réponde malhonnêtement.
Un répondant pourrait bloquer les annonces sur un ordinateur portable de travail et les autoriser sur un téléphone. Cette personne pourrait répondre honnêtement oui dans un sondage tout en générant à la fois des visites bloquées et débloquées.
Un visiteur fréquent contribue plus à une mesure de la circulation au niveau du site qu'une personne qui visite une fois. Un sondage qui compte chaque répondant une fois ne donne pas à cette personne le même poids. Le développeur d'étiquettes professionnelles ne supprime pas cette différence.
Avant de comparer deux chiffres publiés, notez la population, l'unité, la méthode de recrutement ou de collecte et la date pour chacun. Si ces champs sont manquants, les chiffres peuvent motiver une question, mais ils ne peuvent pas établir un écart de comportement précis.
Dessiner la chaîne de mesure avant d'écrire un détecteur
Une chaîne utile commence par une visite admissible à la publicité. Demandez ensuite si la page et les scripts pertinents chargés, si le consentement a permis l'activité prévue, si une demande de publicité s'est produite et si la réponse a produit une impression selon la définition du fournisseur.
Une étape échouée peut avoir plus d'une cause. Un script peut être bloqué par une extension, une fonctionnalité de navigateur, une règle de réseau ou une défaillance temporaire. Une annonce ne peut pas être demandée parce que la page ne place pas une dans ce contexte. Une requête peut réussir sans produire une impression remplie.
Si le code surveille une charge de script, appelez le résultat une observation de script-load plutôt qu'un recensement complet du comportement de blocage. S'il utilise un élément de test, expliquez ce que cet élément teste et ce qu'il ne peut pas détecter.
Ce niveau de détail peut sembler moins impressionnant qu'une partition de bloqueur tout-usage. Il est plus utile pour débogage, parce que l'éditeur peut étudier la phase spécifique qui a changé au lieu de traiter chaque événement manquant comme un choix délibéré de l'utilisateur.
Les visites inconnues font partie du problème du dénominateur
Un détecteur implémenté dans JavaScript ne peut pas nécessairement observer chaque visite dans laquelle JavaScript ne fonctionne pas. Un rapport du détecteur peut donc décrire les visites qu'il voit plutôt que toutes les visites atteignant le site.
Use chosen figures to make the distinction concrete. Suppose server-side records contain 10,000 eligible page responses after the researcher's documented filtering. The client detector reports on 7,000. Of those reports, 1,400 indicate its tested blocking condition.
The observed rate among reporting cases is 20%. It does not establish a 20% rate among all 10,000 responses. Three thousand cases did not report, and their behavior is unknown. The server count also needs its own checks for automated requests, caching, duplicates and the unit counted.
Il peut être possible de lier ou d'enquêter sur les cas inconnus avec des éléments de preuve supplémentaires. Il n'est pas approprié de les affecter tous à bloquer ou à débloquer simplement pour produire un pourcentage complet. Publier la couverture de déclaration à côté du taux détecté.
L'analyse manquante n'est pas identique à la publicité manquante
Lire la documentation des Docs mentionne explicitement plusieurs raisons pour lesquelles les hits du serveur ne peuvent pas s'enregistrer en tant que pages vues Google Analytics. C'est un rappel précieux qu'une observation analytique a son propre chemin de collecte. Ce n'est pas un compte d'impression publicitaire indépendant.
Un visiteur peut bloquer l'analyse tout en autorisant une publicité, ou permettre l'analyse lorsqu'une demande de publicité échoue. Un choix de consentement peut affecter un système différemment d'un autre.
Chez Mozilla Documentation améliorée sur la protection de suivi Ces protections fournissent une autre raison d'inspecter l'implémentation réelle au lieu de supposer qu'une requête absente identifie une extension ou une intention utilisateur.
Pour un examen d'entreprise, garder la couverture analytique et la couverture publicitaire comme des questions distinctes. D'abord déterminer ce que chaque rapport compte. Ensuite, comparer la portée appariée lorsque possible. Un écart entre deux totaux est un indice à étudier, pas un label expliquant chaque visite manquante.
Un utilisateur bloqueur peut encore voir quelques annonces
La page Read the Docs traite d'options acceptables pour les annonces publicitaires et spécifiques aux éditeurs. Son public de blocage déclaré n'est donc pas nécessairement un public d'où chaque publicité est exclue.
Une réponse au sondage sur l'utilisation du logiciel de blocage n'établit pas que la personne a bloqué les placements réels de cet éditeur. Une extension peut être installée sans appliquer les mêmes règles à chaque site Web ou format publicitaire.
Ne convertissez pas l'état historique de 32 % en une hypothèse de perte de revenus de 32 %. Le contre-ffait pertinent est le revenu qui aurait été gagné en vertu d'une expérience autorisée différente pour ces visites. Cela nécessite plus d'information qu'un taux d'installation ou de détection.
C'est aussi une raison de ne pas décrire les utilisateurs comme exagérant ou en retenant des revenus sur la base de deux sources non appariées. Une question plus utile est de savoir si l'expérience publicitaire de la page est acceptable, compréhensible et compatible avec les paramètres de confidentialité choisis par le visiteur.
Calculer un scénario de recettes avec des hypothèses visibles
Suppose a chosen example has 100,000 pageviews and $1,000 measured advertising revenue. Its observed page RPM is $10. That is the relationship between the recorded totals, not an explanation of why particular visits did or did not produce revenue.
Now imagine the publisher identifies 10,000 additional eligible pageviews that currently produce no ad revenue and can responsibly test a change. If those views earned a chosen $5 RPM after the change, the scenario would add $50. At $10 RPM it would add $100. These are scenario inputs, not predictions or a promise that a blocking-related intervention can recover the visits.
Le calcul ne suppose pas non plus d'effets compensatoires. Si le changement provoque le départ des utilisateurs, ralentit l'outil ou réduit les visites de retour, le résultat net peut différer. La publicité qu'un visiteur permet peut ne pas gagner le même taux que l'inventaire existant.
Utilisez des scénarios pour comprendre la taille du résultat. Ensuite, comparez les données réelles sur les revenus appariés et l'expérience utilisateur après un test soigneusement défini. Ne déclarez pas le scénario plus grand comme revenu récupéré avant qu'il n'existe.
Valider le détecteur avec une petite matrice contrôlée
Testez l'implémentation dans des configurations connues: un navigateur supporté normal, le même navigateur avec une configuration de bloqueur documentée et les états de consentement pertinents. Inclure JavaScript désactivé, une défaillance du réseau simulé et une page qui ne demande intentionnellement pas d'annonces.
Si le code appelle une panne temporaire de requête un bloqueur de publicité, l'étiquette du rapport doit être révisée ou le détecteur doit être amélioré. Si une configuration connue de blocage ne le déclenche pas, documenter cette limite plutôt que de supposer que tous les autres utilisateurs sont débloqués.
Répétez les vérifications sur mobile. Le support du navigateur, les extensions et les fonctionnalités de confidentialité peuvent différer, et un résultat de bureau seulement ne devrait pas être annoncé comme couverture de tous les appareils.
Évitez les tests qui demandent aux gens d'affaiblir les paramètres de sécurité ou de confidentialité comme condition d'utilisation d'un outil de base utile. Un projet de mesure devrait respecter les choix des utilisateurs et recueillir seulement ce dont ils ont besoin.
Comparer les changements dans une méthode stable
Si le taux détecté d'un site change, demandez d'abord si la méthode a changé. Une ressource de test rebaptisée, une configuration de consentement différente ou une version qui retarde les scripts peuvent affecter le signal même si le public sous-jacent se comporte de la même manière.
Conservez une chronologie des rejets de détecteurs et des définitions de rapports. Comparez les fenêtres avec des méthodes compatibles, et annotez les transitions. Ne les rejoignez pas en une seule série lisse sans expliquer une pause de mesure.
Vérifiez également la combinaison de trafic. Plus de visiteurs mobiles, un mélange de pays différent ou une nouvelle source de référence peuvent changer le taux global. Divisez le rapport en groupes utiles seulement lorsqu'il y a suffisamment de preuves pour les interpréter, et préserver les groupes petits ou inconnus sans conclusions surconfiance.
Notre l'explication en deux points s'applique ici: deux taux vous indiquent la différence entre les paramètres, mais pas si le chemin a été progressif, soudain ou causé par un changement de rapport. Gardez des observations intermédiaires quand disponibles.
Publier un résultat qu'un autre éditeur peut comprendre
A useful result includes the measurement window, site or audience scope, tested condition, reporting coverage and known failure modes. Add the totals behind the percentage. A rate based on 20 reports and one based on 20,000 should not look equally settled merely because each is displayed to one decimal place.
Cet article attribue le chiffre historique à Read the Docs; il ne prétend pas avoir réorganisé le système de détection de l'éditeur. La même norme devrait s'appliquer lorsqu'un fournisseur fournit un numéro pour une table de comparaison.
Expliquez ce qui suit. Si la preuve suggère un problème de chargement de script, étudiez ce problème. Si l'expérience publicitaire est intrusive, améliorez-le. Si l'observation est trop incomplète pour distinguer les causes, collectez un échantillon mieux défini avant de faire une prévision de revenus.
Pour un éditeur qui planifie l'entreprise, les revenus observés, le trafic admissible et l'achèvement des tâches sont généralement une base plus solide qu'une hypothèse de blocage empruntée à l'échelle de l'occupation.
Poser de meilleures questions lors de la mise en service d'une enquête
Si une enquête est nécessaire, il faut répondre à sa question à la décision prévue. Interrogez-vous sur une période définie et sur le contexte de l'appareil plutôt que de supposer qu'avoir installé un logiciel signifie bloquer chaque visite en cours.
Publier le libellé de la question et les options de réponse. Indiquer si l'échantillon a été recruté dans une communauté et si les questions sans réponse ont été exclues. Un pourcentage parmi les personnes qui ont répondu à une question facultative n'est pas automatiquement le pourcentage parmi tous les répondants, et encore moins parmi les développeurs.
Ne surchargez pas les répondants avec des distinctions techniques qu'ils ne peuvent pas observer. Une personne peut savoir qu'ils utilisent le paramètre de confidentialité d'un navigateur sans savoir quelles demandes il a empêché sur une page particulière. Un test comportemental et un sondage peuvent se compléter lorsque chacun est décrit honnêtement.
La comparaison la plus utile n'est pas un concours sur lequel le pourcentage semble plus autoritaire. C'est une explication documentée de ce que chaque méthode peut observer et qui reste l'incertitude importe à la décision de l'éditeur. Cela rend la recherche utilisable sans transformer une ancienne statistique du public en une revendication non soutenue sur tout le monde.