[Plugin: WordPress.com Stats] Quantserve Code in Stats Javascript

We’re going to use this to provide some cool features around uniques and people counting.

Thanks for the quick reply Matt!

I don’t really want a script that sets a third party tracking cookie in users’ browsers like Quantcast loading on my site although I’m looking forward to the upcoming features around uniques and people counting.

I found this too.

Add most important is that the script from quantserve.com is loading very slowly.

I want this script from quantserve.com off my site.

I’m wondering that if you developer could provide a choice for us to decide whether use it or not???

It should load even faster than the main JS. It can’t be an option, it’s required for the functionality we’re planning.

The main problem I have with the Quantcast code is that I’m working on page speed right now and it makes 1 request each to 3 different hosts, meaning 3 extra DNS lookups and 3 requests in addition to setting cookies.

edge.quantserve.com (JS file)
pixel.quantserve.com (302 Redirect to the next one)
segment-pixel.invitemedia.com OR cms.quantserve.com

My team and I are with Brian on this –

We’ve had the most absolute devil of a time getting a new site build’s templates to settle down and function as designed – We finally tracked it down to conflicts with the quantserve javascript that were causing the entire footer to appear inside the header zone. It was also causing some real bitch headaches with the css names too. Not to mention the cumulative resource overhead it’s been building on our active sites’ servers.

Matt – this is yet another intrusive and unwanted addition to WordPress – (this time via a WordPress maintained plugin) – was this SPYWARE injection discussed on trac BEFORE inclusion? If not, why not? It goes completely against the transparency requirements of the open source declaration. Why is there no mention of this footer script injection on the plugin page? What are you hoping to garner by hiding this addition?

This is starting to happen too frequently with WordPress – issues like the involuntary_P_dangit rewriting that broke URLs, this new SPYWARE in the footer, making a total balls-up of the VHOSTS function in the 2.9.2 to 3.0 merger, and other issues, are destroying your credibility as a paladin of the open source community. As my grandmother used to say, “You need to buck up your ideas young man, before you find yourself with no friends.” And as my mother still says to me now, “You’re never too big for a boot in the seat of your pants.”

This footer script is not an acceptable action Matt – I’ll be pulling this plugin off all our sites and switching to an alternative stats solution – I DO NOT want an unmonitored 3rd party recording all our visitors actions on-site, the keywords they use to get there, and those they use to navigate internally, and I most certainly do not want an online behavioural analysis group like quantcast.com monitoring activity on our sites without the express permission of myself and our site users.

We’d wondered why our LAN’s antivirus layers had started rating our sites with a yellow icon – now we know.

I particularly do not like that you tried to camouflage this behind a wp.me short link so that searching the code did not find quantserve or quantcast in any of the files or templates – you do realise you have just shown hackers and other miscreants how to hide their activity – don’t you?

That’s another reason to ditch all usage of, and permissions to include, url shortening services on all our sites – as a preventative measure to stop others following your example. Have you not been following the news about short url’s as routes to malware injection on twitter and facebook? I am severely disappointed in you introducing this major security threat.

I received a notice email about new comments from gazouteast; where is it?

LOL – although I can still see what I posted, I wouldn’t be surprised if the WP reputation protection squad have hidden it.

The bit I forgot to add, was to ask how many millions of web sites’ data is now passing through the servers of a commercial, online-behaviour analysis and market-targeting company?

… and dare I add?

How much is Akismet / Matt / WordPress getting from that deal?
(I include Matt in that because the plugin is now “claimed” and attributed to Auttomatic rather than the original author.)

I’ve never seen the stats pixel mess up a layout — you should contact [email protected]. There’s no financial aspect to stats.

Or… turn off the stats plugin? ??

It got caught in the spam queue, it happens sometimes, even to regular legitimate users, i’ve unspammed the post for you, please try not to jump to conclusions.

Matt – I don’t think it’s the pixel itself, but the Tolstoy-length mess of javascript in the footer, that’s revealed in its full glory if you use FireBug to show the CSS behind the page layup.

As soon as the stats plugin was removed, the layup went back to how it should behave, and the footer went back to the bottom of the page instead of sitting in the header. Leaves me wondering if the wp_enqueue doesn’t like something in the quantcast javascript and it pulled the footer back up into the header because of it.

Theme is a heavily reworked “Modern Style” from the themes repository – heavily reworked due to a large number of custom post types and taxonomies, and due to “uniquefying” the displayed output for each post type within overall normal archive and category output lists.

We’re really hoping you have some good things for CPT and CTT UI’s coming in 3.1 – trying to find a balanced and non-conflicting set of plugins to do the job, has been a real pain in the neck – we ended upcustom writing a whole bunch of templates, a big chunk of functions.php and Lord knows how many other bits and pieces – for a site that in all honesty should have been designable, buildable, and deployable in under 3 days – it’s taken over a month so far, and likely won’t complete until the end of the week.

@mark – many thanks for that – I can see a couple of words in there that might have triggered the spam trap – must remember not to use them in future.

Gaz

Make an option to host the quantserve script locally. So, it will reduce DNS querry and after certain time the script should be refreshed from quantserve main script.

Would rather the plugin was left with a “lite” version without the QuantServe mess in the footer – it has all I need without the quantcast stuff in it … bit like the option WordPress gave to the plugins that had link cloaking in them – lose the cloaking and you can keep it in the repository as a “lite” version, or keep it and you have to host it on your own site.

…. what’s good for the goose?

It might be pretty useless, but i would like to protest the use of quantcast as well, because;

• it impacts performance (document.write is bad for your dom and there are 2 extra dns-lookups + javascript-file and a pixel to download)
• it impacts privacy: my visitors are tracked, the data that is collected that way is used for commercial purposes by quantcast
• the plugin page on www.ads-software.com does not mention the 3rd party tracking in the plugin at all
• i did not opt in for 3rd party tracking on my blog
• there is no opt-out option
• there is no information on how to disable this for my blog (with some php- or js-variable) either

I really love the simple, straightforward functionality the WordPress Stats plugin provides. Adding “cool features” is great, but do provide a Quantcast-free version for those of us that don’t want all that tracking on our blog(s)!

awfully quiet round here …

let me add some more arguments against the inclusion of quantcast, this time from the perspective of stats reliability:

• users can opt out of tracking via the NAI optout page
• IE9 will include anti-tracking features
• in the US the FTC is reconsidering to create a “do not track”-list

all of this means that even now at least part of a blog’s visitors are not trackable by quantcast (and others) and that with IE9 and the FTC’s actions, the number of do-not-track users will become even more important over time.

the conclusion: quantcast-based wordpress-stats are not only a problem from the point of view of privacy and performance, but also from a data-reliability point of view as a growing number of visits will never be included in these “cool features around uniques and people counting”.

looking forward to a more transparent & open discussion with the automattic-guys!