Tonight, while writing another blog post, I tried clicking on the bit.ly link to go to my app’s page, and instead saw this:

Somehow, my link had been flagged as malicious and I’ve been missing out on potential sales because bit.ly decided to break my link. Why though?

Looking at bit.ly’s FAQ, they say:

Bit.ly filters all links through several independent services to check for spam, suspected phishing scams, malware, and other objectionable content. We currently include Google Safe Browsing, SURBL, and SpamCop in our operations.

Checking Google Safe Browsing, SURBL, and SpamCop, I see neither planetaryscale.com nor itunes.apple.com are blacklisted.

Okay, that’s weird… but wait! It looks like when I originally created the link, it was actually a link to a tinyurl.com link. That was kind of dumb of me. However, as a sanity check, I’ve created a link to Disney.com with tinyurl to see if it too will be blacklisted by bit.ly. Unsuprisingly, it is. Checking Google Safe Browsing, tinyurl.com is listed as an intermediary to malware, as is bit.ly.

So, the takeaway from all of this is: as far as I can tell bit.ly is flagging all links to tinyurl.com as malware, even just a link to the tinyurl homepage.

Why is this worse than just a screwup on my part? Consider that bit.ly is used to automatically shorten URLs in a lot of services, such as Twitter. A quick check shows bit.ly also flags links to the homepage of is.gd, tr.im, cli.gs, tiny.cc, BudURL.com, snipr.com, snipurl.com, and kl.am, all of which are competitors. In fact, if I tried to link to the Enterprise Edition of BudURL in a tweet, it would be automatically converted to a bit.ly link. Clicking on that link would take someone to a giant warning page, rather than the product of a competitor.

I realize bit.ly is trying to do this as a safety feature, but as it stands I’m moving my web links to direct URLs. The added value of their statistics tracking just isn’t enough to offset the risk of them breaking my links.

I track the sales data for my company’s iPhone apps using AppViz and thought it’d be interesting to whip up a graph of my iPhone app revenue in this format. Here’s the result (red is low revenue, green is high):

Sales peaked in January when the Mappity offline city maps apps were released, and have been falling since then. Those blank spots in the second half of 2009 are days of $0 in revenue.

Interestingly, it looks like Mondays and Tuesdays are relatively weak days for sales. This is probably due to customers going back to work or school.

If you’re an app developer and would like to generate a graph like this of your own, it’s really easy. If you have AppViz, export your data in the “Revenue by Day” format. Then, run the Python script I wrote to convert the data, which is available on GitHub.

Download the calendarHeat.R file from the original blog post and import it into R. Then, import the reformatted revenue data and generate the graph with this bit of R code:

data <- read.csv("PATH TO DATA", as.is=TRUE, sep='\t')
data <- transform(data,
week = as.POSIXlt(Date)$yday %/% 7 + 1,
wday = as.POSIXlt(Date)$wday,
year = as.POSIXlt(Date)$year + 1900)

calendarHeat(data$Date, data$Converted.Revenue, varname="iPhone Revenue")

Replace "PATH TO DATA" with the path to your CSV file to import the data. Enjoy!

Not only did Amidst go down, but Mappity Quakes didn’t work during the duration of the outage due to being served off of the amid.st domain. I’m sorry for the downtime and am really embarrassed that I let this happen.