Dashbord支付KPI

TL;DR

一個行車記錄儀分為三層：漏鬥健康（Attempt→Auth→Capture），財務效率（TtW/TtR，Cost/GGR，FX）和基礎設施可靠性（Webhook/Latency/Settlement）。秘訣是正確的計算基礎，強制性細分（國家×提供者×方法× BIN × ticket_size × risk），閾值SLO和到達走廊時的現成花花公子。

1）對於誰以及我們要解決的問題

首席執行官/通用汽車（每天3-5分鐘）： "付款轉換和收款速度正常？接受資金的成本得到控制？"

Payments/Treasury Head（每小時）： "提供商/國家/方法在哪裏？即時付款是否有足夠的流動性？"

Fraud/Risk（每天）： "AR考慮了防凍劑？Abandon на 3DS и Soft declines?»

支持/運營（在線）： "什麼樣的退貨和退貨ETA?Webhooks掛在哪裏？"

Finance/Recon （D+1）： "按時結算？傭金和FX是否符合計劃？"

2）主要指標和精確定義

2.1個支付漏鬥

Attempt-啟動付款。
Auth Approved-已批準的授權。
Captured-已成功註銷。

• `AR_gross = Auth_Approved / Auth_Attempted`
• `AR_net = Captured_Tx / Auth_Attempted`
• `Capture_Success = Captured_Tx / Capture_Attempted_Tx`
• `Capture_Latency_p95 = p95(capture_ts - auth_ts)`

2.2調查結果和回報

Payout Success % = Success_Payouts / Attempted_Payouts

TtW p95 = p95(payout_credited_at - payout_initiated_at)

Refund Rate = Refunded_Tx / Captured_Tx

TtR p95 = p95(refund_credit_at - refund_initiated_at)

Refund Error % = Refund_Failed / Refund_Attempted

Refund_to_Source%-返回原始方法的百分比

2.3成本和FX

Cost/Tx = Fee_fixed + AmountFee_pct + FX_Spread

Cost/GGR = ΣCost / GGR

FX Slippage (bps) = (exec_px − mid_px)/mid_px × 10 000

2.4集成的可靠性

Webhook Delivery p95 (сек), Success %

API Latency p95/p99 (auth/capture/refund/payout)

Settlement Timeliness=在此期間進入聲明的T+N/所有蹦床的蹦床

2.5 3 DS/摩擦（用於地圖）

3DS Challenge Share = Challenge / 3DS_Total

Frictionless Share = Frictionless / 3DS_Total

Abandon on 3DS = 3DS_Started − 3DS_Completed

3）切口和過濾器（最小設置）

Фильтры в шапке: `date range (UTC)`, `country`, `provider`, `method_group`, `BIN`, `device/os`, `ticket_size bucket (≤€50 / €50–200 / >€200)`, `risk_segment`, `kyc_tier`, `new_vs_returning`, `affiliate`.

• country×provider, BIN×country, method×provider, device/os, ticket_size.

4）主屏幕標記（布局）

1.KPI的最高標記（昨天/今天，與p7中位數的比較）：

`AR_net`, `Capture_Success`, `Payout Success%`, `TtW p95`, `TtR p95`, `Cost/GGR`, `Webhook p95`, `Settlement Timeliness`.

2.Funnel（Attempt→Auth→Capture）具有段選擇和故障原因顯示（導軌上的ISO/頂部代碼）。

3.Heatmap AR通過「鄉村×提供者」和單獨的BIN heatmap達到最高音量。

4.3 DS面板：Challenge/Frictionless/Abandon+與基準線的比較。

5.Payout & Refund Health: Success%, p95 (TtW/TtR), ошибки, Refund_to_Source %.

6.Cost＆FX：方法Cost/GGR，站點FX slippage/fees。

7.集成可靠性：Webhook delivery p95/Success%、API latency p95/p99, Duplicate rate, Report delivery SLA。

8.事件面板：active alertes（參見第8節）,failover狀態和國庫註釋（L0, prefund）。

5）SLO和Alertes（走廊）

• 'AR_gross'地圖3DS2：82-92%（按細分市場）；'AR_net' ≥ 80%
• `Capture_Success` ≥ 98.5%（小時）
• `Webhook p95` ≤ 3 с, Success ≥ 99.9%
• `Payout TtW p95` instant ≤ 120 с;（T+1）-每天100% D+1
• 'Refund TtR p95'卡≤ T+1 b.d.；instant ≤ 60 с
• `Refund Error %` < 0.3%
• `Settlement Timeliness` ≥ 99%
• 「成本/GGR」-通過方法定制的目標走廊

• 7天中點「AR_gross↓> 3個百分點」（國家/PSP/BIN）→ P1/P0
• `Capture_Success < 98%` (час) → P1
• 'Webhook p 95>5 c'或副本>0 → P1
• `Payout TtW p95 > SLO` или Success%<99% → P1
• `Refund Error% > 0.3%` или `Double Refund > 0` → P0
• `Settlement on-time < 99%` → P1
• 「Cost/GGR」通過P2方法從走廊→出

每位alert都會打開runbook'a（行動/上報/傳單）卡。

6）公式和計算基礎（詳細信息）

所有股票-具有明確的基礎：在「denominator」圖爾蒂普中指定。
時間-在UTC；p-quantili： PERCENTILE_CONT。

「AR_clean」（運營）=「Auth_Approved/（ Auth_Attempted − Fraud_Preblocked − Abandon_3DS）」

`Net_Conversion` = `Captured_Tx / Auth_Attempted_Tx`

`Refund_to_Source %` = `Refund_to_Original_Method / Total_Refunds`

「Idle Cash%」（在國庫迷你小部件中）=「（Balance − Target_Balance ）/Balance」

7） UX模式

頂部是KPI，下面是funnel+heatmaps，底部是集成和財務。
帶有公式/基數/例外的Tultips（例如「反型後」）。
比較線：p7中位數和「昨天「/」上周一」。
按點擊進行演練：從heatmap到故障BIN→Issuer→kody表。
RCA的快照：後太平間的「固定」按鈕。

8）花花公子（嵌入式動作卡）

Auth drop →切換智能路由,在BIN上提高3DS-challenge,並限制回程。
Webhook延遲→包括計費，凍結自動反射/危險汽車付款，提高等效性。
Payout降解→導軌操縱器，寶藏頂級，VIP優先級。
Settlement延遲→ StressRes，標記為「Suspense」，在PSP中升級。
Refund錯誤/雙打→ refund-freeze，和解，堅韌不拔。

（該卡包含支票單和升級聯系人。）

9）數據模型（最低限度）

events/payments_flat:
payment_id, user_id, country, provider, method_code, action(deposit/refund/payout),
attempt_ts, auth_status, auth_ts, three_ds(flow, challenge_flag, started_ts, completed_ts),
capture_status, capture_amount, capture_ts, partial_flag,
refund_status, refund_amount, refund_initiated_ts, refund_credit_ts,
payout_status, payout_amount, payout_initiated_ts, payout_credited_ts,
fees_fixed, fees_pct, fx_spread, currency, amount,
risk_segment, kyc_tier, bin, asn, device_os, ticket_bucket

events/webhooks:
provider, event_kind, event_ts, delivered_ts, retries, duplicate_flag, idempotency_key

settlements/reports:
provider, batch_id, settlement_date, amount_settled, currency, fee_amount, status

treasury/pockets (mini-widget):
pocket_id, counterparty, currency, balance, target_balance, low_watermark, updated_at

索引：通過「provider」，「method_code」，「country」，「bin」，「event_ts」。

10） SQL切片（示例）

10.1漏鬥和AR

sql
WITH base AS (
SELECT
DATE_TRUNC('hour', attempt_ts) AS h,
country, provider, method_code,
COUNT() FILTER (WHERE auth_status='ATTEMPTED') AS auth_attempted,
COUNT() FILTER (WHERE auth_status='APPROVED') AS auth_approved,
COUNT() FILTER (WHERE capture_status='CAPTURED') AS captured_tx
FROM payments_flat
WHERE action='deposit'
GROUP BY 1,2,3,4
)
SELECT h, country, provider, method_code,
auth_approved::decimal / NULLIF(auth_attempted,0) AS ar_gross,
captured_tx::decimal / NULLIF(auth_attempted,0)  AS ar_net
FROM base;

10.2 Webhook SLA

sql
SELECT
DATE_TRUNC('hour', event_ts) AS h, provider,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (delivered_ts - event_ts))) AS wb_p95_sec,
AVG(CASE WHEN retries=0 AND NOT duplicate_flag THEN 1 ELSE 0 END) AS wb_success
FROM webhooks
GROUP BY 1,2;

10.3 Refund & Payout Health

sql
SELECT
DATE_TRUNC('day', COALESCE(refund_initiated_ts, payout_initiated_ts)) d,
method_code, provider,
COUNT() FILTER (WHERE refund_status='ATTEMPTED') AS refund_attempted,
COUNT() FILTER (WHERE refund_status='SUCCESS')  AS refund_success,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (refund_credit_ts - refund_initiated_ts))) AS ttr_p95_sec,
COUNT() FILTER (WHERE payout_status='ATTEMPTED') AS payout_attempted,
COUNT() FILTER (WHERE payout_status='SUCCESS')  AS payout_success,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (payout_credited_ts - payout_initiated_ts))) AS ttw_p95_sec
FROM payments_flat
GROUP BY 1,2,3;

10.4 Cost/GGR

sql
SELECT
DATE_TRUNC('day', capture_ts) d,
method_code, provider,
SUM(fees_fixed + amountfees_pct + fx_spread) AS total_cost,
SUM(capture_amount) AS total_captured,
(SUM(fees_fixed + amountfees_pct + fx_spread) / NULLIF(SUM(total_captured),0)) AS cost_to_captured
FROM payments_flat
WHERE capture_status='CAPTURED'
GROUP BY 1,2,3;

11）附加屏幕

BIN Drilldown： AR/decline-codes, 3 DS摩擦,latency by發行人。
Provider Scorecard： SLA 度量、事件、積分、成本/GGR。
Treasury Snapshot：L0/L1殘留物，預基金，StressRes，TtF補給。

Recon View： 定居時間,Aging非縫制蹦床,Fee accuracy.

12）數據質量i治理

具有轉換的KPI字典（公式/基數/例外）。
單個TZ=UTC，p分量僅為CONT。
事件和Webhook的偶然性。
Tolerans 的時間/金額/FX政策（用於對賬/潛伏期）。
CI中的數據測試：非空除數基數，時間戳單調性，空分數。

13）實施： 支票單

• 定義了KPI/公式/基數並記錄在字典中。
• 對事件/註冊表進行配置和規範化。
• 建造了「payments_flat」，「webhooks」，「settlements」，「treasury」店面。
• 實施了heatmaps，funnel，latency，payout/refund panels。
• 設置了SLO和Alerta急流；與花花公子有關。
• 訪問角色：C級（只讀摘要）,Ops/Fraud （drill-down）。
• 每周提供商QBR基於Provider Scorecard。
• UAT測試集：演示dataset，p-quantiles驗證，基數正確性，alerts。

14）常見錯誤

基地的混合（「attempt」與「capture」）→錯誤的結論。
沒有「ticket_size」分段→扭曲的AR圖像。
3 DS上的abandon忽略→提供商的「誇大」問題。
缺少webhook duplicates控制→雙重動作。
不完整的settlement/Fees展示→ 無法評估成本/GGR。
沒有SLO和花花公子，行車記錄儀就變成了「無動於衷的展示櫃」。

總結

Dashboard支付KPI是一種操作工具，而不僅僅是圖形。它連接漏鬥，金錢和基礎設施，依靠清晰的公式和細分，產生自動信號，並立即提出行動。結果：上AR_net，走廊中的TtW/TtR，受控制的Cost/GGR，事件迅速本地化，並且與提供商的對話基於數字。