基于百度地圖的用戶投訴圖形化分析工具開發

中國電信股份有限公司商丘分公司 劉干 劉博琳 李超光

針對用戶投訴高發區域定位過程繁瑣的問題，提供一種基于百度地圖的可視化分析工具。首先通過在程序中嵌入百度地圖的方式，實現數據查詢和地圖展示；然后將投訴點進行聚合，生成可視化圖層，定位投訴高發區域；接著根據用戶投訴情況，結合周邊基站信息，分析問題原因；最后針對問題，制定可行的解決方案。工具簡化了投訴分析過程，為用戶投訴高發區域的問題分析提供了有效參考。

隨著5G 網絡建設逐步推進，越來越多的用戶享受到5G 網絡帶來的高速上網體驗。在無線網絡為用戶提供便捷高效的通信服務的同時，用戶對網絡的依賴性更強，對網絡質量的要求更高。而隨著用戶對無線網絡期望的提升，產生了更多的投訴。在2G/3G/4G/5G 共存的復雜組網架構下，網優人員的用戶投訴分析工作面臨新的挑戰。為了簡化投訴分析流程，提升投訴處理效率，減輕投訴處理人員的工作負擔，我們需要對投訴分析方法進行研究，從而更加快速精準地對問題原因進行定位。

1 程序總體設計思路

根據目前可使用的數據，編寫程序來實現投訴點的圖形化顯示分析具有可行性。為了讓程序可以更快地被接受使用，操作步驟既要方便簡潔，又要符合使用人員的操作習慣，為此我們參考了本地投訴處理人員的分析思路對程序進行設計。

首先確定程序需要實現的目標。考慮到投訴處理人員在日常工作中，既需要對投訴內容與用戶進行溝通，查找問題產生的具體原因，又需要定期分析投訴發生情況，提供優化建議。因此程序需要實現以下功能：（1）投訴信息及周邊信息的圖形化顯示；（2）投訴數據的分析匯總功能；（3）投訴分析過程中的輔助測量功能。

為了實現上述功能，參考日常投訴處理方法，確定了對投訴數據的處理流程：首先由.NET 程序對投訴信息進行處理，從區縣、問題現象、投訴原因等維度對數據進行匯總，用于展示投訴的整體情況；然后根據投訴數據的關鍵字段，生成投訴點的位置數據，用于顯示投訴相關信息；最后根據日常工作的使用需求，在地圖文件中添加測距、基站信息顯示、經緯度定位等輔助功能。程序功能結構圖如圖1所示。

圖1 程序功能結構圖Fig.1 Program function structure diagram

程序中百度地圖的顯示，是通過在.NET 程序中嵌入Chrome 控件，由控件加載HTML（Hyper Text Markup Language，超文本標記語言）文件來實現的。由于Chrome 控件對應瀏覽器的版本是固定的，這樣做既可以避免因瀏覽器版本不同造成顯示異常，又可以很方便的對控件的加載內容進行調整。

2 投訴數據圖形化顯示方案

2.1 投訴數據的來源

投訴處理過程中，對于網絡質量類問題，會由投訴處理人員對用戶進行回訪。根據用戶提供的信息，記錄下日期、營業部、投訴內容、網絡問題位置等關鍵信息，作為投訴分析和問題處理的依據。

由于投訴數據來源于多位工作人員，因此需要統一數據記錄的口徑來提升數據質量。詳細準確的記錄有利于提升數據分析的準確性和問題的解決速度。

2.2 投訴熱點區域呈現

對投訴點分析時，相對于表格匯總，采用圖形顯示的方式往往更加直觀。一方面可以根據圖形的高度或顏色，很容易發現高投訴量區域；另一方面可以將投訴與地圖結合起來，快速對問題點進行定位。根據投訴處理過程，通常需要先找到投訴熱點區域，然后對區域內的投訴點逐個分析，因此程序將投訴點顯示功能分為了聚合顯示和分散顯示兩種。

（1）聚合顯示。聚合顯示用于顯示投訴的整體情況，實現方式為調用百度地圖的MAPVGL 功能。百度地圖API 本身提供了多種聚合顯示方式，例如熱力點、熱力柱、煙花點和波紋點等，可以選擇其中的一種或多種方式進行圖形呈現。由于不同種類熱力圖的投訴點數據可以通用，因此只需要調整熱力圖的生成代碼就可以實現不同類型熱力圖的顯示切換。具體來說就是在.NET 程序處理投訴信息后，生成JS 文件來儲存投訴點信息。然后根據使用者選擇的熱力圖類型，將嵌入文件中保存的熱力圖代碼寫入網頁中。由于每種熱力圖代碼中投訴點信息的引入來源均為JS 文件，因此無論采用哪種聚合顯示方式，都可以正確反應投訴點的分布信息。另外，熱力圖本身也存在多個關鍵參數來控制顯示圖形的大小、顏色、高度閾值和動畫時間等顯示效果，通過使用配置文件來記錄使用者的當前設置。

而在工具使用過程中，對于聚合顯示功能，可能會因數據分析或是寫分析報告的需要，頻繁切換顯示方式來對比采用不同聚合方式下的顯示效果。因此為了保持地圖使用的連續性，與地圖顯示相關的參數在切換過程中需要保持一致，否則會影響使用者對區域內投訴情況的觀察。顯示相關的參數包括：地圖中心點、縮放等級、地圖朝向、地圖的傾斜角度和地圖切換前瀏覽的內容。在地圖切換前，我們將這些參數傳遞到.NET 程序中進行保存，新地圖生成后，地圖加載前，對新生成地圖中的相關參數進行修改，來保證顯示方式的切換不會改變使用者的觀察對象。

如圖2所示，通過對投訴點聚合顯示，可以快速發現投訴熱點區域。在發現了熱點投訴區域后，接下來需要分析區域內投訴點的分布，此時將熱點區域顯示切換為區域內的投訴點進行顯示。

圖2 投訴點聚合顯示Fig.2 Aggregated display of complaint points

（2）散點顯示。散點顯示用于呈現某片區域內投訴點的具體情況，顯示類型為帶標簽的坐標點，標簽顯示內容設定為對投訴內容的描述。對位于市區縣城內的投訴點進行分析時，通常需要考慮樓宇遮擋對信號的影響，因此投訴點散點顯示時的地圖需要有足夠大的縮放等級。此時地圖可以顯示出周邊建筑信息，在該放大等級下設置打點和扇區圖形的大小可以方便投訴處理人員查看地圖上的樓宇、道路和其他建筑物的信息，作為投訴原因分析時的參考內容。

在分析工具使用過程中，對于散點顯示功能，我們發現如果采用較長周期的投訴數據，地圖上某些區域的投訴點會比較密集。大量標簽同時顯示時出現互相遮擋的情況，導致很難觀察到目標投訴點的投訴描述，此時顯示效果較差。為了避免標簽顯示混亂，投訴點的標簽被默認設置為隱藏，考慮到標簽的整體顯示也存在使用場景，于是在下方添加了按鈕用來切換標簽的整體顯示和隱藏。除此之外，還對投訴點添加了鼠標的移入移出事件。當鼠標移動到投訴點上會觸發Mouseover 事件，此時也會顯示該投訴點的信息，鼠標移出時則根據標簽是否整體顯示來判斷標簽是否顯示和隱藏。通過這些設置，使用者可以靈活選擇分析時想要查看的投訴點信息，提升了工具的易用性。

2.3 輔助分析功能添加

在對投訴高發區域內的投訴點進行分析時，通常需要根據地理位置、小區分布等因素判斷是否存在弱覆蓋、干擾或設備故障。因此添加了測距、經緯度定位、圈定小區和周邊小區信息顯示的功能，用于在投訴分析過程中，輔助問題原因的分析。下面分別說明各個功能的實現方式：

（1）由于百度地圖API 提供測距功能，所以直接調用了DistanceTool 來實現地圖測距，相關設置在腳本文件DistanceTool.min.js 中可以進行調整。

（2）經緯度定位方面，由于網絡部門人員使用的是WGS84 坐標系下的經緯度坐標，而用戶更習慣使用手機自帶的百度地圖進行定位，同一個經緯度在不同坐標系下會產生位置偏移，因此在進行經緯度定位時，分別提供了這兩種坐標系下的經緯度打點定位功能。兩種坐標系中，BD09 坐標系下的經緯度可以直接在百度地圖上進行打點，而WGS84 坐標需要先轉換為BD09 坐標，然后再通過百度地圖進行打點。WGS84 坐標向BD09 坐標轉換，既可以使用百度地圖提供的坐標轉換接口進行轉換，也可以使用近似計算的方式來轉換[1]。使用百度地圖接口轉換的精度高，但由于需要將數據發送給坐標轉換接口，接收到轉換結果的時間較長。而近似計算則是將WGS84 坐標轉換為GCJ02 坐標，然后將GCJ02 坐標轉換為BD09 坐標，由于是在本地計算機上計算，轉換結果生成速度較快。

（3）圈定小區和周邊小區信息顯示功能的實現，首先由JS 修改Chrome 控件的參數作為觸發事件，然后.NET程序監聽到此類事件后，根據控件傳遞來的數據，按照預先設定的處理方案來執行對應操作。例如當繪制圓形來圈定基站時，先由Chrome 控件向.NET 程序傳遞圈定范圍的中心點和半徑大小，然后由.NET 程序分別計算周邊小區與中心點間的距離，判斷小區是否在圈定范圍內。最后對圈定范圍內的所有小區按照與中心點的距離進行排序，將排序后的小區信息和距離信息添加到Datagridview 控件中進行展示。

2.4 小區數據加載方式優化

地圖中需要顯示的數據有投訴點和周邊小區兩類，投訴點因數量相對較少且顯示圖形簡單，通常可以直接加載。而小區由于數量較多，方位角繪制會使圖形變得更加復雜，直接加載可能會出現加載時間過長的問題，影響使用感知，因此需要優化小區數據的加載方式。

（1）小區加載的問題。由于大量小區同時加載會導致地圖顯示速度變慢，因此使用了劃分柵格加載的方式，通過只繪制必要的小區來減少地圖的加載時間[2]。先在地圖上使用一個矩形將小區所在區域完全包圍，該區域一般是地市所在范圍。矩形的四個角根據經緯度最大值和最小值決定。然后將矩形分割為若干小正方形，正方形邊長由當前地圖縮放等級決定，需要確保控件顯示區域內的基站可以被顯示。之后根據地圖中心點所在柵格的編號，分別考慮當中心點位于邊緣柵格、矩形四個角所在柵格和其他柵格情況下，需要加載的柵格編號。每次只加載中心點所在柵格及周邊柵格內的小區數據，繪制出小區圖形，而不繪制其他柵格內的小區。

（2）地圖縮放時出現的問題。隨著地圖縮放等級逐漸縮小，地圖柵格中包含的小區數量會越來越多，既影響了地圖的加載時間，也會導致投訴點過于密集而影響顯示效果。為了解決這個問題，對比了不同縮放等級下的顯示效果，觀察到當地圖縮放等級小于13 時，由于地圖中的顯示的區域相對較大，此時繪制后的扇形小區重疊問題嚴重，影響地圖的顯示效果，此時適合將小區信息按點進行顯示。而當地圖縮放等級在13 以上時，已經可以比較明顯的看到地圖上的街道和建筑信息[3]，此時地圖上的基站分布也較為分散，相鄰扇區的繪圖重疊問題得到改善，此時對小區圖形進行繪制。

（3）還需要解決地圖變化時小區顯示更新的問題。當使用者拖動地圖后，控件顯示區域的柵格可能會發生變化，此時需要根據相應的事件，觸發對顯示小區的更新。通過查閱百度地圖開發文檔，發現當地圖發生拖拽后，地圖的Dragend 事件會被觸發，于是可以將該事件的發生作為地圖需要重新加載的觸發標志。當Dragend事件發生時，地圖的中心點發生變更，此時將參數傳遞給.NET 程序，由.NET 程序依據獲取的經緯度確定當前應顯示的柵格，然后對柵格內的小區進行重新繪制。

2.5 使用效果對比

為了驗證圖形化分析方法對投訴處理的有效性，我們選取了最近一個月內的投訴數據進行分析驗證。將投訴數據和工參導入程序，在生成的投訴熱力柱中，選擇若干Top 區域內的投訴點數據分析投訴原因，然后與人工分析進行對比。通過對比分析結果，圖形化分析和人工分析均可以發現熱點投訴區域，分析數據可用于后續的投訴處理。從處理過程上來看，相對于人工查找投訴熱點，結合百度地圖進行圖形化分析更加容易上手，可以更快發現熱點投訴區域，避免因疏忽遺漏問題點，能夠有效提升投訴處理效率，提升了處理準確性。

3 結語

處理好用戶投訴對提升用戶滿意度和實現網絡價值都具有重要的作用，尤其是在當前通信行業對客戶體驗愈發關注的情況下，提升自身的服務質量和服務效率，才能在激烈的市場競爭中脫穎而出。通過采用數字化的分析手段，逐步優化投訴處理方法，提升投訴分析的準確性和處理的及時性，這對接下來客戶服務能力的提升提供了一個發展方向。