---
tags: JUJI
---

# 績效指標討論
## 10/20會議記錄
* 會議摘要
* 時間相關指標建議放在第二階段
* 營運相關數據統一用DB數據，以dashboard呈現，再下載/加工呈報上去
* firebase埋點收集到的資料目前沒有抄寫至DB，所以斷點監控的數據須至後台查詢
* 細部討論
* 導流
* 目前沒有規劃要投入行銷成本來獲客，不用看行銷成本轉換率
* 未來直接導到官網或app store，進行A/B test測試成效
* 註冊
* 只要完成註冊，同意隱私權&個資運用，就算是我們的會員，我們就可運用客戶的資料
* 申請
* 緊急聯絡人那個頁面提交後打API，後端就會建資料在DB，後台畫面呈現資料還在上傳中，且後台人員無法進行審核。要等到完成撥款帳戶填寫及上傳才算申請完成，後台人員才可進行審核。
* 保留方案件數：只要有按保留方案按鈕就算
* 欲申請方案-額度/期數/手機廠牌型號/手機不符還是要埋點，以便抓出沒有完成申請客戶的資訊
* 審核
* 系統撤件類型
* 未完成補件：DB會有值
* 方案到期：DB不會有值
* 先只看整體平均審核時間，不看各階段審核時間
* 在審核階段，審核成功會請客戶繼續簽約，客戶可以主動取消申請(按「忍痛放棄」按鈕)
* 撥款
* 資料有誤，重新申請：撥款資訊有誤，客戶想要重新申請時點擊
* 撥款是即時發動的，按下確認後直接打銀行API進行撥款
* 撥款失敗原因有系統因素, 帳戶沒錢或帳戶有問題，有抄寫至log，但目前無法判斷是否因警示戶而撥款失敗
* 資金的監控須每日更新
* 帳單資訊都是先寫好，資訊有異動才會啟動排程去覆蓋資料，像是有發生延滯，滯納金就會覆寫為100。
* 違約
* 催收目前都還沒有資料
* 延滯幾天算違約 (M3)，發生違約了再委外請人催收，三個月後無法收回的認列呆帳
* 收益
* 收益頻率改成週
* 預期收入：先估當月可能會發生的利息收入
* 實際收入：平台費＋已繳利息收入
* 客服
* 頻率改成月

* 待辦事項
* 目前APP使用行為無法比對至本人，確認是否有方法可以做到身份比對 (Jasmine)
* 了解/申請Redash權限 (Brady)

## 10/31會議記錄
* 日報 (動能＆營運)
* 產表時間：每天早上1點產前一天案件
* 成功撥款
* 對應金流出帳，會有網銀資料，所以會有報表
* 撥款失敗
* 後台下載的excel，看不到銀行的reject code，要手動去撈取資料
* 上線初期為了追蹤業績動能，部分關鍵指標(標註粉紅色)先產日報，後期再改成週報，並於站站更新案件狀況＆採取行動
* 審查中代碼都會是10 (包含財力證明未審或未完成電話照會)，若審核都完成，只差主管放行，代碼會呈現11。

* 週報（進度報告）
* 產表時間：週日22點產前一週案件
* 補上日報標註粉紅色指標
* 違約相關數據由客服/徵審發動，這邊就不放違約指標，月報再來追蹤資產品質狀況
* 新增實際收入相關數據，預期收入先不放
* 月付金 (本金＋利息)認列為營收
* 滯納金有可能溢繳 (週報可以不用計算太精準)
* 月報（財報）
* 產表時間：每月？號產前一個月案件
* 指標分為兩種
* 新貸案件 (申請日為月報ETL日前一個月，例如10/15產月報，觀察9/1-9/30申貸案件的狀況)
* 整體案件 (月報ETL日當下狀況，例如10/15產月報，觀察所有核貸案件的狀況)
* 數據產製方式
* 每日 Zeppelin 撈資料貼到 excel，再進行資料整理成產製成dashborad
* Zeppelin 直接產製成 dashborad
* 待辦
* 確認撥款失敗清單 (Jasmine)
* 與財務 align 實際收入計算邏輯 (Johnson)
* 調整報表內容 (Brady)
* 確認績效指標完整性 (大家)