CS and the City

I’ve been a user of AwardWallet for a couple months now, a site that keeps track of many of my travel reward programs. You can think of it as Mint.com for loyalty programs. It turns out that I’m far more likely to participate in programs and actually be loyal to the brands if I can monitor my account status.  AwardWallet isn’t perfect, but it serves a large need I have.

Unfortunately, Southwest either doesn’t understand this benefit, or doesn’t actually want its customers to use the loyalty program because they’ve blocked AwardWallet from collecting this information on my behalf.  The team emailed me this week with the disappointing news:

Dear Sean,

We are writing to inform you that unfortunately Southwest is no longer allowing us to pull data from their website anymore. You can update your balance manually and you can use AwardWallet to auto-login to Southwest’s website. From now on you need to track the expiration date of your Southwest miles manually.

Southwest’s response to another AwardWallet user was equally frustrating:

We regret your disappointment that Southwest does not participate with third party companies who offer frequent flyer information on their web sites. Our reasoning lies in the fact that we can only safeguard a safe and secure program by keeping our Customers flight credits and Awards within our own internal system. While Award Wallet’s intentions may be genuine, by allowing them to have access to Rapid Rewards Members’ account information, we could potentially jeopardize not only our program’s integrity, but our Members’ personal information.

The fact that I have 11 Rapid Reward points (I only need 5 more for a free flight!) is not, in any world, hyper secure information. If I as a customer, choose to have that information aggregated in a way that provides value, that is my prerogative.  I’m convinced they recognize this too and that their concern is almost certainly that I am giving some third-party my login name and password in order to collect this information.  This I do recognize as a security issue, but it’s a problem with an easy and well recognized solution.

What I propose is a MicroFormat for APIs.  I’d like to define a protocol to increase the use of loyalty program data with the follow features:

• REST API for querying both the current status and the history of transactions for any given rewards program.
• Simple JSON data structure with extensible fields so that programs can customize to suit their needs
• OAuth based authentication
• (Optional) PubSubHubbub-based notifications for status updates

If every loyalty program adopted this, web services and iPhone apps the world over could quickly expose this information to users in a meaningful way, and instantly make adoption of those programs a lot more valuable to their customers, and ultimately make those customers a lot more loyal.

I’d love to see Southwest actually push toward a solution that enabled this sort of usage.  Looking at the AwardWallet forums, there’s obvious demand from power users.  Seems to me, they might be the types of customers that Southwest would consider worth pleasing.

This week I’ve been taking a look at the recently announced pubsubhubbub by Brad Fitzpatrick and Brett Slatkin of Google. The duo proposed and implemented a protocol for implementing near-realtime notifications on top of RSS and Atom. The protocol describes three roles: A publisher, a subscriber, and a hub. The hub basically acts as an intermediary, receiving subscription requests from subscribers and forwarding update notifications from publishers to subscribers.

One of the first things I noticed about the protocol is that subscribers are required to have an internet accessible URL for validating subscription registration and receiving notification pings. This is not an issue for the Google Readers and FriendFeeds of the world, but this does leave desktop RSS readers out of the party.

Also interesting to note is that there’s nothing that requires the hub to be a separate entity from the publisher. In fact, it could be very desirable for the publish to own the subscription hub. Besides removing one notification roundtrip from the protocol, it would also give publishers more control over how often to ping users on updates. Nothing in the protocol requires that a notification be sent every time, so it would be possible to only notify a subset of users in real time (perhaps the ones that pay), and others on a regular basis.

Depending on how deep your RSS Trivia knowledge goes, this might sound awfully close to the rssCloud element, but Brett points out that the key differentiator here is PSHB’s “fat pings“, that is, the entire updated content is sent as the ping to the user.

To reduce latency and polling, PSHB supports persistent HTTP connections from hubs to publishers, but it could use FriendFeed’s SUP protocol to detect updates as well.

Though solving slightly different problems, it’s interesting to compare the SUP’s and PSHB’s stance on polling. SUP obviously relies heavily on polling, despite drastically reducing the amount required. While PSHB has strong opinions against. Polling is certainly less error prone, in addition to being less efficient. For example, how does PSHB handle dropped pings to subscribers? I admittedly haven’t dug too deep, but I assume a reasonable amount of state must be maintained in the hub to handle these cases smoothly.

Ultimately the most valuable contribution of the entire project might be the two outspoken Google employees behind it. Already they are seeing some adoption. The pubsubhubbub demo at Real-Time CrunchUp announced launched FeedBurner support and showed prototypes of Blogger and Reader support. Having evangelists inside the company puts early adoption in other Google products much more likely, which in turn will give the standard much more credibility.