When I originally tossed the Stockmoose up a couple of months ago, it was mostly a prototype–one that had taken a single evening to produce, and one that was based on a single request to my artist girlfriend: “Can you draw me a moose with a tie?” Well, now it’s finally back with a new coat of paint, some basic anti-gaming measures, and a few other things to spice it up. The “borrowed” Yahoo stock charts have been replaced with our own proprietary charts, and each stock now has a sort of miniature info card so the choice isn’t based solely on name-recognition. We also created a list of 25 Silicon Valley stocks that most people around here have probably heard of–just to make it a little more engaging. Some of the early results are actually a little surprising. In our SV25, TiVo is actually pretty close to the bottom while Netflix is near the top. Based on what I know of the two, I would’ve actually assumed this to be the opposite of what would happen.

The most interesting result, though, has been the clickthroughs. As an experiment, I tossed $50 into Project Wonderful to point some traffic at the moose. PW grew up around web-comics, and you pay for time instead of clicks. The resultant CPC is incredibly low ($0.04-$0.05), but it’s extremely low quality traffic–totally untargeted, and often times people just click on the ads because they think it supports the comics they like. Roughly 1 in 8 unique visitors visiting the Stockmoose have been clicking through to Piqqem, meaning the $0.05 CPC for the StockMoose turns into a $0.40 CPC for Piqqem itself. Because our niche is in the financial sector, most CPC ads on Google cost anywhere from $.60 to $1.20 for even moderately relevant keywords.

It gets better. The bounce rate for traffic coming off of the Adwords was in the neighborhood of 70%, while those coming in off of Stockmoose are closer to 40%. I don’t know if we have enough data to be statistically significant or not, but the concept seems sound. Instead of trusting Google to target our ads to relevant “customers” (they’re good at what they do, but there’s thousands of people out there who make a living scamming AdSense), we instead cast a much wider net and do the targeting ourselves. Those that are interested in the stock market, interested perhaps in the wisdom of the crowd, click through to the main site. Those that don’t either bounce or hang out and pick a few stocks in the Stockmoose game. Either way–our “crowd” results get better and we have an opportunity to pitch the main site.  Win win.

Another day, another kooky web idea. This time, it’s the Stock Moose. We’ve had a lot of debate at work on how to gather data, how to present that data, and how to make that collection/presentation process engaging enough that someone might actually enjoy doing it just for the sake of doing it (rather than tying it to some future promise of “Oh, we’ll give you an edge on the trading room floor”). Back when the college football season was in full swing, Yahoo! introduced what they called the Team Ranker. The concept is incredibly simple: pick two teams out of a hat and display them both (with perhaps a few bits of useful info such as a win-loss record or… a stock chart). The user simply has to click on the one they think is better. Period.

Whichever team (or in this case, stock) has the best win percent is rated as #1, and the rest are sorted accordingly. The system was far too simple to game, at least for football. What this usually meant is that earlier in the day (when the East Coast is awake and voting) highly ranked teams in the SEC and other eastern conferences dominated the rankings. When it got later in the afternoon, teams with East Coast fan bases slipped in the rankings while PAC-10 teams rose into the top spots. This is unavoidable for something like football, where fans are fiercely loyal to their own teams over all others–but is the same true for stocks?

Would users on the East coast sway the list towards East-coast stalwarts like Coke and Home Depot while the West coast might favor silicon valley darlings over all others? It’s hard to say–especially considering that I limited the field to the Nasdaq 100, which is primarily dominated by tech stocks.

The beauty of today’s technology, though, is that these debates don’t have to remain purely academic. The Stock Moose is thin. It’s very, very thin. But rather than spend a few hours swapping emails back and forth with my bosses on whether or not something like that would even work, tools like Heroku make it possible to just go build it. I spent a grand total of around four hours kicking that thing out, and probably half of that time was spent trying to decide on a name for it (and then trying to explain to my girlfriend why I needed her to draw me a moose with a tie). The other half was spent cooking up the round-robin logic, which is probably way too complicated. Building something like this within our own code base–or even hosting it on our own servers without asking permission–would be unthinkable.

If we ultimately decide it’s a failure (which most little web projects are), what’s the cost? There’s always a chance, though, that something so simple (and arguably, so ugly) might go viral. If that happens–and that’s a big IF–what do we get? A little free advertising. If it doesn’t happen, we’ve still profited: we can now cross something else off our list and move towards a more targeted product.

Besides, Stock Moose has a nice ring to it.

When I read about insoshi on Mashable and TechCrunch this morning, it got my mind buzzing… and immediately my thoughts turned to another Y Combinator startup–Heroku. I’ve been using Heroku for quite awhile now, and both my fondness for Ruby on Rails and my disdain (so far) for Google’s Big Table make it my prototyping engine of choice for the time being. The integration is not perfect by any stretch of the imagination, but here’s a quick and dirty way to get an insoshi install running on Heroku (assuming you have an acccount):

First Steps

1. Download the insoshi tarball
2. Create a new heroku app
3. Import the insoshi tarball (how convenient is it that the heroku app importer wants a tarball!)
4. Run rake db:migrate (this will run a ton of migrations… once complete you can press escape to close the little popup)
5. Run rake install (this will create the default preferences file and the default forum.

Hiccup #1The session variable in Heroku is enormous… so jamming it into the pageviews table causes the app to choke. Solution: well, we’ll just toss out that data for now. I’ll try to come up with a more elegant solution later, but for now the goal is simply getting the app to run. The stack trace points you to Line #30 of app/controllers/application.rb, where the page_view is inserted. Comment out Line #32 (“:session => session,”) and save. If you refresh the app, you should now get a totally blank screen.

Hiccup #2

There seems to be some sort of conflict between the Heroku toolbar and the css of the stock insoshi install. Luckily, this is fixable. Go into your config directory and create a new file, “heroku.yml”. Add two variables and save the file:

toolbar_collaborators: false

toolbar_public: false

Refresh the app again and you will now see the blank install of insoshi! We’re not quite out of the woods yet, though.

Log in to your default account. The email address will be “admin@example.com” and the password will be “admin”. Insoshi will immediately prompt you to change these away from the defaults.

Changing anything on the profile-edit page and pressing submit will take you straight to another rails crash… but this one is a little misleading. Your edits actually went through fine, it’s the redirect that’s crashing. There’s a SQL call on Line #310 of app/models/person.rb that needs to be modified to be compatible. What was originally:

sql = %(SELECT connections.*, COUNT(contact_id) FROM `connections`
WHERE ((person_id = ? OR person_id = ?)
AND status=?)
GROUP BY contact_id
HAVING count(contact_id) = 2)

Should be changed to:

sql = %(SELECT contact_id, COUNT(contact_id) FROM connections
WHERE ((person_id = ? OR person_id = ?)
AND status=?)
GROUP BY contact_id
HAVING count(contact_id) = 2)

Note that actually TWO changes have been made. First change “connections.*” to “contact_id”. Second, get rid of the goofy ` characters surrounding the word connections in the FROM clause. Refresh the page and you should now be good to go on viewing user pages. You may need to kick your Heroku app to get it to restart (I usually just change a single character in the config/routes.rb file and save for lack of a reset button).

Hiccup #4

This one’s a little obscure. Sign out of your account and click on the “People” tab. Click on the one user (”admin”), and rails will complain once more. I haven’t quite figured out WHY this one is breaking, but I did trace it back and toss in a workaround. The error occurs on Line #42 of app/views/people/show.html.erb. If you call Connection.connected?(SOME_PERSON, nil) in the Heroku console, the app will correctly return false. Though you are not logged in, the current_user variable is actually set to “false” as well. Calling Connection.connected?(SOME_PERSON, false) causes it to choke, which is why Rails is throwing errors. Rather than trace backwards further to see why the app was setting current_user to false, I took the shortcut: I installed an block surrounding that block of code… Voila! Did I mention this was a quick & dirty install?

As far as I can tell, that’s it! You should now have a working install of insoshi to go play around with. The session logging is a little broken, but it’s really all you need to start tinkering.