Cookie blocking - with self set cookies - a solution

[webado]

First please read the first post in this thread to understand the background: http://forum.statcounter.com/vb/showthread.php?t=18334



I have concocted a solution to those pesky blocking cookies which keep on vanishing so easily.

This works by your own site setting its own cookie when you decide you want to block your own hits and then your tracking code checking the presence of that cookie. If no such cookie is present (as it would be for all your visitors), then the hit is logged. Otherwise it means you are the owener of the site and the hits won't get logged. Until you decide to delete the cookie.

This is a solution for those who are owners of their own website.

Cannot be used on public sites like blogspot or any others.

Only works with javascript.


Download www.widget.webado.com/sc-cookies/counter-with-blocking-cookie.zip, unzip it to your pc and read the read-me.txt file .

Maybe if I get smarter I can make a code generator wizard but don't hold your breath.


It involves minimal modification of the way Statcounter code is being used, but no actual modification to the underlying script. SO I assume it will be OK.

Please don't complain that you may have too many pages to modify. I cannot help you there. This is the best I can do under the circumstances.

Best would be if Webmaster were to actually implement a similar method I'm using. But that's not my call.

 

[Nicolette]

Cookie Blocking keeps turning off

I have reset my blocking cookie so as not to track my own visits and every time I go back to check, it's been turned back on. Is there a bug in the system?

Thanks,

Nicolette

 

[webado]

I have reset my blocking cookie so as not to track my own visits and every time I go back to check, it's been turned back on. Is there a bug in the system?

Thanks,

Nicolette

This thread is about a different method of setting cookies that you can use if you have a self-hosted site. Blogs on Blogspot are not self-hosted. So this method cannot be used there.

On a site which you own and control you can use it.

Otherwise you have to refer to the normal methods of blocking the recording of your hits: Statcounter blocking cookie or Statcounter IP blocking.

You can search the forum to see many discussions about why this is happening to you and what you can do to solve it.

 

[Scott_inVA]

First please read the first post in this thread to understand the background: http://forum.statcounter.com/vb/showthread.php?t=18334



I have concocted a solution to those pesky blocking cookies which keep on vanishing so easily.

This works by your own site setting its own cookie when you decide you want to block your own hits and then your tracking code checking the presence of that cookie. If no such cookie is present (as it would be for all your visitors), then the hit is logged. Otherwise it means you are the owener of the site and the hits won't get logged. Until you decide to delete the cookie.

This is a solution for those who are owners of their own website.

Cannot be used on public sites like blogspot or any others.

Only works with javascript.


Download www.widget.webado.com/other_stuff/counter-with-blocking-cookie.zip, unzip it to your pc and read the read-me.txt file .

Maybe if I get smarter I can make a code generator wizard but don't hold your breath.


It involves minimal modification of the way Statcounter code is being used, but no actual modification to the underlying script. SO I assume it will be OK.

Please don't complain that you may have too many pages to modify. I canot help you there. This is the best I can do under the circumstances.

Best would be if Webmaster were to actually implement a similar method I'm using. But that's not my call.

question and comment.
I own my domain hosted by bluehost.com. Presume can I use this soultion there?

Also, the link is dead:
Error 404: Sorry, we don't have this page: /other_stuff/counter-with-blocking-cookie.zip on www.widget.webado.com

Suggestions?

Scott

 

[webado]

Oh, sorry. Got the folder name wrong.

It should be www.widget.webado.com/sc-cookies/counter-with-blocking-cookie.zip .

 

[Scott_inVA]

Christina,

Have an issue with the counter-with-blocking-cookie script linked above. Instructions:

2) Also modify the Statcounter code you are currently using to replace the line currently given as:

<script type="text/javscript" src="http://www.statcounter.com/counter.js"></script>
------------------------------------------------------------------------------------
with this new line:

<script type="text/javascript" src="http://www.yoursite.com/block/my-counter.js"></script>

Problem is the script embedded in statcounter is not the same:

Workaround indicates this is the script to replace:
<script type="text/javscript" src="http://www.statcounter.com/counter.js"></script>

Actual Statcounter script:
<script type="text/javascript" language="javascript" src="http://www.statcounter.com/counter/counter.js"></script>

Doesn't work. I've tried to debug but had no success.
Any thoughts?

Scott
Mid-Atlantic WX.com
Lexington, VA

sample page with statcounter code: http://www.midatlanticwx.com/hurricane.htm

 

[webado]

Typo on instructions, sorry.

I meant you replace the Statcounter script, whatever that may be with what I gave.

Nobody's used it yet, so nobody's brought it up. Even I'm not using it.

Ok, I'll get back to it and fix it.

 

[webado]

Ok, fixed the readme.txt file. Download the zip again if you like.

The scripts ought to be correct in fact.

 

[Scott_inVA]

Typo on instructions, sorry.

I meant you replace the Statcounter script, whatever that may be with what I gave.

Nobody's used it yet, so nobody's brought it up. Even I'm not using it.

Ok, I'll get back to it and fix it.

Lemmeno when done and I'm happy to be your test case and share results here.
I did attempt to do some editing and switching in debug to no avail.
I'm driving myself nuts with Statcounter :shock:

Scott

 

[webado]

Done already.

 

[gpaciga]

How is this solution different from using the built in StatCounter blocking cookie? Is it just the until until expiration is much longer, or is there something deeper about it? There doesn't seem to be any obvious reason why this version will avoid being erased by AdAware or the browser clearing its cookies. Correct me if I'm wrong.

 

[webado]

The bigger problem concernng the Statcounter cookies is that one tends to accumulate rather a lot of them (login, forum, each project, from each website you visit that also uses Statcounter). There is a limit of 20 cookies that can exist in a browser from any one website (here we are talking only Statcounter). As soon as the 21st cookie shows up, the oldest one is deleted.
So your own blocking cookies set by Statcounter are likely to vanish just because of that.

Ad Aware will not delete this cookie since it's set by your own site, it's not a third party cookie. Or if it wants to delete it, just place it in the ignore list and it will never be selected again, unliek Statcounter which gets selected every time because it is already on the list of tracking sites.

Because you are not competing with the tons of Statcounter cookies, this one, set by your own site, has a good chance of not getting automatically deleted by the browser when there are more than 20 cookies from the same site or mroe than 300 cookies from all sites.


In any case, you have no other choices. If you have to use blocking cookies, that's the way things go. If you can block your hits by IP that would be a lot better - but you need a static IP.

 

[ed]

Has anyone had luck with Crisooc's method?

I'm tired of clearing session cookies in order to retain the blocking cookies, and interested in trying Crisooc's client-based method. I'm surprised, though, that there haven't been any reports about it here since the last post of 07-27-2006. Has anyone tried rewriting the code and creating folders/files as Crisooc suggests, and has it solved the disappearing blocking-cookie problem? tia, ed

 

[webado]

I used to use it myself until I got a static IP.

If you don't make any mistakes in the code, and if you remember to first set your cookie on each of your sites, it works.

And of course if you don't delete all cookies whenever you clean up.

 

[ed]

I used to use it myself until I got a static IP.

If you don't make any mistakes in the code, and if you remember to first set your cookie on each of your sites, it works.

And of course if you don't delete all cookies whenever you clean up.

Cool, I'll do it. Thanks for your analysis and fix. - ed

 

[paranoid87]

hey guys..i just downloaded the zip file..the readme.txt thanks again chrisooc

 

[kma221]

i 'll be downloading it once i get some time since statcounter is on lots of pages in mysites its gonna take a while to do that but thanks for the nice code

 

[theBast]

By the looks of my cookies file, this is still an issue..

BTW, the official cookie "standard" is only a guideline.. FireFox, and MSIE don't always limit cookies to 20/300, depending on a number of factors which aren't all consistent or documented by the browsers. Right now, I have 50 cookies for .statcounter.com., which includes my blocking cookies, tracking cookies, login cookies, etc.

If the SC webmasters/admins are watching, look into the various cookie handling functions in PHP. There are a number of options which let you "stack" multiple data items onto a single cookie. 4K is actually a lot when you realize each item of data in each cookie is only a few bytes.. 4K = 4000 (or 4096 base2, if you're picky) bytes.. at 20 bytes max per site, one cookie can store tracking data for 200 sites in one cookie. Even more if you use additional techniques, such as binary cookies (converting to base64) or gzip compression to reduce the data size even more.

Of course, the downside to this is the additional overhead of unpacking each cookie, processing it to find the desired information, and repacking it to re-set it with any modifications. Other solutions (with similar overhead problems) could be using one single cookie, which simply identifies the client with a row in a database that contains much more additional information.

There are also various hybrid schemes which attempt the best of each solution, such as using one-cookie-per-subserver/subdivision, but each of those cookies can stack say, up to 100 sites/users. Then if my siteid/userid was say, 413678, you could look for cookie "sites_4136", which contains an array of cookie data, with my specific info being at index 78. Only the most immediate and common data would be stored directly in the cookie, while less commonly needed data could be stored off in a database on the server side, with only an index to the data stored in my cookie. And so on.

HTH, HAND.
TB