WASP Blog » Analytics

Webinar: Is the Check Engine Light “On” for your Analytics?

Dave Renouf — Wed, 16 Feb 2011 16:34:11 +0000

With complex analytic funnels, multiple goal tracking and multiple technologies, keeping your analytics reporting properly can be a long and tedious process. But for less than 30 cents a day, WASP can detect every tag that a website or web page is running in a matter of seconds, so that you can debug your analytics faster and more confidently than ever before.

Learn how WASP can:

- Quickly diagnose basic analytic tags
- Run site audits and generate reports
- Flag tagging problems
- Simplify e-commerce workflow

Watch the webinar

Automated SiteCatlyst version scan with WASP Pro

Dave Renouf — Tue, 12 Oct 2010 18:52:11 +0000

Migrating SiteCatalyst to version 14.9 ?

Any time there is a major update in your analytic tagging, such as necessary new variables or javascript changes that require references to new Javascript code, it can take ages to ensure that all of your tags are updated properly. Verifying large sites by hand is nearly impossible.

To ease this process, you can use the scanning capability of WASP Pro. This simple tool will automatically crawl your entire website and provide a detailed report of which pages have not been updated or are missing tags altogether.

Let me show you how WASP Pro does this. First, you define what you want to scan, including how many pages you want to scan, maximum depth, and even rules as regular expression to filter pages in or out of your scan.

Once the scan is complete, you can view a report that shows you all of the analytic solutions detected and the number of pages that have the solution integrated.

If you click on the tagged pages, you will see a list of all the pages with those tags, in a table format. If you click on the missing pages, you will see all the pages missing those tags. In the example below, we clicked on the missing pages for Omniture SiteCatalyst.

We also have what we call the “upside down” view. Instead of looking at the data at the page level in a table, we give it to you at the tag level using a tree. You can drill down into every single variable and value in order to see what page have those values. If we take our Omniutre SiteCatalyst example, you can see specifically what pages are tagged with what version.

And of course you can always export any of the data in .csv format to analyze in other tools such as Excel.

Naturally, once you have your report you can use the interactive functionality of WASP to diagnose the pages that are causing you problems and make sure all your pages are properly tagged.

Feel free to contact us for an interactive demo.

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.