In this post, we wanted to give you a bit of insight into our recently completed Kickstarter campaign. We hope that this information is illustrative, and that it offers a view of our particular encounter with the 'Kickstarter aftermath.' We also hope you find our logistics useful for handling similar projects, either through Kickstarter or any other crowdfunding site!

As some of you know, Kickstarter gives project creators access to a rather nice 'dashboard' (administrative front-end). We found this tool extremely useful for monitoring the campaign's progress in real-time. Once the campaign had ended, however, we were split between using Kickstarter's tools versus our own scripts to interact with the backers' data.

As our project was successfully funded, we were able to access the backers' information through the project dashboard. This interface gave us the option of sending out a survey to our backers in which we could gather any info we deemed necessary (the most crucial: preferred shipping address). In addition, we were able to download a group of .csv files with the backers' basic contact information (name, email, reward selection, payment status). These files were conveniently separated according to reward level. After some debate, we decided not to send out a survey, but rather build a very simple Web Application to handle our backers' data.

The first step towards constructing this online platform was to port the data out of the .csv files, and into our own database (MySQL) servers. To do so, we wrote a parsing script in Ruby. Once the data were ported we needed to double-check that the processing worked correctly, and so, we generated a timeseries plot of the number of backers and pledge amounts ensuring that the data matched the actual results of the campaign (double-checked that strings containing commas, e.g., "$1,250.00" were read correctly).

The results showed $68,000 pledged and 517 backers (hooray!), which meant that our scripts had worked correctly. As a next step, we wanted to know how many successful payments we had received (some Non-U.S. cards were not coming through), in order to determine how many rewards needed to be ordered and shipped:

While inspecting the payment processed/failed data, we noticed that the funds in our Amazon Payments (which is in charge of processing credit cards for Kickstarter) account differed from the number obtained by adding up all the transactions marked as "successful" by Kickstarter. This was unsurprising as it is only natural for there to be some asynchrony between Kickstarter's and Amazon Payments' servers. This presented a perfect opportunity to explore further the post-campaign data.

As it turns out, Amazon Payments also allows payment data to be exported in a comma- or tab-delimited format. A challenge, however, was that there wasn't a straight-forward way to correlate the Kickstarter data with those on Amazon Payments. The only (almost) unique piece of information about a backer is her name, but because Amazon Payments and Kickstarter accounts are separate, there was no guarantee that the name on both sites was identical.

After about a week, the two data sources converged as can be seen from counting the number of failed (16) and completed transactions (501). Our scripts keep a close eye on duplicate entries (common for the failed transactions) and other anomalies in the data; honestly, I can see how this would become a bit painful once the number of backers exceed a few thousand.

The next steps for us included notifying the 16 backers about their payment status—a step we also automated with a simple Ruby script (using SendMail). And also, calculating what type of reward(s) the payment covered. We'll show you how this was done, and the steps that followed on Part II of this story... stay tuned!