<<撰文:猴子2號>>figure-1

您的服務好嗎?

無論是公司老闆、設計師或是我們這些程序猿,在生產產品服務時都容易陷入了 Super User 的迷思,對自己提供的服務都是充滿自信的、自己做的東西當然就是最好的,但....在商業市場來說一切都還是消費者說的算,無論從過去 UI / UX使用者體驗到最近沸沸揚揚的大數據分析,從根本的目的都是想知道使用者在你的服務中做了哪些事情的行為追蹤進而推敲出使用者體驗或後續提供更好的服務。


使用者在幹嘛?

搜集了解使用者的體驗是確實是一個不容易的事情,在傳統上如果一間公司想要知道客戶的滿意度最容易的方法就是發送問卷調查,但問卷調查本身並無法強制力且會主動填寫問卷調查的使用者通常也都是常用服務希望服務更好的一群,當客戶只是順手路過對您的服務沒根本不認識你也沒有忠誠度時,他也就沒有動機會想主動填寫問卷(除非利誘),正因如此問卷可能會因為這些誤差讓開發人員/公司產生錯覺,這種偏差很有可能讓您的產品逐漸朝向為特定族群服務。


Google Analytics (簡稱 GA)是開發軟體服務時第一直覺會想到的流量分析行為追蹤服務,可以方便與快速的方式架構出一個 [事件收集]的環境,但 Google Analytics 提供的內容會模糊化使用者資訊,我們只能知道有一個人知道在哪個頁面觸發了什麼事情,但無法詳細知道是誰做的,而且資料用量有上限(數據用量上限 - Analytics (分析)說明)數據會採用統計內容的方式呈現,我們無法就無法得知完整實際資訊。


對於行為分析來說我們當然希望能知道用戶行為越多越好,希望紀錄能呈現出來的內容越完整,那 Google Analytics 就不敷我們使用了。不過也不用太擔心,目前線上有很多類似的 Log Record 服務如 Mixpanel 提供了完整的 SDK 跟圖形化介面的網站來呈現所有數據;但如果您是個 Geek 您也可以用資料庫來自行開發屬於自己的 Log Server 行為追蹤伺服器


紀錄?有這麼簡單嗎?

來吧~我們來提鍵盤來記錄使用者的行為紀錄吧!可是....當我們提起手指打下第一個字母後應該就會立刻遇到一個嚴重的問題,我們到底要記錄什麼?想知道什麼?身為程序猿的我們,我想我們永遠無法從 PM / 老闆得知答案的,他們有 99% 的機率會說 “都記錄啊!”。

那在公司第一線開發的我們,是不是有機會製作出一個通用且擴展性高的 Log 紀錄結構呢?能不能有機會從一筆 Log 就知道使用者的行為?如果 Log 能清楚明白地呈現出使用者到底在幹嘛,那可以非常大的程度降低 Log 的解讀門檻,讓公司的 PM、Marketing 甚至客服相關的同事們都可以從 Log 中釐清產品好壞的真相。


「人、事、時、地、物」

Log 紀錄就跟說話寫文章一樣,無非就是[哪一個使用者?][做了什麼事情?][什麼時候?][在哪裡?][對象是什麼?],依照上述的內容我們可以簡單的建立以下的資料結構: 

{

        user_id: '',         // 哪一個使用者?

        do: '',                 // 做了什麼事情?

        place_id: '',       // 在哪裡?

        target: '',          // 對象是什麼?

        create_time: '', // 什麼時候?

}

 

依造上述結構我們來試試看建立一筆記錄看看: 

/* 會員編號 2001 點擊購買按鈕 在 PG0001 產品頁面,在 2019-01-03 19:00:30 */

{

        user_id: '2001',                                      // 哪一個使用者?

        do: 'click_buy_button',                         // 做了什麼事情?

        place_id: 'product_page',                    // 在哪裡?

        target: 'PG0001',                                  // 對象是什麼?

        create_time: '2019-01-03 19:00:30', // 什麼時候?

}


可以從單筆紀錄很容易看出這個使用者當下的使用行為,但在實際運用上上述就容易遇到擴展性低的問題,所以我們稍微修改了一下資料結構,增加了一個彈性的 params 參數讓紀錄的擴展性可以高一些,並且可以記錄更多額外的參數,讓不同需求的同事能使用不同的參數來分析紀錄。

/* 會員編號 2001 點擊購買按鈕 在 PG0001 產品頁面,在 2019-01-03 19:00:30 */

/* 會員編號 2001 點擊購買按鈕 在 1000元 產品頁面,在 2019-01-03 19:00:30 */

/* 會員編號 2001 點擊購買按鈕 在 3C 產品頁面,在 2019-01-03 19:00:30 */

{

        user_id: '2001',                                    // 哪一個使用者?

        do: 'click_buy_button',                        // 做了什麼事情?

        place_id: 'product_page',                   // 在哪裡?

        params: {                                             // 對象是什麼?

                product_id: 'PG0001',

                product_price: '1000',

                product_type: '3C',

        }, 


        create_time: '2019-01-03 19:00:30', // 什麼時候?

}

 

好的~~您的彈性可擴展記錄結構的行為紀錄已經完成了,可以跟上頭交差順便打卡下班了。

就這麼結束了嗎?如果你是力求完美的程序猿,交出這個 Log 紀錄後應該會覺得這架構似乎符合紀錄資訊,可是又好像缺了些什麼?有點騷到了癢點可是卻沒止癢嗎?


您還能做得比想像多更多

Log 行為紀錄明確了,但是這些紀錄似乎又缺了些什麼?每筆紀錄都好像很有意義的存在,可是紀錄跟紀錄間卻有種很不明確的關係,我們來幫 Log 紀錄增加一個參數 pre_place_id 來紀錄上一頁 id 建立前後關聯吧!這個參數不只可以讓我們知道 Log 的前後關係來建立完整的行為紀錄追蹤,也可以讓其他同事得以分析此頁面的來源狀況是不是符合預期。 

/* 會員編號 2001 從產品搜尋頁來,點擊購買按鈕 在 PG0001 產品頁面,在 2019-01-03 19:00:30 */

/* 取得在 product_page 所有的 pre_place_id,分析哪些頁面來的最多 */

{

        user_id: '2001',                                      // 哪一個使用者?

        pre_place_id: 'product_search',          // 從哪來?

        place_id: 'product_page',                    // 在哪裡?

        do: 'click_buy_button',                         // 做了什麼事情?       

        params: {                                              // 對象是什麼?

                product_id: 'PG0001',

                product_type: '3C',

                product_price: '1000',

        }, 

        create_time: '2019-01-03 19:00:30', // 什麼時候?

}

 

另一個在解讀紀錄時會發生的問題是,使用者未登入時該怎麼辦?難道就不記錄嗎?這個的問題有很多種處理方法,很多的方法共同都會面臨要解決一個問題,在使用者未登入時賦予一個短時間不會重複的 id 作為另一種身份辨識使用。這邊我們提供最簡單的方法是給埋入 Server 建立的 Session_id:

/* 會員編號 2001 從產品搜尋頁來,點擊購買按鈕 在 PG0001 產品頁面,在 2019-01-03 19:00:30 */

/* 取得在 product_page 所有的 pre_place_id,分析哪些頁面來的最多 */

{

        session_id: '425jqk1a1m9ne8cqn5c44cib0j', // 哪一個使用者?

        user_id: '2001',                                                   // 哪一個使用者?

        do: 'click_buy_button',                                      // 做了什麼事情?

        pre_place_id: 'product_search',                       // 從哪來?

        place_id: 'product_page',                                 // 在哪裡?

        params: {                                                           // 對象是什麼?

                product_id: 'PG0001',

                product_type: '3C',

                product_price: '1000',

        }, 

        create_time: '2019-01-03 19:00:30',             // 什麼時候?

}

  

每次看資料時都需要調出所以 Log 資訊,是否我們也能透過前後關係明確,我們似乎也可以從資料中重新透過動作與頁面關係重新塑造結構一個使用者的完整行為方便觀看,以下為呈現當下重構結構的示意:

{

        session_id: '425jqk1a1m9ne8cqn5c44cib0j',

        user_id: '', 

        do: 'page_open', 

        place_id: 'index',

        params: {},

        create_time: '2019-01-03 19:00:30',

        action: [

                { 

                        do: 'send_login',

                        params: {},

                        create_time: '2019-01-03 19:03:35',

                },

                { 

                        do: 'click_productBox',

                        params: {

                                product_id: 'PG0001',

                        },

                        create_time: '2019-01-03 19:03:35',

                },

                ....

        ],

        next: [

                {

                        session_id: '425jqk1a1m9ne8cqn5c44cib0j',

                        user_id: '2001', 

                        do: 'page_open', 

                        place_id: 'product_page',

                        params: { 

                                product_id: 'PG0001',

                                product_type: '3C',

                                product_price: '1000',

                        }, 

                        create_time: '2019-01-03 19:03:37', 

                        action: [

                                ...

                        ],

                        next: [

                                ...

                        ],

                },

                ...

        ]

}

  

透過整理後的 action 與 next 來建立動作的描述結構,再透過上述結構利用繪圖模組建立圖形化整體資料

figure-2

透過圖表呈現,我們可以用行為追蹤的角度去理解使用者從何而來、做了什麼、去了哪裡,從茫茫紀錄中用輕鬆的方式建構使用者整體行為流程分析。


大功告成?

完成了 Log 行為紀錄追蹤整個架構好像完成了一件大事,但真正重要的事情才要準備展開,把所有的紀錄塞到資料庫只是所有事情的第一步,別忘了 UI / UX使用者體驗大數據分析 才是做 Log 行為紀錄追蹤的目的,紀錄在資料庫如果不去分析了解上面所做的事情都是枉然了,別讓紀錄就丟在資料庫中長草,時不時地把資料撈出來分析才是最重要的事情

 



如果您喜歡我們的文章,歡迎追蹤我們的方案,如對上述技術有其他疑惑或想討論的地方,也可透過下方留言大家一起討論,或訂閱我們的方案我們將提供專業的經驗分享與專業的技術建議。

拍手 拍手
好文章需要你的鼓勵
拍手 拍手
追蹤

推薦文章

您需要 後才能開始留言
還沒有人討論誒,快來搶沙發...
聲音節目
沒有描述
--:--
--:--
1.0x
播放速度
2.0x
1.75x
1.5x
1.25x
1.0x
0.75x
收藏節目
播放清單
沒有播放清單
沒有待播放的清單
返回播放器
接著播放
清除全部
沒有待播放的清單