User Inactivity: One Reason and Another

Standard

Last week Fred Wilson posted The Difference Between Total Users and Active Users, which proposed that web services focus on active users rather than obsessing over the many, many inactive user accounts that litter every even slightly successful service. He noted that:

It is not a problem for a service to have a large group of non-active users if they have a large group of active users. It’s the latter group that you need to focus on. Over time, I’ve learned that many non-active users become active for one reason or another. But they don’t become active by focusing on them. They become active because you focus on the successful users and make them even more successful. [Emphasis mine.]

While I don’t by any means believe Fred was suggesting that we shrug our collective shoulders and say “fuck ’em, they’ll turn active if they feel like it. Or not. Whatever…” I’ll hit the point where I think he glossed over some real work before the point where I agree with him.

Once a user has registered with your service, that person needs to do something. If you’re clever or lucky enough to have a registration path that (painlessly) catches people as they’re already using your service to fulfill their heart’s desire, you’re already in good shape; in many cases, however, you’re dealing with people for whom registration is a first step, and you need to (a) make it very, very clear what they do next and (b) make that action useful to them as an individual user.

Proposition One: We’re All Selfish Bastards

With so many sites including—or centered on—”social” components, it’s easy to create an onboarding process that has new users working to benefit the service or community rather than themselves. While I’m terrified to think about some of the product meetings happening post Fred’s “20 seconds tweet,” it’s still important to acknowledge that we’re all selfish to some degree: if a web service isn’t really useful to you until you’ve been working with it for days or weeks, what are the odds you’ll keep with it until you hit that turning point?

To be fair, though, even services that offer both clear post-registration direction and immediate benefit to the individual have users…a lot of users…who fade into inactivity almost immediately. It’s hard to get these people going precisely because you’ve done a pretty good job at showing them what you have to offer them.

Your “hey, we haven’t seen you in a while” emails or text messages will prod a percentage back into activity, but many of them just didn’t click right now with what you’re doing, and there’s no one single reason for it. And this leads us into the area where I very much agree with Fred:

Proposition Two: Even Selfish Bastards Have Friends

If you focus on your inactive users, you’re going to find a dozen different possible reasons for their inactivity for every ten users you analyze; if you ask them why they’re inactive, eight will ignore you…and the other two will give you those same dozen reasons plus a couple of others for good measure.

But, as I said, even selfish bastards have friends, and some of their friends may be among your active users. If you make those friends increasingly happy with what you provide, they will (as Fred noted) become your best advocates. They will, little by little, convince their lapsed brethren to give your service another try.

Twitter, in my experience, is the reference implementation of this phenomenon. Many people (myself included) created an account, didn’t see the point, and only transformed into active users weeks or months later, as others espoused the value of the service. That’s not to say that I necessarily find it useful in the same way as the people who were pitching it to me, but rather that their enthusiasm was sufficient to carry me through to the point where I found my own selfish use for it.

In most situations I think that you learn more from digging into your failures than from examining your successes, but user activity is one curious case where extra attention to what you’re already doing right has a far bigger payoff.

Follower Count: Pageviews 2.0

Standard

On the Hype Machine’s Twitter Music Chart

The Hype Machine crew recently released a Twitter Music Chart. First off, it’s pretty excellent:

We monitor Twitter for links pointing to tracks on the Hype Machine. We then give each of those tweets a number of points based on the number of followers (and the ratio of friends & followers) that person has. Finally, we add up all the points and figure out which tracks are tweeted by either the most influential twitter users, or by the largest group. Simple.

I like it because it’s simple, and because it offers a new view on the relative popularity of the music that appears on hypem.com; maybe all those twittered links to Hype Machine tracks are of no particular significance, but it’s well worth a little digging to see whether there’s anything there in that data. And I particularly like how open Anthony and team are about how the charts are built: there’s no secrecy about how and what they’re measuring.

What I like less is what they’re measuring. It’s a sweet start, but I think that having Twitter follower count and ratio at the center ends up a weakness: friend/follower counts are the pageviews of the social Web.

I will admit that these “pageviews” can be a very useful metric, and—probably more significant—that we haven’t worked out many other metrics for the social aspects of the Web, but nevertheless pageviews for Web sites begat site visits, unique visitors, visit frequency, average time on site, goal conversions, and any number of other metrics precisely because by themselves pageviews didn’t end up signifying much. Who were those pageviews, where were they coming from, what were they doing? Without context, a count of pageviews just isn’t substantial enough.

Since it’s pretty lame to complain without offering some kind of solution, I’ll offer my first thought: keep the follower data as a component of the algorithm, but add some context. The twittered links have a timestamp associated with them, so factor in visits to the linked hypem.com page and plays of the track in the 60 minutes following the tweet. If someone has a high follower count on Twitter but their followers don’t click through on or listen to their Hype Machine tweets, that person’s influence on the charts should decrease over time.

That’s certainly not a perfect answer (it doesn’t work on the first hypem.com tweet, becomes increasingly complicated if multiple people twitter a link around the same time, etc.), but some change along these lines would move the charts in a productive direction. Information is data placed into context, and follower count is data; find the right place for it and then we’re really in business here.

Anatomy of a Better Twitter Bot

Standard

So you may recall that I put together a Twitter bot for the lyric of the day club a few months ago. You may also recall that I mentioned that my co-conspirator Daryn Nakhuda has the ability to write code that doesn’t, you know, “fail mysteriously and silently” and such.

Well while it’s taken us a while to get there, but Daryn has now rewritten the LOTD bot. While I was on vacation and virtually inaccessible, Twitter disabled the “replies” API call, which meant that the LOTD bot couldn’t access the lyrics that people were posting. And since I was without internet access and had intermittent cell phone coverage, the bot went down and stayed down until Daryn managed to contact me.

After an amusing little incident where I accidentally sent the admin password for the server to hundreds of people, Daryn got coding and wrote LOTD Bot, Mark II. In addition to general improvements, Daryn added one completely awesome feature: now, if the bot can’t get replies from the Twitter API it fails over to do a search on Summize to find new replies to post. Sweet, no? Here are the (slightly updated) requirements and info for LOTD Bot, Mark II:

Requirements
To run a variation of this @lotd script, you must be able to understand Perl well enough to make some basic modifications to the script, and must be able to set up a simple database table (phpMyAdmin is your friend). In addition, you need a server or account at a Web hosting service that:

  • Allows you to set up a (small) database.
  • Allows you to run perl.
  • Has the XML::Simple and LWP::UserAgent perl modules installed, or will allow you to install them.
  • Allows you to run scheduled jobs (i.e. cronjobs)

Overview
It’s a very simple setup: there’s a single perl script running on my server that gets the replies posted to @lotd via the Twitter API (or via a Summize search, if the API call fails), loads them into a database table, and then republishes the posts in the lotd account (again via the API). It’s scheduled to run once every 15 minutes, around the clock. The script uses the XML::Simple and DBI modules, but doesn’t have any other dependencies.

To run your own bot using this script, you’ll need to:

  1. Create the Twitter account that will be the repost bot.
  2. Create a database table as described in the next section.
  3. Update the script below:
    • The DB connect information for your database. (Line 14)
    • The Twitter username/password information for your Twitterbot account (there are “read from” and “write to” values, but they’ll point to the same Twitter account in most cases). (Lines 16 – 20)
    • The regex to remove @YourTwitterBot from replies before it reposts them. (Line 40)
  4. Upload the finished script to your server.
  5. Set up a cron job to periodically run your script (@lotd runs every 15 minutes).

…and that’s pretty much it.

Get the Database Table Structure (MySQL CREATE)
Click the link above, copy and paste, and change the table or field names as seems appropriate.

Get the Example Script
Click the link above, copy and paste, and make the updates noted in the post above. If you change the database table or field names, make sure that you also update the script appropriately.

Gedankenexperiment: Here is the Internet

Standard

A digital native is a person who has grown up with digital technology such as computers, the Internet, mobile phones and MP3. A digital immigrant is an individual who grew up without digital technology and adopted it later. A digital native might refer to their new “camera;” a digital immigrant might refer to their new “digital camera.”

Description of “digital natives,” coinage generally credited to Mark Prensky

The idea of building competitors to Twitter on the same platform, or redistributing Twitter to multiple players reminds me of the idea that New York City should be rebuilt in Ohio because it would be cheaper. Or perhaps we could distribute a little of New York City in every state of the Union. New York City is what it is because of the people who live and visit there. Building another New York City in Las Vegas doesn’t result in the phenomenon that is New York City.

Echovar on decentralizing Twitter

There are roughly three New Yorks. There is, first, the New York of the man or woman who was born here, who takes the city for granted and accepts its size and its turbulence as natural and inevitable. Second, there is the New York of the commuter—the city that is devoured by locusts each day and spat out each night. Third, there is the New York of the person who was born somewhere else and came to New York in quest of something. […] Commuters give the city its tidal restlessness; natives give it solidity and continuity; but the settlers give it passion.*

E.B. White, Here is New York (1948)

It took a week or so for these three things to snap together in my head, but when they did I was surprised how beautifully and accurately E.B. White described the population of the Internet.

I consider myself, and many of the people that I know, settlers: we have chosen to live a part of our lives online, and building online is important to us. Commuters have long since arrived—people who come online for work, or to do a little shopping, or in search of entertainment, but for whom the Internet is simply an interesting, useful, nice place to visit.

I’m not certain that there are yet many, if any, true natives, but I’m looking forward to seeing the (to me) strange changes engendered by people who can take the physical and metaphorical connectedness of the Internet for granted as a part of their daily lives.

* Personal note: my parents (both originally from the Midwest) moved to New York in 1968, and I was born in 1971. When I first read this passage, years ago now, I finally started to understand how my parents’ New York was different from my own—and that New York was important to them in a way that I think I can never entirely understand.

Friday’s Brain Dead Emails

Standard

The McKinsey Quarterly Goes Social
The McKinsey Quarterly dropped me an email yesterday to let me know about the exciting new features that they’ve added: RSS feeds and social bookmarking! A very social and up-to-date organization, apparently. Interesting, then that they still follow the distinctly anti-social practice of sending me email from a dead address, with the friendly note “PLEASE DO NOT REPLY TO THIS E-MAIL.” Way to start conversations, kids.

Update (4 hours post-publishing): To expand a little bit on the above, a snippet from an email that I sent to a correspondent who prefers not to be named. I’ll just say that I’m pleased and impressed when people respond very reasonably to criticism that might perhaps be called “snarky.”

What struck me about the email, though, is that in a message that’s about social communication tools being introduced, the email tells people how they shouldn’t communicate (all caps “PLEASE DO NOT REPLY TO THIS EMAIL”) rather than telling them what they should do if they want to communicate with you. Why not shift the focus to providing guidance to subscribers, rather than stopping one particular behavior?

Amazon Recommends Pretending to Target Emails
In other news, the Amazon recommendation email situation that I’ve blogged about before continues its slide into absurdity. For a quick recap:

  • Back in the winter of 2005 Amazon would email me about stuff like an opportunity to get an 18% discount when pre-ordering an M83 album because I’d bought “Svefn-G-Englar” by Sigur Rós. Good.
  • In the spring of 2007 Kim Cameron wrote about the same sort of positive experience with Amazon recommendation emails. Excellent.
  • Come the winter of 2008, things get ugly. Because I have “shopped for electronics” (not purchased, mind you, but shopped for) Amazon emails me to recommend that I buy an Archos DVR. Lame. I have to assume there’s a new hire in the marketing department.

And now it’s the spring of 2008 and that new marketing hire appears to have settled in for the long haul. What’s the latest recommendation email from Amazon?

As someone who purchased video games or music from genres included in the game, you might be interested in our Grand Theft Auto IV music downloads store.

Seriously, Amazon? I’ve purchased “video games or music from genres included in the game?” Wouldn’t it be simpler to just skip a couple of steps and move directly into emailing me whatever your marketing department wants to send, whenever they want to send it? Once useful email program, fast becoming a sad joke.