The number of impressions, hits and sales for the Lottery Calculator dropped after the big Powerball jackpot in April, but the conversion rates seem to be remaining stable.
As with last month, I’m posting the numbers as conversion rates for the year to date.
May saw a bump in the number of people interested in lottery related searches. The spike was highest on May 17th, so it is probable reasonable to assume that the large Powerball jackpot ramping up to $590,000,000 before the big winning ticket was sold.
As with last month, I’m posting the numbers as conversion rates for the year to date.
The conversion rates stayed fairly stable from April. It’s definitely neat to see that they stayed regular through spike of traffic in the middle of the month.
The Lottery Calculator App is definitely not one of the huge iStore success stories, but it is turning out to be a very good educational test bed. Things are probably great if you can get featured by Apple. Unfortunately, very few apps can be featured, so a different approach to marketing is required.
Funnel for Analytics
The web page I set up for Lottery Calculator is very basic, not much more than the app store entry. One key difference is that I can get a little information on how many visitors there are and do some analysis on the funnel. The metrics currently gathered are hits, outclicks, and how many of those hits are from the target platform (iPhone or iPad). Additionally, I gather information from the Google Webmaster tool about how often the page shows up in search as well as the number of actual purchases. Assuming the purchases are overwhelmingly from people who found it from the web page and that most users find it via Google, I’ve set up the basic funnel. Search->Hit->Outclick->buy.
A little basic math provides the conversion rates
February is skewed due to a brief ad campaign that brought in 15 hits. I modified the web page a bit based on SEO advice from around the web in March which I think is responsible for two bumps, the first almost immediately, then a significant jump in impressions in mid April.
One thing that jumps out at me is how very little data is needed to give somewhat consistent results. I expected the graph to jump all over the place, but the curves quickly flattened out. If I’d have known, I would have began collecting and analyzing much sooner instead of assuming I had too little data to be useful.
VSIP application submitted!
Last week, I applied for Voluntary Seperation Insentive Pay (VSIP) at my day job. With the sequestration and looming furlough, they offered a stack o’ cash as a carrot to trim the work force. The program is a severance pay for people who voluntarily leave, with a handful of rules attached. If I were to rejoin the DoD or take on a “Personal Services” contract in the next 5 years, they would want me to pay the VSIP back.
What I’ve been up to
I’ve been reading the startup websites for years. I’ve spent some free time learning the technologies like Ruby on Rails, jQuery, NoSQL (Cassandra, MongoDB, CouchDB, etc), OpenID, CSS, etc. There are even a handful of web experiments (Adage, Belter, funnyname, Kore0, notify, password generator, performance monitor) and an iPhone/iPad app for computing the cash payout if you win a lottery (Lottery Calculator). Quite a bit of effort in learning the basics of SEO and the basics of marketing, as well.
I’ve actally been planning on leaving ARL for a while, so this seems like a kick in the ass with some extra cash to extend my runway. The VSIP isn’t guaranteed, and I’ll probably still be at my day job until September, but one of those big steps has been made!
Over the next six months, I’m planning on continuing to save like mad and work on learning the marketing and business side to being an entrepreneur. The financial prospects of the Lottery Calculator iPhone app are fairly grim, but it is useful as an educational tool. A little interface clean-up and the VCS Notification Service will be ready for “launch” and I hope to learn a lot more, and maybe even get lucky with a revenue stream. We’ll see where life takes me on this next adventure
Image credit: juliengron
Google announced sunset of their
RSS Reader and the geekier side of the internet seems to have exploded.
Many articles and comments talk about the various alternatives and how the lack of an 800 pound gorilla in the room will foster innovation in the RSS reader market. People will try and comment new approaches and ideas in how to consume their RSS feeds and small businesses will try new approaches to capitalize on the large displaced user base. On February 18th of 2013, I looked around for alternatives and found all of them wanting in some form or another, so I stuck with Google Reader at that time. This time, I’m being forced to find a replacement, so I guess I looked a little harder. The one that seems to match my use the most is TheOldReader, a simple Ruby on Rails SaaS that makes heavy use of AJAX (and had significant growing pains the last couple of days). It’s very close to Google Reader, so it might be worth a try.
Several other comments on various boards, forums, and other sites indicate that a lot of people are going to write their own. Honestly, I had the same idea at first, then decided to use a preexisting one and make suggestions to the developers to help shape it to my needs, then I decided it’d be better to just write my own, then I decided to let someone else, … Fighting the “Not Invented Here” syndrome. In the end, there are a lot of RSS readers now, a lot more on the way, and I think my time can be better spent elsewhere. Good luck to those who give it a shot!
The other major category of activity over the sunset of Google Reader is a lot of people claiming that Google has made a huge mistake and will be sorry. That seems like a petty and naïve stance to take. Of the geek friends I’ve talked to, only one other actually uses an RSS reader. The non-geek friends have heard something about google something going away, but have no clue what it is. While the minority is vocal and occasionally makes a good point, it’s very much a minority and I think well outside of domain Google seems to be focusing on lately. Googles reason for existence is to make money and they’ve probably done analysis of direct revenue, indirect revenue and cost before making this decision. Larger companies often even accept a little loss on a pet project just to keep the developers happy.
It’ll be interesting to see what the RSS world looks like when the dust settles.
I’ve been thinking a lot about SEO, long tail optimization, and various other methods for driving traffic lately. I have also been watching the analytics religiously and trying to guess at what matters. A certain blog post (the one about using jquery’s asynchronous request stuff, or AJAX, to update a bootstrap progress bar) seems to be well placed out on that long tail and drives a notable portion of that traffic.
This certain post only gets around 100 impressions a month from google, but has a CTR of about 20%. I have other pages that generate several times as many impressions, but never rack up the click count to even register. There definitely seems to be something about using long tail optimization to target the niche, as the other pages that get traffic mostly sit at 0 hits. Here is the google analytics graph of the jquery/bootstrap progress bar page
While the traffic is hardly impressive, it is enough to start providing numbers to optimize. This is exciting as I have a brain chock full of lean startup concepts and am eager to start applying them in a practical fashion. The trick will be look for that magic balance where there is enough traffic to be worth it, but small enough interest that it’s not a saturated market. Neat stuff!
In the future, I think would like to start doing market research before blogging. Obviously, I like writing about some fairly esoteric topics, like how to generate Mac application bundles using SBCL or Setting up the UncommonWeb application server, but those pages get very little attention. The entry on the jQuery/bootstrap kinda felt like pandering when I wrote it, but drives more traffic than all the others combined. I think I’ve been focusing too far down the long tail!
In early May of 2012, I jotted down a set of ideas for the next code to write. I had decided that it would either be a web app (UnCommonWeb based) or a mobile app. With the mobile apps, android let you get an app running on a device for free, but iOS seemed far more monetizable. While I was toying with ideas that only a geek could love, Erin had a clever idea; an app to estimate the ‘cash in hand’ if you win the lottery.
The huge lottery jackpot values advertised are cooked in an interesting way. Estimates are made of ticket sales and some ‘magic math’ is done on that number to come up with an investment value. The advertised jackpot is the sum of the payouts if the original lump were invested and a fixed amount cashed out monthly over the term listed in the small print, something like 30 years.
That $100,000,000 jackpot on the billboard is NOT the winning amount! It’s an approximation of the value of the actual value if invested into a fund and tapped as an income value. If you wanted to cash out in one lump some and manage your own investments, the amount is significantly less.
Once you decide to take the cash out value, there are additional taxes that further reduce the take-home value. We focused on the US, looking at the Mega-Millions and Powerball lotteries in particular. The tax turned out to be chock full of special cases. There’s a federal hit right off the top. Some states don’t tax lottery winnings, others do. Some cities apply their own taxes. If you happen to win the lottery and live in Yonkers, there are 4 different taxes applied! If you buy the ticket in a state you’re not a resident of, the tax situation is further complicated.
So in late April of 2012, we set to work. We reverse engineered the ‘magic scalars’ and built the tax tables. We wrote a library in C to estimate the actual cash payout based on jackpot, location, residency, etc. We wrapped it in a simple iOS frontend and submitted it to the app store in late June. After about a week and a half, it quickly went from ‘waiting for review’ to ‘in review’ and ‘approved’. Success!
One of the challenges I’ve had in working with UnCommon Web (UCW) as an application server behind an Apache front-end is handling connection information. Modproxy creates a new connection to the app server itself, losing some of the incoming information. One way to pass that “extra” info to the app server is using an apache configuration line like this:
RequestHeader add "X-Name" "value"
This appends the new key/value pair to the HTTP headers. In my case, I wanted to tell if the connection was using SSL or not. In VirtualHost directive for the SSL listener, I added a line saying that the protocol is ‘https’.
RequestHeader add "X-Protocol" "https"
In the non-ssl version, I put in a line saying the protocol was http.
RequestHeader add "X-Protocol" "http"
With the apache configuration done, apache can be restarted. Catching the value is as simple as querying the http headers in the application. Once possible way to do that in UCW is something like this
(defun protocol (req)
(let ((prot (assoc "X-Protocol"
(headers (it.bese.ucw.core::headers req))
(when prot (cdr prot))))
2012 has been a busy and educational year.
To get my feet under me better with UCW and common lisp, I wrote up the Adage website. Right now it has a handful of fortune databases plus a handful of Charlie Sheen quotes.
The LottoCalc iOS app Erin had the idea for was written and posted in the store. Sales haven’t been great, but there was definitely a lot of educational value and perhaps an updated version would be a great test bed for learning more about marketing.
As a followup to LottoCalc, I wrote a quick KaBOOM! game using OpenGL ES 2 with the appropriate GLSL parts and a scratch build minimal scenegraph manager. Apple rejected it due to poor art, and I’m very slow about generating art, so it’s on the backburner for now. The web page for it is http://elfga.com/KerBLAM.
In November, I started up the Notify project to replace the defunct CIA.vc system for posting VCS commit messages to IRC. The core is open source and available at https://github.com/erikg/cl-cia. The two tricky parts are parsing the wide variety of email formats generated from commit hooks and all the little details of the web interface.
I’ve also learned a lot about SEO this last year, with my web traffic up more than 600%. The website is now littered with fixed names and events for google analytics, scripts to generate sitemaps, and all sorts of other neat little details.
I mentored in both the Google Summer of Code and Google Code In projects in support of BRL-CAD, as well as working a full time job and taking time to do the family thing. Quite a year.