[發(fā)明專利]一種數(shù)據(jù)埋點(diǎn)的配置方法、存儲介質(zhì)及設(shè)備

有效

• 申請?zhí)枺?/td>: 202111645403.8
• 申請日: 2021-12-30
• 公開（公告）號: CN114356733B
• 公開（公告）日: 2022-09-16
• 發(fā)明（設(shè)計(jì)）人: 陳文海;趙鑫鑫;佘文文
• 申請（專利權(quán)）人: 山東辰華科技信息有限公司
• 主分類號: G06F11/34
• 分類號: G06F11/34;G06F11/32
• 代理公司: 暫無信息
• 代理人: 暫無信息

本發(fā)明的一種數(shù)據(jù)埋點(diǎn)的配置方法、存儲介質(zhì)及設(shè)備，其中方法包括以下步驟，S1、采用全埋點(diǎn)+代碼埋點(diǎn)的綜合模式，設(shè)定前端記錄用戶的行為日志，對頁面訪問、按鈕點(diǎn)擊這些基礎(chǔ)事件，全面記錄和上報(bào)，對功能事件，增加專門的埋點(diǎn)；S2、基于后端同步各項(xiàng)業(yè)務(wù)數(shù)據(jù)日志，建立維度信息表，完善EV事件的處理方法，確保數(shù)據(jù)的準(zhǔn)確性和全面性；S3、進(jìn)行埋點(diǎn)流程管理和數(shù)據(jù)過濾管理。本發(fā)明能夠基于埋點(diǎn)配置、處理和埋點(diǎn)系統(tǒng)進(jìn)行埋點(diǎn)流程管控和方案編制，完善埋點(diǎn)技術(shù)方案的頂層設(shè)計(jì)，通過業(yè)務(wù)映射增加對事件信息和屬性信息的理解，監(jiān)控使用情況，解決埋點(diǎn)的觸發(fā)機(jī)制不清晰不明確的問題，提升埋點(diǎn)數(shù)據(jù)準(zhǔn)確性和全面性。

技術(shù)領(lǐng)域

本發(fā)明涉及數(shù)據(jù)采集技術(shù)領(lǐng)域，具體涉及一種數(shù)據(jù)埋點(diǎn)的配置方法、系統(tǒng)及設(shè)備。

背景技術(shù)

所謂埋點(diǎn)，就是數(shù)據(jù)采集領(lǐng)域的術(shù)語，作為一種常用的數(shù)據(jù)收集方法，它的學(xué)名應(yīng)該叫做事件追蹤，對應(yīng)的英文是Event Tracking，指的是針對特定用戶行為或事件進(jìn)行捕獲，處理和發(fā)送的相關(guān)技術(shù)及其實(shí)施過程。

數(shù)據(jù)埋點(diǎn)是基于業(yè)務(wù)需求或者產(chǎn)品需求對用戶行為的每一個(gè)事件對應(yīng)位置進(jìn)行開發(fā)埋點(diǎn)，并通過上報(bào)埋點(diǎn)的數(shù)據(jù)結(jié)果，記錄匯總數(shù)據(jù)后進(jìn)行分析，推動產(chǎn)品優(yōu)化和指導(dǎo)運(yùn)營，或者用于研究用戶的行為習(xí)慣等方面。

比如直接采用友盟、百度統(tǒng)計(jì)這樣的第三方統(tǒng)計(jì)工具進(jìn)行數(shù)據(jù)埋點(diǎn)，通過嵌入AppSDK 或JS SDK，來直接查看統(tǒng)計(jì)數(shù)據(jù)。這種方式只能采集很基礎(chǔ)的數(shù)據(jù)，比如頁面訪問，按鈕點(diǎn)擊等等，但是想分析各個(gè)維度的情況，分析服務(wù)端的庫存、訂單等情況，就基本上無法實(shí)現(xiàn)。

再如企業(yè)自行設(shè)計(jì)進(jìn)行人為埋點(diǎn)，只使用業(yè)務(wù)數(shù)據(jù)庫來完成數(shù)據(jù)分析，理論上可行，但是由于業(yè)務(wù)數(shù)據(jù)庫面向OLTP的業(yè)務(wù)事務(wù)過程，很多中間數(shù)據(jù)不會保存，很多分析沒辦法做，且性能上完全不支持大規(guī)模的數(shù)據(jù)分析，運(yùn)行速度遲緩。

在埋點(diǎn)的實(shí)際操作過程中，經(jīng)常會遇到各種技術(shù)問題，比如：

① 業(yè)務(wù)兼容的問題

前期規(guī)范執(zhí)行之后，后續(xù)隨著業(yè)務(wù)的拓展，已有數(shù)據(jù)字段滿足不了業(yè)務(wù)的分析需求；

②產(chǎn)品兼容的問題

埋點(diǎn)從應(yīng)用端來區(qū)分，包括web/ios/android、小程序、公眾號，還要區(qū)分是原生還是H5，新老版本之間肯定會帶來一些模塊化的差異；

③前后端埋點(diǎn)不一致的問題

前端請求服務(wù)端的數(shù)據(jù)大多是存在binlog里面的，數(shù)據(jù)日志同步解析的過程里面可能會存在丟包的可能性，數(shù)據(jù)倉庫的穩(wěn)定性也會影響數(shù)據(jù)質(zhì)量；后端服務(wù)信息存儲的數(shù)據(jù)是存在mysql，表字段結(jié)構(gòu)化，分多表存儲，需要靠主鍵進(jìn)行關(guān)聯(lián)，有大量的ETL過程，兩者之間可能因?yàn)閿?shù)據(jù)清洗、處理、實(shí)時(shí)技術(shù)等原因，造成數(shù)據(jù)差異化；

④ 自埋點(diǎn)和第三方應(yīng)用統(tǒng)計(jì)口徑的問題

自埋點(diǎn)一般都會定義一個(gè)唯一id作為區(qū)分用戶的標(biāo)志，但是第三方是缺少用戶屬性信息的判斷，一般會以設(shè)備號uuid/imei，或者IP地址段、mac地址段作為區(qū)分標(biāo)志，從而造成統(tǒng)計(jì)數(shù)據(jù)上的差異化，對于留存分析、轉(zhuǎn)化分析、流失分析需要用到明細(xì)數(shù)據(jù)的場景，可兼容性不是很友好；

⑤ 埋點(diǎn)開發(fā)技術(shù)執(zhí)行不到位的問題

絕大多數(shù)情況下說埋點(diǎn)，一般都是說前端埋點(diǎn)，前端開發(fā)工程師在做埋點(diǎn)的時(shí)候又多是人為埋點(diǎn)，在開發(fā)過程中，會造成部分信息冗余、重復(fù)、記錄不完整的情況存在；

⑥多產(chǎn)品之間的模塊差異化問題

埋點(diǎn)不能夠只有一套標(biāo)準(zhǔn)規(guī)范，多生態(tài)應(yīng)用下，業(yè)務(wù)繁瑣，在產(chǎn)品、技術(shù)的架構(gòu)上有明顯的差異，不同的產(chǎn)品、模塊、坑位、點(diǎn)擊事件的定義也可能有一定的區(qū)別，這時(shí)候可能需要根據(jù)場景劃分不同的埋點(diǎn)標(biāo)準(zhǔn)；

⑦自定義埋點(diǎn)信息的鍵對設(shè)計(jì)問題