Good suggestion. I just went into the reCAPTCHA plugin and edited so it will only appear for those with less than *5* approved comments. You shouldn’t see it now in fact. Let me know if you’re experiencing otherwise.

Regarding your questions:
1) Sorry, I had thought I made is clear in the WHOIS discussion, that I am a programmer of GoStats. Although I’ve stepped away from the development side as of late, I still play a part in overseeing the role. (Yes, I also work at b5. You may have noticed that the post about me is very recent.)
2) The javascript flaw is very real. However, a vast majority of web users enable javascript, so for most purposes this isn’t a big issue. Also, additional data can be included in a -noscript- tag to get some data to the user.
3) The pageload-stop issue is also a possible problem. It would be interesting to see what the real difference is for the average site. I have a guess that it wouldn’t be very big. (assuming that the site in question isn’t of very low quality) You do have a point, depending on implementation or site structure, you could potentially lose some data.

Commenting with the “from gs” would be spammy if my post was a simple mindless statement, like: “nice site”, or “great post A+++”, etc. I think at present, giving commenters a way to attribute their thought-out responses is best served in the “from -company-” method. (not everyone is a mouse-over surfer) It would be great if we had a built in method to do that. I still don’t see spam or seo being a basis or part of the “from -company-” design. Would you look at it the same way if it was “Ted from Microsoft”? I think it would devalue the feedback if I stuffed the name field with keywords or a marketing tag-line, this is just a basic attribution.

The ReCAPTCHA doesn’t bother me. Now that I think about it; it would be more convenient to not captcha the moderated commenters. But I could see how that has abuse potential.

Hmmm, it might be good to get my typo on the fist line of my first comment: “I’ve be following ” -> “I’ve been following “

Having the extra “from GS” part does seem kind of spammy because we can easily see where you’re from with the link and you simply stating somewhere in the body of your first post in a non-spammy way (as you did above) who you are and what company you represent. Just as I was able to reference my programming site as relevant in our conversation without having to put ‘TDavid from …’ in my name.

However, as a significant number of VP, CEO, authors, owners, etc have left comments on this blog over the years it would be worthwhile to have a company/title field in the comments OR the option to create a profile, neither of which are currently in use here

I wonder though if by adding that field if people would put a bunch of junk in there, plus the more input fields the less likely someone is going to want to leave a comment which kind of defeats the purpose. We’ve recently started experimenting with the CAPTCHA below which I feel strains the process too. How do you feel bout this CAPTCHA, Richard? Has it been annoying having to answer those two words to prove you aren’t a bot or is it not that big of a deal? The refresh button will quickly provide an easier to read one if necessary. At least with this particular CAPTCHA there is a benefit to society.

I’m in favor of simplifying the conversation process rather than providing extra profile input fields in the comment form or expecting people to add titles or company names to their name. You know how it goes, Richard, if you have something that looks spammy or unmoderated it is a turn off of sorts to get involved. I’m interested in intelligent, on topic discussions from real people like we’ve been having above, not getting drive by comments from people who only want to pimp their stuff. You aren’t doing that and IMHO by adding the “from …” to your name kind of devalues your feedback and participation here. That’s all I’m saying, if that makes sense (?).

You do bring up an excellent point (thank you) that it would be nice if respected readers from companies such as yourself could link to a profile of themselves here at the site in a manner which would be dignified and professional and not turn people off. I suspect that functionality will be made available for those who (optionally) wish to fill out a profile at this site someday. Seems like a need has been developing

And your model is flawed (wrong order logically and not as I’ve described above either) when you are seeding the user with update intervals and not contacting the API with every page hit — re-read what I wrote carefully and you’ll see me say several times that you don’t do this with every page hit (hit the API). Most APIs have daily limits for number of calls anyway. First, let’s look at what’s wrong with your 7 step model:

7 steps as described by you
[client] —> [web page] —> [web server] —> [ext. api server] —> [web server] —> [web page] —> [client]

would actually look like this (web server contacted before the web page is processed by the web server):

3 steps
A. [client] -> [web server] -> [web page]

The web server (in step 2) could hand off the hit data to another program on the server that decides every X number of hits or at a designated interval to make the remote webserver call using the data collected by A for B:

3 steps
B. [web server] -> [web server] - [ext. api server response: XML, JSON, etc] -> [web server] (saved for operation A to dynamically load)

And you completely ignored these points:

1) my question whether or not you are a programmer at Gostats
2) my point about JavaScript being flawed when the user doesn’t have Javascript enabled which is a huge disadvantage in reliability.
3) the fact that lost stats occur when people stop page loading (and thus the Javascript call never executes)

With a server side architecture you don’t have #2 or #3 problem. As soon as there is a connection, you’ve got the data you need to track. Also if there is a delay or bottleneck in the data flow process speaking to the third party API server, it is kept separate from the surfer. They will not be exposed to the slowdown, all they would see is data not being refreshed as output on the webpage at the designated interval.

The model I described is still running and collecting real time stats, it’s just not providing real time updates to the web page visitor. In the case of a counter being updated, it’s possible to increment a counter from a last known position server side and still show the web visitor a correct count without needing to contact an API. To the visitor they see a counter iterating which could all happen in my 3 step process.

Perhaps the closest visual representation of true real time stats I’ve seen with a stats program that shows much more than a simple counter iterating would be Visitor Ville which will show a Google bus dropping off in 3D visitors to your site in “real time” — but even in that case there is a delay while the animation is moving. That delay, however small, is likely doing exactly what I described above: processing things on the backend where it should be rather than trying to make the web visitor wait.

There is always a delay of some sort processing the data on the backend the way it should be. That delay time can be very short and still work as I described above.

I’m not convinced that the API can be more efficient than javascript.
An api would work like this: (arrows denote data flow)
[client] —> [web page] —> [web server] —> [ext. api server] —> [web server] —> [web page] —> [client]
Javascript method:
[client] —> [web page] —> [javascript] —> [ext. app. server] —> [client]
(not to mention that the client can (and often do) multi-thread the http/javascript requests)

Convenience, speed/efficiency, and specialization of applications are huge reasons for third party javascript. The complexity to setup and API system and it’s corresponding drawbacks vs js don’t really make the benefit you described worth it for the majority of sites.

Regarding the SEO: Ask yourself why you searched for Richard from GoStats? I bet you wouldn’t have done that if I simply signed Richard. Right? Yeah, it makes sense that the results would contain other posts I’ve replied to. Do you think that it isn’t relevant that I sign my name that way? (do you think it’s spammy? why?) If you were given the job to organize the web (like google does), would it make your job easier if I signed Richard or ‘Richard from GoStats’?
-I would not recommend you compare the value of search phrase by the number of results it returns. By that measure you are doing me a favor since “Richard” alone returns 10x the results. …And I’m pretty sure you are the only one searching “Richard from GoStats” today.

Ahh, but I also learned you are (were?) the sales exec at B5. I’d say 24,000+ “calculated” Google results indicates the term is SEO friendly. You are selling advertising for them, eh?

“Overall, let’s think about what cases will benefit from an API?”
I was telling the VP of Quantcast a little while back that stats programs like his and yours would benefit from offering an API model in addition to the JavaScript for webmasters who would prefer to package and send along the data and let you sort it out.

The advertiser transparency angle is the downside but then you could still load an external javascript after the page load and compare against the data served through a single (larger) POST than a bunch of GET with every visit to catch webmasters fudging the numbers.

Again, the main point of javascript has little to nothing to do with efficiency because I can group the data server side and run some backend process to pass off the data whenever and where ever I want — shielding the visitor from the hit by hit by hit cycle. It can still be collected in real time on my server and passed along to an update widget or even a static image that is refreshed every minute or less.

What people call “real time” these days can be a bit misleading as to the frequency of publishing that data, particularly with all the server gymnastics happening. If a stats widget is updated once every 1-5 minutes that is good enough for the vast majority of webmasters/publishers out there.

The data can and should still be collected in real time, but we’ll have to agree to disagree if you think that should be happening in a Javascript call versus server side (with Javascript after page load execution to capture the other details that can only be grabbed through JS). This doesn’t even address the fundamental flaws with an all-JavaScript model. What about users who turn off Javascript in the browser or non-JavaScript browers? They aren’t being counted in an all-Javascript model. There are also the bot scrubbing algos which is whole other kettle of fish.

Let’s be realistic about the number of widgets that really, truly need to be updated with every single page hit. The answer is very few. Take a MLB scores widget. Even if it’s pitch by pitch, there is a delay as the pitcher goes off the mound, uses the rosin bag. This site could have a dozen hits before that next update and this isn’t even our most busiest sites — a dozen hits to say: nothing has changed. A movie times widget doesn’t need to check back to the server only but once a week when new movies are announced but I’ve seen some that check back several times a day. There is a lot of waste happening with widgets executing calls back and forth to servers when they don’t need the frequency they are using. That’s my point here and it’s coming from an architecture standpoint.

The major benefits third party stats services like yours provide is to advertisers and thus a secondary benefit to me so I can show advertisers a third party and presumably more neutral point of view. They can also just take a look at the server logs and get all the data they need without any lost hits to Javascript-less browsers and users.

Bottom line: I can get any piece of information about each visitor any third party site offers better, faster and more reliably directly from the surfer here at our sites. Webmasters don’t need any third party stats service as a middle layer, however they are there for convenience and advertiser transparency and/or in the case where people are using third party hosted sites to begin with and can’t run their own code.

Don’t get me wrong, I’m not saying third party stats services such as yours, Site Meter, Google Analytics don’t have value because they certainly do, but let’s not try to pretend that these services are using the most efficient model to gather stats with a completely JavaScript-only architecture. They’re not.

Overall, let’s think about what cases will benefit from an API? Cases where we can cache the data? Which widgets will benefit from that? Non-real-time, widgets that may not need to be always “fresh”. In widgets which display something this will work fine, but most widgets are widgets because they display something that updates quickly or customizes itself to the user. Overall, the static widgets fit the API model. We might be missing some ease of installation with an api, but for experienced users, the api will work fine for specific in-only data solutions.

Yeah, it is a great thread we have going here. To address the name for my comments, I actually switched to RFG because people told me that they didn’t have enough full disclosure about who I represent. (Yes, I know I even had the url of my site too) The ‘richard from gostats’ is basically the best way I found to properly address the name field question. I wouldn’t say that there is an seo benefit there. Who searches for that phrase anyway? I’m sure you can imagine some seo motivated phrases.

Yeah, it looks like you’ve got me by a few months in the WHOIS data age Don’t worry, GoStats isn’t my first web project.