起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識沒有網站地圖的你是否迷失在APP中？
想必APP運營人員都可能會遇到需要看各個頁面之間的轉化率和訪問深度的各個頁面之間關系的情況，但卻必須要人工梳理；或者是新頁面上線卻未能及時通知導致數據統計疏漏的情況。面對這樣的情況，作者介紹了“網站地圖”工具，探討網站地圖的制作和用戶的訪問阻力、訪問意向的問題。一起來看。
前言
作為APP運營人員，你有沒有經歷過想看一下各個頁面之間的轉化率和訪問深度但是必須要人工梳理各個頁面之間關系的情況？作為數據分析人員，你有沒有經歷過各個團隊新上線一個頁面未能及時通知，導致數據統計遺漏的情況？隨著APP越來越復雜，這樣的問題會越來越多的轉化為線下溝通，人工頁面邏輯梳理，進而引發大量的人力工作，試想一下，支付寶如果想要統計全APP各個頁面之間的訪問情況并進行實時的數據監控是不是做不到？
聰明如你是不是一定會給出否定的答案，這樣大型又先進的APP肯定是能夠做到全站實時監控的，那么如果做到的呢？筆者不好妄加猜測，不過今天筆者帶來一套解決全站監控問題的小工具——網站地圖。
網站地圖是什么呢？
他是網站APP中各個頁面之間的邏輯關系，就像是百度地圖一樣，梳理了在APP上各個頁面之間訪問的路徑，通過網站地圖能清晰的看出各個頁面之間的關系，擁有上帝視角，了解APP的全貌。
網站地圖能夠做什么？
首先上面的兩個問題：轉化率和訪問深度的鑒定就能夠順利實現了，知道頁面的前后關系，頁面的前后訪問情況就能夠確定了，再輔以用戶的訪問流，頁面的轉化率、訪問深度也迎刃而解。
在有這兩個指標構建完成的情況下，大家有沒有點應用的想法？
常規用法固然是很多的，比如：看各頁面路徑的分流效果如何？頁面匯總時是否壓力過大？用戶是否存在訪問迷路的情況？頁面流程的訪問阻力有多大？用戶訪問某個交易的意向有多強？……
本文我們一起來討論一下網站地圖的制作和用戶的訪問阻力、訪問意向的問題。
一、網站地圖的制作
之前學習爬蟲的時候大家一定了解了深度遍歷和廣度便利兩種算法邏輯，假設APP的頁面結構如下圖：
APP結構簡圖：
一個小小的爬蟲遍歷如上整個網站往往會有兩個方法：
其一：深度遍歷
從主頁面出發，沿著下一層頁面樹方向進行縱向遍歷，直到找到葉子頁面節點為止。然后回溯到前一個節點，進行右頁面樹節點的遍歷，直到遍歷完所有可達頁面為止。
如圖為：
其二：廣度遍歷
從主頁面出發，再橫向遍歷頁面樹統一層級的各個頁面節點，在此基礎上縱向遍歷下一層級，直到遍歷完所有可觸達的頁面。
如圖為：
通過爬蟲的行走路徑大家有沒有一些建圖的思路？
假如說有一個爬蟲遍歷完所有的頁面，我們是否可以通過他的訪問順序梳理出頁面之間的關系呢？在數據準確的情況下，筆者相信這一思路是存在可行性的，即通過用戶的訪問流結合深度遍歷方法整理出一個完整的頁面關系圖——網站地圖。
對于一些比較大型的APP往往會有一個比較大的客戶群體，此處我們進行兩個假設：
1）假設有1億客戶，所有的客戶訪問路徑加在一起一定會遍歷到APP上所有的頁面，即便有個別頁面不被訪問，也是小概率事件或者不重要的頁面，這樣的頁面我們暫且不做考慮。
2）APP埋點系統準確記錄了上下兩個頁面的關系或者記錄了完整的時間戳，頁面之間訪問沒有中斷，能夠梳理出用戶的訪問流。
基于這樣的假設，我們就可以構建我們的網站地圖了：
這篇文章我們無法梳理大量的客戶，就權且假設五個客戶走完了上面APP所有的頁面，基于這五個客戶的訪問路徑，開始我們的地圖之旅：
五個客戶的訪問流程為：
- A客戶：b-j-k-j-b-p-b-m-n-e-n-m-0-m
- B客戶：t-a-d-e-f-e-p-e-d-a-g-h-i
- C客戶：c-d-f-d-c-b-c-a-d-e
- D客戶：k-z-a-c-d-c-a-d-e-f-e-p
- E客戶：a-b-a-g-h-i
我們的梳理步驟為：
1）先設定起始主頁[a，b，c]，對于一個APP來講往往存在一到多個主頁，是客戶登錄APP后的主要呈現頁面；
2）將訪問流按照第一個主頁位置進行切分，主要是因為部分活動類頁面會跳轉到主頁的前面，導致客戶訪問的第一個頁面不是主頁，進而引發APP結構混亂，解決的方法是人為的設定主頁，然后從主頁向前后兩端推進，就可以分清楚哪些頁面是活動頁，哪些頁面是功能頁。
梳理出的頁面結構可見上圖。
3）經歷過上面的步驟后，我們五個客戶的訪問流會變成>=5的多個訪問流片段：
我們模擬一下構建地圖的流程：
每一個訪問流都可以看作是對地圖中的一個子樹的遍歷，我們只需要遍歷每一個訪問流，然后將其合并即可。
以第一個訪問流為例：
從b主頁開始，遍歷下一個頁面j，如圖（指針位置即為下一次遍歷開始的位置）：
然后再從j開始往下遍歷，得到頁面k，如圖：
構建好上面的頁面結構后，我們再從k開始往下遍歷，得到頁面j，與前一個頁面相同，所以遍歷往前一層，到達j頁面，如圖：
從頁面j的位置再進行下一次遍歷，得到下一個頁面為b，b與上一個頁面也相同，所以再往前一頁，如圖：
如上面循環，下一個頁面是p，所以在b頁面的基礎上構建與j平級的頁面，如圖：
以此循環，直到訪問流到達最后一個頁面，得到如下該用戶的訪問子樹：
同樣的方式可以得到其他幾個訪問流的頁面子樹：
結合上面的五個子樹，我們得到一個綜合的樹為：
另外，我們需要將主頁前段的活動頁添加到訪問樹中，本案例中的主頁前置頁面如下：
在構建前置頁面樹時需要將前置訪問流反轉，然后再在反轉數據的基礎上循環上面的方法，構建完成后再反轉回原來的樣式，得出下圖：
結合兩個結構圖，我們得到了完整的APP網站地圖結構：
比較前面的網站樣式，我們發現，這個方法得出的圖形與APP的原有頁面結構一致，可以算作是一個行之有效的方法。
經過上面復雜的計算過程，我們得到了一個漂亮的網站地圖，該如何應用呢？我們一起來抽絲剝繭。
我們直觀的來想一下網站地圖的價值，或許通過借鑒的方式我們會發現一些思路，比如：百度地圖的用法有哪些？在哪些場景下地圖會有獨一無二的價值？
假如我們在使用APP時我們最在意的是什么呢？
1） 我們想要的東西在哪里？
2） 能否迅速的找到我們想要的東西？
3） 有多少路徑可以到達我們的目的地？
那么，假如我們是網站的交通管理員呢？我們又在意什么？
1） 客戶都是從哪里來？到哪里去？
2） 大家訪問是否流暢？是否走錯路？是否迷路？
3） 入口是否直觀？有多少人需要問路？即有多少人是通過搜索到達目的地？
上面這幾個問題自然是一個決策者或者業務方最關心的問題，但是作為一個產品方，如果拿著這些問題去找開發溝通，估計會被打回來，原因很簡單，能不能轉化成技術聽得懂的語言。
說的天花亂墜，這個東西有什么用途呢？
平臺體驗優化最常規的思路是確定用戶的訪問路徑，從訪問流程中找到最有效的路徑，從整個網站角度講，網站地圖即為比較常用的行為分析工具。
通過上文網站地圖的構建，大家可以更深度的了解我們的網站，了解客戶在網站中的行為軌跡，如果輔助以客戶成交的信息，以及客戶進APP之前的路徑，我們就可以完整的勾勒出客戶單次的訪問軌跡，再延伸一點考慮，如果我們把客戶每次訪問的這三組數據串聯起來，將其包裝成一個節點cell，然后沿著時間線將客戶在我們公司每次訪問產生的cell串聯起來，就形成了客戶在我們公司從生到死的一個完整生命周期。
生命周期的探索我們會在接下來的文章中詳細描述，本文我們先對網站地圖的一些簡單用法進行介紹討論，如有不足之處，歡迎大家指正~
二、用戶的訪問流暢程度
用戶進入到網站之后最直觀的思路即為：找到目標交易并完成，在這個過程中，用戶會點擊一個個頁面，完成一次次跳轉，影響用戶跳轉的兩個主要因素為：跳轉時長（跳轉性能）、交易信息清晰程度，這些影響因子即為阻力。從數據上看，轉化率是計算訪問流程中是否受到阻力的一個主要指標。
在一個正常的訪問流程中，是什么原因導致轉化率降低？
數據角度上我們可以通過客戶去了哪里來間接判斷：
1）上面頁面訪問到C頁面之后，客戶返回到其他頁面，然后在其他頁面完成了交易，或者有所停留，我們可以初步判斷客戶的這次阻力是由于沒有找到想要的交易導致。如下圖：
這種情況即為我們常說的走錯路的狀態，問題的發生多為分流頁表達不清楚，按鈕呈現有歧義導致的，客戶理解不了按鈕所對應的交易，所以采用試觸的方式逐一點開看一下，這對于客戶來講是一次時間的消耗和耐心的消磨。
2）有些客戶是到達C頁面，然后返回到上一級頁面，然后再返回的情況。如圖：
這種情況對于客戶來講往往是因為客戶在C頁面決策的信息停留在A頁面或者B頁面，導致客戶返回到AB頁查看對應的消息，確定消息后再回到C頁面決定是否繼續往D頁走。這種情況下的計算往往需要結合PV和UV的轉化率。比較會發現：C-D頁面的PV、UV轉化率存在一定的差異，PV轉化率明顯較小，而UV轉化率處在一個合理的轉化范圍。
3）客戶到達C頁面之后直接跳走，絲毫也不停留，如圖：
這種情況由于留下的數據較少，其實就很難判斷原因了，姑且可以猜測幾個較為明顯的原因：頁面跳轉較為緩慢、用戶意圖不是成交、當下頁面的產品吸引力不夠強等等。
三、識別迷路的用戶
在你訪問這個APP的時候，有沒有想找一個功能但是左右都找不到的情況？
我相信是有的，特別是剛使用一個軟件的時候，筆者一開始在使用微信時，想要找一個“QQ郵箱提醒”的功能，左左右右找了好長時間，最終一個個的遍歷找到這個功能在：“設置”—“通用”—“輔助功能”里面：
從上面的描述，大家有沒有一些想法呢？
如果一個客戶在無法確定出功能位置的時候，他會怎么做呢？
1） 直接搜索對應的功能；
2） 按照自己的認知，在相似的功能菜單里進行遍歷；
剛才在微信里的操作，筆者也是遍歷了“賬號管理”，“通用”等按鈕。微信欄能夠設計出如此簡潔的界面已屬不易，如果是一些其他的APP呢？我想就不會三步到達目的地了吧？
通過上面的案例我們總結一下客戶的迷路行為：
1） 在多個相似頁面之間來回查找；
2） 進入搜索欄進行搜索；
在訪問數據上比較直觀的發現是：
1） 訪問鏈路較長；
2） 重復跳轉同一個頁面；
3） 部分頁面的停留時長較長；
如果我們計算在一次訪問中的session_pv(頁面總數)/session_uv(頁面去重數量)，我們會發現這一數值會偏高，我們姑且把這一值叫做迷路指數。
假設有100個客戶，產生了100次訪問，則會產生100個比值。
如果這個比值的眾數和中位數高于均值，則意味著大部分客戶的迷路指數偏高，客戶訪問過程中存在一定的迷路現象。
基于這樣的假設，我們再深度遍歷高重復的路徑，逐一探索，發現重復背后的秘密。
例如：
我們發現在客戶的訪問過程中：“賬戶管理”和“通用”兩個菜單重復率較高（PV/UV），而且兩個菜單同時出現的概率（關聯規則）也很高，單獨取出這段訪問路徑（模式識別）的情況下我們是不是會得出一些推斷性的結論呢？
比如：
1） 名稱設置不清晰，客戶看到不能確定其對應的功能范圍，導致需要點進去才能確定；
2） 信息不夠完整，客戶需要在“賬戶管理”里面操作一半，在“通用”里面操作另一半；
讀到這里，你是不是也會有一些新的思路呢？
好了，就分析到這里吧，在網站中，對路徑的分析是沒有止境的，畢竟這是直觀呈現客戶動作的地方，比如：如何確定用戶意圖？預測客戶在什么情況下會形成訂單？預測客戶成交時可否添加用戶的訪問路徑？貝葉斯條件下客戶的訪問路徑是否會有隱秘軌跡？
專欄作家
野水晶體，微信公眾號：livandata，人人都是產品經理專欄作家。金融行業的互聯網老兵，聚焦數據驅動，將算法、數據融入產品設計與運營策略，構建金融增長方法論。
本文原創發布于人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協議。
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
確實需要一個網站地圖，現在有些網站太高級了，我進入一個新的網站真的可能會迷路，終究還是老了
有沒可能是現在app太復雜，需要瘦身？