It might seem natural to award a single point for the most basic activity you want to gamify in an overall program, but in fact it binds up the dynamics in such a way that long-term success becomes more difficult. To foster longevity, gamification must follow an Implement–Monitor–Adjust loop. Singular awards will hamstring future adjustments.

The prescription: initially, only award points in multiples of 10 (or more).

It's easiest to illustrate this with an example. It's a lengthy one, with lots of if/then/on-the-other-hand, and [spoiler alert] the most compelling bit is probably the player's mental model. (Feel free to skip ahead.)

Scenario

For this example, we need a system that has a mix of both high- and low-value user actions. (The value is determined by business needs that align with user objectives.) I'll choose a domain dear to me: classical music. Let's imagine that the Houston Symphony Orchestra wants deeper engement with their casual web visitors, with the ultimate goal of driving more ticket sales. User actions that they want to incentivize are (from lowest value to highest):

  1. Logging into the web site
  2. Attending a concert or other event
  3. Referring someone who then buys a ticket

Having chosen the meaningful actions, the HSO team goes to town designing the game mechanics (all we're concerned with here is point accumulation). They decide that attending an event is worth twice as much as merely logging in; referring a friend who then buys a ticket is worth twice as much again. So, they launch a program in time for the fall season where players earn 1 point for logging in, 2 points for attendance, and 4 points for referrals. Seems reasonable.

(By the way, I realize this made-up scenario is a little simplistic, but stick with me—it's just to illustrate the mechanics.)

Oops #1—the need for a new activity

By January, the social media team is ready to introduce social sharing to the web site, and they want the gamification system to encourage users to post news of concerts on networks like Facebook and Twitter. They know that social amplification is important, and they believe that such sharing is 80% as valuable to the organization as referrals.

You already see the problem. There's no place in the point schedule for the new activity other than the 3 point mark. So they're forced to settle for a nonoptimal ratio and hope that the incentive structure is adequate.

"Aha! But they could just award 3.2 points for the new activity!"

That's very clever! But, there are two problems. First, many off-the-shelf systems are only designed for integral point values, so awarding fractions may not be an option. Even a homegrown system may only store integers, and changing this will require expensive engineering resources.

Second, there's a psychological problem with decimal places that I'll get to near the end.

Oops #2—the need to devalue

You've probably already caught the more serious problem with the original point scheme: can it really be that referring a friend who then purcases tickets is only worth 4 times that of a web site login? A user who refers five new purchasers might be responsible for several hundred dollars in new revenue, but they would earn fewer points than someone who just visits the web site every day in September. Understandably, the most valuable fans of the orchestra will be very turned off by this, and the program will actually erode goodwill and extinguish the most valuable behaviors. By February, it's clear that they must devalue the login currency.

(The excellent folks at the HSO wouldn't have made this mistake, but let's pretend they did.)

Again, assume that decimal places aren't possible, so the only option is to increase the value of the referral points. So now they award 16 points for each referral.

The problem is that they've also effectively devalued prior referrals. Your referrals in September are only worth a quarter of mine in March. This is still a major turnoff. To get around this, the HSO team can write a quick program to go back through all the point awards and re-award them at the higher levels. That's a sound solution but a very expensive one, because there's no such thing as a quick software program—they all require engineers and some non-trivial amount of QA testing, plus change management and all that jazz.

Preventive measures

If they'd started out with at least multiples of 10, making for a 10-20-40 initial point schedule, they could just lower the login awards to 2 points and call it a day. In my example, they'd still want to write a script to revoke all the old login awards and recalculate them at the new rate, in order to fix the glitch that upset their key influencers (that is, referrals being lapped by logins). However, in a more realistic scenario the issue of a skewed ratio won't be so catastrophic. It's more likely that you'd be adjusting the weights by 50% or less, not by a factor of 5. In that case, correcting the sins of the past may not be necessary so long as you stop compounding them.

Flexibility is important

I'll stop belaboring the fictional example now. (You're welcome.) The entire idea I want to reinforce here is that gamification programs must adapt over time if they are to avoid player disengagement and extinction. Even though there are ways around the problems caused by a point schedule without enough wiggle room, why put yourself in that straitjacket in the first place? Much better to set yourself up for easier success by building some flexibility into the dynamics from the ground up.

The psychological component

Also consider player psychology. It feels more rewarding to get 100 points than 1. This is why moving to fractional points isn't a great solution. 25.6 looks like balmy temperature in Celsius degrees, but 2,560 is a much more compelling number on a leaderboard or your profile. If none of the rest of this article compels you to award points in multiples of 10 or 100, the psychological aspect alone should be enough.

Aside: better living through better programming

Since I brought up the topic of retroactive devaluation and the need to recalculate prior awards after a change in the point schedule, I'll propose a way around that. Some of the struggles I've described assume that the system that awards the points is "baked, not fried". In other words:

  1. a user does some activity;
  2. points are awarded in a fixed amount, like a real-world currency;
  3. these points go into the bank (database);
  4. whenever the system displays the user's point total, a single number is pulled from the bank without any calculation.

This is a natural way to design a system for high performance—almost no work has to be done in order to display point totals. The heavy lifting is done at award time. This makes sense when read/write ratios are as high as they will be in any system where you encourage uptake by making the game obvious to all users (which is true of almost all gamification programs).

An alternative would be the fried approach:

  1. a user does some activity;
  2. the activity alone is recorded in the database;
  3. when the system displays the user's point total, the various activities are multiplied by the current point values.

Frying is very appealing as it allows game designers to adjust point schedules without the need to either engage engineers or upset players through retroactive devaluation. You certainly can't goof with the schedule willy-nilly. A constantly shifting point total immediately erodes trust and engagement. However, when the occasional adjustment is required (as it will inevitably be), you can post notices and even send e-mail notifications educating users about the change.

This approach is fraught with peril as well, because players may latch on to the fact that they had 1,500 points and now only have 900, even though everybody is in the same boat. This is no different than what would happen in a baked system when currency weights are adjusted, it's just that the fried system makes such changes quite inexpensive compared with the need to engineer a rejiggering of points that are already recorded in fixed currencies at the bank.

The runtime performance of the system has to be carefully considered, of course. A best-of-both-worlds approach could store points in a bank but recalculate them nightly if there have been any changes to the point schedule. I'll leave the rest of that as an exercise for clever engineers.


Get in touch!

Let's grab coffee!

Anywhere in beautiful Austin, TX., or virtually.