خودکار رویدادها و پاداش ها - قوانین و وب سایت ها
گیمیفیکیشن مبتنی بر دو «موتور» است: رویدادها (آنچه کاربر انجام داده است) و قوانین (آنچه قرار است برای آن باشد). برای این کار در مقیاس بزرگ و بدون خطا، شما نیاز به یک اتوبوس رویداد قابل اعتماد، یک موتور قوانین، مکانیسم تحویل/جایزه و حفاظت دقیق در برابر تقلب دارید. در زیر معماری عملی، قالب ها و چک لیست ها وجود دارد.
1) رویداد → قانون → معماری جریان پاداش
1. ورودی (ورودی رویداد): SDK/وب، وب سرور از پرداخت/ارائه دهنده بازی → API دروازه → صف/اتوبوس (کافکا/خرگوش/ابر میخانه/زیر).
2. Normalizer: اعتبار سنجی، غنی سازی (جغرافیایی، دستگاه، payer_flag)، نسخه طرح.
3. قوانین موتور: به ثمر رساند/XP، چک کردن ماموریت/ماموریت، پاداش/اطلاع رسانی باعث می شود.
4. Orchestrator پاداش: محاسبه پاداش، بررسی بودجه، دروازه های RG/KYC، ایجاد یک «وظیفه صدور»، ورود به سیستم.
5. پرداخت/پاداش خدمات: کش/کش جایزه/freespins/کوپن, webhooks خارجی (کیف پول, ارائه دهندگان).
6. هشدار دهنده: فشار/در برنامه/ایمیل/پیام های فوری با محدودیت فرکانس.
7. ذخیره سازی/تجزیه و تحلیل: رویدادهای خام، فروشگاه ها، A/B، هشدارها.
8. ضد تقلب/RG: mouthguards، اکتشافی/ML، نگه دارید و بررسی جوایز بزرگ.
2) مدل رویداد (حداقل مجموعه)
جی سون
{
"event_id": "d9e8-... -5c2", "event_name": "شرط", "نسخه": "1. 2. 0"، "ts": "2025-10-24T11:37:21Z," "کاربر": {
«id»: «u_123,» «geo»: «TR»، «پلت فرم»: «android»، «payer_flag": درست «، risk_flags": [«vp _ nightly»]
}، «زمینه»: {
" :" "" : "ip": "203. 0. 113. 24"
}، «بارگیری»: {
"game_id": "slot_wolf," "شرط": 0. 5، «برنده»: 1. 25، «ارز»: «EUR»، «ارائه دهنده»: «GameCo»
}
}
Базовые типы: 'login', 'session _ start/end', 'bet/spin', 'win', 'deposit', 'withdraw _ request', 'kyc _ status _ changed', 'mission _ view/join/progress/complete', 'tournament _ join/score/update/reward', 'reward _ ised', 'rg _ event'.
3) موتور قانون: چگونه منطق را توصیف کنیم
مفاهیم: قوانین (اگر/پس از آن)، بخش ها، پنجره های زمان، سخنرانان، اولویت ها، نسخه بندی.
یک مثال از قانون اعلانی (سبک YAML):rule_id یامل: r_points_winmult_v2 زمانی که:
event_name: فیلترهای شرط بندی:
- محموله. شرط بندی> = 0. 2
- استفاده کننده جغرافیایی در [«TR «، «BR»،» PE»]
- در حال حاضر بین «2025-11-01» و «2025-11-30»
امتیاز:
فرمول: "طبقه ((محموله. برنده/بارگیری. شرط بندی) 3) "
کلاه ها:
: 50 : 200 : 1500:
on_progress:
آستانه: [100، 300، 800]
reward: [{type: «fs», value: 10}, {type: «bonus_cash,» value: 2}, {type: «loot», rarity: «rare»}]
گارد محافظ:
: 2 : واقعی:
budget_soft_cap: 80000 متا:
نسخه: "2. 0"
آزمایش: «scoring_ab_2025w45»
4) Webhooks: ادغام سرور و سرور
4. 1. Webhooks خروجی (از شما به ارائه دهندگان/کیف پول)
روش: 'POST https ://partner. مثال/پرداخت
Подпись: 'X-Signature: HMAC-SHA256 (مخفی، بدن)' + 'X-Request-Id' (idempotency).
Retrai: عقب نشینی نمایشی، 'max _ retries = 8'، jitter، DLQ.
Idempotency: تکرار همان «X-Request-Id» → شریک باید با همان «payout _ id/status» پاسخ دهد.
نمونه ای از payload:جی سون
{
« :» «» : «پاداش»: {«نوع»: «پول نقد»، «مقدار»: 10. 00, «ارز»:» EUR»}, «دلیل»: «milestone_300_points,» «kyc_level": 2 «, محدودیت ها»: {«شرط»: 0 «, expiry_at": «2025-12-01T00: 00: 00Z»}
}
4. 2. ورودی webhooks (به شما)
اجازه دهید فقط لیست IP/MTLS، HMAC و طول عمر امضا ('X-Timestamp'، ± 5 دقیقه) را بررسی کنید.
بدنه خام + هدرها را در فروشگاه حسابرسی (WORM) ذخیره کنید.
هر دو/تکرار → بررسی کلید idempotency در برابر ورود به سیستم.
5) قابلیت اطمینان: جریان «حتی» بدون پرداخت دوگانه
حداقل یک بار در مصرف + کنترل کننده های idempointent → استاندارد طلا.
کلید Idempotency: 'هش (event_id + user_id + rule_id)' برای به ثمر رساندن ؛ کلید جداگانه برای صدور پاداش «reward _ task _ id».
معناشناسی دقیقاً یک بار فقط از نظر منطقی واقع گرایانه است (از طریق idempotence)، نه حمل و نقل.
ترتیب رویدادها: فروشگاه 'event _ ts' و 'ingest _ ts' ؛ استفاده از پنجره مرتب سازی مجدد (به عنوان مثال، 60 ثانیه) و پخش از صف توسط کلید «user _ id».
صف نامه مرده (DLQ):- ما پیام ها را با یک خطای دائمی می نویسیم (طرح موقت تصویب نشد، امضا نامعتبر است، بودجه بسته شده است).
- سرویس بررسی DLQ با دکمه های طرح مجدد/قطره/ثابت.
6) بودجه و حفاظت از حاشیه
استخرهای بودجه: «nov _ season»، «daily _ sprint»، «vip _ weekend».
سهمیه ها: کلاه نرم/سخت، «قطع کننده مدار» - هنگام رسیدن به 90٪ بودجه، جوایز بزرگ را به حالت نگهداری منتقل کنید.
هزینه تنها: 'جایزه و پاداش هزینه در هر فعال/Payor'، افزایش خالص.
اولویت ها: RG و انطباق مهم تر از تبلیغی هستند - در صورت درگیری، پاداش به تعویق می افتد.
نمونه ای از بررسی بودجه (طرح SQL):SQL
انتخاب pool_id، SUM (مقدار) AS صرف، بودجه AS محدودیت، SUM (مقدار )/بودجه به عنوان پر کردن
از reward_ledger
WHERE pool_id =: استخر و تاریخ (ts) = current_date
گروه بر اساس pool_id، بودجه ؛
7) دروازه های RG/KYC/Geo (ایمنی و انطباق بازیکن)
KYC: L2 حداقل برای کش/جوایز بزرگ ؛ freespins با L1 معتبر هستند.
RG: چک کردن محدودیت های سپرده, خود حذفی, سرد کردن → جوایز یخ زده تا زمانی که محدودیت برداشته می شوند.
Geo: فهرست کشورهای مجاز برای هر قانون جایزه/استخر.
هشدار آستانه: رشد شدید «تقریبا رسیده» در حساب های فردی = دلیلی برای نگه داشتن و بررسی.
8) قوانین ضد تقلب و تله متری
کلاه از نقاط در نرخ/دقیقه/ساعت/روز, حداقل واریانس شرط, ممنوعیت الگوهای «ایده آل».
سیگنال های فنی: بدون سر، device_fp تکراری، زیر شبکه های پروکسی.
ناهنجاری ها: «نقاط/شرط» و «نقاط/دقیقه» - «دم» طولانی در 99 درصد.
نگه دارید و بررسی برای برندگان برتر: بررسی خودکار KYC + بررسی دستی.
9) نظارت، معیارها و هشدارها
SLO/SLA:- مصرف p95 ≤ 250 میلی ثانیه ؛ پردازش قانون p95 ≤ 150 میلی ثانیه ؛ به روز رسانی هیئت مدیره ≤ 2 ثانیه ؛ جایزه ≤ 60 ثانیه
- بودجه خطا <0. 1٪ رویدادها/روز.
- SRM در آزمایش (انحراف ترافیک)، رشد DLQ، افت امضای اعتبار HMAC، غلبه بر بودجه، افزایش تکراری بی نظیر.
- رویدادها/ها، تاخیر، تحمل خطا ؛
- قیف: رویداد → قانون → reward_task → reward_issued ؛
- هزینه: جایزه/پاداش در هر فعال، افزایش خالص ؛
- کیفیت: پرچم های تقلب، بلوک های KYC، محرک های RG.
10) نسخه و مهاجرت
هر قانون به صورت versioned ("قوانین. نسخه ').
شما نمی توانید قانون فعال را بدون نسخه جدید ویرایش کنید ؛ استفاده از ficheflag و «حرارت صاف» (10٪ → 50٪ → 100٪).
نمودار رویدادها از طریق رجیستری طرح ؛ تغییرات ناسازگار - نسخه اصلی تنها.
11) تست اتوماسیون A/B (کوتاه)
واحد - کاربر ؛ وظیفه چسبنده ؛ طبقه بندی (پرداخت کننده/جغرافیایی/پلت فرم).
تابلوهای جداگانه یا عادی سازی نقاط برای از بین بردن تداخل.
اولیه: participation_net، تکمیل، ARPPU خالص ؛ Guardrails: شکایات/1k، پرچم های تقلب، RG باعث می شود.
CUPED و هموریاها برای کاهش واریانس.
12) نمونه: از حکومت به موضوع
12. 1. ماشه پیشرفت میکرو پاداش
جی سون
{
"نوع": "reward_task. ایجاد شده «،» : « » « :» مبدا «: {» قانون _ id «:» r _ points _ winmult _ v2 «،» آستانه «: 300}،» پاداش «: {» نوع «:» «» مقدار «: 2،» ارز «:» EUR «،» شرط «: 15}»، « :» وضعیت «:» در انتظار «،» : « »
}
12. 2. webhook خروجی برای کیف پول
پست/کیف پول/اعتبار
درخواست ایکس: rid_7f5..
برچسب زمان X: 1730061700
X-امضا: sha256 = 7b9a...
{«user_id":"u_123,» «مقدار»: 2. 00، «ارز»:» EUR»، «دلیل «: «قانون: r _ points _ winmult _ v2»}
Success → 'reward _ task' = 'successed' و نوشتن در 'reward _ ledger'.
Failure (5xx/timeout) → retray with the same 'X-Request-Id'.
Dip (4xx) → تجزیهٔ دستی + DLQ.
13) غرفه ها و جداول (طرح)
SQL
- مجله جوایز
ایجاد reward_ledger جدول (
id BIGSERIAL کلید اصلی، متن منحصر به فرد، متن ، متن ، نوع متن، ارزش عددی (18,2)، متن ارز، هزینه عددی (18,2) پیش فرض 0، - وضعیت P&L متن، - موفق/شکست خورده/برگزار شد TIMESTAMPTZ، TIMESTAMPTP سیستم های TZ
);
- عدم توانایی
ایجاد شاخص منحصر به فرد uniq_reward_task در reward_ledger (reward_task_id) ؛
- بودجه
ایجاد reward_budget جدول (
pool_id کلید اصلی متن، بودجه عددی (18,2)، صرف عددی (18,2)، دوره تاریخ
);
14) امنیت و حریم خصوصی
امضاهای HMAC، MTLS، اجازه لیست IP.
رمزگذاری در حمل و نقل/استراحت، چرخش کلید، اسرار در طاق.
به حداقل رساندن داده ها در payload (PII به طور جداگانه، توسط token link، TTL).
گزارش های حسابرسی غیر قابل تغییر (WORM).
سیاست حفظ و نگهداری (حق فراموش شدن، deduplication-safe).
15) چک لیست راه اندازی
- طرح رویداد و رجیستری، قراردادهای webhook (امضا، TTL).
- صف، بازپرداخت، DLQ، دستگیره های بی نظیر.
- کلاه/guardrails در قوانین، دروازه KYC/RG.
- بودجه استخر، قطع کننده مدار، هشدار سرریز.
- داشبورد SLO + قیف پاداش.
- فیلترهای A/B و نظارت SRM.
- دفترچه حوادث (پخش، یخ زدن، شماره دستی).
16) مورد کوچک (مصنوعی)
رویدادهای متصل از ارائه دهندگان بازی و کیف پول ؛ شامل «برنده/شرط» به ثمر رساند با نگهبانان دهان.
Webhooks HMAC را امضا کرد، تا 8 تلاش، DLQ با بررسی هر 2 ساعت.
برای 4 هفته: تاخیر پردازش p95 180 ms ؛ DLQ <0,06٪ ؛ پرداخت های تکراری 0 ؛ پرچم های تقلب − 0 4 ص ؛ ΔParticipation_net + 6,3 п п.; Δ ARPPU (خالص) + €2,1 при جایزه و پاداش/فعال + €0,7.
نتیجه گیری: مقیاس بندی قوانین به جغرافیایی جدید با استخر بودجه محلی.
خودکار سازی پاداش "ارسال فشار با freespins نیست. این یک سیستم مهندسی است: تحویل قابل اعتماد رویدادها، نسخه بندی دقیق قوانین، قابلیت اطمینان و امضاها، خصوصی سازی بودجه، دروازه های KYC/RG، ضد تقلب و نظارت. ساخت این چارچوب یک روز - و هر ماموریت، مسابقات و «لحظات غارت» کار خواهد کرد قابل پیش بینی، در زمان و با یک اثر خالص مثبت است.