The New York Times announced last week that they would go to a partial-pay model in 2011. While they’re still working out the details, they plan to implement some kind of metering system that allows readers to access a certain amount of content before being required to pay. The sarcastic voice inside of me thinks it’s an interesting choice to only charge their more loyal readers. ahem.
There’s been a lot of talk about whether it’s a good move, and their own chairman and publisher Arthur Sulzberger admitted “This is a bet, to a certain degree, on where we think the Web is going.” I won’t bore you with more of the same commentary about IF it’s a good idea (there are TONS of articles on the subject already). Rather, I’ll share with you my first thoughts when I heard this.
The New York Times gets over 15 million visitors per month. To give you a sense of scale, that’s approximately 10% of what google gets. That’s a lot of people and a lot of content.
They need to manage this like a huge site migration project and deal with issues such as preserving bookmarks, old incoming links, usability, SEO, security (any time you change to a pay model you put yourself at greater risk for attack), modifying internal business processes and staff training. Here are a couple of the key points they’ll need to work through.
SEO
Approximately 25% of nytimes.com referrals come from search engines . Google alone stores over 12 million links into nytimes.com.
While they’ll need to lock down content, they’ll also want to keep that traffic. How can they do both?
- Option 1: They choose the serve the full article to search engines via checking the user agent. Pro – SEs index the full article. Cons – SEs can penalize sites that serve up different content to SEs, and users could access the full articles by using the cached version in the SE. OK, not a great approach.
- Option 2: Serve the full article, but tell SEs not to cache it by using the robots tag X-Robots-Tag: noarchive, nosnippet. The only improvement upon Option 1 is that SEs will not archive the content. They’ll still penalize the site for serving them additional content though.
- Option 3: Serve a summary of the article to SEs, and the full version only to users. Pro – The summary content would attract many users. Cons – Only parts of the article are indexed and available via search, and this would be a resource-intensive effort for the NYT.
Metering Public Access
If they’re only going to allow X views per time period they’ll need to come up with a clever, non-intrusive way to do it. Here are some ideas…
- Option 1 – Cookies : Drop a cookie that expires in whatever time period they specify. Increase the count of the cookie each time the person reads another article, and serve up a message when the person reaches the limit. Pros – Easy to implement, no special software, seamless user experience. Cons – Easy to workaround, and those who have access to more than one computer get more than one set of views.
- Option 2 – Plug In : Require users to install a plug in to read articles. Pro – Less prone to tampering. Con – How many of you would install a plug in to read a newspaper?
- Option 3 – Authentication: Require users to log in to read articles. Pro – Tied to a person rather than a computer. Con – How many of you would create an account and log in to read a newspaper?
Frankly, I don’t think any of these choices are great and I’m curious what they come up with instead. I’d love to be a fly on the wall when the business people describe to the tech people just what they need to implement.
I’m anxious and curious to see what they decide to do. As a media company with such a broad following they could have an impact on how content is distributed and accessed across the web.
