以新浪網為例談互連網產品之間的打通問題

      我們談互連網產品之間“打通”這個話題。照例，為了說明道理，我們會拿別人網站的案例來解釋。

      先看案例：新浪網的新聞、UC聊天、微博之間。
      在訪問新浪新聞時候，右下角會有一個浮動窗的標題列。說要不要跟一起看這個頁面的人聊聊。

      點開之後發現是新浪UC聊天室。我於是可以說話了。還被提示可以跟某人私聊。（其實這裡解決了很大的“使用者互動”的問題，這次不表。）

  
      我的問題出現了，我在這寫，跟新聞評論有什麼關係嗎？寫了一句，發現沒有關係。聊天內容不會寫入評論。
      可其實我是想發一句評論的，於是重新在評論內容裡寫。發現，這裡面寫的時候“還可以發到微博”，而且預設是勾選的。

      發完之後在微博裡會馬上寫入一條。

      看到嗎？這裡面是三個產品之間所謂“打通”的情況。管UC聊天室的人會說“太爽了，我們截獲了大量新聞評論的使用者。”並且他一定會因為此次“打通”獲得讚賞。管微博的人會說“新聞評論成了我們重要的內容來源。”這次打通因為預設的強制輸入而獲益頗多。而管新聞評論的呢，只能對UC聊天室“門口截流”的行為恨得咬牙切齒，也暗罵“微博的東西還不都是老子提供的。”
      其實這是一個不太好的狀態，我們看看他們的關係：
  
      我們會發現，新聞評論是個“被攀附”的角色，可能就因為他最老最強大吧，於是扮演的多有“長兄為父”的意味。

      我不曉得新浪網後面的故事，就事論事的說，這並不是真正意味的“打通”。那麼在我看來，“打通”是怎麼一回事呢？

• “打通”是運營層面的問題，也是一個“方向”。

我堅持認為“打通”是需要運營來考慮的。運營需要考慮，我這個產品需要怎麼推廣；使用者從哪裡來；我的使用者和什麼產品的使用者重合度比較高；在別人的產品使用中，我怎麼滲透進去；我怎麼讓使用者用完別人的產品到我這來看看……

做產品的同學會把運營提出的“打通”需求簡單化，認為“提供幾個API”或者“調用人家幾個API”就完事了。殊不知，
如果把自己產品獨立來看，別人頁面上的小塊，是一個很重要的使用者接觸點，無論是什麼地，都要細細耕耘呀。
如果把整個網站做一個整體看，各個產品之間的關係，會讓使用者有很多不同的感受。

• “打通”≠ 布點，應該是雙向的。

很多時候我們的同學把“打通”理解成“布點”，可是“布點”是單向的，是在別人那“開闢殖民地”，這種掠奪式的東西，不可能被人喜歡。於是，大多數人就會舉著大老闆的令箭來談，那就真的是掠奪了。

遺憾的是，大多數人去跟被打通方談的時候，都是打著“打通”的旗號，行“布點”之事。

這東西更應該想BD，先考慮清楚，我的產品對別人能有什麼協助，別人認可之後再提出你要別人怎麼幫你。

當然，形成單向的原因，很重要是實力不匹配，比如新浪新聞評論從UC那可能還真獲得不了什麼。我想說的是，如果是單向的，麻煩考慮一下別人產品的使用者體驗，別讓人覺得你在人家門口截斷了客流。

• 產品設計時就要考慮“被打通”的事兒。 

貌似沒人來談打通的產品不是好產品。呵呵。

於是，產品設計的時候，我覺得應該考慮一下有一天“被打通”的情況。這可能包括：
是否提前準備好被調用的開放APIs，總要有地方能聯通得起來，否則“殖民地”就成了人家的“自留地”了。
是否考慮好“被打通”的節點，哪些地方是可以放入東西的，那些不可以。因為，別人打通你的時候，不會替你考慮你的使用者體驗。想想新聞評論被UC打通的事兒吧，浮層嚴重幹擾新聞評論的邏輯性，可是UC暗爽啊。
好的做法是，當人來跟你談“打通”的時候，你的方案已經給人準備好了。

• 別讓使用者同時接受你眾多產品的邏輯。 

這還是產品需要考慮的問題。Sh4rk說設計是“用視覺語言去解決邏輯問題”，就是這個道理。

如果使用者到新聞頁面，看到了UC聊天室，看到了微博，甚至再看到一些其他的新浪產品，他會不會覺得“很暈”“很亂”“不知所措”呢？
如果有，這個頁面所有者的責任就大了。

我想說的是，“被打通”應該是好事，但是如果被“喧賓奪主”而影響了你的產品邏輯，或者影響了整個網站產品之間的邏輯，那就是壞事了。
在這個角度上說，新浪這麼做危險係數比較高。

      好了，基本上說完了。那麼有沒有這方面做得好的呢？看看QQ吧，產品之間的關係和打通，很多地方值得我們學習。

      總結一下，我們說的是：運營要考慮打通，但絕不是布點，是雙向的工作。產品設計要做好被打通的準備，要考慮使用者邏輯。