jpreardon.com

Visits to your site from browsers that do not run javascript will not be tracked by the standard Google Analytics Tracking Code (GATC). This isn’t a huge problem on most sites. On mobile sites, however, this can mean that you are not collecting data on a significant percentage of your visitors.

Google Analytics has the ability to track mobile sites without using javascript. This works by making a server side call to Google Analytics rather than relying on the browser to make this call with javascript. Google has provided example code in PHP, PERL, Java and ASPX. Unfortunately, they do not provide an example rails implementation–not yet anyway. To fill that void, Moneyspyder has created a sample Ruby on Rails application that implements the Google Analytics mobile tracking code (also available on github).

When I implemented mobile tracking on a site, I (very wrongly) used the sites regular “UA” account number. Mobile page views were indeed tracked, but only as one visitor. To say this another way, all mobile visitors activity looked as if they were coming from one single, long visit with a ton of page views. When I used the proper, mobile account number things started looking much better. This is strange behavior, but someone reported the same problem in the GA support forum. So, learn from my mistake.

To get started with Google Analytics mobile tracking, get your mobile Google Analytics account number by creating a new GA profile or hitting the “check status” link on an existing profile’s settings page. Once you are on the page that contains the standard tracking code, click over to the advanced tab and select the “A site built for a mobile phone” radio button. You’ll see some example code (the default is PHP). Your mobile GA account number is listed near the top (“$GA_ACCOUNT = “MO-XXXXXXX-X”;”). It will look pretty much the same as your regular account number with one exception. The first two letters will be “MO” rather than “UA”.

One other caveat here is that you should not attempt to use both the standard GATC and the server side tracking code on the same page.

Google Analytics has released an asynchronous version of their tracking code. Listed among the benefits of using the asynchronous tracking code are shorter page load times and more accurate visitor tracking–both good reasons to consider using the asynchronous code.

Implementing the asynchronous code is as easy as implementing the current, synchronous version. If, however, you have made any customizations to your existing tracking code, you will need to migrate those customizations to the asynchronous version. Those interested in migrating GA tracking code customizations should take a look at Google Analytics for Developers and these migration examples.

via Google Analytics Blog

Google Analytics does not track links to external sites, nor does it track non-pageview events such as file downloads. For most sites, these are pretty valuable metrics that should be tracked. Many people deal with this by manually adding onclick code that calls the _trackPageview function to all of their links. At best, this is time consuming, at worst it is error prone and many links get forgotten.

There are several ways to automate this so that the these external and file download links will get tracked by Google Analytics without the need to add code to every link. One way is to use javascript to add the _trackPageview event to all of the links that need it, dynamically, when the page loads. This ensures that all of links on the page get the proper treatment. This is especially important if you are using some form of CMS where some of the links are likely to be in the content, while others are in the templates. Brian Clifton has a javascript on his site that does just that: Updated auto tracking script for file downloads, outbound links and mailto links

In my experience, this method works quite well, and it takes just a few minutes to implement.

The NYTimes OPEN blog talks about their TimesMachine implementation, and how they used EC2 to convert the archive information into something usable on the web. TimesMachine, by the way, is an archive of Times pages going all the way back to issue number one (18 September 1851).

via Amazon Web Services Blog

Leopard comes with Rails, but I prefer to roll my own in an effort to keep my environment stable. As always Hivelogic has the goods:

• Installing Ruby, Rubygems, Rails, and Mongrel on Mac OS X 10.5 (Leopard)
• Special bonus: Why not install the latest copy of Subversion? This was written a while back, I followed the directions but went for version 1.4.6 rather than the one referenced on Hivelogic. You might get an error message when compiling, if so, follow the instructions in the comments.

Amazon’s S3 Service went dark for a time today. This, of course, effectively shuttered the businesses (or parts thereof) that rely on S3 for online storage. It seems that things are returning to normal, but some customers are upset–and rightfully so. Amazon touted this storage as being pretty much bulletproof; widespread, unscheduled downtime does not live up to that promise.

In Amazon’s defense, this is the first major S3 outage, so their track record is pretty damn good. I’ve been an advocate of S3 for some time, and will continue to be so long as outages like this one do not become commonplace.

This just serves as a reminder that functions relying on web services should fail gracefully. This may be a tall order, if not impossible, for some applications. But, compensating for these sorts of failures should be a major design consideration for developers of applications that consume web services.

Amazon released SimpleDB to limited beta in December. It’s just what it sounds like, a database to add to Amazon’s stable of web services. I’m a little surprised that SimpleDB does not support SQL, but I can understand why they chose to go in the direction they did.

For the full lowdown, check out Amazon’s SimpleDB page or this article on GigaOM which sums up SimpleDB quite nicely.

Gregg Pollack, of Rails Envy fame, gave a good presentation on REST web services at the Orlando Ruby User’s Group recently (video here). This is a great primer for anyone trying to figure out what all this REST stuff is about. He also touches briefly on a couple Rails 2.0 features like ActiveResource.

A taxi passenger recently found out how open NYC’s new taxi computers are to casual exploration. A wayward error message and some ingenuity lead to an open Internet browser and access to the computer’s file system. It’s disheartening to learn that these computers, provided by TaxiTech, are open to the probing of casual users. It is even more alarming when considering that these systems are used to process credit card payments as well. Are customers’ credit card numbers stored on these computers? If so, are they secure? Let’s hope that TaxiTech and its partners have designed a system that does not put customer information at risk when errors occur.

I also wonder how all these Windows machines riding through the streets of New York are patched and upgraded. Is there an automated updating scheme, or are they wide open to attacks from the Internet until someone gets around to patching the machines?

Until these questions are answered, paying with cash might be the best option.

via City Room

BUG is an open-source, hackable hardware platform from Bug Labs. It is not only cool, but it also may be the holiday gift for the geek/hacker in your life. Keep an eye on their store as they promise to be open this year.

Robert Scoble recently spent some time at Bug Labs HQ in New York and has three videos to share (below). I was more excited about the BUG after watching the first five minutes of video than I have been reading the Bug Blogger for several months. No disrespect to the Bug Bloger here, I just think that the videos show how close these things are to getting into people’s hands. Very exciting.

1. Introduction
2. The final product
3. Open hardware

via Webreakstuff