AIAIO: Our Blog

Ai is pushing live the latest version of the Continental Airlines International Restaurant Week website today. Its rollout (the third annual campaign we’ve done for them) is a reminder of the impact an integrated marketing plan can have on an online project.
For Continental, the website is the home base of an annual promotional campaign. International Restaurant Week leverages the cuisines of twelve of New York’s finest restaurants as the airline “takes you to even more places.” This year, the website showcases a signature dish contest, judged by Tom Colicchio, as well as user-generated ratings and reviews.
But what will make this campaign successful is the steady flow of traffic generated by Continental’s marketing efforts. This year’s promotion included prominent, handsome advertising in magazines and newspapers in New York, where the promotion is taking place. Targeted emails were sent to Continental OnePass list members, and a promo tile is in place on the Continental Airlines home page.
All this is creating strong traffic to the site. Continental’s Restaurant Week is a short-term promotion; it can’t wait for natural search results or rely on the press release to pull people in. So Continental worked proactively, and the result is a steady flow of users that will stay engaged for the duration of the promotion.
With targeted emails, print ads and online messaging, Continental is reaching a defined market effectively. It’s a powerful combination that should be considered for any marketing initiative with well defined goals.

Yesterday was the third successful Tie Tuesday at Ai HQ.
What, pray tell, is Tie Tuesday? As it sounds, it’s when this otherwise ultra-casual office dandies up for a day, and anyone who’s game sports some proper neckwear. Outfits range from tie-and-jeans to full slacks-and-shoes getups, and are worn regardless of client-facing assignments–two of us wore ties to a casual on-site client meeting yesterday.
Tie Tuesday came about naturally, after two of our developers wore ties on a whim in the same week. “Hey,” we thought, “this oughta happen more often.” But one guy wearing a tie does not a movement make, so acting on a tip from this author’s wife, Tie Tuesdays at Ai were born.
We’re doing it until Memorial Day. If you’re in the neighborhood on a Tuesday this spring, just look for the dapper dons on the Shake Shack line. (Shake Shack Tuesday–now there’s an idea….)

Monday’s news from Major League Baseball’s online team reminds us how far the digital world has to go to replicate offline revenue streams.
The news, on its face, was good: MLB has made nearly $1 million on its iPhone app since launching it early this month. It actually grossed $1.3 million, which puts it just shy of the seven-figure mark after Apple’s 30 percent cut. Silicon Alley Insider says MLB’s repurposed content makes this a profitable enterprise.
And yet. A million dollars sounds good until one considers that MLB makes tens of millions of dollars per year on its national TV contracts, and hundreds of millions more locally. The YES Network alone brought in $360 million last year.
MLB’s approximate $910,000 net revenue on the MLB app barely buys a decent TV campaign on one of its local affiliates. Heck, it wouldn’t even pay Pedro Feliciano’s salary.
With all the doom and gloom about old media floating around, it’s no surprise that media outlets are looking for good-news stories. But it will take a lot more than a million bucks from the iTunes store to make up for the potential lost revenue as people move from radio and TV to webcasts.

Have you ever been in the middle of a project, needed a few quick lines of code, and Google wasn’t quite helping you out?

Are you the kind of person who enjoys taking a few minutes from time to time to help out your friends with your coding prowess?

We created a new social coding utility called @codeoff just for you. Use the Twitter @codeoff account to reach out for quick programming help and/or exercise the good Samaritan in you by responding to quick requests.

We’re also hoping @codeoff awakens the competitor within the coder, as people fight to be the fastest/best in posting requests and sharing code replies.

Need some code?
1. Follow @codeoff on Twitter.
2. Tweet code you need to @codeoff:

Format:
@codeoff language requirement
Example:
@codeoff python: writer a retweeter

3. Wait for @replies :)

Code some code?
1. Follow @codeoff on twitter.
2. Look for code tweets.
3. Code.
4. Post your code to http://gist.github.com.
5. @reply to @codeoff, including the requester and your gist url.

Format:
@codeoff @user http://gist.github.com/gistid
Example:
@codeoff @apumapho http://gist.github.com/101263

We hope you enjoy using @codeoff.  Drop some comments and let us know your feedback.

The news that Yahoo is shutting down Geocities got me curious about how Yahoo did on the deal. A decade later, was Yahoo right to make the acqusition in the first place?
I did some research, some math, and a bunch of IM brainstorming with Tristan Louis and came up with the following.
The basics: Yahoopaid $2.87 billion in stock for Geocities in May 1999 after announcing a deal that January at $3.57 billion. Adjusted for splits and inflation, that’s the equivalent of $1.54 billion in Yahoo stock today, or $1.2 billion in 1999 dollars–a far more reasonable figure than the dot-com-inflated sums that Yahoo and Geocities swapped. Considering that the transactions were all on paper, the deal already makes some sense. (Tristan’s initial calculation put the value of the 1999 stock at $155 million–a steal!–but that may have been done without factoring in Yahoo’s three stock splits.)
But did those billions pay off?
First, consider direct revenue. Geocities had $7.82 million in revenue the final quarter before the acquisition. Taking into account traffic trends for the years following, and estimating revenue based on industry flows, the total revenue from Geocities display advertising–for 10 years–comes to around $320 million (not inflation-adjusted). Not a lot compared to the $2.87 billion purchase price, but at least Yahoo got back 10% of its stock swap in cash.
Yahoo Geocities also had a premium model, with Plus members paying $4.95 a month and Advantage members $19.95. Yahoo never released membership specifics, but we can generously estimate that 1% of Geocities’ 14 million members signed up for a larger model, with a small segment going to Advantage. That program still exists, which means there’s some incremental revenue even now. Geocities Plus probably pulled in more than $8 million in its peak year, which extrapolates to roughly $60 million total since its introduction.
We can assume Yahoo Geocities had all sorts of marketing partnerships, each of which generated as much as $250,000 per initiative above and beyond basic ad revenue. Let’s generously peg this value at $20 million total, mostly during Geocities’ peak usage years.
So that comes to $400 million in revenue. Decent money, but far from profitable on its own.
Then let’s consider the traffic implications. In today’s world, the traffic figures from the 1990s are laughable: Geocities was the fifth busiest site on the Internet in June 1997… and four months after that they signed up their millionth user. Then again, in the era of rapid growth, though, paying for traffic made sense. By the time the sale closed, Geocities was up to 3.5 million user sites and 19 million unique users.
From that angle, the sale paid some robust early dividends. Yahoo’s traffic increased by nearly two-thirds following the acquisiton. That’s a lot of new eyeballs seeing the Y! and becoming familiar with Yahoo’s name and, ultimately, its other services.
Yet Geocities peaked in 2002 and has been in slow decline ever since. After hitting 27.7 million in March 2002, the numbers kept dwindling: to18.9 million in October 2006, then 15.1 million in March 2008, down to 11.5 million unique users last month. So the long term didn’t play out perfectly, thanks to more robust social networks superseding Geocities’ early style.
With all this hindsight, it is doubtful that Geocities can be called a profitable acquisition. It probably can be considered a break-even, though, given the number of different revenue streams and added Yahoo network traffic the site brought.
Geocities is also notable for what it did for Yahoo off the balance sheet. The bold acquisition of a social site, and its subsequent integration with Yahoo, paved the way for future site aggregations. Yahoo’s purchases of Flickr and del.icio.us show Yahoo’s continued commitment to community, and its willingness to assimilate other networks with its own (albeit with varying degrees of success).
Indeed, Geocities can be considered a hallmark of Yahoo’s style and a bellwether in its corporate history. For better or worse, that alone makes the acquisition a solid one.

The lead eMarketer story today is How Much Ads Cost. It breaks down offline media CPMs in a handy graph, then makes a separate set of online assessments.
The biggest takeaway? Display advertising doesn’t pay. Online display ads ran at a $2.46 CPM in 2008. That’s less than 10% better than what outdoor advertising charges for billboards and bus stations.
The article goes on to note better returns in video (CPMs anywhere from $7.40 to $35, depending on placement) and search ($75!). But it doesn’t eliminate the big message: online display advertising doesn’t pay. Not well, at least.
Of course, display ads are de rigueur in much website creation, and a buoying component of media sites. But display has become a baseline and not a profit center. This is happening offline as well as online. The New York Times recently reported on evolving revenue channels at magazines, where subscriptions are becoming pricier profit centers–the opposite of the traditional model, where subscriptions covered postage and ad revenue ran the business.
Savvy online publishers are realizing this and similarly evolving their models. Beyond video advertising, sites can offer premium content, exclusive access, tools and other items to entice more value out of individuals. Business-to-business revenue needs to morph into something more profitable as well, whether it’s through partnerships, sponsorships, cobrands, or something else.
Innovation is going to be key in the coming years. Because a simple ad banner unfortunately won’t pay the bills.

Ai took its second team business trip by train this week and came away completely satisfied with the experience.

We took the Acela from New York to Washington, D.C., a strikingly fast ride (2:40) compared with driving (4:15) and even Acela’s own New York-Boston line (12 miles shorter yet an hour longer). Our entire trip was downright pleasant.

What makes the Acela so great?

1. Convenience. Train stations in the northeast are located downtown with ample taxi and subway access. (Compare with air travel: no hour-long $40 cab rides out of town.)
2. Hassle. Or, rather, the lack of it: no security checks, no traffic, no boarding by zone. Just a queue to get onto the train, and the odd requirement that we sign our tickets for the conductor. 
3. Comfort. The Acela is roomy: tall ceilings, wide aisles, lots of places to stand and stretch. The snack car is a pleasant walk and is staffed by inviting attendants. We grabbed four-seat work areas with fold-out tables, which allowed us to collaborate, and hang out, as a group. A beverage cart brought us sodas and Entenmann’s cookies (!). The Acela’s seats are on par with most airlines, but with better legroom.
4. Access. For three hours, we had respectable connections to the rest of the world via Verizon and AT&T cell phones. Acelas don’t have wifi yet, but we tethered a laptop to an bluetooth EVDO connection and were able to email and share files comfortably.
5. Time. Going to the airport for a shuttle flight would have taken roughly the same amount of time as our train ride. But instead of spending most of that time in transit–driving to the airport, waiting on security lines, sitting without electronic equipment before takeoff, taxiing to a gate, taking another car into town–our three hours were spent comfortably, in a single seat, with laptops and phones fully operational.

Which is not to say rail travel is perfect. The Acela is far from its high-speed potential, and suffers from Amtrak’s notorious reliability problems: on our Boston trip our train completely died in Rhode Island, then began running smoothly 15 minutes later. But at least there we were on the ground, looking at foliage, enjoying our comfy cabin.

Our trip was a success, and so was the commute. Here’s to hoping President Obama’s high-speed rail concept actually goes somewhere.

This is what Jim Goldman of CNBC would like you to believe. But if you have a PC, at least it only costs $140.

Is isn’t always desirable, or even necessary, to validate every attribute in a given model with every save. For example, I recently had to build out a tabbed interface for editing products. Normally, when a user would press save, with the controller code calling update_attributes, errors would appear for attributes outside the current tab.
The need for intelligent, conditional validation begat the following module, which can be included in any ActiveRecord class:

module SelectiveAttributeValidatable
def self.included(base)
base.send(:include, InstanceMethods)
base.class_eval do
alias_method_chain :update_attributes, :check
end
end
module InstanceMethods
# Store the set of attributes passed in to #update_attributes.
def update_attributes_with_check(attrs)
@attrs_to_validate = attrs.keys.map(&:to_s)
update_attributes_without_check(attrs)
end
# Returns true if a given attribute was passed in to #update_attributes.
def should_validate?(attr)
if self.new_record?
attrs_to_validate_on_create.include?(attr)
else
@attrs_to_validate.blank? ||
@attrs_to_validate.include?(attr) ||
self.status == 'ENABLED'
end
end
# This method must be overwritten in the class
# where this module is included. Specify whichever
# attributes you want validated on create:
#   ['name', 'sku']
def attrs_to_validate_on_create
[]
end
# Allows the should_validate callback to be thrown.
def method_missing(method, *args)
if method.to_s =~ /^should_validate_([_\w]+)[?]/
return should_validate?($1)
else
super
end
end
end
end

After including this module, you’ll need to add conditions to your validations, as follows:

validates_presence_if       :description,  :if => :should_validate_description?
validates_numericality_of  :age,            :if => :should_validate_age?

Once you’ve implemented the conditions on your validation, any call to update_attributes will validate only the attributes included in that call.
Caveat
You probably want to make sure that your objects are eventually valid. In my case, this entails storing an enabled/disabled state on the object. This way, I can specify that when the object is enabled, all of the validations should be in effect.

Over the weekend, like many Americans, I did my taxes. I’m required to file a couple of different Schedule C’s for various side-businesses I have, and when it comes time to hunt for deductions, it sure is nice to be a programmer.

I had initially thought that I would be able to download the entire year’s bank transactions into a CSV file, but alas, my bank (and many others, I’m finding) only provide 45 days of history. They do, however, allow you to download PDF files of all of your statements, and so there I was staring at thousands of transactions in PDFs, dreading retyping them into Excel.

Enter my skills as a Rubyist. I sought out the PDF::Reader library, which allows you to hook its parsing engine to a custom callback and do what you want with it. This definitely parsed the PDF fine, but I had no context; no idea where I was in my statement, because there’s no callback for a “new line” character – it’s just a stream of words. I found that if I used Adobe Acrobat to save the files as text-accessible, then I started to have statements I was able to work with.

Now that I had ‘lines’, I was able to use the power of regular expressions to get the data I needed. The lines I was interested in started with a date and an amount, and the rest was just description for my transaction.

Here’s the warts-and-all code I used to compile the year’s worth of spreadsheet data. It’s truly “quick-and-dirty”, but it saved me tons of time. The next step, of course, would be to implement regular expressions against the ‘memo’ field of these transactions, and pre-suppose categories and deductions based on these patterns. But then again, maybe it’s time to just use Quicken and stop waiting until the last minute.