場景化的最短路徑
脫離場景講縮短路徑是耍流氓，不妨舉幾個例子。
6.1 線下場景
一個小程式能產生 10000 個帶參數二維碼，使用者透過不同的二維碼可以進入同一個小程式不同的頁面。
拿前面公車的例子舉例。假設某個城市，每一個公車站的每一路車的站牌上都貼了不同的二維碼，在等車的乘客掃某路車的二維碼，就可以知道該路車的位置以及預計到達時間。
如果拿服務號來做，也能產生參數二維碼，但用戶依然需要點擊關注和點對應的連結進入公車的頁面。如果拿 app 來做，除了需要下載之外，我們還需要輸入想找的公車號碼。
顯然，小程式在等車這個場景中，縮短了使用者獲得資訊的路徑。用戶將會更喜歡。
你可能會說，上面說的，用 HTML5 不也可以實現麼？每一路車不就是一個不同的 URL 麼？是的，但在這個場景裡，HTML 的體驗遠遠沒有小程式優秀。
所以，小程式可以縮短線下場景的服務路徑。
6.2 社群場景
在《小程式的想像》這篇文章裡，我曾經說過，微信小程式是適合做垂直社群產品的。
你會發現，不管哪個產品裡，但凡我們跟其他人建立了聯繫，幾乎都會交換微信號，然後就在微信裡繼續聊，而很少回到原來的產品。
因為我們的社交關係已經被微信牢牢握住。然而，每個人都有垂直社交的需求，例如，我喜歡看賽車，所以想跟其他喜歡看賽車的人交流；他喜歡旅遊，想和其他驢友交流心得；A 和B 都是馮大輝的粉絲，他們想和其他大輝粉一起交流……
過去大半年，你會發現大輝經常在公眾號推他的小道消息讀者群，最初，這個讀者群是基於另一個app 的，後來，這個app 出了微信網頁版。
你可以很容易想像，從公眾號導流到一個 app 是很不容易的，況且，還是導流到一個非剛需的垂直社交圈裡。
路徑太長，使用者很容易流失。
設想小道消息讀者群，或者可能會有的「可能吧讀者群」是一個微信小程序，用戶在微信裡就直接使用，轉換率是不是會高很多？
如果結合小程式可以在對話清單置頂、可以收藏、可以深度搜尋的特點，這種垂直社交的轉換率和活躍度是不是會高很多？
所以，小程式可以縮短社群場景的轉換路徑。
6.3 協作場景
和社群場景類似，以往我們要在手機上與同事做工作上的溝通或協作要通過微信以外的工具，但與外部夥伴的溝通又必須回到微信，訊息在兩個工具之間並不能做很好互通，在這種場景裡，溝通的路徑被拉長了。
設想一個公司內部溝通用的是阿里的釘釘，但與外部溝通依然是微信，假設（不過不太可能）阿里做了一個微信小程序版本的釘釘，這個公司的協作和溝通就可以全部在微信裡進行，不管是訊息的傳輸路徑還是員工的協作路徑，都被縮短了一大塊。
你可能會問，為什麼做小程式就是縮短了路徑？因為絕大部分中國用戶的絕大部分時間，都被微信這個「場景」霸佔了，透過小程序，可以與微信分享用戶的時間。
所以，小程式可以縮短協作場景的溝通路徑。
更多微信小程式想透過場景化縮短路徑相關文章請關注PHP中文網！
