文 | 阑夕

　　在「即刻」订阅超过一百个主题之后，它终于成为我在每天都会打开的应用之一。

　　「即刻」是一款支持用户自定义信息颗粒度的产品，与我有关的主题，就有「阑夕又有新的女演员点评」、「阑夕的几点看法」、「阑夕微博点赞提醒」等。

　　这些主题既有「即刻」官方主动策划并创建的，也有基于公开规则由用户提交创建的，前者需要针对某种颗粒的内容撰写算法程序，比如「又有大公司的负面信息了」，显然需要专门的索引和判断，而后者则由指定动作触发，比如「张小龙又有新的知乎回答」，只需要爬取张小龙的知乎账号动态就可以实现。

　　「即刻」的运行机制，让人想起美国的自动化神器「iFTTT」，这是「if this then that」的缩写，通过调用互联网产品的开放API，用户可以高度定制由一种动作引发另一种动作的功能，同时排除冗余干扰。

　　比如想要获得下雨提醒，用户可以不必安装某款天气应用——它意味着你可能会收到大量并不需要的提醒——而是可以使用「iFTTT」关联这款天气应用的API，并下达指令：只要所在地的天气状况变成下雨，那就通知另一款短信应用，由后者给自己发送一条注意带伞的内容。

　　在英文互联网的世界，因为去中心化的游戏规则属于「政治正确」的一部分，所以大多数主流产品——包括Google、微软、Facebook、雅虎旗下的总计上百款应用——都在技术协议层面允许「iFTTT」的操作，甚至主动提供了前端的触发条件，比如Flickr就支持用户通过「iFTTT」把所有被其打上星标的图片同步到Dropbox，一些智能家居产品，也支持「iFTTT」做出诸如当狗盆里的食物吃光之后提醒主人及时添加这种便利功能。

　　众所周知，中国的互联网公司对于用户资源的重视超乎想象，故而可能诱导用户接触其他应用的风险是极少可给容忍的，而「iFTTT」及其模仿者在国内几乎都毫无施展空间，直到「即刻」在内容领域曲线救国，部分性的重新定义了信息流的去中心化。

　　换句话说，「即刻」注重的是条件端的个性化定制，而在触发端，则统一收于「即刻」应用内的提醒，最终形成崭新的阅读场景。

　　比如在「即刻」里有很多「XX微信公号有更新了」的自建主题，它完全没有任何不同的创造体验——用户大可在微信里订阅这个公号——但是之所以用户愿意在「即刻」里完成这个动作，不外乎微信本身的溢出效应：订阅的公号太多，以至于对更新提醒变得麻木起来，加上公号与公号之间的认知权重区别难以划分，于是干脆在「即刻」里单独设计一个更新提醒。

　　曾和「即刻」的联合创始人林航聊过，他认为社交网络鼓励用户追求事无巨细——你关注一个人，恨不得连他的吃喝拉撒都不能漏过——这让那些不愿照单全收的需求陷入特别难受的境况。

　　于是，弱水三千，只取一瓢饮，「即刻」的产品定位，就只是那个瓢而已。

　　不过，瓢也有瓢的问题，那就是在它的盛水面积不够大的时候，完全无法起到止渴的作用，这也是为什么在本文开篇，我说只有在关注了超过一百个主题之后，才有动力每天打开「即刻」。

　　因为内容太少了。

　　我是一个除了微信之外不会向任何应用开放推送通知权限的非典型用户，所以「即刻」对我而言也不是一个通知工具，而是在细分信息类型之后的补充性阅读器。

　　（当然，「即刻」的典型场景，依然是指定资讯的即时通知，比如用户关注了某款空气净化器的降价提醒，那么一旦系统识别价格下调，就会立刻向用户推送消息。）

　　而「即刻」的单个主题多数并不属于频繁更新的性质——或者说用户使用「即刻」的目的之一就是降噪——所以如果关注的主题规模有限，每天打开「即刻」获取的内容根本不够看。

　　像是「煎蛋24小时热文」、「不好笑便利店」、「游戏玩家的日常」这类有着高频预期及日更内容源的主题还好，然而如果关注的大多是低频主题，比如「ISIS被灭进展提示」、「人工智能有重大新闻」、「豆瓣9.0分以上的新电视剧提醒」这些，一个礼拜都刷不出一条新的内容也不意外。

　　所以，「即刻」的产品和运营团队，也在尽可能的促进用户留存方面，下了很大功夫。

　　比如「即刻」曾经改版，让用户在一次刷新没有获得新的关注内容时，在顶部塞进一些随机取样的热门内容，「诚实的伪造」出有内容更新的体验，削弱用户的失望感。