（图1，阿北很早时候的豆瓣截图）

如上图，阿北的豆邮有1206封未读。（如果是邮件处理的，算特例，在此不做分析。其实邮件处理对于普通用户来说是把双刃剑…）
注：豆瓣的站内信最早包括关注通知、站内信等信息，现在“在九点的关注”还阴魂不散的出现在这里。

（图2，UCDCHINA的百度站内信截图）

如上图，UCDCHINA的百度站内信有50封未读。（前面一百多封的时候我还在百度，有信息就处理，粘度高的不能再高。后来交给UCDChina的团队用，这些站内信就都懒得处理了…）
注：百度的站内信是整个百度线的沟通渠道，包括所有百度可能需要发给用户的信息、站内信，甚至新用户注册的时候也有几封信。最早的时候这些信息在站内信里面连分类都没有，现在有了。

在豆瓣、百度、facebook、Flickr、5Gme.com…，你的站内信有多少未读？

为什么这些站内信失去了作用？ 原因很简单：欲废此功，必先自宫。

别指望用站内信来教育新用户。
新用户不会对“站内信”产生很大的兴趣，如果不是有相对迫切的“需求”，用户不会专门跑到你的网站看站内信和听你用机器说一句“欢迎光临”。给新注册用户默认发“欢迎”的信件，坏多于好（具体得看你的用户层次和产品性质，“欢迎”是最俗的主题，可以想想有没有更好的主题）。
发一封，并同时给用户提供方便删除的途径，有时确实可以起到提醒、教育用户对“站内信”的认知作用。但，某些网站在一注册就收到“欢迎”“系统通知”“申明”“密码安全”等四五封站内信。无异于自毁城墙，对于大部分非“初级网民”来说，他们看看标题就直接离开了。留下”站内信(4)”这个烙印，永不再用。（有些是为了推卸“法律责任”，这么干是最没有出息的行为）

清零。让用户清除压力。
已读、删除功能很重要。如果必须发，没有必要的话不要默认预览太多内容。一封看了标题就能明白大致内容的信，如果不是很有兴趣或者必须要处理，用户不会打开同时也懒得随手删除。两封、三封、四封.. 人都有天生的“懒惰性”，再无聊的用户，看着数字到了两位数，就失去了感觉，对站内信产生了天然的“免疫力”。
必须很突出的展现给用户很方便的“清零”功能，让他们很熟练的运用“清零”手段。甚至不惜以牺牲体验为代价，设置一定的阅读门槛（比如，默认预览内容少）让他们“打开”（打开=清零）。

最好把“系统通知”和“信件”分开。
繁复的不停更新的“系统通知”会让用户失去对站内信的兴趣，进而影响对真正“信件”的兴趣。在重要界面上（往往是首页）开辟一个“通知”区域很有必要，这样可以增强用户对“通知”的重视，也会降低系统对于“信件”的干扰。因为，站内信一般情况都只是在导航上有一个“未读数字”的提醒，用户可以很快的视而不见；而通知在首页上会是一块内容，相当于“眼中钉”，“清零”动作也变成了随手的“任务”。某种意义上“通知”就等于“任务”。

“站内信”不是取之不竭的“金矿”。
最害怕给网站添加站内信功能，因为每次添加站内信功能的时候，最重要的工作就是“谈判、立军法”。不立“军法”，不敢开战。
因为，站内信一出来，肯定是没完没了的“这个活动需要给用户群发…”“这个促销需要群发..”“这个新功能需要群发…”
没完没了、没完没了、没完没了… …

特别是一些根本不懂互联网运营（大部分运营人员还是很强的，少部分如此）的人，特别是一些只知道盯着PV看自身网站资源能割多少肉，根本不去管产品会不会废掉的运营人员，特别是一些只知道眼前KPI的人。 他们真的想象力匮乏，站内信对他们来说就是一个“金矿”、“救命稻草”，甚至不停的告诉你“打开率很高、效果很好…”
就算你不停的给他解释“打开率肯定随着活动的越多在不停下降，这个打开率的下降就是站内信这个功能的慢性死亡的征兆”，他们也一样熟视无睹。只知道不停的说“老板要KPI…”
如果没有军法，如果你的运营搭档很XX。你必须的得罪他们。或者你死掉。

当然，我不是反对完全不可以用站内信去做运营和营销的事情。只是“必须有节制”，必须把这些内容当作“对会员有用的增值服务”，不附和这个标准的就是在屠杀产品。

很显然，当一个网站技穷到只能在自身产品核心功能，或者核心和用户的沟通渠道上，附加大量多余营销内容的时候，这个产品/渠道（包括短信通道，给用户的通知邮件等等）已经患上了慢性癌症，死亡的征兆已经来临。
往往运营一段时间以后发现功能已经无法运转了，不是因为“产品有问题”，而是我们在市场运营、产品运营的时候给这些基础功能强压了太多，他们本不该承担的“责任”。 最终导致夭折…

只要是对用户有价值的功能，用户不会嫌弃。绝大部分时候，是你，是你逼着用户嫌弃它们。欲废此功，必先自宫。

最后，附图一张：

（图4，我的的5Gme.com站内信截图）

未读信息为0。这是我站内信利用率最好的一个网站。因为除了私信就是私信。不是因为他是sns，而是因为他抄的和facebook一样，分开了处理，没有干扰。）

原文：http://uicom.net/blog/?p=795