“故事”功能是社交類產品打入短視頻領域的鋒利武器嗎？作者結合幾款產品展開了分析。

Story（故事）功能最開始是由國外的閱后即焚Snapchat在2013年做出的第一個不是閱后即焚的功能。它允許用戶記錄一天24小時內的動態，其他用戶可按照時間軸進行查看。但發布的內容僅保留24小時，超過24小時就會被刪除，無法在被查看。

2016年Fackbook、Instagram也推出此功能，并將其放到首頁的feed信息流的上方，以極高優先級占據首頁的位置，讓每個用戶進入app時都能第一時間看到自己關注的人的Story。

國內從2016年年末開始火起來的短視頻風口，越來越多的短視頻app開始出現，從一直堅持短視頻的快手，到火山小視頻，抖音等等的一些短視頻如雨后春筍般出現。

2017年7月新浪微博參考Instagram的形式推出微博故事，抖音短視頻社區也推出抖音故事，keep也參照此形式發布了運動時刻功能，以故事功能強勢打入短視頻領域。

新浪微博、抖音、keep故事功能的對比分析和其優缺點

圖1-新浪微博、抖音、Keep三款產品的故事功能對比

三個產品的該功能形式基本一致，優點也相差不大：

1. 有利于用戶快速觸達KOL，吸引用戶快速留存下來。
2. 有利于通過視頻圖片引起共鳴，快速產生社交行為，從而建立關系鏈
3. 有利于快速展示平臺特色內容，吸引用戶快速留存下來。

而共同的缺點是：

1. 普通用戶生產視頻內容的心理成本較高，積極性不高
2. 普通用戶產生的視頻內容趣味性不高，難以引起共鳴
3. 普通用戶產生的視頻內容極難引起陌生人之間進行社交

故事功能是否適合以上的app？

1.新浪微博聚集了數量眾多、各行各業的KOL，特別是明星。用戶已經可以在電視電影等一些其他媒體傳媒上認識了解他們，因此當用戶進入app首頁的時候看到自己感興趣的KOL的故事時，是有很大概率會被吸引去觀看的，進而提高用戶留存。同時微博故事在發布、評論、加關注都有一定紅包激勵，更多地去刺激用戶在故事上進行進一步的社交行為。其后續的表現還有待觀察。

圖2-新浪微博的微博故事及其紅包激勵

2.抖音作為一個短視頻社區，原有形式的短視頻拍攝需要的學習成本略高，技巧性比較多。但故事相對比較容易拍攝，直接長按拍攝，加上濾鏡即可。這個對拍攝者來說是比較友好的一個展示自己的一個功能。但是在抖音里，原有的高技術性、高趣味性的視頻內容已經占據了比較大的位置，而且內容的曝光率會幣故事更高（首頁有專門的關注tab展示關注的人的抖音視頻）。

故事的曝光率會較低，內容趣味性不高，而且評論、加關注等社交行為的產品交互設計并沒有設計得比較突出，導致抖音故事的存在感比較低，用戶感知不強，導致生產內容的意愿低，陷入惡性循環。如圖中的比較有名氣的彭十六發布的故事，在4小時內沒有一條評論。

抖音在最開始推出此功能時，其展示方式為，初次進入app，固定展示在頂部，原有的短視頻內容下移。這其實是影響了用戶最初進入到視頻流的沉浸式體驗的，用戶每次都需要手動關閉故事，再觀看主要的視頻內容。近期可以看到，原來的抖音故事從初次進入固定顯示在頂部，變為了隱藏顯示，開始有意去削弱這一塊展示優先級。個人覺得可以把故事內容往首頁的關注tab里面放，用戶可以在觀看關注的人時觀看到對應的內容，進而進行社交行為。

圖3-抖音故事的形式及其產品功能設計

3.Keep作為一個健身領域的垂直社區，動態tab下熱門的內容非常多。原有的視頻、圖片的內容是相對比較優質的。但原有的視頻內容發布隱藏較深，且正常發布的內容比較難出彩，一般用戶會選擇使用其他app進行視頻拍攝，然后再將視頻發布到keep中?，F在運動時刻其實對這一方面是有所補足的。首先其發布按鈕放在動態的同等優先級上，讓之前使用動態發布視頻的用戶留意到這個功能，增加其內容產出。同時在熱門頂部展示入口，讓用戶更多地看到用戶發布的內容，增加可消耗的內容，提高用戶留存。

? 但是keep的的主要用戶是對健身感興趣的用戶，內容發布者往往是在健身領域有一定威信，或者是一些在健身上獲得一定成效的用戶。此類型用戶一般會以自己的身材為傲，會更偏向記錄自己的健身成果，更希望獲得成就感。但運動時刻僅保留24小時的機制對讓發布者獲得成就感并沒有太大貢獻（因為獲得的評論會消失，獲得的關注會保留）。

圖4-Keep的運動時刻產品功能設計及其發布入口

故事功能相對于產品內部原有的專業水平更高的視頻內容，更多關注的是用戶本身的平庸生活化的視頻。如何去刺激用戶去發布故事、對故事進行評論點贊，是以上產品都應該考慮的問題。目前看來就只有微博在這方面做的好一些。故事功能在社交app中的表現如何，是否能夠像instagram那樣成功，還有待觀察。以上是一些個人沒有數據支持的一些個人見解，謝謝。

本文由 @木路 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自PEXELS，基于CC0協議