WASP Blog » Trics

Google Analytics, Facebook and WASP

Dave Renouf — Wed, 28 Apr 2010 14:44:37 +0000

More and more companies are building communities using social networking sites and there has been a lot of buzz lately about tracking Facebook Fan pages with Google Analytics. Integrating GA into Facebook can be a challenge since what you can actually do is limited and trying to see if your implementation of GA works on your Facebook Page can be an even bigger challenge.

That’s why WASP was created, and as you have probably guessed by now, you can use WASP to see if those “invisible” tags you placed on your Facebook page are triggered properly and are sending back the proper data.

Yesterday, I created a Facebook Fan page for WASP, and then followed the instructions here to insert the data I want to feed to my Google Analytics account. I passed in 3 values: googledomain=facebook.com, pagelink=/FB/Landing and pagetitle=FBLanding.

And, now if I visit my Fan page with WASP enabled, this is what I see:

When I open up the side bar, I can also make sure I am sending the proper data back to my Google Analytics account:

And, even if I created my Fan page yesterday, people are already finding me and here are the result in my Google Analytics report:

Voila! I’ve just confirmed that it’s all working properly. This technique will not only work for Google Analytics but with over 200 analytics solutions detected by WASP, even if they are triggered on event as mention in my event post.

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.