• 前言：

• 1. 分析思路

  • 1.1 定位問題

  • 1.2 排查影響因素

• 2. 自動化實現

  • 2.1 必備功能（由始至終）

  • 2.2 面向用戶（由內而外）

  • 2.3 前后端邏輯

前言：

作為一名數據分析師，分析“某某指標下降或者提升”是非常日常的工作。但如果每次一遇到這類問題就一通操作分析，著實有些耽誤時間。好在這類“指標異動”的分析通常是有一些固定的套路的，邏輯并不復雜。

因此，咱們嘗試抽象出這類問題的解決方法，并做一個「自動分析」的工具，來替代數據分析師的這部分日常工作，解放生產力呀。

本文就拿“GMV異動”舉例，來介紹這類指標異動的分析思路、以及如何實現自動化。

其中“分析思路”在業內主要有兩種：貢獻度和基尼系數。本文主要介紹前者。

1. 分析思路

1.1 定位問題

1. 確定發生期和基準期

即：什么時候相對什么時候的下降？

• 發生期：GMV產生變化的時期，比如2021年11月1號-11月30號

• 基準期：參照期，比如2021年10月1號-10月31號

這里注意，發生期和基準期的天數是否相同？如果是相同，那么直接對比總GMV變化就行；反之可以對比他們的日均GMV變化。為了方便“自動化”，我們暫且都按日均GMV算。

2. 確定數據準確性

這是我們在收到“GMV異動”時候，第一個要排查的因素！

為什么要把【數據準確性】放到第一個？因為以免我們吭哧吭哧分析半天后發現：“原來只是數據源出問題了”，白白浪費了分析資源！

那么數據準確性可以從以下幾個方向確定：

• 數據傳輸、存儲、清洗有沒有問題？

• 與該指標（GMV）關聯的其他指標是否異常？

• 指標統計口徑是否異常？

• 是否有業務邏輯上的更改？

• 是否埋點上報異常？

• 是否指標計算方式更改？

3. 按【GMV=dau轉化率客單價】來定位問題所在

到此，我們進入正題，開始開始定位GMV異動的可能原因。

按GMV公式，我們分3步驟探索：

定位GMV下降的特征——對應GMV本身

是否是由于dau基數影響到gmv——對應公式里的dau

定位GMV下降的特征的支付漏斗折損位置——對應公式里的轉化率

下面具體展開：

1）定位GMV下降的特征

統計GMV的常見維度，分為固有屬性和變化屬性，如：

• 固有屬性：（用戶從一開始就自帶的屬性，在之后的行為里都不會發生變化）

• 新增渠道：ios，華為，小米，vivo，oppo，其他...

• 城市線 ：一線，二線，三線，...

• ...

變化屬性：（用戶在之后的行為里可能會產生變化的）

• 支付時段：0-6點，6-12點，12-18點，18-24點

• 支付方式：sdk支付，微信支付，...

• sku類型：包月，包季，包年，...

• ...

展開這些維度，計算這些維度下的特征對GMV異動的貢獻度，并按貢獻度降序排名

記：

發生期各維度的特征為gmv2，總值為sum2

基準期各維度的特征為gmv1，總值為sum1

某特征貢獻度=(gmv2-gmv1)/(sum2-sum1)

給貢獻度設定閾值，認為超過該閾值就是需要重視的特征，比如“貢獻度超過20%”就算它是影響GMV異動的特征

把以上特征分為【固有特征】和【變化特征】

2）是否是由于dau基數影響到gmv

計算兩個時期下的【固有特征】的特征的DAU相對差異：

同樣還是給差異設定閾值，如果超過該閾值就是dau基數影響了GMV。

比如：

“新增渠道-ios，在發生期的dau比基準期的dau低了50%”，那我們就認為ios的基數變化可能是影響GMV異動的因素之一。

3）定位GMV下降的特征的支付漏斗折損位置

計算兩個時期下的【固有特征】和【變化特征】的轉化漏斗，來看是哪個位置的上級轉化率產生較大差異。

比如：

支付路徑為【a-b-c-d-e】，其中發生期和基準期的【a-b-c-d】的各級轉化率的相對差異不超過5%，比較穩定；但是發生期【d-e】的上級轉化率的比對照期低50%，那我們認為【d-e】是一個對GMV異動折損比較大的位置。

綜上，我們基本定位到：

• 是哪些特征的GMV產生了異動？

• 是否是因為這些特征原本的基數（dau）異動了，而導致GMV異動？

• 在這些特征下的支付路徑上，有哪些位置產生了折損？

1.2 排查影響因素

我們再繼續從產品內外部尋找可能導致產生“異動特征和折損位置”的事件。

1. 內部

• 大盤

  • 拉長時間軸到去年/上季度/上月/上周同期，看歷史異常還是近期異常？*添加其他產品的同期數據，看是否大家都是異常？

• 產品

  • 發生期的版本是否有功能調整、樣式改版、策略調整？

  • 發生期的版本是否有其他缺陷？

• 技術

  • 【支付路徑】之間哪里有bug？

• 運營

  • 運營活動、push效果如何？

  • 拉新渠道、投放推廣是否發生變化？

• 用戶

  • 用戶群是否發生變化？

2. 外部（PEST）

• 政治

  • 政策影響、監管

• 經濟

  • 竟品app數據、雙11、618

• 社會

  • 假期效應：開學季、暑期、傳統節假日

  • 熱點事件：突發熱點

綜上，我們基本能定位到GMV下降的可能原因：

找出“異動特征和折損位置”

找出產生“異動特征和折損位置”的事件

2. 自動化實現

所謂“自動化”，其實是指：開發一個讓“GMV下降”能夠一鍵分析的數據產品。

我們首先需要確認該產品的必備功能；其次是它的面向用戶，即“給誰用”；最后確定該產品的前端展示和后端交互邏輯。

2.1 必備功能（由始至終）

把必備功能分為以下3類：

• 展示現狀：剛開始讓用戶看到他所要分析的2個時期的GMV現狀，每天是如何波動的？絕對值差異和相對差異分別是啥樣的？

• 自動一鍵分析：接下來交給我們后臺一鍵分析，除了給出“異動特征和折損位置”的數據過程，還要對其每一步進行自動化文字解讀。

• 快速：最后盡量使整個“一鍵分析”的過程控制在秒級別

2.2 面向用戶（由內而外）

知道用戶是誰，才能知道給他具體做什么功能；以及讓這些功能的理解成本最低、用起來順手又方便。

• 數據人員：

  • 因為原本的“異動分析”工作是咱們數據分析師承擔的，因此得要這個產品首先滿足咱們自己人，先要讓分析師用起來爽；

  • 即使該產品的理解門檻高，分析師也能比較容易的解讀。

• 業務人員：

  • 其次是最關注“異動分析”的是業務同學，業務同學對“分析思路”的理解成本相對分析師要高一些，因此我們要把該產品的理解成本再降低，讓業務更快跑起來！

  • 有的業務同學在獲取“GMV異動原因”的信息后，需要把這個解讀匯報給領導，因此存在“信息二次傳遞”的情況，我們還需要繼續往外考慮。

• 領導：

  • 最后我們希望該產品能夠被領導們用（稱）上（贊）呀！讓領導們能夠自由分析、提高信息傳遞的效率，因此就更需要讓該產品容易用、好用。

2.3 前后端邏輯

根據以上對產品功能、面向用戶的明確，我們最后把產品的設計為如下幾部分：

1. 前端

• 篩選區域：

  • 日期：發生期、基準期

  • 各個維度

• 數據現況展示：（使用GMV分區表）

  • 相對差異：（發生期-基準期）/基準期，也按day1-dayn展開

  • 基準期是20天、發生期是15天

  • 那么橫軸上起點是基準期和發生期的第一天的GMV、以此往后推

  • 基準期的是day1-day20、發生期是day1-day15

  • 橫軸上先是基準期、再是發生期

  • 拉長自然日期的GMV展示，比如：

  • 合并2個時期的GMV絕對值展示，比如：

  • 合并2個時期的GMV相對差異展示

• 貢獻度分析：（使用GMV分區表）

• DAU分析：（使用支付漏斗表）

• 漏斗分析：（使用支付漏斗表）

以上3個步驟是對應【1.1定位問題：按【GMV=dau轉化率客單價】來定位問題所在】

• 大事件：

  • 大事件是指【排查因素里的內外部事件】，這部分需要人工手動維護。

• 自動化總結

  • 對以上每個步驟的自動化文字總結，這樣更方便用戶理解分析過程。

2. 后端數據

• GMV分區表（按各維度展開）

• 支付路徑漏斗表（按各維度展開）

到此，實現“自動化GMV異動分析”的講解就結束啦。總之，本文的分析思路是簡化版，具體還需要各位大佬結合實際業務場景做定制化的修改啦～

·················END·················

總結

以上是生活随笔為你收集整理的如何让“GMV下降”实现自动化分析？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。