سپرده خالص: محاسبه و کنترل

1) سپرده خالص چیست و چرا آنها مورد نیاز

• اقتصاد واحد (ارتباط ND با LTV، ARPPU، NGR)،
• بازی مسئولانه (محدودیت ها، کنترل خود، منبع بودجه)،
• ریسک و انطباق (AML/تحریم ها، ناهنجاری ها)،
• معاملات (اولویت بندی پرداخت ها و پاداش های ضد سوء استفاده).

ایده اصلی

بازیکن X (سپرده) کمک، Y (برداشت) به ارمغان آورد. همه چیز که در اکوسیستم باقی می ماند به عنوان «پول سپرده در واقع» بازیکن سپرده خالص است، تنظیم شده برای بازده، بازپرداخت، لغو و سایر عملیات فنی.

2) فرمول ها و مرزهای حسابداری

2. 1. فرمول پایه (سطح محصول)

ND = Deposits
− Withdrawals − (successful, paid)
− Refunded Deposits
+ Chargeback Debits
− Chargeback Credits
± Reversal Adjustments

• سپرده - تنها دستگیر/حل و فصل. مجوز بدون ضبط بعدی - حساب نمی شود.
• برداشت - ما را به حساب تنها پرداخت (پرداخت/حل و فصل). درخواست های ND رد شده/لغو شده کاهش نمی یابد.
• سپرده های بازپرداخت شده - بازگشت سپرده به همان منبع (همان روش).
• بدهی ها/اعتبارات بازپرداخت - اثر خالص اختلافات (نوشتن/بازپرداخت).
• اصلاحات معکوس - اصلاحات فنی (به عنوان مثال، بازگشت از کیف پول «اشتباه»، معکوس تکراری).

2. 2. پیشرفت های حسابداری

پاداش و شرط رایگان: در سپرده شامل نمی شود; اینها وامهای داخلی هستند. با این حال، سناریوهای سوء استفاده (سپرده برای پاداش → پول نقد فوری) باید ND را از طریق برداشت سریع و/یا از طریق اصلاحات ضد تقلب کاهش دهد.
کمیسیون PSP: به طور پیش فرض، آنها از ND (ND - «بازیکن محور» متریک) کسر نمی شود. کمیسیون - در P&L.
انتقال داخلی/کیف پول متقابل (ورزشی → کازینو): ND تغییر نمی کند (این یک حرکت در تعادل است).
لغو در داخل: لغو ND را کاهش نمی دهد (پس از همه، خروج انجام نشد).
تخفیف تبلیغاتی/اعتبار دستی: اعتبار نقدی اپراتور ND را افزایش نمی دهد.
توکن ها/رمزنگاری: با توجه به معادل فیات در لحظه حل و فصل (نگاه کنید به چند ارز).
پرداخت جزئی/تقسیم: ND در حال رشد است با یک مقدار است که واقعا حل و فصل.

2. 3. مرزهای دوره

• مبتنی بر فعالیت (توسط معامله «setted _ at»). توصیه شده برای گزارش مالی
• Request-based (by 'created _ at '/' requested _ at'): مناسب برای تجزیه و تحلیل سریع محصول، اما نه برای آشتی.

3) ارزیابی چند ارز و نرخ ارز

تمام عملیات به گزارش ارز (به عنوان مثال، EUR) در نرخ ارز در زمان حل و فصل نقشه برداری.
Фиксируйте: 'amount _ original', 'currency _ original', 'fx _ rate _ at _ settle', 'amount _ reporting'.
برای رمزنگاری، از قیمت میانگین وزنی (VWAP) در منبع انتخاب شده در «setted _ at» استفاده کنید.
هنگام تغییر دوره ها، ND های تاریخی را بیش از حد ارزیابی نکنید: FX واقعی را در زمان رویداد نگه دارید.

4) سطوح نقش ND

ND_user سرمایه گذاری خالص یک بازیکن خاص است.
ND_segment - توسط کشورها، کانال ها، ارائه دهندگان پرداخت، وابسته.
ND_cohort - با تاریخ ثبت نام/اولین سپرده.
ND_platform کل ND پلت فرم برای دوره است.

5) سیاست ها و محرومیت ها

5. 1. قانون همان روش & بازگشت به منبع

اگر سپرده A از طریق روش M آمد، بازگشت وجوه سپرده است ترجیحا از طریق M تا به مقدار سپرده خالص ساخته شده است. این خطرات AML و پرداخت متقابل بحث برانگیز را کاهش می دهد.

5. 2. تنظیمات داخلی

هر گونه تنظیم دستی باید یک reason_code، یک دنباله حسابرسی و اشاره به فعالیت اولیه داشته باشد.
تنظیمات نباید از دست دادن تعقیب/سوء استفاده ماسک.

5. 3. چرخه پاداش

علامت گذاری به عنوان «پاداش رانده ND» (سپرده که جایزه فعال) با یک پرچم. ساخت گزارش ND با/بدون سپرده مربوط به پاداش.

6) مدل رویداد و طرح داده

6. 1. رویدادهای کلیدی

'DEPOSIT _ AUTHORIZED'، 'DEPOSIT _ CAPTED'، 'DEPOSIT _ REFUNDED'

«برداشت _ درخواست شده»، «برداشت _ پرداخت شده»، «برداشت _ رد شد»، «برداشت _ لغو شد»

«استرداد»، «استرداد»، «اعتبار»

'ADJUSTMENT _ APPLIED' ( : REVERSAL، ، . п.)

همه رویدادها idempotent هستند («idempotency _ key», «event _ id»). پشتیبانی دقیقا یک بار تحویل به DWH از طریق 'event _ id' deduplication.

6. 2. مینی نمودار (ساده شده)

payments. transactions (
id, user_id, provider, method, type, status,
amount_original, currency_original,
amount_reporting, reporting_currency, fx_rate_at_settle,
requested_at, settled_at, related_tx_id, reason_code, meta
)

types: DEPOSIT    WITHDRAWAL    REFUND    CHARGEBACK_DEBIT    CHARGEBACK_CREDIT    ADJUSTMENT status: PENDING    AUTHORIZED    CAPTURED    PAID    REJECTED    CANCELED    REFUNDED    SETTLED

مجموع ND ها جمع آوری شده توسط «نوع» و «وضعیت» با فیلتر «تنها حل و فصل/پرداخت/دستگیر، که در آن قابل اجرا» در نظر گرفته.

7) کنترل کیفیت داده ها و آشتی

7. 1. آشتی با PSP/خریدار

آشتی روزانه گزارش PSP (فایل های حل و فصل) با معاملات خود را.
مسابقات برای «provider _ ref»، مقادیر، تاریخ های حل و فصل، ارزها و هزینه (برای P&L).
عدم تطابق → بلیط در Ops: «ضبط گمشده»، «بازپرداخت مضاعف»، «ارائه دیرهنگام».

7. 2. ضد حباب و idemotency

کنترل: منحصر به فرد توسط «(ارائه دهنده، provider_tx_id، نوع، settle_date)».
گزارش حسابرسی جداگانه برای عملیات دستی («ADJUSTMENT _ APPLIED»).

7. 3. یکپارچگی قانون کسب و کار

نمایش «پرداخت شده» بدون سابقه سپرده در روش انتخاب شده یک پرچم قرمز است.
نزدیک در زمان «سپرده _ اسیر» → «برداشت _ پرداخت» برای همان مقدار - پرچم خاکستری (پاداش سوء استفاده).

8) گزارش و داشبورد

8. 1. KPI های پایه

'ND _ total' برای دوره ؛ ' ND _ per _ user ',' ND _ median ';

تجزیه ND توسط کشور، روش، PSP، وابسته ؛

'ND _ 7/30/90' توسط گروه های ثبت نام ؛

نقدی تاخیر تبدیل: میانه از «سپرده _ اسیر» به «برداشت _ پرداخت».

8. 2. بخش های ریسک

بازیکنان با «ND≈0» و گردش مالی بالا نامزد برای تایید منبع بودجه هستند.
چرخش سریع (سپرده → برداشت) <N ساعت - ماشه بررسی.

8. 3. هواپیماهای تجزیه و تحلیل

محصول (ورزشی/کازینو/زندگی می کنند): که در آن ND است که بیشتر «سالم».
روش های پرداخت: شکست ND در طول ترافیک تقلب در یک روش خاص.
کمپین ها/پاداش ها: لغو ND و لغو پس از اثر.

9) ضد تقلب و سیاست های بازی مسئول

محدودیت سپرده (روزانه/هفتگی/ماهانه) - در گزارش ND یک متریک انطباق جداگانه است.
قوانین سرعت: n سپرده> X در دقیقه Y + حافظه پنهان سریع = بلوک/چک دستی.
تحریم ها/PEP/SoF: رشد ND بالاتر از آستانه → منبع اجباری بودجه.
Mullocalization: مقایسه جغرافیایی/روش/کشور بانکی به کشور KYC.
خود حذفی: ND پس از خروج باید به شدت 0 باشد ؛ هر گونه تلاش - هشدار.

10) فرآیندها و SLO ها

SLO محاسبه ND-داشبورد: T + 1، آمادگی تا 09:00 TZ محلی منطقه گزارش.

• از دست رفته PSP فایل های حل و فصل،
• تکراری منجر به بخش نادرست ND می شود
• اختلاف جرم FX.
• DRP: پردازش مجدد ND از طریق جذب مجدد رویدادها در طی یک دوره با نظم قطعی.

11) نمونه SQL (قالب)

11. 1. محاسبه ND توسط کاربر و روز

sql
WITH base AS (
SELECT user_id,
DATE(settled_at) AS d,
SUM(CASE WHEN type='DEPOSIT'     AND status IN ('CAPTURED','SETTLED') THEN amount_reporting ELSE 0 END) AS dep,
SUM(CASE WHEN type='WITHDRAWAL'   AND status='PAID'           THEN amount_reporting ELSE 0 END) AS wd,
SUM(CASE WHEN type='REFUND'     AND status='SETTLED'         THEN amount_reporting ELSE 0 END) AS ref_dep,
SUM(CASE WHEN type='CHARGEBACK_DEBIT'  AND status='SETTLED'        THEN amount_reporting ELSE 0 END) AS cb_deb,
SUM(CASE WHEN type='CHARGEBACK_CREDIT' AND status='SETTLED'        THEN amount_reporting ELSE 0 END) AS cb_cr
FROM dw. transactions_flat
WHERE settled_at >=:from AND settled_at <:to
GROUP BY 1,2
)
SELECT user_id, d,
dep - wd - ref_dep + cb_deb - cb_cr AS nd
FROM base;

11. 2. پرچم چرخش سریع (سوء استفاده)

sql
SELECT t_dep. user_id, t_dep. id AS dep_id, t_wd. id AS wd_id,
EXTRACT(EPOCH FROM (t_wd. settled_at - t_dep. settled_at))/3600 AS hours_between,
t_dep. amount_reporting, t_wd. amount_reporting
FROM dw. transactions_flat t_dep
JOIN dw. transactions_flat t_wd
ON t_dep. user_id = t_wd. user_id
AND t_wd. type='WITHDRAWAL' AND t_wd. status='PAID'
AND t_wd. amount_reporting BETWEEN t_dep. amount_reporting0. 9 AND t_dep. amount_reporting1. 1
WHERE t_dep. type='DEPOSIT' AND t_dep. status IN ('CAPTURED','SETTLED')
AND t_wd. settled_at - t_dep. settled_at <= INTERVAL '24 hours';

11. 3. تقسیم بندی بر اساس روش/PSP

sql
SELECT method, provider,
SUM(CASE WHEN type='DEPOSIT'  AND status IN ('CAPTURED','SETTLED') THEN amount_reporting ELSE 0 END) AS dep,
SUM(CASE WHEN type='WITHDRAWAL' AND status='PAID'          THEN amount_reporting ELSE 0 END) AS wd,
SUM(CASE WHEN type='REFUND'   AND status='SETTLED'         THEN amount_reporting ELSE 0 END) AS ref_dep,
SUM(CASE WHEN type='CHARGEBACK_DEBIT' AND status='SETTLED'     THEN amount_reporting ELSE 0 END) AS cb_deb,
SUM(CASE WHEN type='CHARGEBACK_CREDIT' AND status='SETTLED'     THEN amount_reporting ELSE 0 END) AS cb_cr,
SUM(CASE WHEN type='DEPOSIT'  AND status IN ('CAPTURED','SETTLED') THEN amount_reporting ELSE 0 END)
- SUM(CASE WHEN type='WITHDRAWAL' AND status='PAID'          THEN amount_reporting ELSE 0 END)
- SUM(CASE WHEN type='REFUND'   AND status='SETTLED'         THEN amount_reporting ELSE 0 END)
+ SUM(CASE WHEN type='CHARGEBACK_DEBIT' AND status='SETTLED'     THEN amount_reporting ELSE 0 END)
- SUM(CASE WHEN type='CHARGEBACK_CREDIT' AND status='SETTLED'     THEN amount_reporting ELSE 0 END) AS nd
FROM dw. transactions_flat
WHERE settled_at BETWEEN:from AND:to
GROUP BY 1,2
ORDER BY nd DESC;

12) هشدارها و محرک ها (سیستم عامل)

Spike ND↓ on method: افت ND> 30٪ d/d - بررسی حوادث PSP و قفل.
ND↑ اسپایک توسط بخش: رشد ND> 50٪ W/W - AFF جدید به احتمال زیاد است. -source یا تنظیم مجدد طرح.
ND≈0 گردش مالی بالا - چک KYC/SoF اجباری.
سهم غیر طبیعی از بازپرداخت/بازپرداخت در ND - حسابرسی زنجیره «depozit → igra → vyvod».

13) بهترین شیوه (کوتاه)

1. خوانده شده ND توسط تاریخ حل و فصل و رفع FX در زمان حل و فصل.
2. سخت جدا انتقال داخلی از پول بازیکن.
3. تمام ویرایش های دستی - با reason_code و حسابرسی.
4. قوانین ضد تقلب برای چرخش سریع و روش های متقابل.
5. دو گزارش: عملیاتی T + 1 و بسته شدن مالی (ماه/سه ماهه).
6. نسخه منطقی: ND v1/v2 با مهاجرت از storefronts تاریخی.

14) سوالات مکرر

س: آیا یافته های لغو شده شمارش می شود ؟

پاسخ: نه. فقط «برداشت _ پرداخت شده» ND را کاهش می دهد.

س: با سپرده ای که مجاز است اما دستگیر نشده است چه باید کرد ؟

A: در ND شامل نمی شود. اینها قبض های واقعی نیستند.

س: چگونه پس از نتیجه گیری در حال حاضر ساخته شده است ؟

A: «CHARGEBACK _ DEBIT» یک سهم منفی بازیکن را اضافه می کند (اساسا، پلت فرم از دست می دهد)، ND با بدهی افزایش می یابد، اما گزارش مالی نهایی نیز باید زیان/هزینه در بازپرداخت را نشان دهد.

س: آیا کمیسیون PSP باید از ND کسر شود ؟

A: نه، ND یک متریک بازیکن محور است. کمیسیون - در P&L.

15) چک لیست پیاده سازی

• اتوبوس رویداد با idemotency و تضمین تحویل
• 'transactions _ flat' ویترین با انواع/وضعیت های متحد
• عادی سازی FX در حل و فصل، ذخیره سازی اصلی
• PSP قوانین نقشه برداری وضعیت → وضعیت خود را
• آشتی روزانه با PSP و هشدار دلتا
• داشبورد ND (به طور کلی، توسط روش، توسط بخش، توسط کوهورت)
• سیاست های بازی مسئول و SoF مبتنی بر ND باعث
• مستندات فرمول ND v1 و برنامه تکامل v2

خلاصه

سپرده های خالص متریک مرکزی پول «واقعی» بازیکن در سیستم است. ND صحیح نیاز به قوانین سختگیرانه شناخت (تاریخ حل و فصل)، چند ارز دقیق، idempotence رویداد، آشتی منظم با PSP و ساخته شده است در راه اندازی ضد تقلب. یک راهنمای وضعیت واحد و نوع شناسی عملیات را تشکیل دهید - و ND تبدیل به یک پشتیبانی قابل اعتماد برای هر دو مالی و کسب درآمد مسئول خواهد شد.