互联网产品的“打通”问题

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