WASP Blog » Analytics

WASP 2.1 Released

Dave Renouf — Wed, 14 Jul 2010 15:08:56 +0000

We are very excited to announce the recent release of WASP 2.1.

Whats’s new?

Detail view of your tags
- Never miss an in-between call again, as we keep track of the last 5 pages you browsed
- Filter solution list by type, so you only see what you need
Capture title, description and meta data of the sites you’ve scanned to allow enhanced SEO and a powerful tag cloud for easy analysis and drill down on the specific pages that use those tags
Localization in French
Execution time and latency information for all the tags
Seomoz.com related SEO data in the WASP popup
Additional tags detected
Minor improvements, including bug fixes as always
Market research functionality to analyze your competitors’ sites (Did we mention new tag cloud! )
Automate market research scans

Thanks for all the great feedback from the community,
and the help from my beta testers (yes you guys )

We sincerely hope you enjoy the new release!

BTW, you can try it free here: http://webanalyticssolutionprofiler.com/try.htm

Looking for beta tester WASP 2.1

Dave Renouf — Wed, 09 Jun 2010 20:38:34 +0000

We are almost ready to launch WASP 2.1, but we need to do another round of beta testing.

We are looking for users to jump in and help.

We will give you a 30-day license of WASP 2.1 Analyst.

Email us at support [at] webanalyticssolutionprofiler.com for more details.

This one will be a lot of fun!

Tracking GA Onclick Events

Dave Renouf — Sun, 25 Apr 2010 12:00:41 +0000

I was just asked today if WASP 2.0 tracks Google Analytics events. Yes, it does!

So, take for example the following html code:

pageTracker._trackEvent(‘Video’, ‘Play’, ‘Escape from New York’); alert( ‘Successfully called pageTracker._trackEvent()’ );”>Video, Play, Escape from New York

In this example, a link to play a video, we want to pass specific information to GA to track a specific video being played.

Once you click on this link, if you look in the WASP sidebar you will see the Google Analytics call being made and all the data being transmitted. If you look carefully, the tag UTME will have the value you are looking for:

So, even if the event is not triggered on page load, WASP will still catch it at the moment it is fired. This also applies to other events such as flash animation and more.

Tracking tool diagnostics

Dave Renouf — Tue, 05 Jan 2010 18:12:55 +0000

We received this email a while ago and recently received more information. I thought it would be appropriate to share some of the insight that came out of it

—————————————————————————————-

Greetings,

Iâ€™m Matteo , developer in xxxxxx.com.

Iâ€™m currently developing a tracking system for the site using WASP as main tool for checking and testing, and Iâ€™m facing a strange problem:

in some cases, when I try to track forms in a onSubmit event handler, Â I get WASP displaying correctly the data I want to track, but no packet is sent to the tracking system.

I know that this is an implementation issue, but I expected WASP to show nothing if the packets are not sent.

Can you please provide me with some detail about how does WASP capture tracking packets?

I really like the tool, and Iâ€™d like to keep using it, but Â I really have to know that it is reliable enough.

Thanks for your time and for assistance

—————————————————————————————-
Matteo confirm Wasp shows the data is generated by the tracker but he does not see it on the receiving end. He goes along and give more detail in the next email.
—————————————————————————————-

The problem, in more detail, is the following:

Iâ€™m using WASP along with firebug (that has a good packet sniffing feature).

I cannot see the image request with the sniffer but WASP actually shows me the tracking. In all the other cases the packets are shown, and I can see the collected data on the tracking system side, so Iâ€™m sure Iâ€™m tracking on the correct ID.

You told that WASP watches for packets, as I supposed. This is the reason of my last email: I still cannot figure out what is happening. Probably, as you said, is a problem involving the implementation and the particular environment.

Thanks anyway, if I figure out whatâ€™s going on Iâ€™ll let you know immediately.

Matteo

—————————————————————————————-

He also does not see anything with Firebug but confirms he is using the proper ID for tracking.Â Recently, we got the resolution from Matteo:

—————————————————————————————-

The problem was the related to NS_BINDING_ABORTED error code (as seen in HttpFox).

Probably this is what is happening:

Firebug is smart enough (or not smart enough, depending on your point of view) to hide all the ajax call that will never come back with a response.

This can happen if you send out an async call, and then quickly tell the browser to change web page (e.g. all the events with a page change, like link clicks).

WASP shows the packet, and this seems to be the right behavior. We could say that, in this strange case, we can be sure to being trying to track the event (WASP shows it) but we cannot be sure to actually track it (we cannot wait for the tracking system response, due to user experience constraints).

Hope this is all (and hope this is what is really happening)

Thanks for all, and have a happy new year

Matteo

—————————————————————————————-

This means, NS_BINDING_ABORTED cancels the async call back and the analytics server did not succeed. Due to the page being changed too quickly, the async connection was killed in the process.

Firebug Â did not display the call at all making it hard to see what was going on.

WASP was properly showing the tracking code being executed and sent to Google Analytics by the client’s browser but didnâ€™t show the error code of the aborted connection. Itâ€™s also the fastest and most convenient way to confirm itâ€™s working properly

HTTP Fox, being a more technical analysis of network traffic, was properly showing all the connections and status codes. However, you need greater technical skills to use it and itâ€™s a little more tedious to use.