Meta-commitment


#1

I think the biggest problem with commits.to is that a typical new user (even an eager beta user) will create an account, create one or two commitments, then forget all about it. Their score will asymptotically approach zero and then all their incentives are to never touch it again. The person is strictly worse off than before they created an account in the first place. :disappointed:

I propose we commit to addressing that before opening the beta!

Brainstorming:

  1. Mandatory Beeminder integration! You can’t have a commits.to account without beeminding it.
  2. If your score falls below 50% then your whole account is automatically deleted.
  3. In combination with #1 or #2, automatic meta-commitments to keep making commitments.
  4. Simply charge a serious amount of money for the service.

#2

Thinking about point 2 makes me realise that some way of “resetting” your account (maybe just by deleting and recreating it) will be quite important to prevent people getting into the situation that they hate their commits.to score and never want to go near it again.

Once someone is invested in their score they’ll presumably never want to do this and lose their history, so it doesn’t ruin the incentive. But I can imagine it taking a few tries before people successfully integrate it into their habits.


#3

As a user, I’m not very comfortable with it when sites try to make me
keep using them. But this does seem like a pretty likely problem. Some
not-very-thought-out thoughts:
Maybe a opt-out beeminder integration that’s out of the way enough
that people won’t disable it unless they specifically want to not
have it?

Deleting accounts that fall below 50% would make your first few
commitments pretty high stakes. In a sense they are already; if you
only use it briefly anything you do then has a disproportionate effect
on your score.
Maybe weight people’s scores toward the site average when they’re new?
This should accurately reflect reliability: if someone comes on the
site and fulfill one commitment, I don’t assume they’re perfect on
such a small sample size; I conclude that they’re slightly more
reliable than my prior.
A downside is that this makes the score more opaque.

I do like the idea of automatic meta-commitments


#4

@justyn, good points! I’d advocate for restrictions of some kind on the reset option, mainly because I don’t like the idea of falsifying your reliability score by starting over. Actually, this is slightly related to the idea future discounting.

@forrestwolf, also great points! And I agree about not being annoying about it. But with both Beeminder and Commits.to, committing is the point. So it could be part of the sign-up process to opt in to a commitment device for actually staying on the wagon. I want to do that for Beeminder itself too. Ideas at doc.beeminder.com/metamind which perhaps has a natural Commits.to analog in the form of meta-commitments.


#5

I like the idea of an opt-in Beeminder integration. In the meantime, however, does anyone have good ideas on how to set up a manual Beeminder integration? I don’t mean “how” in a technical sense, I mean: what sort of Beeminder goal do you think would work well? What should the units be, etc.? I definitely need something to keep me accountable to looking at my commits.to so I don’t forget what’s there, but not sure off the top of my head what a good goal would be.


#6

Good question. Mine is a simple do-more goal, tracking the sum of my scores on all my promises.

I update it manually.


#7

Right, I remember that from your blog post about it. I’m not sure if I want to do that, because it constrains you not only to finish commitments, but also to make a certain number of commitments in the first place. It is OK with me if I go a week without making any new commitments; I just want a way to make sure I don’t forget about the commitments I did make.


#8

I see. Yeah, that’s important! And it makes sense to not want to commit to a rate of making new commitments. That’s even part of the original vision for this whole thing: to commit to logging every “I will” statement, with a goal of reducing the number of times you do that so that you only do it when you really, really mean it!

Fewer commitments is absolutely a win condition! (So @byorgey’s question remains open: what’s the right beemindable metric?)

Sort of related: I think a pretty key feature to implement (arguably another one without which we shouldn’t accept more beta users) is emailing the user every promise when it’s created. That could help with getting reminded because you could snooze the email or otherwise use it to remind yourself to do the thing.

More related: Did you notice we have an “add to Google Calendar” link? I haven’t been in the habit of clicking that but I think I shall now that I’ve reminded myself! It might also want to be more prominent somehow. Maybe being super in-your-face until you click it and then it transforms to something subtle. That might serve as pretty good inducement to calendar your commitments.


#9

PS: I said my graph was manual but if I get in the habit of clicking the “add to Google Calendar” link then it will actually be semi-automated. That’s because I have an IFTTT applet that automatically sends every calendar entry to my commits.to Beeminder graph, initially with a 0 as the datapoint value. So when I have a commits.to beemergency I can change those zeros to my actual scores (and I have few enough calendar entries in general that it’s no big deal to also delete the entries that don’t correspond to commits.to commitments).


#10

I do know there is an “add to Google Calendar” link, and I use it, and it’s better than nothing, but it’s not really a solution for me since I’m not in the habit of looking at my Google Calendar for todos; I just use it for my schedule (and what with teaching classes, meetings, students booking meeting slots, etc., I can easily have ~10 calendar entries per day, which makes a system to auto-log calendar entries a nonstarter for me). The email thing would actually be perfect for me since from there I could easily incorporate the items into my existing systems for tracking todos.


#11

Another candidate solution to the meta-commitment problem: Charge a serious amount of money for it. (Let me quickly add that to the brainstorming list above and wikify it. [done])

Asking people to speculate on how much they’d pay for something is notoriously unhelpful [1] but let’s try anyway. What’s the most you might pay for commits.to? (Note: Poll is anonymous. We won’t shake you down if you admit to a high value!)

  • $0–$9 / month
  • $10–$19 / month
  • $20–$49 / month
  • $50–$99 / month
  • $100–$199 / month
  • $200–$499 / month
  • $500+ / month

0 voters

Footnote

[1] It seems people are just horrible at introspecting about this and err enormously in both directions. Some want to avoid essentially voting for it to be more expensive than it needs to be, and others want to be encouraging or to feel generous or they think aspirationally about what they’d pay if they could. Consensus seems to be that those factors distort the answers so much that you might as well not even ask.


#12

One option I can think of is to require a credit card on signup, and force the user to commit to some kind of payment scheme: either the beeminder approach where as long as you don’t fail commitments you don’t pay or the Journal Jerk method of charging you a lot, but less if you keep coming back to commits.to over the months.

For the first option, you could offer either the ability to charge yourself as you fail commitments by increasing degrees, or charge yourself when your reliability drops below a certain number, or if it stays there for too long, or some combination.


#13

This seems a bit off topic to me, but I’d game to try to answer if I had a better feeling of what is offered.

Specifically, I think it would only be worth paying for if it comes with enough Chrome extension / Android app-ery to make it as close to 0 friction as possible. The product (in my mind) is all about this UX.