編輯導語：如今網際網路行業發展完善，很多時候會用業務資料化的方式進行業務運轉和資料的提取，業務資料化也需要各部門的配合；本文作者詳細介紹了什麼是業務資料化，以及如何踐行，我們一起來看一下。
“業務資料化“這一概念屬於老生常談，網際網路行業中，資料是一切行為的基礎；業務運轉過程中會產生、積累大量的資料，在大量的資料中提取重要資訊利用、分析、迭代，才能促進業務可持續的正向發展——這一完整的迴圈過程才能稱之為“業務資料化”。
今天就從實際工作場景出發聊聊“業務資料化”該如何實現；說到“業務資料化”，不得不先講講各工種之間的配合。
老闆下達一個決策命令，資訊傳輸的先後順序通常如下圖所示：
首先是產品和運營，這裡的產品指前臺產品，如：扛起DAU的使用者產品、扛起收入的商業產品，他們站在業務的前線，距離決策指令是最近的。
接下來是資料分析師，他會穿梭於各種評估、彙報、覆盤之間，接收到的資訊基本是二手資訊。
然後是資料產品，前臺產品、運營、分析師分別從各自的角度驗證專案的可行性，最終才會推進業務指標、模型的系統化、視覺化。
最後是資料開發工程師，處於資訊傳輸的末梢。
大家應該都知道接力猜詞的遊戲，在資訊傳達的過程中一定會出現折損和偏差，團隊各環節都很關鍵，配合度決定了遊戲的結局。
業務運轉中，如果資料生產使用閉環遇到障礙，可能會導致資料產品、工程師的產出滿足不了業務同學的訴求；業務同學提出的零散資料需求，會被視為資料體系之外的邊緣化需求；夾在中間的分析師同學會接到很多取數需求做著重複的機械勞動。
久而久之，出現斷層，業務資料只做到了積累沒有高效應用，業務資料化就成了空話。
這個過程中，資料分析師就應該起到承上啟下的作用，跟前臺產品、運營比更懂資料，跟資料產品、工程師比更懂業務，且站在資訊傳輸的中心。
以具體資料需求為例，還原推進場景：一個Landing Page使用者訪問路徑資料需求。
業務同學的訴求：需要知道使用者從起始訪問頁面至轉化行為頁面中，訪問了哪些頁面觸發了哪些點，記錄訪問的先後順序，並且對產生的轉化量做頁面和點的歸因。（內心OS：使用者的行為日誌裡不應該都有嗎？這是個基礎建設的需求，理應滿足！）
資料產品同學：背景是？資料細到使用者的應用場景是？如果是低頻需求分析師不可以支援嗎？（內心OS：你知道這資料量有多大嗎？平臺上已有的路徑分析不能滿足你們的需求嗎？）
分析師：……（內心OS：又躺槍了）溝通一度陷入僵局。
我們拋開自身的職業立場來分析一下這個需求。
“需要知道使用者從起始訪問頁面至轉化行為頁面中，訪問了哪些頁面觸發了哪些點”，是因為需要知道使用者會在哪些頁面的哪些位置轉化？中間經歷了多少步？縮短能否提升轉化率？
“記錄訪問的先後順序”，是因為不同的訪問順序代表了使用者的不同意圖。
“聚合頁→列表頁→聚合頁→詳情頁”和“聚合頁→列表頁→詳情頁→詳情頁”，同樣經歷4步轉化，前者初斷：推薦並不精準使用者帶有明確意圖訪問轉化。
後者初斷：使用者根據推薦內容轉化；“並且對產生的轉化量做頁面和點的歸因”所有的動作都需要量化拆解，才能更好的達成目標。
02 如何實現業務資料化？相信業務方在提出資料需求之前一定做過資料分析的工作了，無論是自己分析還是提需求給分析師，此時承擔分析師角色同學的表述都十分關鍵。
優秀的分析師該這樣做：
1. 闡明需求背景這個Q頁面CVR增長的OKR是環比+10%，產品同學在目標拆解的過程中發現沒有辦法把目標拆到頁面的具體ICON，這就沒有辦法細化頁面最佳化方案。所以向我求助。
2. 描述已驗證的實現方法1）根據產品同學的訴求，我制定了分析框架，總結起來要得到的核心結論是：使用者轉化在哪類頁面的哪個位置？經歷了幾步動作？轉化前訪問路徑特徵能否說明使用者意圖？建議最佳化哪些位置可以使頁面CVR環比增長10%？分別會帶來多少增長？
2）我看了一下平臺現有功能，只要頁面流量路徑，沒有定位到頁面和具體ICON的點選轉化。
3）我查看了底層的A、B、C、D表目前缺少的是頁面與點之間路徑的串聯。
頁面cvr增長10%，會帶來**%的客戶增長，進而帶來**%的收入增長，這個專案能夠帶來的收益還是很客觀的，你可以評估一下。
一頓操作猛如虎，相信資料產品同學最後會鄭重的接了這個大專案並把它規劃到這個Q的OKR裡面；可見，業務資料化的關鍵是利用資料的客觀性證明了需求的可行性，進而減少了資訊傳遞過程中的折損，統一了目標；業務資料的良性迴圈，對於業務的發展一定是如虎添翼。
今天的事例場景不僅想要展現業務資料化如何實踐，更想要寫給很多正奮戰在工作崗位上的分析師同學。
怎樣擺脫查數姑、大表姐的單一定位？怎麼證明自己的價值？
那就是跨界交流！熟悉業務、瞭解資料架構、提升專案推進能力，這些跨界技能可以幫助我們充分的實現自己的價值，會讓我們未來的路越走越寬！
#專欄作家#大鵬，公眾號：一個數據人的自留地。人人都是產品經理專欄作家，《資料產品經理修煉手冊》作者。
本文原創釋出於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議。