Tracking tool diagnostics
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.
—————————————————————————————-
—————————————————————————————-
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.
