Unique Visitors log: php print_r

[unitedscripters]

The finally working Unique Visitor stats has a bug: it prints in the headers the whole php associative array holding the data, I mean this:

Array ( [0] => Array ( [browser_name] => Firefox [browser_version] => 0.10. [os] => Windows XP [res] => 5 [ip_number] => 1374724659 [link] => http://www.unitedscripters.com/phps/manual1.html [returning_count] => 0 [javascript] => 1 [country] => Belgium [region] => Limburg [city] => Hasselt [ipLATITUDE] => 50.933 [ipLONGITUDE] => 5.333 [isp] => Belgacom Skynet Sa/nv [entry_t] => 2004-10-27 23:09:40 [entry_url] => http://www.unitedscripters.com/index.html?file=/phps/manual1.html&ref=http://www.google.com/search?q=php foreach array string&start=0&start=0&ie=utf-8 [entry_url_display] => www.unitedscripters.com/index.html?file=/phps/manual1.html&ref=http://www.google.com/search?q=php foreach array string&start=0&start=0&ie=utf-8 [entry_title] => UNITED SCRIPTERS [link_display] => www.unitedscripters.com/phps/manual1.html [exit_t] => 2004-10-27 23:09:40 [exit_url] => http://www.unitedscripters.com/index.html?file=/phps/manual1.html&ref=http://www.google.com/search?q=php foreach array string&start=0&start=0&ie=utf-8 [exit_url_display] => www.unitedscripters.com/index.html?file=/phps/manual1.html&ref=http://www.google.com/search?q=php foreach array string&start=0&start=0&ie=utf-8 [exit_title] => UNITED SCRIPTERS ) [1] => Array ( [browser_name] => MSIE [browser_version] => 6.0 [os] => Windows NT4.0 [res] => 3 [ip_number] => 3479226950 [link] => [returning_count] => 0 [javascript] => 1 [country] => Canada [region] => Quebec [city] => Montreal [ipLATITUDE] => 45.5 [ipLONGITUDE] => -73.583 [isp] => Videotron Telecom Ltee [entry_t] => 2004-10-27 23:09:24 [entry_url] => http://www.unitedscripters.com/index.html?file=/scripts/dhtml4.html&ref=http://images.google.ca/imgres?imgurl=http://www.unitedscripters.com/scripts/e [entry_url_display] => www.unitedscripters.com/index.html?file=/scripts/dhtml4.html&ref=http://images.google.ca/imgres?imgurl=http://www.unitedscripters.com/scripts/e [entry_title] => UNITED SCRIPTERS [link_display] => [exit_t] =>

etc ect

ciao :-)

well that wasn't supposed to get out so early - thx for the heads up

[unitedscripters]

You're very welcome. I like statcounter immensely, no matter if at times it makes strange things: all web applications are complex.

By the way, do you know that I have two counters pointing to the same file and yet they register a difference of unique visitors that at times reaches 50%?

That is I have a counter (say counter 1) placed (wrongly) in the HEAD tags at www.unitedscripters.com
and another (say counter 2) correctly placed in the BODy tags at unitedscripters.com/door.html

Now, the former in the hEAD tags (counter 1) is a framesetter document.

The latter in the BODY tags is in the main frame that is framed by the framesetter above. So, whoever visits counter 1 in the head tags, immediately loads also the framed document and should hit also counter 2, correct? That's how frames work.

Yet listen to this, counter 1 (i'm referring to UNIQUE visitors) registers regularly at least 35% of visitors more than counter 2.

I am afraid this would be much harder to track down you have all my understanding, but please give a bit of consideration to this: we have really two counters that should register the same amount of visitors that are actually registering a significant gap.

See:

http://my3.statcounter.com/project/standard/stats.php?project_id=331813
Wednesday 27th October 2004 Reloads:538 Unique:460

And:
http://my3.statcounter.com/project/standard/stats.php?project_id=330951
Wednesday 27th October 2004 Reloads:328 Unique:288

Yet whoever vistis the first is _bound_ to visit the second counter too.

Any idea uh?

[webado]

Without seeing your site yet, I'll say the framesetter will also be used when the framed page links to some other page. That other page will display within the same frame in the framesetter. Perhaps this is what's happening, so your framesetter si used more often than your main page.

Another possibility is visitors (be they people or bots) who don't support frames, will hit your framesetter and leave. The framed page will not have loaded at all.

And yet a third possibility is visitors who visit your page (again people or bots) who don't wait around until the entire framed page loads and leave (so the counter on the framed page doesn't get a chance to execute). This will be especially noticeable if your page is somewhat slow in loading.

And a forth possibility is if the counter in the framesetter is counting all pageloads whereas the one in the frame is counting unique visitors, of course there will be differences.

The reason you should not place the counter in the <head> portion is that you can only place the javascript part of it, not the <noscript> part, so non-javascript enabled browsers won't trigger the counter at all.

use frames and be prepared for possible weirdness :)

ok visitor stats have now been finished properly.

[unitedscripters]

visitors stats are great now, the best I ever saw.

As for frames, the first thing a visitor would load in the framesetter document is the counter.
The first thing the visitor will load in the first frame, is again theb other counter. So whoever hits the framesetter hits both counters soon, and wheover doesn't wait for a counter being loaded, is automatically not waiting for the other counter too, so the visit is not registered at all by both counters.
The two counters are the first thing loaded: they're either in the head tags (wrong position) or soon after the body tag (second counter)

Really, we have a discrepancy of above 35% which seems a bit too much: maybe using frames hinders the counters, but frames have been with us for ten years by now, we should no longer consider them a weird option. We see frames everyday when we browse the net.

35% of difference is too much argh!

ciao

[unitedscripters]

Ok I have worked around that issue.
I have done what follows, listen:

1) I keep the counter that works best in the framesetter head tags
2) set it to visible (!)
3) disabled in the framesetter all scripts that write on the page (!)
4) in the first framed document, I retrieve from the framesetter document the counter IMG tag that should have been printed there (but a framesetter cannot be printd) and print it on the FRAMED page (!)

This brilliantly solves the issue. I would even venture to suggest Statcounter to consider proposing this procedure for experienced users: it enhances immensely the usage and enjoyability of statcounter on FRAMESETTER documents.
The counter thus grabs FRAMESETTERS visitors quite smoothly without ANY loss of data, and the counter is printed as well in the forefront because the number is redirected to be printed within a framed document (printing on the framesetter itself would have meant destroying the site for would have overwritten the whole framesetter).

The statcounter code is NOT TOUCHED in the least! It's all a workaround that doesn't touch the counter code itself at all.

I then added with the counter the gif of statcounter (so I have counter and gif both) and linked it all to statcounter, and I added the line
STATCOUNTER IS THE COUNTER UNITEDSCRIPTERS SUGGESTS and linked it to statcounter too.

I nearly squared the circle: we'd be all happy I guess: statcounter code not touched, counting printed as every counter should do, yet counter still in the framesetter document thus grabbing data from frames without problems!

Framesetter is: http://www.unitedscripters.com/
Framed document is: http://www.unitedscripters.com/door.html

=========TECHNICAL SOLUTIONS=========
Technical solution for framesetter was:
<script>
document.write=document.writeln=function(){return false;}
</script>

Technical solutionn for door.html was:
<script>
if(top["sc_tracking_url"]){/*retrieves from the framesetter and prints it in the FRAME!*/

document.writeln("<A HREF=\"http://www.StatCounter.com\" TARGET=\"_blank\"><IMG SRC=\""+top["sc_tracking_url"]+"\" ALT=\"StatCounter - Free Web Tracker and Counter\" BORDER=\"0\"><\/A>");

}
</script>

Doing this allows statcounter to work awesomely good also on framesetter and PRINT on a FRAMED document WITHOUT touching the counter code at all: it performs as if it were INVISIBLE on the framesetter, and performs as normally visible in the framed documnet.
ciao!
Alberto