BigDoor on Twitter BigDoor on Facebook Google+ Subscribe to the BigDoor blog feed

Enter your email address

Delivered by FeedBurner

BigDoor gamification in action!

Archives

Categories

Items

Archive | API

BigDoor’s Jeff Malek Talks Databases and Horizontal Scaling

September 18, 2012 by

When talking to people about BigDoor, we often get asked about our backend database systems. Potential clients want to know whether or not our system can handle their traffic (yes, it can) and other start-ups want to know how we scaled to handle the high traffic levels of our awesome clients. We thought it would be useful to give a little bit more information about our system as well as share some of the things we learned in the process. There is no better expert in this topic than our CTO/Co-founder Jeff Malek. He took a break from working his daily magic to give some perspective and advice. 

A friend was recently asking about our backend database systems.  BigDoor’s  systems are able to successfully handle high-volume transactional traffic through our API coming from various customers, having vastly different spiking patterns,  including traffic from a site that’s in the top-100 list for highest traffic on the net.   Don’t get me wrong; I don’t want to sound overly impressed with what our little team has been able to accomplish, we’re not perfect by any means and we’re not talking about Google or FaceBook traffic levels.  But serving requests to over one million unique users in an hour, and doing 50K database queries per second isn’t trivial, either.

I responded to my friend along the following lines:

  1. If you’re going with an RDBMS, MySQL is the right, best choice in my opinion.  It’s worked very well for us over the years.
  2. Since you’re going the standard SQL route:
    1. If your database is expected to grow in step with traffic, and you’re thinking about sharding early – kudos.  You’re likely going to have to do it, sooner or later.
      1. Sooner vs. later if you’re in the cloud and running under its performance constraints.
      2. Do it out of the gate, if you have time, after you’ve figured out how you’re going to do it (i.e. whether you’re going to leverage a tool, DYI, etc).
        1. In other words, if you have time, don’t “see how long you can survive, scaling vertically”.
          1. Sharding while running the race : not a fun transition to make.
      3. I realize what I’m saying is counter to popular thinking, which is “don’t shard unless you absolutely have to”.
        1.  Without the assumption that your data set is going to grow in step with your traffic, I’d be saying the same thing.
    2. Designing your schema and app layer for sharding, sharded on as few keys as possible, ideally just one, is not future-proofing, it’s a critical P0.
  3. Since you’re going to be sharding MySQL, your options are relatively limited last I checked.
    1. Ask for input from folks who have done it before.
    2. The other sharding options I started looking at over two years ago all had disallowing limitations, given our business model.
    3. At quick search-glance just now, it also does appear that dbshards is ruling this space at this point.
  4. So barring any other options I’m missing, your best options that I’m aware of:
    1. dbshards
      1. Definitions we/they use, to help clarify discussion  :
        1. global tables : tables that contain the same data on every shard, consistency managed by dbshards.
        2. shard : two (primary and secondary) or more hosts that house all global table data, plus any shard-specific data.
        3. shard tree : conceptually, the distribution of sharded data amongst nodes, based on one or more shard keys.
        4. reliable replication : dbshards-proprietary replication, more details on this below.
      2. pros
        1. The obvious : you’ll be able to do shard-count more reads and writes that you’d otherwise be able to do with a monolithic, non-sharded backend (approximately).
          1. Alternatively, with a single-primary read-write or write-only node, and multi-secondary read-only nodes you could scale reads to some degree.
            1. But be prepared to manage the complexities that come along with eventual read-consistency, including replication-lag instrumentation and discovery, beyond any user notifications around data not being up-to-date (if needed).
        2. It was built by folks who have only been thinking about sharding and its complexities, for many years
          1. who have plans on their roadmap to fill any gaps with their current product
            1. gaps that will start to appear quickly, to anyone trying to build their own sharding solution.
              1. In other words, do-it-yourself-ers will at some point be losing a race with CodeFutures to close the same gaps, while already trying to win the race against their market competitors.
        3. It’s in Java, vs. some other non-performant or obscure (syntactically or otherwise) language.
        4. It allows for multiple shard trees; if you want (or have to) trade in other benefits for sharding on more than one key, you can.
          1. Benefits of just sharding on one key include, amongst other things, knowing that if you have 16 shards, and one is unavailable, and the rest of the cluster is available, 1/16th of your data is unavailable.
            1. With more than one shard tree, good luck doing that kind of math.
        5. It provides a solution for the auto-increment or “I need unique key IDs” problem.
        6. It provides a solution for the “I need connection pooling that’s balanced to shard and node count” problem.
        7. It provides a solution for the “I want an algorithm for balancing shard reads and writes”.
          1. Additionally, “I want the shard key to be based on a column I’m populating with the concatenated result of two other string keys”.
        8. It has a distributed-agent architecture, vs. being deeply embedded (e.g. there are free-standing data streaming agents, replication agents, etc instead of MySQL plugins, code modules, etc ).
          1. Provides future-proofing, scaleability and plug-ability.
          2. Easier to manage than other design approaches.
        9. Streaming agents allow you to plug into the update/insert stream, and do what you like with changes to data.
          1. We use this to stream data into Redis, amongst other things.  Redis has worked out very well for us thus far, by the way.
          2. Other dbshards customers use this to replicate to other DBMS engines, managed by dbShards or not, such as a column store like MonetDb, InfoBright, even a single standalone MySQL server if it can handle the load.
        10. It supports consistent writes to global tables; when a write is done to a global table, its guaranteed to have been done on all global tables.
        11. It doesn’t rely on MySQL’s replication and its shortcomings, but rather on its own robust, low-maintenance and flexible replication model.
        12. Its command-line console provides a lot of functionality you’d rather not have to build.
          1. Allows you to run queries against the shard cluster, like you were at the MySQL command line.
          2. Soon they’re releasing a new plug-compatible version of the open source MyOSP driver, so we’ll be able to use the same mysql command line to access both dbShards and non-dbShards managed MySQL databases.
        13. Its web console provides a lot of functionality you’d rather not have to build.
          1. Agent management and reporting, including replication statistics.
          2. Displays warning, error, diagnostic information, and graphs query counts with types.
          3. Done via the “dbsmanage” host, which provides centralized shard node management as well.
        14. It’s designed with HA in mind.
          1. Each shard is two (or optionally more, I think) nodes.  We put all primary nodes in one AWS availability zone, secondaries in a different one, for protection against zone outages.
          2. Write consistency to two nodes; in other words DB transactions only complete after disk writes have completed on both nodes.  Secondary writes only require file-system (vs. MySQL) disk writes.
          3. Managed backups with configurable intervals; MySQL EC2/EBS backups aren’t trivial.
          4. Web-console based fail-over from primary to secondary; this is very helpful, particularly for maintenance purposes.
        15. Proven to work well in production, by us and others.
          1. We’ve performed 100K queries per second in load-testing, on AWS/EC2, using m1.xlarge instances.
        16. Designed with the cloud and AWS in mind, which was a great fit for us since we’re 100% in AWS.
        17. “dbsmanage” host
        18. Drivers included, of course.
          1. In addition to MyOSP, they have JDBC, PQOSP (native Postgres), ADO OSP (for .NET), and soon ODBC.
        19. Go-fish queries allow you to write standard SQL against sharded data
          1. e.g. sharded on user.id : SELECT * FROM user where FirstName=’Foo’;
            1. will return all results from all shards performing automatic aggregation
              1. sorting using a streaming map-reduce method
        20. Relatively easy to implement and go live with; took us about six weeks of hard work, deadline-looming.
        21. It’s the market-leading product, from what I can tell.
          1. 5 of the Top 50 Facebook apps in the world run dbShards.
        22. It supports sharding RDBMSs besides MySQL, including Postgres, DB2, SQL Server, MonetDb, others coming.
        23. Team : top-notch, jump-through-their-butts-for-you, good guys. 
        24. Ability to stream data to a highly performant BI backend.
      3. cons
        1. As you can see, some of these are on the pro list too, double-edged swords.
        2. Cost – it’s not free obviously, nor is it open source.
          1. Weigh the cost against market opportunity, and/or the additional headcount required to take a different approach.
        3. It’s in Java, vs. Python (snark).
        4. Doesn’t rely on MySQL replication, which has its annoyances but has been under development for a long time.
          1. Nor is there enough instrumentation around lag.  What’s needed is a programmatic way to find this out.
        5. Allows for multiple shard trees.
          1. I’m told many businesses need this as a P0, and that might be true, even for us.
          2. But I’d personally prefer to jump through fire in order to have a single shard tree, if at all possible.
            1. The complexities of multiple shard trees, particularly when it comes to HA, are too expensive to justify unless absolutely necessary, in my humble opinion.
        6. Better monitoring instrumentation is needed, ideally we’d have a programmatic way to determine various states and metrics.
        7. Command line console needs improvement, not all standard SQL is supported.
          1. That said, we’ve managed to get by with it, only occasionally using it for diagnostics.
        8. Can’t do SQL JOINs from between shard trees.  I’ve heard this is coming in a future release.
          1. This can be a real PITA, but it’s a relatively complex feature.
          2. Another reason not to have multiple shard trees, if you can avoid them.
        9. Go-fish queries are very expensive, and can slow performance to a halt, across the board.
          1. We’re currently testing a hot-fix that makes this much less severe.
          2. But slow queries can take down MySQL (e.g. thread starvation), sharding or no.
        10. HA limitations, gaps that are on their near-term roadmap, I think to be released this year:
          1. No support for eventually-consistent writes to global tables means all primaries must be available for global writes.
            1. Async, eventually consistent writes should be available as a feature in their next build, by early October.
          2. Fail-over to secondaries or back to primaries can only happen if both nodes are responding.
            1. in other words, you can’t say via the console:
              1. ‘ignore the unresponsive primary, go ahead and use the secondary’
            2. or:
              1. ‘stand me up a new EC2 instance for a secondary, in this zone/region, sync it with the existing primary, and go back into production with it’
          3. Reliable replication currently requires two nodes to be available.
            1. In other words, if a single host goes down, writes for its shard are disallowed.
              1. In the latest versions, there’s a configuration “switch” that allows for failing-down to primary
                1. But not fail down to secondary.  This is expected in an early Q4 2012 version release.
          4. dbsmanage host must be available.
            1. dbshards can run without it or a bit, but stats/alerts will be unavailable for that period.
          5. Shard 1 must be available for new auto-increment batch requests.
          6. go-fish queries depend on all primaries (or maybe all secondaries via configuration, but not some mix of the two as far as I’m aware) to be available
    2. DYI
      1. I can rattle off the names of a number of companies who have done this, and it took many months longer than our deployment of dbshards (about six weeks, largely due to the schema being largely ready for it).
      2. Given a lot of time to do it, appeals to me even now, but I still wouldn’t go this route, given the pros/cons above.
    3. The latest release of MySQL Cluster may be an option for you, it wasn’t for us back with MySQL 5.0, and not likely now, due to its limitations (e.g. no InnoDB).
    4. AWS RDS was an option for us from the onset, and I chose to manage our own instances running MySQL, before deciding how we’d shard.
      1. For the following reasons:
          2. >I wanted ownership/control around the replication stream, which RDS doesn’t allow for (last I looked) for things like:
          1. BI/reporting tools that don’t require queries to be run against secondary hosts.
            1. This hasn’t panned out as planned, but could still be implemented, and I’m happy we have this option, hope to get to it sometime soon.
          2. Asynchronous post-transaction data processing.
            1. This has worked out very well, particularly with dbshards, which allows you to build streaming plugins and do whatever you want when data changes, with that data.
              1. Event-driven model.
              2. Better for us than doing it at the app layer, which would increase latencies to our API.
        1. Concern that the critical foundational knobs and levers would be out of our reach.
          1. Can’t say for sure, but this has likely been a good choice for our particular use-case; without question we’ve been able to see and pull levers that we otherwise wouldn’t have been able to, in some cases saving our bacon.
        2. Their uptime SLAs, which hinted at unacceptable downtime for our use-case.
          1. Perhaps the biggest win on the decision not to use RDS; they’ve had a lot of down-time with this service.
        3. Ability to run tools, like mk-archiver (which we use extensively for data store size management), on a regular basis without a hitch.  Not 100% sure, but I don’t think you can do this with RDS.
        4. CloudWatch metrics/graphing is a very bad experience, and want/need better operational insights to what it provides.  Very glad we don’t depend on CW for this.
      2. All of these reasons have come at considerable cost to us as well, of course.
        1. Besides the obvious host management cycles, we have to manage :
          1. MySQL configurations, that have to map to instance sizes.
          2. Optimization and tuning of the configurations, poor-performance root-cause analysis,
          3. MySQL patches/upgrades.
          4. maybe more of the backup process than we’d like to.
          5. maybe more HA requirements than we’d like to; although I’m glad we have more control over this, per my earlier comment regarding downtime.
          6. maybe more of the storage capacity management than we’d like to.
        2. DBA headcount costs.
          1. We’ve gone through two very expensive and hard-to-find folks on this front, plus costly and often not-helpful, cycle-costing out-sourced DBA expertise.
          2. Currently getting by with a couple of experienced engineers in-house and support from CodeFutures as-needed.
      3. As I’ve seen numerous times in the past, AWS ends up building in features that fill gaps that we’ve either developed solutions for, or worked around.
        1. So if some of the RDS limitations can be worked-around, there’s a good chance that the gaps will be filled by AWS in the future.
        2. But it’s doubtful they’ll support sharding any time soon, there’s too much design and application-layer inter-dependencies involved.  Maybe I’m wrong, that’s just my humble opinion.


Posted in: API, Blog, Development, Improvements, Startups, Technology

Catching the “head-slappers” early

October 10, 2011 by

Software usability evaluation isn’t at all a new concept, nor is it exclusively the realm of bespectacled folks in lab coats, deftly avoiding eye contact behind one-way mirrors. Far from it – “discount” usability testing methods and tools have democratized the process nearly as much as cloud computing has done the same thing to scaling a business’s online infrastructure. (User interface evaluation is even being crowdsourced by companies like UTest.). But your fast-paced market probably demands that you be incredibly nimble and “launch first, ask questions later” – and hope your analytics, some A/B variant testing framework, and direct feedback optimize an initial design. But if you don’t take time to show really early, rough sketch stuff to potential users, “head slappers” – painfully obvious mistakes visible only once you stop protecting your early design from exposure to its intended audience – will lie in wait.

We recently tested portions of a major design update to our tools for publishers who design and deploy BigDoor’s gamification solutions to their sites. The goal? We wanted to learn if our introductory “onboarding” process demonstrated this new experience effectively enough to potential publishers to persuade them to sign up.

Findings? Nope. It did not.

But that’s really good news. Because we had several potential publishers attempt to complete this sign up process and share their frustrations/confusion, we were able to:

  • Remove jargon and update terminology that explained little
  • Identify a point where adding a couple of previews and simple callouts to explain “this does that,” and “this works like that,” makes all the difference
  • Learn that once publishers did find their way through it was fairly easy to understand how to set up the site features they wanted to use

This post should also serve as a shameless plug for Silverback, a stylish, clever tool for video recording a participant’s face and the screen they’re working on, picture-in-picture style, using a Mac laptop’s standard video camera. The impact of the results above was much easier to demonstrate to the entire company with some key video highlights, and all the raw footage was right there on my laptop to work with the moment we wrapped up testing. Hugely useful.

Some imposter dramatizes a dialog box

The barriers to quick, in-house (and crowdsourced) methods for finding out how many head-slappers your early UI designs are lower than ever before. Huge ROI for a relatively tiny investment of time and effort awaits teams of any size.

- Matt Shobe, BigDoor Chief Design Officer & early stage mistake-maker

Posted in: API, Blog, Development, Improvements, Startups, Technology, UI, UX

Two Pizza Teams Yield Better #Gamification

October 6, 2011 by

Most studies have consistently shown that the optimal size of a work team is around 5-7 people. Many of us Amazon.com alumni used to call this concept the “two-pizza teams“–if it takes more than two pizzas to feed your team, then the team is too large. “Two pizza teams” have been around for a while now, well before “Agile” and “Scrum” entered the Product Development vernacular.

At BigDoor, we’ve been growing so fast that it was taking about 5 pizzas to feed our growing dev team. Plans to split into smaller teams began to get more serious. Finally last week, with the addition of our new awesome Product Managers Fayez and Scott, we re-organized into three scrum teams. Each team now has 6-7 members and the results have been immediate.

Here are some things we saw in the new teams’ first week:
• Planning meetings took less than an hour
• Team members have been more vocal and participating more in meetings
• Team members are much more aware of the status of the sprint and if co-workers need help
• New teams had successful sprints
• Sprint stories fall much more within a theme and are less randomized, resulting in a more focused team

As we continue to grow our organization it’s really exciting to take knowledge that worked very well in the past and apply it to our team.  Now, what’s for lunch!?

Posted in: API, Blog, Development

Add Some ESP to your App Search

September 28, 2011 by

Today our friends at AppStoreHQ launched a new product that aims to help people find apps they love with the promise to “Never Install a sh*tty app again!” The 100% rearchitected version of AppESP is now available.

The guys at AppStoreHQ are using BigDoor behind the scenes to connect with Facebook, invite friends to use AppESP as well as provide feedback on user actions, including rating and sharing apps with friends. Additionally they designed a custom set of badges and a virtual economy, “AppBucks” that users can accumulate as they interact with the app. Cheers to Scott and team!


Posted in: API, Blog, Startups

BigDoor Is Hiring

June 28, 2011 by

We’re pleased to announce that BigDoor is hiring! Are you an unconventional Black Box Tester? Can you use your reporting and analytic skills as a rockstar Business Intelligence Analyst? Are you a creative and strong Web Designer with web UI skills? A killer Content Manager? BigDoor is looking for YOU!

We’re a Seattle-based startup looking for individuals to help us create the next big killer company. Our platform helps digital publishers create loyalty programs and game mechanics into their site or application through points, badges, levels, virtual currency and virtual goods as well as building economies for our partners. We’re developing a game mechanics and virtual economy ecosystem based around our RESTful API to interact with our MySQL database for clients and we perform high transaction volumes. Our customers include digital publishers, content providers, app developers, goods vendors, and advertisers. Our platform is extensible in order to allow a wide variety of apps to be built on top of it. Sound interesting? Send your details to HR@bigdoor.com.

Posted in: API, BigDoor news, Blog, Development, Startups, Technology, UI

Gamification of Major League Baseball

May 10, 2011 by

Today we are very proud to announce a partnership with MLB Advanced Media (MLBAM), the interactive media and Internet company of Major League Baseball. Major League Baseball! Fans visiting MLB.com’s Gameday section can earn and collect unique player badges that provide prestige, personalization and recognition.

Our CEO Keith Smith put it best, “It’s incredible validation for us that MLBAM chose BigDoor as its gamification partner. This is another critical milestone for us as we endeavor to build a loyalty and rewards program that will increase engagement and revenue for our partners.” MLB.com’s CTO, Joe Choti said,“Integrating a badging rewards program for fans as they consume content on MLB.com was a priority for the 2011 season. We’re pleased to deliver this enhanced level of fan engagement through our partnership with BigDoor and its powerful and flexible gamification solution.”

What’s even more exciting is we’ll be working with MLBAM in the future and will continue implementing additional opportunities for fans to earn badges and engage on their site. “Play Ball!”

Posted in: API, Badges, BigDoor news, Blog, Gamification

Leveling Up Our Front-End Development

April 29, 2011 by

Hello World!

My name is Collin. I’ve been at BigDoor from the beginning and have developed many iterations of our Front-End library. I have failed and have been successful. In all cases, the goal is to make something easy, fun and awesome to use. In dev-land this translates to quick iterations, learn from the issues and make it better. That being said, I’m very happy with our recent release of our JavaScript library. There are definitely warts and improvements to be made but I firmly believe we finally have a library to build from.

Engineering Goals
Our Front-End libraries have both short and long term goals. Usually our short term goals are feature driven while our long term goals are for long term adoption. The following long term goals have been driving our development from the beginning.

  1. Must be generic so that a developer can come in and start extending or adding features as they see fit
  2. Support the non-developer community by designing a clean API to support programmatic configuration

In our previous libraries we were more concerned with our short term goals by adding features and iterating over those features to get them right. Those goals still exist from a design perspective but from the engineering perspective we needed to shift how we were developing in order to support these two long term goals.

Past Design
Previously we developed ‘modules’ which provided an interface for a given feature. These modules would provide an API for the feature and handle remote and local communication. We also incorporated jQuery plugins. We used 3rd party plugins and wrote our own to define what feature a node would provide.

If we continued this way, we could never meet our goals. We were only developing the Logic and UI layers. We needed to shift from a scripted feature set to a full feature application with a clear separation of concerns.

Current Design
Before we started a recent custom implementation, we knew we had to provide better separation if we were going to be successful. We spent a few days drawing diagrams, researching best practices, deciding on how to leverage existing libraries and coming up with names for what we were trying to define.

Once we had flushed out our ideas we had to go back and provide some structure for how we could think and talk about it more publicly. We took the multitier architecture model and identified our layers as the following:

  • Communication
  • Data
  • Logic
  • Presentation
  • Configuration

When these were identified we only had a rough sketch of which classes belonged where but we had to start developing due to our impending deadline. However, this was the first time we had a clear separation of concerns and a shared language to work from and couldn’t wait to get started!

We now have the following architecture to work from in order to meet our short term goals as well as quickly and accurately iterate over our feature development:

  • Communication
    • Transport
    • API
    • BigDoor (inherits from API)
  • Data
    • Model
  • Logic
    • Authentication
    • Controller
    • Provider
  • Presentation
  • Configuration
    • Application

Future Design
It would be nice if I could predict the future and tell you what features and functionality we are working towards but I can’t. What I can say is that we are working hard to make this publicly available as soon as possible by reintegrating Facebook Like, Badges, etc., as well as prototyping new applications.

I’m super excited with this release and couldn’t be happier to be a part of this team. I can’t wait to see what we can come up with next!

Goodbye World!

–Collin Watson

Posted in: API, Blog, Development, Success, Technology

BigDoor Announces The Engagement Economy At Ad: Tech

April 11, 2011 by

Today our Co-Founder and CEO Keith Smith and our Director of Monetization and Implementation Tommy Lee are attending Ad:Tech San Francisco. We’re really excited to announce the launch of the BigDoor Engagement Economy with Cost Per Quest! The BigDoor Engagement Economy is a new way for sites to engage their users while monetizing their content. One of the initial pieces is Cost Per Quest, an entirely new, performance based, ad format meant to reward end users for their time and attention while engaging deeply with online brands. Quests are a critical component of BigDoor’s Engagement Economy and are sold to advertisers on a Cost Per Quest (CPQ) basis.

The BigDoor Engagement Economy is currently in private beta mode. Last week, in partnership with SpectrumDNA Quests launched with UGO Entertainment. The incredible team at SpectrumDNA worked their magic and has truly created a gamified experience that’s intrinsically a social loyalty program incorporating interaction with news and information, as well as a rewards system that is original, native and meaningful.

We talk to websites all the time and get the question about our rumored “hidden fees.” We truly believe gamification should be a profit-center for web publishers and app developers, not a cost-center so we offer our technology for free. However, in order to provide publishers a free platform as well as enable them to make money by using gamification, we realize we need a solution that works not only for publishers and end-users, but also for advertisers as well. We think that any solution that gives advertisers traffic, can make publishers money, and reward users can be an Epic Win! The BigDoor Engagement Economy will roll out to a broader network of publishers by Summer 2011.

Online website owners interested in learning more about our Engagement Economy and Cost Per Quest advertising pilot program can contact us. Additionally, those attending San Francisco’s ad:tech 2011 are encouraged to meet with Keith Smith (keith@bigdoor.com; @ChiefDoorman) and Tommy Lee (tommy@bigdoor.com; @pikopoki) during the event, April 11-13, 2011.

Posted in: Advertising, API, BigDoor news, Blog, Conferences, Gamification, Monetization, Partners, Technology, User engagement

Slaying Database Monsters

March 23, 2011 by

Recently we were happy to post some shout outs for our dev team, who executed a significant upgrade to our systems with minimal disruption. A flawless transition to keep things performing at the levels we expect. But how does the API usually perform? We wanted to share some stats regarding how quickly our API typically responds. Below are some external, minute-by-minute checks of our API from a diverse set of US locations. The following was taken over the course of a 24-hour period:

Average GET requests: Under 175 milliseconds
Average Leaderboard requests: Under 250 milliseconds
Average transaction POST: Under 400 milliseconds

By way of comparison, Facebook’s average API response time for us over the course of the last month has been 14,249 milliseconds.

The key takeaway here is: “Our tech boys rock” but in more technical terms: “We slayed the evil database monster with some crazy ass ops wizardry.”

Posted in: API, Blog, Improvements, Technology

Level Up For 30 Minutes With Brad Feld

March 7, 2011 by

We wanted to let everyone know about this amazingly cool experiment Brad Feld is currently testing on his site. For those of you who don’t already know Brad, he’s the managing director at Foundry Group who invests in software and Internet companies (including Zynga). He was recently named the
“Most Respected Venture Capitalist”and he’s also one of our investors. For the next 30 days Brad will use the BigDoor MiniBar on his site to offer 30 minutes of his time as a reward for anyone who wants to exchange 10,000 Feld Gelt for the opportunity to speak with him. With the help of BigDoor’s MiniBar (white-labeled on Brad’s site), users have five easy options to earn Feld Gelt, including Check-in when visiting Brad’s site; Adding a comment to any blog post on the site; Sharing or Tweeting posts; ‘Like’ any post from the MiniBar and most importantly, the best way to earn Feld Gelt is when users click on links you have shared or Like links in your Facebook feed. Users can get started working their way up the Leaderboard for a chance at 30 minutes with Brad!

Update: Brad’s deal was so popular that it took about eight minutes to sell out! Brad mentioned there might be a new deal and we’ll update with any new details!

Posted in: API, Blog, Gamification, Gaming, Loyalty, Monetization, Startups, Technology, Virtual Currency