互联网产品的打通问题

　　我们谈互联网产品之间＂打通＂这个话题。照例，为了说明道理，我们会拿别人网站的案例来解释。
　　先看案例：新浪网的新闻、UC聊天、微博之间。
　　在访问新浪新闻时候，右下角会有一个浮动窗的标题栏。说要不要跟一起看这个页面的人聊聊。
　　点开之后发现是新浪UC聊天室。我于是可以说话了。还被提示可以跟某人私聊。（其实这里解决了很大的＂用户互动＂的问题，这次不表。）
　　我的问题出现了，我在这写，跟新闻评论有什么关系吗？写了一句，发现没有关系。聊天内容不会写入评论。
　　可其实我是想发一句评论的，于是重新在评论内容里写。发现，这里面写的时候＂还可以发到微博＂，而且默认是勾选的。
　　发完之后在微博里会马上写入一条。
　　看到吗？这里面是三个产品之间所谓＂打通＂的情况。管UC聊天室的人会说＂太爽了，我们截获了大量新闻评论的用户。＂并且他一定会因为此次＂打通＂获得赞赏。管微博的人会说＂新闻评论成了我们重要的内容来源。＂这次打通因为默认的强制输入而获益颇多。而管新闻评论的呢，只能对UC聊天室＂门口截流＂的行为恨得咬牙切齿，也暗骂＂微博的东西还不都是老子提供的。＂
　　其实这是一个不太好的状态，我们看看他们的关系：
　　我们会发现，新闻评论是个＂被攀附＂的角色，可能就因为他最老最强大吧，于是扮演的多有＂长兄为父＂的意味。
　　我不晓得新浪网后面的故事，就事论事的说，这并不是真正意味的＂打通＂。那么在我看来，＂打通＂是怎么一回事呢？
　　＂打通＂是运营层面的问题，也是一个＂方向＂。
　　我坚持认为＂打通＂是需要运营来考虑的。运营需要考虑，我这个产品需要怎么推广；用户从哪里来；我的用户和什么产品的用户重合度比较高；在别人的产品使用中，我怎么渗透进去；我怎么让用户用完别人的产品到我这来看看……
　　做产品的同学会把运营提出的＂打通＂需求简单化，认为＂提供几个API＂或者＂调用人家几个API＂就完事了。殊不知，
　　如果把自己产品独立来看，别人页面上的小块，是一个很重要的用户接触点，无论是什么地，都要细细耕耘呀。
　　如果把整个网站做一个整体看，各个产品之间的关系，会让用户有很多不同的感受。
　　＂打通＂≠ 布点，应该是双向的。
　　很多时候我们的同学把＂打通＂理解成＂布点＂，可是＂布点＂是单向的，是在别人那＂开辟殖民地＂，这种掠夺式的东西，不可能被人喜欢。于是，大多数人就会举着大老板的令箭来谈，那就真的是掠夺了。
　　遗憾的是，大多数人去跟被打通方谈的时候，都是打着＂打通＂的旗号，行＂布点＂之事。
　　这东西更应该想BD，先考虑清楚，我的产品对别人能有什么帮助，别人认可之后再提出你要别人怎么帮你。
　　当然，形成单向的原因，很重要是实力不匹配，比如新浪新闻评论从UC那可能还真获得不了什么。我想说的是，如果是单向的，麻烦考虑一下别人产品的用户体验，别让人觉得你在人家门口截断了客流。
　　产品设计时就要考虑＂被打通＂的事儿。
　　貌似没人来谈打通的产品不是好产品。呵呵。
　　于是，产品设计的时候，我觉得应该考虑一下有一天＂被打通＂的情况。这可能包括：
　　是否提前准备好被调用的开放APIs，总要有地方能联通得起来，否则＂殖民地＂就成了人家的＂自留地＂了。
　　是否考虑好＂被打通＂的节点，哪些地方是可以放入东西的，那些不可以。因为，别人打通你的时候，不会替你考虑你的用户体验。想想新闻评论被UC打通的事儿吧，浮层严重干扰新闻评论的逻辑性，可是UC暗爽啊。
　　好的做法是，当人来跟你谈＂打通＂的时候，你的方案已经给人准备好了。
　　别让用户同时接受你众多产品的逻辑。