As I write this, 50MM monthly active users are engaging with the BigDoor platform across our publisher sites. For a company that started with the simple idea of making online experiences more fun and engaging, knowing that our platform reaches that many people is astounding. As we launch more and more gamified loyalty programs with larger audiences, the importance of our platform’s performance and scalability has increased as well. To stay ahead of our publisher’s needs, we’ve been making major updates to our tech stack, ensuring that our platform comfortably supports the 20MM user actions per day and 1.5MM users who access BigDoor programs during peak hours.
Knowing that our platform integrates with the websites of some of the most influential brands across multiple industries might keep some of us up at night, but it also drives us to constantly push the envelope in terms of what our clients can expect in terms of features and performance.
In the past six months, we implemented significant performance improvements resulting in an average API latency of less than 250ms.
Visitors to any of our publisher’s sites continue to consistently and reliably enjoy our end-user experience. We’ve met 100% of our SLA’s high availability requirements this year, exceeding our 99.9% uptime goals for every month in Q1.
But, we are overachievers and we aren’t done yet.
On Wednesday night, we notified our publishers and Twitter followers that the BigDoor platform would be temporarily unavailable for an hour of maintenance. The maintenance window was required for the deployment of a new version of our backend database sharding framework, which will allow us to support even higher availability, increased responsiveness and more scaling capacity for our ever-increasing audience sizes.
The updates to our backend systems have only been in effect for a short time, but we are pleased with the results they are showing already.
In response to a growing number of current and future partner’s inquiries and suggestions, we are very excited to announce BigDoor’s newest platform feature: Internationalization.
Working with brands that achieve global reach, we acknowledge the need for rewards and loyalty programs that engage customers internationally and across languages. Unlike other vendors in the space, touting their “global” or “world leading” platforms with English-only language support, BigDoor has always prided ourselves in making our platform available in any language, but we weren’t satisfied with the complex translation progress that slowed down our typical implementation process. We decided to launch internationalization to enable brands around the world to easily implement a BigDoor Gamified Loyalty Program in any language (or combination of languages).
With internationalization the BigDoor user interface will reflect browser-specified languages allowing visitors to seamlessly interact with a brand’s loyalty program, no matter what language version of the site they are on. Badges, quests, rewards and achievements will display in the browser-specified language throughout a customer’s session. The feature will also cover BigDoor powered redemption emails, ensuring that the entire BigDoor experience is available to customers, no matter what language they are using.
BigDoor publishers will be able to add language configurations to current loyalty programs, without affecting the existing experience. The internationalization feature will also allow publishers to break down existing analytics by language, giving even deeper access to valuable customer data and insights.
To learn more about BigDoor’s internationalization feature, or to talk with a BigDoor Loyalty Expert, please contact us at: Info@BigDoor.com.
The typical visitor to the BigDoor office, often comments on one of two things: The eerie silence or their inability to distinguish between developers, executives and anyone else. It’s true, the BigDoor office is one big buzzing space of activity, with every employee moving around from desk to desk, or tapping away at their keyboard furiously with a look of concentration. We all wear T-shirts, drink copious amounts of diet coke or red bull and argue over who gets the conference room, the comfy couches or the bar stools in the kitchen for their meeting. That fluidity of employees is one of the truly unique things about working for a start-up and we continue to see employees grow and learn in truly awe-inspiring ways. CTO and Co-Founder Jeff Malek took some time to talk about how BigDoor is organizationally structured and what that means for employees who work here.
One of our rockstars here at the company had questions about our organizational structure, trying to determine who was in each of our departments. He’d listed what he thought those department “labels” were (Bizdev, Development, etc) and who he thought belonged in each of those branches of our company. He’s recently been asked to improve our process and communication during customer on-boarding, largely because he’s very detail-oriented, organized, and process-driven. To get this done, he’ll need to be interfaced with other folks in the company that he hasn’t before, so asking about who does what and where in the company is totally understandable, expected and part of his diligence.
This approach and thinking around a company’s organizational structure is age-old, and for good reason. But it’s Org v1.0.
It’s human nature to try and departmentalize, categorize, bucket, silo, label, simplify or otherwise narrow down anything in life. In this case the context is “who does what and in what group”, an attempt to establish who falls into what departments at our company, and there were two (somewhat) flawed assumptions:
we have departments that contain people
person x belongs in department y
What we actually strive to have at BigDoor and will continue to work towards as long as we possibly can, is a team of people who wear one or more hats, and we call those hats “roles”. The internet has taught us that tagging is a much more flexible, powerful and realistic way to associate attributes with anything, more so than creating hierarchical taxonomies. For the database-minded, it’s the difference between a many-to-many entity relationship and a one-to-one.
A tag can be associated with many different things, and a thing can be associated with many different tags. In the same way, engineers who operate in many different roles (e.g. production developer, test developer, project manager, UAT tester, etc) grant both the company and themselves much more power and benefit than if we were to create a Quality Assurance department and put specific people in it, and only in it.
Once you create departments and put people in them, there’s no going back. The company is limited to asking Joe in the Foo department to fulfill Foo tasks. All or most Foo tasks go into the Foo department, agility and flexibility go out the window, and a manager ends up with being “accountable” for department Foo and tasks of type Foo. Department Foo is one tier on the multi-waterfall path toward the “done” that never gets done, and it will wind up being the managers fault, so they start getting cycled in and out of the company, along with the teams. Barf. I want to fight the Foo just thinking about it.
Once someone starts thinking in terms of belonging to the Foo department, it’s totally natural to become closed off to doing anything but Foo work.
Now, if I don’t live in a department, but I’m on the team that is supposed to take care of end-users, that’s a different way of looking at things. My team doesn’t “do QA” or “do Product Management”, it takes care of customers, which is what we all should be thinking about as a P0 (highest priority). That’s a great reason to have a group of people working together.
So we have a Player team, “player” being a euphemism for end-users. The purpose of that team is to meet the needs of our end-user customers. The Player team is cross-functional, it does it all: it determines what the next highest priority is for the customer, works out how to meet their needs, builds it, tests it and deploys it. Everyone required to meet the needs of the customer is on the team, whether it be someone to fix a problem with our build system, stand up a new server, design a new graphical interface, deploy an API performance optimization, or change the backend database schema. The team pushes to continuously improve and learn, on all fronts.
This non-departmental approach raises valid concerns for folks, around topics like accountability, ownership (“if everyone owns it, no one owns it”), and scaleability. But clearly, even without a Project Management department, someone can still own a publisher on-boarding project management role, for example. More about scaleability with regard to the organization here.
It’s true there are tradeoffs to this approach, but it’s better for the company and for our employees to leverage the multiple skills and talents buried deep throughout our awesome team.
All that said, we all can’t do everything, and it’s necessary to create categories at least at a high level for various reasons. It’s also true that some external customers may be more impressed with us if we talk about our QA Department, while others may be more drawn in by an agile approach to org structure.
So ultimately, I encouraged the engineer to avoid thinking along the lines of departments and silos as much as possible, and just question whether certain terms or departmentalizations are needed to begin with. Focus more on identifying the individuals you’ll be thinking of as stakeholders, and get to know what they’re specializing in.
Titles are another story altogether, and at BigDoor they’re much more valued and needed outside than within the company. We’re all engineers and salespeople to varying degrees, having additional strengths and attributes.
Strengths, attributes, tags, descriptors…too bad there wasn’t some way to quickly visualize these, and convey someone’s strengths and achievements better than with just a “title”. Like a badge. Kidding – of course we do that. Here are some of the badges that we put on the back of our engineer’s business cards, each of which are only attainable when specific criteria are met:
Full-stack employees are like gold, and we try hard to cultivate them here. But it takes a rare breed, someone with fire, adaptability, agility, ability, a clear communicator. If you think you’ve got what it takes, and all of this sounds fun to you, please get in touch with me directly – we’re always looking for good people to join our team. We don’t just look for people when we have an opening, that’s very “recruitment v1.0″.
(title is me tipping my hat with much respect to the Foo Fighters, the best makers of music, ever).
Happy Friday! We scoured the internet over the last week to bring you the latest gamification, customer loyalty and rewards program news. There were a lot of interesting new game mechanics applications this week, so be sure to check out some of the cool ways different industries are using gamification!
How SuMo’s gamification helps firms wrestle with green issuesZDNet 9/27/2012 Gamification and green technology are nothing new, but a new app from CloudApps unveiled at the Salesforce Dreamforce event took the next step in green technology. SuMo is designed to encourage employees to hit corporate sustainability and social responsibility goals and it does this by using gamification elements. The app allows companies to measure their goals and success in a way that previously hasn’t been easy for the corporate environment. Additionally, with the apps game mechanics, it encourages employees to engage in company goals by changing their workplace behaviors.
Gamification of security and video surveillance…Info4Security 9/27/2012 If anyone has ever used software that accompanies security or video surveillance technology, you might understand where this article is coming from. Notoriously hard to use and frustrating, some security system companies are turning to UX experts and gamification to help improve the user experience of their software systems. We’ve seen gamification elements used in software before to help guide new users through training and this seems like an interesting application to help alleviate the challenges these companies are facing.
Can Kia’s gamification change the way we drive our cars?The Next Web 9/22/2012 Quite a few auto-makers are turning to gamification to try to alter driver behavior towards a more sustainable way of driving. Toyota and Nissan have both done this with their hybrid cars, and even American car company Chevrolet has included some gamification elements in their Volt electric car. Now Kia is jumping on the trend with their new Optima hybrid. This is a great dissection of the Kia system, with photos and videos to show how the system operates and what behaviors it attempts to discourage.
NASA, Angry Birds and the Question of Gamification Government Executive 9/20/2012 While we don’t really think this qualifies as gamification, we do think it is pretty cool to see a social game like Angry Birds teaming up with a government entity like NASA. We are seeing more and more that the government is willing to embrace games and game mechanics to improve programs (anyone remember America’s Army?) and this seems like a great step in the right direction. Plus, does anyone dislike the Mars rover?
The Sticky Factor: Social Gaming Drives Brand Engagement Over TV AdsAdotas 9/24/2012 Online brands are not the only ones who are focusing on brand engagement. TV shows are also looking for ways to engage their audiences through mobile apps to connect the visual experience with the mobile phones most users are holding while they watch. This article highlights quite a few different companies that are focused on customer retention and engagement for brands and the way they are working with different industries to combat these issues.
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:
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.
Since you’re going the standard SQL route:
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.
Sooner vs. later if you’re in the cloud and running under its performance constraints.
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).
In other words, if you have time, don’t “see how long you can survive, scaling vertically”.
Sharding while running the race : not a fun transition to make.
I realize what I’m saying is counter to popular thinking, which is “don’t shard unless you absolutely have to”.
Without the assumption that your data set is going to grow in step with your traffic, I’d be saying the same thing.
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.
Since you’re going to be sharding MySQL, your options are relatively limited last I checked.
Ask for input from folks who have done it before.
The other sharding options I started looking at over two years ago all had disallowing limitations, given our business model.
At quick search-glance just now, it also does appear that dbshards is ruling this space at this point.
So barring any other options I’m missing, your best options that I’m aware of:
dbshards
Definitions we/they use, to help clarify discussion :
global tables : tables that contain the same data on every shard, consistency managed by dbshards.
shard : two (primary and secondary) or more hosts that house all global table data, plus any shard-specific data.
shard tree : conceptually, the distribution of sharded data amongst nodes, based on one or more shard keys.
reliable replication : dbshards-proprietary replication, more details on this below.
pros
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).
Alternatively, with a single-primary read-write or write-only node, and multi-secondary read-only nodes you could scale reads to some degree.
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).
It was built by folks who have only been thinking about sharding and its complexities, for many years
who have plans on their roadmap to fill any gaps with their current product
gaps that will start to appear quickly, to anyone trying to build their own sharding solution.
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.
It’s in Java, vs. some other non-performant or obscure (syntactically or otherwise) language.
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.
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.
With more than one shard tree, good luck doing that kind of math.
It provides a solution for the auto-increment or “I need unique key IDs” problem.
It provides a solution for the “I need connection pooling that’s balanced to shard and node count” problem.
It provides a solution for the “I want an algorithm for balancing shard reads and writes”.
Additionally, “I want the shard key to be based on a column I’m populating with the concatenated result of two other string keys”.
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 ).
Provides future-proofing, scaleability and plug-ability.
Easier to manage than other design approaches.
Streaming agents allow you to plug into the update/insert stream, and do what you like with changes to data.
We use this to stream data into Redis, amongst other things. Redis has worked out very well for us thus far, by the way.
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.
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.
It doesn’t rely on MySQL’s replication and its shortcomings, but rather on its own robust, low-maintenance and flexible replication model.
Its command-line console provides a lot of functionality you’d rather not have to build.
Allows you to run queries against the shard cluster, like you were at the MySQL command line.
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.
Its web console provides a lot of functionality you’d rather not have to build.
Agent management and reporting, including replication statistics.
Displays warning, error, diagnostic information, and graphs query counts with types.
Done via the “dbsmanage” host, which provides centralized shard node management as well.
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.
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.
Managed backups with configurable intervals; MySQL EC2/EBS backups aren’t trivial.
Web-console based fail-over from primary to secondary; this is very helpful, particularly for maintenance purposes.
Proven to work well in production, by us and others.
We’ve performed 100K queries per second in load-testing, on AWS/EC2, using m1.xlarge instances.
Designed with the cloud and AWS in mind, which was a great fit for us since we’re 100% in AWS.
“dbsmanage” host
Drivers included, of course.
In addition to MyOSP, they have JDBC, PQOSP (native Postgres), ADO OSP (for .NET), and soon ODBC.
Go-fish queries allow you to write standard SQL against sharded data
e.g. sharded on user.id : SELECT * FROM user where FirstName=’Foo’;
will return all results from all shards performing automatic aggregation
sorting using a streaming map-reduce method
Relatively easy to implement and go live with; took us about six weeks of hard work, deadline-looming.
It’s the market-leading product, from what I can tell.
5 of the Top 50 Facebook apps in the world run dbShards.
It supports sharding RDBMSs besides MySQL, including Postgres, DB2, SQL Server, MonetDb, others coming.
Team : top-notch, jump-through-their-butts-for-you, good guys.
Ability to stream data to a highly performant BI backend.
cons
As you can see, some of these are on the pro list too, double-edged swords.
Cost – it’s not free obviously, nor is it open source.
Weigh the cost against market opportunity, and/or the additional headcount required to take a different approach.
It’s in Java, vs. Python (snark).
Doesn’t rely on MySQL replication, which has its annoyances but has been under development for a long time.
Nor is there enough instrumentation around lag. What’s needed is a programmatic way to find this out.
Allows for multiple shard trees.
I’m told many businesses need this as a P0, and that might be true, even for us.
But I’d personally prefer to jump through fire in order to have a single shard tree, if at all possible.
The complexities of multiple shard trees, particularly when it comes to HA, are too expensive to justify unless absolutely necessary, in my humble opinion.
Better monitoring instrumentation is needed, ideally we’d have a programmatic way to determine various states and metrics.
Command line console needs improvement, not all standard SQL is supported.
That said, we’ve managed to get by with it, only occasionally using it for diagnostics.
Can’t do SQL JOINs from between shard trees. I’ve heard this is coming in a future release.
This can be a real PITA, but it’s a relatively complex feature.
Another reason not to have multiple shard trees, if you can avoid them.
Go-fish queries are very expensive, and can slow performance to a halt, across the board.
We’re currently testing a hot-fix that makes this much less severe.
But slow queries can take down MySQL (e.g. thread starvation), sharding or no.
HA limitations, gaps that are on their near-term roadmap, I think to be released this year:
No support for eventually-consistent writes to global tables means all primaries must be available for global writes.
Async, eventually consistent writes should be available as a feature in their next build, by early October.
Fail-over to secondaries or back to primaries can only happen if both nodes are responding.
in other words, you can’t say via the console:
‘ignore the unresponsive primary, go ahead and use the secondary’
or:
‘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’
Reliable replication currently requires two nodes to be available.
In other words, if a single host goes down, writes for its shard are disallowed.
In the latest versions, there’s a configuration “switch” that allows for failing-down to primary
But not fail down to secondary. This is expected in an early Q4 2012 version release.
dbsmanage host must be available.
dbshards can run without it or a bit, but stats/alerts will be unavailable for that period.
Shard 1 must be available for new auto-increment batch requests.
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
DYI
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).
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.
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).
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.
For the following reasons:
>I wanted ownership/control around the replication stream, which RDS doesn’t allow for (last I looked) for things like:
BI/reporting tools that don’t require queries to be run against secondary hosts.
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.
Asynchronous post-transaction data processing.
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.
Event-driven model.
Better for us than doing it at the app layer, which would increase latencies to our API.
Concern that the critical foundational knobs and levers would be out of our reach.
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.
Their uptime SLAs, which hinted at unacceptable downtime for our use-case.
Perhaps the biggest win on the decision not to use RDS; they’ve had a lot of down-time with this service.
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.
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.
All of these reasons have come at considerable cost to us as well, of course.
Besides the obvious host management cycles, we have to manage :
MySQL configurations, that have to map to instance sizes.
Optimization and tuning of the configurations, poor-performance root-cause analysis,
MySQL patches/upgrades.
maybe more of the backup process than we’d like to.
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.
maybe more of the storage capacity management than we’d like to.
DBA headcount costs.
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.
Currently getting by with a couple of experienced engineers in-house and support from CodeFutures as-needed.
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.
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.
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.
It’s Tuesday! Which means that in our attempt to make the not-quite hump day of the week a bit more fun, we headed over to Pinterest! We’ve been wandering through Pinterest keeping our eye on any interesting gamification, customer engagement or social media images we couldn’t resist sharing. Our pin-board has some great stuff this week including tips for customer engagement, understanding game mechanics and a cat couch (yeah, we know…unrelated). Head over to our Pinterest page to check out all the cool stuff we found.
We especially loved this graphic from Google’s “Power of the Internet” campaign. The sheer growth of the internet is pretty amazing!
If you are a frequent reader of mygamification.com you might have noticed that a few weeks ago we quietly updated the look of the BigDoor platform here on the site. Today, we want to proudly announce the newest version of BigDoor featuring a new look, better customization and updated user notifications. With both publishers and the end-user in mind, we’ve updated the BigDoor platform with more publisher features for easier and faster implementation as well as a simple interface to improve user experience.
A few highlights on the update:
Design: With the new update comes a new slick and minimalistic module. Keeping in mind that users come to a site to engage with content, we wanted to compliment a publisher’s site, without visually over-whelming it. The persistent form factor will sit on the bottom right of the page, and won’t interfere with content or the users browsing experience. Interaction happens only when users engage or perform a rewarded action.
Customization: Gamification should be flexible enough to work for a variety of publishers and their sites. With the newest version of BigDoor, publishers can choose what features to implement (be it quests, leaderboards, rewards, etc) without the worrying about user interface. The customizable dock allows publishers to pick and choose which BigDoor powered gamification apps are visible to users, which ensures that every BigDoor gamification solution is unique.
Notifications: Included with our new design, we’ve updated our user feedback to provide users a clear notification when they have made a rewarded action. We believe that a gamification solution needs to clearly communicate to users what actions are valued. Notifications are a great way to draw the users attention to these actions and let them know that they are moving in the right direction. No longer will users be unaware when or why they have received points. This not only improves the feedback loop for the user, but increases the likelihood that users will onboard and join in.
We’re working on loading more quests, adding features and content all the time, so make sure to check back frequently and see this new version at work! If you have any questions about the new look, or would like to talk to one of our gamification experts about a BigDoor solution for your site, you can email us at info@bigdoor.com or check out our website for information about specific BigDoor features.
Last week, our business development team represented BigDoor at the2012 Gamification Summit. We were very excited to unveil our new logo for the first time at an event, as well as talk about some of our awesome clients, new features and get a chance to talk about how we are improving online user loyalty and customer engagement. When BigDoor was starting out, gamification was a concept that most people didn’t understand and relatively few people thought was valuable. We were so encouraged to see how big gamification has become. We heard the conference ended up with ~650 attendees for the two days, and we know we talked to some great people (though we wish we could have talked to you all!)
Nate @ G Summit showing off our swag
One of the coolest things about gamification is that it can be applied to a wide variety of sites. Our flexible Gamified Rewards Program can increase user loyalty no matter what your focus is, which means we have been lucky enough to work with an interesting variety of publishers. While everyone we work with has unique goals and reasons for implementing gamification, we love being able to show how effective our solutions are. That’s why we were very excited that Chamillionaire was able to be a part of Gamification Summit this year.
After searching for a way to engage fans on his website Chamillionaire found the BigDoor solution. He came to G Summit to talk about his unique challenges on Chamillionaire.com and his passion for engaging users and building brand loyalty. If you were able to hear him talk or if you know anything about him you will know that his passion for gamification is infectious. He is not only a very talented entrepreneur but a very convincing person to speak on behalf of gamification. You can view his entire talk on Fora.tv, but we thought we would highlight some of our favorite quotes.
On why rewarding people with status works: “People love status, nowadays people come up to you and introduce themselves without even telling you their name first, they tell you how many followers they have on twitter”
On making the decision to work with BigDoor: “It’s going to cost a million dollars, it’s going to be hard to implement, and all this stuff…and then…I was completely wrong. It didn’t cost a lot, it was actually affordable, it was actually something that was easy to implement to my website.”
On fan engagement: “I believe it’s a relationship, if I do stuff for you, you do stuff for me back”
On the success of his website after adding gamification: “They say a tree falls in the woods and nobody is there to hear it…that’s not my website…it’s a lot different on chamillionaire.com”
On his song hitting number one on itunes: “There’s a lot of people with more fans than me that just can’t do it, because their fans aren’t engaged”
If you were at G Summit, and watched Chamillionaire’s talk, make sure to head over to his Facebook page and tag yourself in the photo here.
Chamillionaire and Nsilo Reddick with the BigDoor Team
You can also check out Chamillionaire’s slide deck from his talk, below:
Our CEO Keith Smith was also a speaker this year and he talked about internet promiscuity and how gamification can turn infrequent visitors into engaged brand ambassadors. With so many options online, marketers need to give users extra incentives tor return and engage. Using game mechanics to encourage users towards desired actions and rewarding them for those actions, is a proven way to build engagement and customer loyalty in today’s tough market. The keys to loyalty and engagement according to Keith; Easy user onboarding, create yearn, reward and social integration.
Keith Smith speaks at Gamification Summit
You can check out the slides from his talk below:
While we mostly focus on creating fun on the web, we also like to bring fun on the road. This year we decided to give out 10 limited edition marshmallow guns to attendees at the conference. Check out a few of the lucky winners, including Caroline Japic, Senior VP of Marketing @ Bunchball. We had a ton of fun putting these together and even more fun playing with them ourselves. If you won one we would love to see some photos!
We had a ton of fun this year and can’t wait to attend again. What were your favorite moments of Gamification Summit?
Happy Friday! We had a crazy week down in San Francisco at Gamification Summit and are happy to be home. We added some awesome photos of the event to our Pinterest account, as well as some great social media infographics and cool design examples. Click the photo to see our favorite pin’s of the week.
One of the lucky winners of our marshmallow guns from #GSummit
Happy Friday! It’s been a busy week here at the BigDoor offices, but we still had time to gather some of our favorite infographics, gamification articles and geeky images from Pinterest for you to enjoy.
We especially enjoyed some of the fathers day themed Pinterest pins we saw this week. We know we are a few days early, but Happy Fathers Day to all the father’s out there!
As I write this, 50MM monthly active users are engaging with the BigDoor platform across our publisher sites. For a company that started with the simple idea of making online experiences more fun and engaging, knowing that our platform reaches that many people is astounding. As we launch more and more gamified loyalty programs with larger audiences, the importance of our platform’s performance and scalability has increased as well. To stay ahead of our publisher’s needs, we’ve been making major updates to our tech stack, ensuring that our platform comfortably supports the 20MM user actions per day and 1.5MM users who access BigDoor programs during peak hours.
Posted in: 
