What is jsHub?(jgc.org)
jgc.org
What is jsHub?
http://www.jgc.org/blog/2009/10/what-is-jshub.html
3 comments
I'm working on a second post about the microformat side of things. But here goes:
Suppose you accept that idea that instead of having 10 different web analytics tags on your page it would be better to have one tag (let's assume it's jsHub), then you can move up a level.
Rather than have each vendor define the metadata they want from the page, it's better to have a single set of metadata that all the vendors can use. So the point of the microformats is that they'll simplify even more the art of page tagging.
If vendors agreed to mark up the page name, or the products shown on the page, using a microformat then a single tag could read them and then fan the data out to various vendors. That way there's no ambiguity about what's being gathered.
Suppose you accept that idea that instead of having 10 different web analytics tags on your page it would be better to have one tag (let's assume it's jsHub), then you can move up a level.
Rather than have each vendor define the metadata they want from the page, it's better to have a single set of metadata that all the vendors can use. So the point of the microformats is that they'll simplify even more the art of page tagging.
If vendors agreed to mark up the page name, or the products shown on the page, using a microformat then a single tag could read them and then fan the data out to various vendors. That way there's no ambiguity about what's being gathered.
I totally get it now. Most of my sites are already using only one vendor per "need," so I didn't get the use case. Now it's clear.
I have a private web spider that's been following the top 1,000 web sites by traffic (plus the Fortune 1000) and the problem is that for the big ones they've got many, many tags like this per page.
The short explanation (from jgc's post):
"jsHub is a single piece of JavaScript (a "tag") that can handle reading different sorts of page information and then send them to many different vendors' products. One piece of code to send to Google Analytics, Omniture SiteCatalyst, WebTrends and Mixpanel."
"jsHub is a single piece of JavaScript (a "tag") that can handle reading different sorts of page information and then send them to many different vendors' products. One piece of code to send to Google Analytics, Omniture SiteCatalyst, WebTrends and Mixpanel."
I think his point is the same thing I'm having a problem understanding. I went to the demo site and saw 17 scripts loaded on the page using firebug; I assumed from the description there would be only one.
Microformats aside, I'm trying to understand the solution to the hub part because that sounds like a problem many people would be interested in fixing.
Microformats aside, I'm trying to understand the solution to the hub part because that sounds like a problem many people would be interested in fixing.
The problem jsHub is trying to solve is not "only ever load one piece of JavaScript in a page" it's "only have one piece of JavaScript for tracking, ad-serving, behavioural targetting, ...".
The reasons to do that are laid out in my blog post but the most important is consistency. If one piece of JavaScript gathers the data once and passes it to various vendors, then you know that the same data was sent, and was actually sent.
The reasons to do that are laid out in my blog post but the most important is consistency. If one piece of JavaScript gathers the data once and passes it to various vendors, then you know that the same data was sent, and was actually sent.
Disclaimer: I'm a jsHub.org founder
You'll probably find that most of the requests you saw in Firebug are for the Inspector tool (built using YUI2).
The jshub.js file is the only 'tag' needed on a website (+ jquery if not already in use) and is designed to provide a 'hub' API for each vendors plug-in to query the data collected and send it on its way to a receiving server so only one file need be maintained as vendors come and go.
You'll probably find that most of the requests you saw in Firebug are for the Inspector tool (built using YUI2).
The jshub.js file is the only 'tag' needed on a website (+ jquery if not already in use) and is designed to provide a 'hub' API for each vendors plug-in to query the data collected and send it on its way to a receiving server so only one file need be maintained as vendors come and go.
So lets say I maintain some medium-to-large corporate websites (because, well, I do).
I want jsHub because it makes my sites load faster, right? How much faster? Any way to get some test cases or examples?
Differences in hit counts and visits between products are indeed annoying, but it serves as a check. How else would we know if traffic dipped overnight or jsHub went down? Also, I think part of the difference in those counts is due to different algorithms for what constitutes a "visit" and different filtering for bots.
And for the microformats, I hope you realize that's an uphill battle. I can't justify redesigning my pages to use some new format without a material benefit.
I want jsHub because it makes my sites load faster, right? How much faster? Any way to get some test cases or examples?
Differences in hit counts and visits between products are indeed annoying, but it serves as a check. How else would we know if traffic dipped overnight or jsHub went down? Also, I think part of the difference in those counts is due to different algorithms for what constitutes a "visit" and different filtering for bots.
And for the microformats, I hope you realize that's an uphill battle. I can't justify redesigning my pages to use some new format without a material benefit.
There is no 'jsHub' to go down. The entire thing is JavaScript inside the browser. There's no dependency on anything at jshub.org.
Microformats aren't asking for a page redesign. They are just class names. Our argument is that a clear specification is many times better than obscure JavaScript variables inside a Omniture tag, or parameters in a comScore Beacon, ...
Finally, the whole point of jsHub is that won't have to tag your site again. Adding a new product to a jsHub tagged web site means just changing the plugins in your jsHub set up.
Microformats aren't asking for a page redesign. They are just class names. Our argument is that a clear specification is many times better than obscure JavaScript variables inside a Omniture tag, or parameters in a comScore Beacon, ...
Finally, the whole point of jsHub is that won't have to tag your site again. Adding a new product to a jsHub tagged web site means just changing the plugins in your jsHub set up.
Thanks, I could have sworn there was a hosted version, but clearly I'm mistaken.
Good idea, but how about not collecting tracking data at all? If you want to know about my web habits, ask me, or pay me to participate in a controlled study. But just spying on anything that you have access to is just going to get you blacklisted in noscript with prejudice.
Which is probably fine. The other 99,999 people who hit the WWF site are not going to care much about what's being tracked, nor use noscript.
Being able to target ads based on user actions leads to better ads and more money for the site. Without doing this sort of thing, it's very hard to make much money at all on web ads.
You'd really prefer to have to register to read every site?
You'd really prefer to have to register to read every site?
Disclaimer: I'm a jsHub.org founder
One of the key reasons for using a microformat (hPage) is the principle to "design for humans first and machines second".
We provide an Inspector tool on our Demo store to meet this principle and hope that, with the microformat's community's help, we can make the data visible in many other tools.
We would like to make website publishers and users more aware of the data being declared and collected so it can be more accurate and therefore more beneficial to all involved.
Currently many users are unaware data is being collected at all.
One of the key reasons for using a microformat (hPage) is the principle to "design for humans first and machines second".
We provide an Inspector tool on our Demo store to meet this principle and hope that, with the microformat's community's help, we can make the data visible in many other tools.
We would like to make website publishers and users more aware of the data being declared and collected so it can be more accurate and therefore more beneficial to all involved.
Currently many users are unaware data is being collected at all.
This is a noble goal — letting the user and site publisher know what data is collected — however, I don't see what the benefit is to the ad providers or data collectors on the sites, other than that they might possibly be able to simplify their Javascript and reduce the load time in pages with that use their scripts.
Am I missing something? Unless consumers start demanding to know what information is collected about them, I don't think that the benefits jsHub has for ad providers are important, and that they won't implement a plugin until they're pushed by some other forces. In other words: the merit of technical innovation isn't enough for them to change their behavior, and they need a bigger incentive in order to consider using jsHub at all.
Am I missing something? Unless consumers start demanding to know what information is collected about them, I don't think that the benefits jsHub has for ad providers are important, and that they won't implement a plugin until they're pushed by some other forces. In other words: the merit of technical innovation isn't enough for them to change their behavior, and they need a bigger incentive in order to consider using jsHub at all.
Do librarians spy on you when they keep track of the books you've checked out, or the grocery store when they keep track of what you've purchased while using your club card? Basically, it's not spying if the other party is already intimately involved in the process.
It's hardly spying when anyone can view the page source and see what's happening. Or install something like Ghostery.
I then went to your site to check out the demo and found a page with lots and lots of external javascript requests, and something about a microformat.
I'm still confused.