我們談互聯網產品之間“打通”這個話題。照例，為了說明道理，我們會拿別人網站的案例來解釋。
先看案例：新浪網的新聞、UC聊天、微博之間。
在訪問新浪新聞時候，右下角會有一個浮動窗的標題欄。說要不要跟一起看這個頁面的人聊聊。
點開之後發現是新浪UC聊天室。我於是可以說話了。還被提示可以跟某人私聊。（其實這裡解決了很大的“用戶互動”的問題，這次不表。）
我的問題出現了，我在這寫，跟新聞評論有什麼關系嗎？寫了一句，發現沒有關系。聊天內容不會寫入評論。
可其實我是想發一句評論的，於是重新在評論內容裡寫。發現，這裡面寫的時候“還可以發到微博”，而且默認是勾選的。
發完之後在微博裡會馬上寫入一條。
看到嗎？這裡面是三個產品之間所謂“打通”的情況。管UC聊天室的人會說“太爽了，我們截獲了大量新聞評論的用戶。”並且他一定會因為此次“打通”獲得贊賞。管微博的人會說“新聞評論成了我們重要的內容來源。”這次打通因為默認的強制輸入而獲益頗多。而管新聞評論的呢，只能對UC聊天室“門口截流”的行為恨得咬牙切齒，也暗罵“微博的東西還不都是老子提供的。”
其實這是一個不太好的狀態，我們看看他們的關系： 
我們會發現，新聞評論是個“被攀附”的角色，可能就因為他最老最強大吧，於是扮演的多有“長兄為父”的意味。
我不曉得新浪網後面的故事，就事論事的說，這並不是真正意味的“打通”。那麼在我看來，“打通”是怎麼一回事呢？
- “打通”是運營層面的問題，也是一個“方向”。
我堅持認為“打通”是需要運營來考慮的。運營需要考慮，我這個產品需要怎麼推廣；用戶從哪裡來；我的用戶和什麼產品的用戶重合度比較高；在別人的產品使用中，我怎麼滲透進去；我怎麼讓用戶用完別人的產品到我這來看看……
做產品的同學會把運營提出的“打通”需求簡單化，認為“提供幾個API”或者“調用人家幾個API”就完事了。殊不知，
如果把自己產品獨立來看，別人頁面上的小塊，是一個很重要的用戶接觸點，無論是什麼地，都要細細耕耘呀。
如果把整個網站做一個整體看，各個產品之間的關系，會讓用戶有很多不同的感受。
- “打通”≠ 布點，應該是雙向的。
很多時候我們的同學把“打通”理解成“布點”，可是“布點”是單向的，是在別人那“開辟殖民地”，這種掠奪式的東西，不可能被人喜歡。於是，大多數人就會舉著大老板的令箭來談，那就真的是掠奪了。
遺憾的是，大多數人去跟被打通方談的時候，都是打著“打通”的旗號，行“布點”之事。
這東西更應該想BD，先考慮清楚，我的產品對別人能有什麼幫助，別人認可之後再提出你要別人怎麼幫你。
當然，形成單向的原因，很重要是實力不匹配，比如新浪新聞評論從UC那可能還真獲得不了什麼。我想說的是，如果是單向的，麻煩考慮一下別人產品的用戶體驗，別讓人覺得你在人家門口截斷了客流。
- 產品設計時就要考慮“被打通”的事兒。
貌似沒人來談打通的產品不是好產品。呵呵。
於是，產品設計的時候，我覺得應該考慮一下有一天“被打通”的情況。這可能包括：
是否提前准備好被調用的開放APIs，總要有地方能聯通得起來，否則“殖民地”就成了人家的“自留地”了。
是否考慮好“被打通”的節點，哪些地方是可以放入東西的，那些不可以。因為，別人打通你的時候，不會替你考慮你的用戶體驗。想想新聞評論被UC打通的事兒吧，浮層嚴重干擾新聞評論的邏輯性，可是UC暗爽啊。
好的做法是，當人來跟你談“打通”的時候，你的方案已經給人准備好了。
- 別讓用戶同時接受你眾多產品的邏輯。
這還是產品需要考慮的問題。Sh4rk說設計是“用視覺語言去解決邏輯問題”，就是這個道理。
如果用戶到新聞頁面，看到了UC聊天室，看到了微博，甚至再看到一些其他的新浪產品，他會不會覺得“很暈”“很亂”“不知所措”呢？
如果有，這個頁面所有者的責任就大了。我想說的是，“被打通”應該是好事，但是如果被“喧賓奪主”而影響了你的產品邏輯，或者影響了整個網站產品之間的邏輯，那就是壞事了。
在這個角度上說，新浪這麼做危險系數比較高。
好了，基本上說完了。那麼有沒有這方面做得好的呢？看看QQ吧，產品之間的關系和打通，很多地方值得我們學習。
總結一下，我們說的是：運營要考慮打通，但絕不是布點，是雙向的工作。產品設計要做好被打通的准備，要考慮用戶邏輯。