Building the new platform

When I first joined the Digital team at the Obama campaign back in June of 2011 the fundraising stakes were as high as they could get. There was speculation in the press that we would raise a jaw dropping $1 billion and while that seems like (and is) a lot of money, we were up against newly instituted Super PACs that could raise an unlimited amount of money (thanks Citizens United!). Not to mention that we would also eventually have a "businessman" opponent that would surely have a strong fundraising operation.

In the end though we astonished even ourselves by beating the expectations and raising $1.1 billion total. $690 million of that came through our various web properties. Because the competition was so steep and because we would be working at such scale, we knew we had to get very serious about our online fundraising platforms.

In the early days of the campaign (April 2011 - May of 2012) all of our online fundraising went through a single platform which was hosted and managed by one of our vendors, Blue State Digital (Blue State). This was a good platform for us at the time because it was easy for content managers to edit and produce fundraising pages without the help of our lone frontend engineer (me). Soon enough the campaign started hiring aggressively and that one frontend engineer turned into fourteen frontend engineers with six specifically focused on fundraising. By early 2012 we had the staff we needed to take our donation platform to the next level and we were certainly eager for the task.

Blue State was very helpful in working with us to create a new donation platform that met the campaign's unusual needs. We settled on a very simple solution of turning the hosted platform into a REST API. The only big change was adding JSON as an output option instead of HTML. Blue State was able to turn this around in only three days which was a huge win for the campaign because we were working on such a short timeline and already bringing in about $15 million a month. After this work was complete we had a very flexible donation API and now it was time to figure out what would consume it.

We knew from the very beginning that our new donation platform needed to be as fast as we could reasonably make it. We were very familiar with all the stories from huge companies like Amazon and Google about how only 100 milliseconds of latency can affect conversions by as much as 1%. Needless to say, performance was was one of our very top priorities.

After working closely with our Devops team to plan the architecture of the platform we decided to go static. We consumed the newly created donation API using JavaScript on static HTML pages which were served by our CDN (Akamai). We chose to do it this way in no small part because this is the fastest possible way to get the HTML document to the user since Akamai has over 50,000 edge servers and the system routes users to their closest server so that the file transfer time is extremely minimal. In our Chicago office we consistently saw HTML transfer times around 20 milliseconds!

Aside from performance, another high priority for the platform was stability. Our online fundraising tended to come in spurts based on what was happening in the news at the time or campaign fundraising emails. For example, our highest surge was $3 million an hour so any down time would have been very costly.

To ensure that the platform was as stable as possible we worked with backend engineers on the campaign's Tech team to make the Blue State API redundant. The Tech engineers built out a duplicate payment processor/API and hosted it on Amazon EC2 (itself redundant across data centers). At this point we had two APIs that we could switch between if one went down, but our Devops team had a great solution to make this automatic. They sprinkled a little Akamai magic and we had an Akamai health check which would automatically divert traffic to one API or the other based on the health check. By the time this was fully functional there was not a single moment in time that our new platform was not able to accept donations.

Testing the new platform

When all the infrastructure was complete we built an identical page on the new platform and compared it to the old platform. We were pretty blown away with the results. We used webpagetest.org to compare the performance between the two and Optimizely to test the conversion rate difference. We made the new platform 60% faster and this resulted in a 14% increase in donation conversions. In the screenshot below, we compared the time-to-paint between the two platforms on IE8 (the new platform is on top).

After we saw those results we launched the platform on contribute.barackobama.com and it quickly became the source of most of the Digital team's fundraising. If you were browsing the site and clicked donate, donated from Facebook or Twitter or if you received a fundraising email from the campaign you probably landed on contribute.barackobama.com.

Once we had this platform in production we used Optimizely to execute about 240 a/b tests to optimize the design/interaction of the donation pages for better conversion rates. By the end of the campaign our 240 a/b tests lifted the donation conversion rate by 49%! Here is a comparison of what we started with and what we ended with (click for high res).

Looking back

Now that the campaign is over I've had some time to look back on the success of this platform and I can say with 100% certainty that this is the best development environment I have ever worked on. There are a lot of incredible numbers above on how we increased conversions with a/b testing and performance improvements, but I think one of the biggest accomplishments with this platform is the ROI it provided our entire team. By using Jekyll we managed to avoid the complexity that comes with most CMS (databases, server configuration) and instead focus on things like optimizing the UI and providing a better user experience. To work in this environment the most a frontend engineer had to learn was the Liquid template language that Jekyll uses and boy is that simple. We didn't have to work with Devops to deploy because all we had to do was overwrite files on S3 and invalidate a URL on our CDN. There is a lot to be said about simplicity.

If you haven't already, I suggest you go take a look at Jekyll. It's not perfect for every project, but when it makes sense it will make your life so much easier (and faster!).

What's the best part though? When we wake up January 21st, 2013, Barack Obama will still be President of the United States of America. Cheers!