October 31, 2012 by Charlotte
Happy Halloween!
While we believe that it is always acceptable to dress up as your favorite thing, Halloween is the day where you don’t have to explain! From all of us at BigDoor, we wish everyone a fun and safe Halloween. For those in the Storm Sandy affected areas, who might be postponing Halloween, we are thinking of you and hope you enjoy the festivities soon.
If you want to check out some of the photos from last years Halloween, you can check them out here.
October 15, 2012 by Charlotte
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).
September 18, 2012 by Charlotte
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.
- It’s designed with HA in mind.
- 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.
September 7, 2012 by Charlotte
Happy Friday! For many of us this was a short week, so you might have spent a lot of it trying to catch up from missing a day. If you lost track of gamification, social media and customer loyalty news don’t worry! You can catch up here.
Using Social Media To Manage Relationships Through The Sales Funnel Business2Community 9/6/2012 Every marketer and sales person is thinking about how to manage customer relationships effectively. This is a great article on how to use the power of social media to build brand affinity with customers in various stages of the sales funnel. The value of social media in building customer relationships validates the success of gamification as a great way for brands to encourage and manage their customers in a variety of ways, including through their social networks.
NFL.com Gets Gamified Just in Time for 2012 Kickoff Gamification.co 9/5/2012 We highlighted the NFL Fan Rewards program last week, but now that it has been up and running for a while, the gamification experts over at Gamification.co highlighted why this implementation is a huge step for gamification and brand loyalty programs. Of the program, Ivan Kuo says, “The NFL brand’s full commitment to a site-wide implementation must be one of the biggest gamification implementations on the web today.”
The 100-Second Guide to Gamification in Education Edudemic 9/2/2012 This infographic has been around for a while now, but in case you haven’t seen it, it is worth a look. Highlighting the potential for gamification in education, elements of gamification valuable to education as well as a few examples of existing programs makes this a densely packed infographic full of great information.
Social Media Marketing Encourages Customer Loyalty Through Interaction Social Focus by CG 8/30/2012 We talk a lot on this blog about building customer loyalty through social media and game mechanics, but it’s always great to hear someone else talking about the value of these tactics. There are some great tips in here (even if she doesn’t include gamification) and it’s worth a quick look if you are interested in brand loyalty and how to create loyal users.
Game design, gamification, game mechanics and games-based learning Doug Belshaw 9/2/2012 As the marketing specialist at BigDoor I spend a lot of time looking at the #Gamification tag on twitter. There has been a ton of activity talking about the Coursera Gamification course led by Kevin Werbach in the last few weeks. This is a great read by someone taking the course and thinking critically about how we interact with games and game design.
Best of Startup Day: Keith Smith on how to avoid failure Geekwire 9/6/2012 We know this isn’t really gamification news, but everyone has had to deal with failure in their lives at some point. Our CEO Keith Smith talked about how to avoid failure and how to deal with it when it’s unavoidable in his 2010 Startup Day talk. Some of his advice, “Be prepared to make sacrifices” “Build and develop the people that are going to be able to bail your ass out” and “Layout the problems that you have, identify those that can kill you, and work on the ones that can kill you the fastest”.
June 18, 2012 by Charlotte
We are proud to announce that BigDoor has been recognized as one of the 100 Best Companies to Work For. Last Thursday night Seattle Magazine awarded BigDoor 6th place in the Midsize company category. It’s exciting for us to be recognized as one of the best among such a successful and competitive group of organizations.
Since BigDoor was founded in 2009, we have seen our product, industry and team grow. Despite all the changes, we have kept a focus on creating a great place to work where everyone has a voice. This award is not just a win for BigDoor, but for all of our team members that have put the time in to help grow the company. We are so thankful for their hard work and determination that this award is dedicated to all of them.
To provide a little background, Seattle Business Magazine’s annual ranking of “100 Best Companies to Work For” recognizes companies based on size (or non-profit status) in Washington State. The award program analyzes company characteristics such as culture, employee benefits, programs and an online survey where employees provide feedback on the company. Each year Seattle Business Magazine partners with research firm Ipsos Worldwide to survey thousands of employees from across the state on what makes their companies the best.
This year alone, BigDoor has also been named as WTIA’s Best Early Stage Company of the Year as part of its Industry Achievement Awards and a TiE50 Awards winner in the Internet/Social Networking Category. We are very proud to be recognized and truly thankful for our awesome team that makes it happen!
June 18, 2012 by Charlotte
Happy Monday! There was a lot of great gamification news last week, from JetBlue’s new game show to getting everyone excited for Gamification Summit 2012. Catch up on everything you missed below.
JetBlue to Launch Live Online Game Show Mashable 6/11/2012 JetBlue announced the launch of it’s live online game show, designed to engage consumers and promote their vacation packages. The game show will have 15 minute episodes that will quiz contestants on travel related questions. The site will also hook into social media sites to engage non-contestants as well. This is another great example of a company that sees the value in making engagement fun and we hope to see JetBlue continue with this in the future!
In Defense of Gamification The Escapist 6/12/2012 Gamification is often accused of manipulating users. In this defense of the use of gamification, Shamus Young focuses on that criticism and highlights why marketers are turning to the use of game mechanics over other marketing techniques.
The 100 Best Companies to Work For 2012 Seattle Business Mag July 2012 We are very proud to have been named the #6 best mid-size company to work for in Seattle. The results were decided by a panel of judges after all company employees were anonymously surveyed. If you are interested in working for us, check out our jobs listing here.
Gamification Summit: What’s New and Who’s Speaking? Fora.tv 6/12/2012 We are very excited to have our business development team heading down to Gamification Summit this week. Gabe Zichermann, the mastermind behind the conference highlighted some of the exciting speakers attending the 2012 conference. Among them, we are most excited for our CEO Keith Smith as well as Chamillionaire.
Why Badges can be Bad – Really Bad Business2Community 6/13/2012 With a title like that, it might be surprising that we included this article, but the message is important to us. Gamification can get a bad reputation due to a lot of the sloppy solutions out there. While we agree that badges (and just badges) can be a sign of a really bad gamification solution, we also agree that badges done right can show real status and achievement that benefit loyal users.
June 1, 2012 by Charlotte
New Seattle technology startup resource Startup City partnered with SEOmoz to rank the top 100 Seattle Startups and BigDoor came in at #33. The rankings used 6 categories to rate companies and compiled points in each category to a final score (ours was 65). Categories were: Brand Name Searches, G-News Mentions, Domain Authority, Linking Root Domains, and Social Media followers (Twitter/Facebook). Companies at the top of the list include Zillow, Wetpaint and Cheezburger Network. Rankings will be reviewed and ranked monthly. Thank you Startup City for putting this together! We think it is awesome.
To check out the full list, head over to Startup City’s website here.
In true startup form, we love to embrace our geekiness on a daily basis, but today is special for a number of reasons. Not only are we celebrating the unveiling of our awesome new logo, but it’s also Geek Pride Day! In honor of Geek Pride Day we took our geekiness up a notch (or two). Our employees are all rocking their favorite geeky shirts, we are kicking off the weekend with some awesome Star Wars trivia, Portal themed cocktails, and munching on some delicious cupcakes from The Yellow Leaf Cupcake Company (because cupcakes are the official geek food of BigDoor).
If you didn’t know, Geek Pride Day is celebrated on May 25th and pays tribute to the first Star Wars movie that was released on May 25, 1977. It is also Towel day, a tribute from Douglas Adams Hitchhiker’s Guide to the Galaxy. Last but not least, Terry Pratchett’s fantasy novel Discworld celebrates May 25th as the day for survivors of the People’s Revolution.
If you are letting your Geek Pride show today tell us about it in the comments or on twitter hashtag: #geekprideday!
Posted in:
Blog,
Startups
Happy Friday! As we mentioned a few weeks ago, the marketing team is experimenting with Pinterest and our new Friday Pinboard. As a general rule, we like to follow the same themes as our blog: gamification and the elements that make it great – loyalty, social media, and engagement. We also like to cover technology, startups and Seattle.
This week we found some fancy infographics about startups, gaming, marketing and geeks. Enjoy!
May 17, 2012 by Charlotte
At BigDoor, we believe firmly that a gamification solution without solid analytics and data is doomed to fail. Accurate recording of actions, points and shares ensures that users are seeing the results of their efforts, and companies are able to track and monitor the success of a BigDoor Gamified Rewards Program. Recently, our internal team headed by CTO/Co-founder Jeff Malek made some important updates to our backend databases that ensure BigDoor can handle the large number of transactions, points and data required by our clients as well as free up valuable engineering resources for the internal team.
Previously, our data came from a replicated slave of its MySQL transactional database and aggregated the results on an additional intermediary MySQL host. Following this process data was then pulled into Tableau for reporting. This custom aggregation and ETL was workable in the beginning, but as we grew along with our client base, the problems of this type of solution began to eat up engineer time and energy.
We found our solution with Full 360 and Vertica. The two companies were able to provide us a solution that was quick to implement and able to handle our complex set of data. By moving away from our custom setup, we are now able to monitor and report with much greater speed and reliability in reporting user actions.
To read more about our transition and the custom solution provided to us by Full 360 and Vertica, you can check out their case study here.
