34,333
edits
Changes
Created page with "If you have decided to adopt a strategy aimed at persuading visitors to disable ad blocking on your site, the next step is to decide the frequency with which the request shoul..."
If you have decided to adopt a strategy aimed at persuading visitors to disable ad blocking on your site, the next step is to decide the frequency with which the request should be presented to each visitor in the event that ad blocking remains enabled.
This chapter will outline some factors to take into consideration when deciding on request frequency before introducing some techniques to implement the functionality.
== Deciding on Request Frequency ==
The objective of asking visitors to turn off ad blocking is, of course, to persuade as many visitors as possible to do so. If a visitor to your site turns off ad blocking as a result of the request then for that person the objective has been met. The question that needs to be considered is what to do about the visitors that continue to use ad blocking.
Suppose that a visitor with ad blocking enabled lands on your website and is presented with the request dialog or notification bar asking that the ad blocker be disabled. This visitor closes the request and continues to access the content on your site without disabling ad blocking. You have the choice of displaying the request every time the visitor loads another page or returns to your website in the future. Alternatively you might decide to show the request again after the visitor has visited another three pages. Another option is to allow the visitor to continue to access pages for another 24 hours before showing the request again.
The best option will depend to a large extent on the typical behavior of your visitors and how valuable they are to you even with ad blocking enabled. If your site has a high percentage of repeat visitors, for example, then you may want to consider showing them the request once each time they arrive on your site but not on every page they visit. This can be achieved by setting a time duration that must elapse before a visitor sees the reminder again. If, on the other hand, most people visiting your site are doing so for the first time and have a tendency to read more than two pages before leaving, it may make sense to display the message once on the first page and then again when the visitor displays the third or fourth page of content. Some combination of these options is also worth considering.
The risk with displaying the request too frequently is that it may antagonize visitors to the extent that they decide to avoid your website in the future, or go looking for solutions to subvert your ad blocker detection code (using a so-called “anti-ad block killer”). If visitors to your site have no value to you if they are blocking ads then showing the request on every page and every visit may be an appropriate strategy. If your website has other objectives beyond generating advertising revenue (such as selling products or services using house ads or building email address lists) then a more subtle approach is warranted so as not to drive away future traffic.
Clearly the best strategy to adopt will depend on your specific website traffic and visitor behavior. Once the decision has been made, however, the steps to implement the chosen request frequency are relatively easy to implement. Before doing so, however, it is important to understand the concept of browser cookies.
== An Introduction to Cookies ==
The word cookie is one of those technological terms where the name does nothing to convey what the feature actually does. It is commonly believed that even the people at Netscape responsible for devising and implementing cookies didn't really have a valid reason for selecting the name. Questionable naming aside, JavaScript cookies are actually an extremely powerful feature.
== What is a JavaScript Cookie? ==
Cookies allow a website to store information on the computers of the visitors browsing the website. Cookies hold string based name/value pairs (i.e. name=value settings), are limited to a maximum of 4kb in size each, and a single server or website domain can only store a total of 20 cookies per user browser.
Another common limitation of cookies is that browsers can be configured to turn off support for cookies. There is the possibility, therefore, that the frequency tracking code outlined in this chapter will fail to function for a certain percentage of your visitors.
Despite the limitations outlined above, cookies provide an excellent way to maintain state on the client’s browser. For example, a cookie can be used to keep count of the number of pages a visitor has loaded, or days that have elapsed since that person was last asked to disable ad blocking.
== The Structure of a Cookie ==
Cookies are created using the cookie property of the Document object. The format of a cookie is as follows:
<pre>
name=value; expires=expirationDateGMT; path=URLpath; domain=siteDomain
</pre>
=== Cookie Name / Value Pair ===
The first section of the cookie defines the name of the cookie and the value assigned to the cookie. Both the name and value settings can be anything you choose to use. For example, you might want to save a user's currency preference - currency=USDollars. This is the only section of the cookie that is mandatory. The following settings can be omitted from the cookies if they are not required.
=== Cookie Expiration Setting ===
The optional expires= section specifies the date on which the cookie should expire. The JavaScript Date object can be used to obtain and manipulate dates for this purpose.
For example, to set a cookie to expire after 6 months have elapsed:
<pre>
var expirationDate = new Date;
expirationDate.setMonth(expirationDate.getMonth()+6)
</pre>
=== Cookie path Setting ===
The path= setting allows a URL to be stored in the cookie. By default, cookies are accessible only to web pages in the same directory as the web page which originally created the cookie. For example, if the cookie was created when the user loaded http://www.techotopia.com/intro/index.html that cookie will be accessible to any other pages in the /intro directory, but not to pages in /navigation. By specifying path=/navigation this limitation is removed.
=== Cookie domain Setting ===
Similar to the path setting, cookies are only accessible to web pages residing on the server domain from which the cookie was originally created. For example, a cookie created by a web page residing on www.techotopia.com is not, by default, accessible to a web page hosted on www.linuxtopia.org. Access to the cookie from web pages on linuxtopia.org can be enabled with a domain=linxutopia.org setting.
== Configuring Expiration-based Requests ==
The first example in this chapter will ensure that a request to turn off ad blocking is made to a visitor only once in each 24 hour period. In other words, once a visitor to your site has seen the request once, regardless of how many times they visit in the next 24 hours they will not see the request again. After 24 hours have passed the request will be displayed the next time the visitor arrives, and the cycle will repeat.
The first step is to implement a JavaScript function to detect and retrieve a cookie from the browser:
<pre>
function getCookie(cname) {
var name = cname + "=";
var ca = document.cookie.split(';');
for(var i=0; i<ca.length; i++) {
var c = ca[i];
while (c.charAt(0)==' ') c = c.substring(1);
if (c.indexOf(name) == 0) return
c.substring(name.length,c.length);
}
return "";
}
</pre>
Next, a function needs to be defined for the purpose of writing the cookie to the browser with an expiration date set to a specified number of hours in the future:
<pre>
function setCookie(cname, cvalue, expirationhours) {
var date = new Date();
date.setTime(date.getTime() + (expirationhours*60*60*1000));
var expires = "expires="+date.toUTCString();
console.log(expires);
document.cookie = cname + "=" + cvalue + "; " + expires;
}
</pre>
Finally, code is needed to check for the presence of the cookie. If it is not present this is either a new visitor or 24 hours have elapsed since this person was last shown the ad blocker removal request. Either way, the cookie needs to be set again. This is achieved by calling the above setCookie() function, passing through the name (“notify”), the value (“true”) and the number of hours to expiration (24). Having written the cookie to the browser’s cookie storage, the ad blocker request is then displayed:
<pre>
if (getCookie("notified") == "") {
// Cookie is not set. Set cookie with 24 hour expiration…
setCookie("notified", "true", 24);
// … and display ad blocker request
$("#myModal").modal("show");
}
</pre>
To see a working example of this technique, visit the following URL. Note that for testing purposes the cookie used in this example is set to expire after one minute:
'''See it in Action'''
[http://www.techotopia.com/survival/expiration.html http://www.techotopia.com/survival/expiration.html]
Load the above page into a browser with an ad blocker enabled and wait for the appearance of the request dialog. Immediately reload the page and note that the dialog does not appear. After one minute has elapsed, reload the page a third time, at which point the dialog will reappear.
== Displaying the Request Based on Page Views ==
The second approach is to keep a count of the number of pages viewed by a visitor, only displaying the request when a specified number of pages have been viewed. While this technique can be combined with a time expiration, for the purposes of this example only the page view count will be used in determining whether a request needs to be displayed.
As is the case with most examples in this book, the following code will need to be executed in the event that the presence of an ad blocker is detected. First, a modified version of the setCookie() method that does not set an expiration needs to be implemented:
<pre>
function setCookie(cname, cvalue) {
document.cookie = cname + "=" + cvalue;
}
</pre>
Next, a new function will be implemented which will be called when an ad blocker is detected and will return a true value if the request needs to be displayed:
<pre>
function checkPageViewCount() {
var countStr = getCookie("viewcount");
var countInt;
var result = false;
var maxcount = 3;
if (countStr == "") {
result = true;
countInt = 1;
} else {
countInt = parseInt(countStr);
if (countInt == maxcount) {
result = true;
countInt = 1;
} else {
countInt++;
}
}
setCookie("viewcount", countInt);
return result;
}
</pre>
The code begins by attempting to get the cookie from the browser. If the cookie does not exist the result variable is set to true and the page view count set to 1.
<pre>
var countStr = getCookie("viewcount");
var countInt;
var result = false;
var maxcount = 3;
if (countStr == "") {
result = true;
countInt = 1;
}
</pre>
If the cookie exists, the page count value is converted to an integer (remember that cookies are only able to store string values) and checked to see if it has reached the maximum page views allowed before the request is to be displayed (in this case 3 pages). If this is the third page opened by the site visitor the result value is set to true (indicating the request needs to be displayed) and the count reset to 1:
<pre>
else {
countInt = parseInt(countStr);
if (countInt == maxcount) {
result = true;
countInt = 1;
}
</pre>
If the page count has not yet reached the maximum allowed page views, the page count is incremented:
<pre>
else {
countInt++;
}
</pre>
Finally, the current page count value is saved to the cookie and the result variable returned:
<pre>
setCookie("viewcount", countInt);
return result;
</pre>
All that remains is to call the checkPageViewCount() function when an ad blocker is detected and display the ad blocker removal request in the event that a true result is returned, for example:
<pre>
if (checkPageViewCount() == true) {
$("#myModal").modal("show");
}
</pre>
To see the above code in action, visit the following web page:
'''See it in Action'''
[http://www.techotopia.com/survival/pagecount.html http://www.techotopia.com/survival/pagecount.html]
== Offer a Less Ad Intensive Experience ==
Since visitors have the choice of ignoring the request and continuing on with ad blocking enabled, it may be worth sweetening the request with an offer to reduce the number of ads displayed in return for disabling ad blocking. This can be achieved using the steps outlined in the chapter entitled Filling Blocked Ads with Ad Reinsertion to write empty content to the some of your ad elements combined with a cookie to identify visitors entitled to fewer ads when they return to your website in future (assuming of course that they have not re-instated ad blocking on your site in the meantime).
== Summary ==
When requesting that site visitors whitelist your website, it is important to decide the frequency with which the request should be made in the event that the user continues to block ads. Frequency can be based on the number of page views, elapsed time or a combination of the two. Ad removal requests may also be combined with ad reinsertion to offer visitors less ads in return for whitelisting your site.
As outlined in this chapter, request frequency can be implemented by making use of JavaScript cookies.
<br><br>
This chapter will outline some factors to take into consideration when deciding on request frequency before introducing some techniques to implement the functionality.
== Deciding on Request Frequency ==
The objective of asking visitors to turn off ad blocking is, of course, to persuade as many visitors as possible to do so. If a visitor to your site turns off ad blocking as a result of the request then for that person the objective has been met. The question that needs to be considered is what to do about the visitors that continue to use ad blocking.
Suppose that a visitor with ad blocking enabled lands on your website and is presented with the request dialog or notification bar asking that the ad blocker be disabled. This visitor closes the request and continues to access the content on your site without disabling ad blocking. You have the choice of displaying the request every time the visitor loads another page or returns to your website in the future. Alternatively you might decide to show the request again after the visitor has visited another three pages. Another option is to allow the visitor to continue to access pages for another 24 hours before showing the request again.
The best option will depend to a large extent on the typical behavior of your visitors and how valuable they are to you even with ad blocking enabled. If your site has a high percentage of repeat visitors, for example, then you may want to consider showing them the request once each time they arrive on your site but not on every page they visit. This can be achieved by setting a time duration that must elapse before a visitor sees the reminder again. If, on the other hand, most people visiting your site are doing so for the first time and have a tendency to read more than two pages before leaving, it may make sense to display the message once on the first page and then again when the visitor displays the third or fourth page of content. Some combination of these options is also worth considering.
The risk with displaying the request too frequently is that it may antagonize visitors to the extent that they decide to avoid your website in the future, or go looking for solutions to subvert your ad blocker detection code (using a so-called “anti-ad block killer”). If visitors to your site have no value to you if they are blocking ads then showing the request on every page and every visit may be an appropriate strategy. If your website has other objectives beyond generating advertising revenue (such as selling products or services using house ads or building email address lists) then a more subtle approach is warranted so as not to drive away future traffic.
Clearly the best strategy to adopt will depend on your specific website traffic and visitor behavior. Once the decision has been made, however, the steps to implement the chosen request frequency are relatively easy to implement. Before doing so, however, it is important to understand the concept of browser cookies.
== An Introduction to Cookies ==
The word cookie is one of those technological terms where the name does nothing to convey what the feature actually does. It is commonly believed that even the people at Netscape responsible for devising and implementing cookies didn't really have a valid reason for selecting the name. Questionable naming aside, JavaScript cookies are actually an extremely powerful feature.
== What is a JavaScript Cookie? ==
Cookies allow a website to store information on the computers of the visitors browsing the website. Cookies hold string based name/value pairs (i.e. name=value settings), are limited to a maximum of 4kb in size each, and a single server or website domain can only store a total of 20 cookies per user browser.
Another common limitation of cookies is that browsers can be configured to turn off support for cookies. There is the possibility, therefore, that the frequency tracking code outlined in this chapter will fail to function for a certain percentage of your visitors.
Despite the limitations outlined above, cookies provide an excellent way to maintain state on the client’s browser. For example, a cookie can be used to keep count of the number of pages a visitor has loaded, or days that have elapsed since that person was last asked to disable ad blocking.
== The Structure of a Cookie ==
Cookies are created using the cookie property of the Document object. The format of a cookie is as follows:
<pre>
name=value; expires=expirationDateGMT; path=URLpath; domain=siteDomain
</pre>
=== Cookie Name / Value Pair ===
The first section of the cookie defines the name of the cookie and the value assigned to the cookie. Both the name and value settings can be anything you choose to use. For example, you might want to save a user's currency preference - currency=USDollars. This is the only section of the cookie that is mandatory. The following settings can be omitted from the cookies if they are not required.
=== Cookie Expiration Setting ===
The optional expires= section specifies the date on which the cookie should expire. The JavaScript Date object can be used to obtain and manipulate dates for this purpose.
For example, to set a cookie to expire after 6 months have elapsed:
<pre>
var expirationDate = new Date;
expirationDate.setMonth(expirationDate.getMonth()+6)
</pre>
=== Cookie path Setting ===
The path= setting allows a URL to be stored in the cookie. By default, cookies are accessible only to web pages in the same directory as the web page which originally created the cookie. For example, if the cookie was created when the user loaded http://www.techotopia.com/intro/index.html that cookie will be accessible to any other pages in the /intro directory, but not to pages in /navigation. By specifying path=/navigation this limitation is removed.
=== Cookie domain Setting ===
Similar to the path setting, cookies are only accessible to web pages residing on the server domain from which the cookie was originally created. For example, a cookie created by a web page residing on www.techotopia.com is not, by default, accessible to a web page hosted on www.linuxtopia.org. Access to the cookie from web pages on linuxtopia.org can be enabled with a domain=linxutopia.org setting.
== Configuring Expiration-based Requests ==
The first example in this chapter will ensure that a request to turn off ad blocking is made to a visitor only once in each 24 hour period. In other words, once a visitor to your site has seen the request once, regardless of how many times they visit in the next 24 hours they will not see the request again. After 24 hours have passed the request will be displayed the next time the visitor arrives, and the cycle will repeat.
The first step is to implement a JavaScript function to detect and retrieve a cookie from the browser:
<pre>
function getCookie(cname) {
var name = cname + "=";
var ca = document.cookie.split(';');
for(var i=0; i<ca.length; i++) {
var c = ca[i];
while (c.charAt(0)==' ') c = c.substring(1);
if (c.indexOf(name) == 0) return
c.substring(name.length,c.length);
}
return "";
}
</pre>
Next, a function needs to be defined for the purpose of writing the cookie to the browser with an expiration date set to a specified number of hours in the future:
<pre>
function setCookie(cname, cvalue, expirationhours) {
var date = new Date();
date.setTime(date.getTime() + (expirationhours*60*60*1000));
var expires = "expires="+date.toUTCString();
console.log(expires);
document.cookie = cname + "=" + cvalue + "; " + expires;
}
</pre>
Finally, code is needed to check for the presence of the cookie. If it is not present this is either a new visitor or 24 hours have elapsed since this person was last shown the ad blocker removal request. Either way, the cookie needs to be set again. This is achieved by calling the above setCookie() function, passing through the name (“notify”), the value (“true”) and the number of hours to expiration (24). Having written the cookie to the browser’s cookie storage, the ad blocker request is then displayed:
<pre>
if (getCookie("notified") == "") {
// Cookie is not set. Set cookie with 24 hour expiration…
setCookie("notified", "true", 24);
// … and display ad blocker request
$("#myModal").modal("show");
}
</pre>
To see a working example of this technique, visit the following URL. Note that for testing purposes the cookie used in this example is set to expire after one minute:
'''See it in Action'''
[http://www.techotopia.com/survival/expiration.html http://www.techotopia.com/survival/expiration.html]
Load the above page into a browser with an ad blocker enabled and wait for the appearance of the request dialog. Immediately reload the page and note that the dialog does not appear. After one minute has elapsed, reload the page a third time, at which point the dialog will reappear.
== Displaying the Request Based on Page Views ==
The second approach is to keep a count of the number of pages viewed by a visitor, only displaying the request when a specified number of pages have been viewed. While this technique can be combined with a time expiration, for the purposes of this example only the page view count will be used in determining whether a request needs to be displayed.
As is the case with most examples in this book, the following code will need to be executed in the event that the presence of an ad blocker is detected. First, a modified version of the setCookie() method that does not set an expiration needs to be implemented:
<pre>
function setCookie(cname, cvalue) {
document.cookie = cname + "=" + cvalue;
}
</pre>
Next, a new function will be implemented which will be called when an ad blocker is detected and will return a true value if the request needs to be displayed:
<pre>
function checkPageViewCount() {
var countStr = getCookie("viewcount");
var countInt;
var result = false;
var maxcount = 3;
if (countStr == "") {
result = true;
countInt = 1;
} else {
countInt = parseInt(countStr);
if (countInt == maxcount) {
result = true;
countInt = 1;
} else {
countInt++;
}
}
setCookie("viewcount", countInt);
return result;
}
</pre>
The code begins by attempting to get the cookie from the browser. If the cookie does not exist the result variable is set to true and the page view count set to 1.
<pre>
var countStr = getCookie("viewcount");
var countInt;
var result = false;
var maxcount = 3;
if (countStr == "") {
result = true;
countInt = 1;
}
</pre>
If the cookie exists, the page count value is converted to an integer (remember that cookies are only able to store string values) and checked to see if it has reached the maximum page views allowed before the request is to be displayed (in this case 3 pages). If this is the third page opened by the site visitor the result value is set to true (indicating the request needs to be displayed) and the count reset to 1:
<pre>
else {
countInt = parseInt(countStr);
if (countInt == maxcount) {
result = true;
countInt = 1;
}
</pre>
If the page count has not yet reached the maximum allowed page views, the page count is incremented:
<pre>
else {
countInt++;
}
</pre>
Finally, the current page count value is saved to the cookie and the result variable returned:
<pre>
setCookie("viewcount", countInt);
return result;
</pre>
All that remains is to call the checkPageViewCount() function when an ad blocker is detected and display the ad blocker removal request in the event that a true result is returned, for example:
<pre>
if (checkPageViewCount() == true) {
$("#myModal").modal("show");
}
</pre>
To see the above code in action, visit the following web page:
'''See it in Action'''
[http://www.techotopia.com/survival/pagecount.html http://www.techotopia.com/survival/pagecount.html]
== Offer a Less Ad Intensive Experience ==
Since visitors have the choice of ignoring the request and continuing on with ad blocking enabled, it may be worth sweetening the request with an offer to reduce the number of ads displayed in return for disabling ad blocking. This can be achieved using the steps outlined in the chapter entitled Filling Blocked Ads with Ad Reinsertion to write empty content to the some of your ad elements combined with a cookie to identify visitors entitled to fewer ads when they return to your website in future (assuming of course that they have not re-instated ad blocking on your site in the meantime).
== Summary ==
When requesting that site visitors whitelist your website, it is important to decide the frequency with which the request should be made in the event that the user continues to block ads. Frequency can be based on the number of page views, elapsed time or a combination of the two. Ad removal requests may also be combined with ad reinsertion to offer visitors less ads in return for whitelisting your site.
As outlined in this chapter, request frequency can be implemented by making use of JavaScript cookies.
<br><br>