RTP: konfiqurasiya modeli

RTP (Return To Player) - oyun/variant riyaziyyatı tərəfindən müəyyən edilmiş uzun məsafədə nəzəri qayıdış faizi. Prodakşendə RTP idarə olunan məhdudiyyətlər və siqnallar toplusuna çevrilir: harada, kimə və hansı şəraitdə riyaziyyatın bu və ya digər variantına icazə verilir (97/96/94/92 və s.), faktiki dönüşü necə saymaq, sapmalara necə reaksiya vermək və uyğunluq üçün dəyişiklikləri necə sənədləşdirmək.

1) Terminlər və səviyyələr

Theoretical RTP (tRTP) - elan edilmiş variant riyaziyyatı (sertifikatlaşdırılmış).
Effective RTP (eRTP) - seçimlər (cekpot bonusu, bonus buy, side-bets, provayder komissiyaları) nəzərə alınmaqla gözlənilən geri qaytarma.
Realized RTP (rRTP) - zaman pəncərəsi/raundlar (empirik) üzrə faktiki geri dönüş.
RTP Variant - xüsusi bir bild/oyun profili (məsələn, 96. 5%).
RTP Band/Policy - yurisdiksiyalar/tenantlar üçün icazə verilən diapazonlar.

Modelin məqsədi: icazə verilən tRTP-ni başlanğıc kontekstinə (tenant, region, valyuta, kanal) bağlamaq və eRTP/rRTP-ni SLO ilə yoxlaya bilməkdir.

2) Konfiqurasiya ölçmələri (qaydaları təyin etdiyimiz yerdə)

1. Provayder/Game/Variant - ümumiyyətlə dəstəklənir.
2. Tenant/Brand - kommersiya və UX həlləri (hansı RTP göstərmək).
3. Region/Yurisdiksiya - lisenziyalar və tənzimləyici çərçivələr.
4. Kanal - web/native/retail/terminal (bəzən hovuzlar/parametrlər fərqlənir).
5. Valyuta - cekpotlar və komissiyalar ilə kəsişir (eRTP-yə təsir edir).
6. Müvəqqəti pəncərələr - promo dövrlər, kanareya hesablamaları.

3) İyerarxiya, prioritetlər, merj

GLOBAL_DEFAULT < PROVIDER < GAME < VARIANT < TENANT < REGION < CHANNEL < CURRENCY < WINDOW

Konkretləşdirmənin olmadığı yerdə valideyndən miras qalırıq. Hər hansı bir açıq deny aşağı səviyyələrdə allow örtür.

4) Konfiqurasiya sxemi (YAML, nümunə)

yaml rtp_config:
schema_version: 1 global_defaults:
allowed_bands: [96, 95, 94] # percentages rounded to whole min_band: 92 show_rtp_label: true # show RTP in the providers directory/card:
prag_play:
games:
gates_of_:
variants:
"96. 5": { status: "allow", label: "96. 5%" }
"94. 0": { status: "allow", label: "94%" }
"92. 0": { status: "deny" }
jackpot_uplift_bps: 35       # +0. 35% to eRTP with tenant pool active:
brand_eu:
regions:
EE:
bands_allow: [96, 94]
default_band: 96 channel:
web:  { bands_allow: [96], default_band: 96 }
retail:{ bands_allow: [94], default_band: 94 }
DE:
bands_allow: [94]
default_band: 94 compliance:
mandate_rtp_label: true currencies:
EUR:
fee_bps: 0 # impact on eRTP
TRY:
fee_bps: 10           # -0. 10% eRTP on paid rollout features:
canary:
brand_eu: { region: "EE", game: "gates_of_", variant: "96. 5", traffic_pct: 10, ends_at: "2025-11-07T00:00:00Z" }
sla:
monitoring_windows:
- { name: "daily",  duration_h: 24, min_rounds: 1_000 }
- { name: "weekly", duration_h: 168, min_rounds: 10_000 }
ertp_tolerance_bps: 50  # eRTP vs tRTP, ±0. 50% for information alerts rrtp_tolerance_bps: 150 # rRTP vs tRTP, ± 1. 50% on weekly window

5) Dərc etməzdən əvvəl validasiya

Variantın sertifikatlaşdırılması: variantda etibarlı sertifikat/ID bild var.
Yurisdiksiya çərçivəsi: Seçilmiş band bölgədə icazə verilir.
Fich uyumluluğu: bonus buy/jackpot/side-bets eRTP-ni xaricə çıxarmır.
UI müqavilələri: bayraq 'show _ rtp _ label '/bəzi bazarlar üçün məcburi etiket.
Tutarlılıq: hər kontekstdə defolt bandı var («dəlik» olmaması üçün).
Dry-run: formullara görə eRTP hesablanması və SLO/tolerans ilə müqayisə.

6) eRTP saymaq üçün necə

eRTP = tRTP
+ jackpot_uplift
+ side_bet_uplift
- provider_fee
- platform_fee
- bonus_buy_friction

• jackpot_uplift - mütərəqqi hovuz bonusu (bps, hovuzun ölçüsündən və dərəcəsindən asılıdır).
• side_bet_uplift - side-betlərdən gözlənilən pay (mümkünsə).
• provider/platform_fee - raund/bahis üçün fix/faiz, bəzən valyuta ilə bağlıdır.
• bonus_buy_friction - bonus almaq mexanikasından «sürtünmə» (əgər qiymət fair value-dən yüksək olarsa).

Bütün terminlər və mənbələr determinik hesab olunur və konfiqurasiya hadisəsinə daxil edilir.

7) RTP-yə təsir

Bonus Buy: nəticələrin paylanmasını dəyişə bilər; eRTP-ni ayrı-ayrılıqda saxlayın.
Jackpot: eRTP yığımdan asılıdır; eRTP diapazonuna icazə verin, lakin nəzarət nöqtələrini saxlayın (məsələn, hər N% hovuz böyüdükdə - yenidən hesablama).
Side Bets/Feature Bets: ayrı-ayrı RTP profilləri; məhdudiyyətli bölgələrdə onları qadağan edin.
Volatility profile: RTP eynidir, lakin dispersiya fərqlidir; profil (low/med/high) band yanında saxlayın.

8) Kataloq, başlanğıc və adapterlər

Kataloq/Read Model: 'tRTP _ band', 'eRTP _ range', 'label', fic bayraqları saxlayın.
Game Launch: Sessiyaya başladıqda adapter kontekst üçün icazə verilən bandı yoxlayır; uyğun deyilsə, başlamağı qadağan edir.
Round Events: Round hadisələrinə. Started/Resulted 'əlavə' rtp _ context '(variant_id, band, flags) - bu audit və metrikanı asanlaşdıracaq.

9) Monitorinq, SLO və drift

• 'rRTP _ window _ daily/weekly' - pəncərələrin faktiki qaytarılması.
• `rounds_count`, `stake_sum`, `win_sum`, `jackpot_contrib`.
• `deviation_bps = rRTP - tRTP` и `rRTP - eRTP`.
• 'bonus _ buy _ share', 'side _ bet _ share' - sürüklənmənin səbəbini anlamaq üçün.
• 'jackpot _ level' və tezliyi.

10) Anti-sui-istifadə və müdafiə

Anomaliyalar: qazancın kəskin partlayışları, feature buy ardıcıllığı → cihaz/hesab/IP/seqment üzrə yoxlama.
Limitlər siyasəti: Anomaliyalar zamanı bonus buy/side bets-i müvəqqəti olaraq söndürün.
Vendor-fid: Fich ehtimalını provayderin referans fidi ilə müqayisə edin.
Sampling əl review: yüksək dispersiya və tez-tez şikayətlər ilə oyunlar.

11) Uyğunluq və şəffaflıq

Yurisdiksiyalar: icazə verilən bandların və məcburi etiketlərin siyahısı (məsələn, RTP/yaş xəbərdarlıqlarının göstərilməsi).
Sertifikatlaşdırma/ID bild: hesabat linki, math profile versiyası saxlayın.
Hesabat: 'tRTP', 'eRTP', 'rRTP' və dəyişiklik hadisələri ilə tənzimləyici hesabatlar verin.
UI/Məzmun: Oyun kartında düzgün RTP etiketi və qeydlər var (əgər eRTP cekpotdan asılıdırsa).

12) Kanarya relizləri və A/B

Canary: bir yurisdiksiyada trafikin 5-10% -i üçün yeni bir band açın → 'rRTP', 'rounds _ count', şikayətləri izləyin.
A/B: dönüşüm/cəlb/ARPU müxtəlif band biznes ilə müqayisə, yalnız RTP.
Avtomatik geri çəkilmə: rRTP kritik hədlərdən çıxdıqda - konfiqurasiyanın geri çəkilməsi.

13) Audit və dəyişikliklərin idarə edilməsi

json
{
"event_type":"RTPConfigChanged",
"changed_by":"user@company",
"tenant_id":"brand_eu",
"scope":"regions. EE. games. gates_of_",
"old":{"default_band":94},
"new":{"default_band":96},
"reason":"licence_update_2025Q4",
"occurred_at":"2025-10-31T12:00:00Z"
}

Dəyişməz jurnalın aparılması mübahisələrin müzakirəsini və tələblərə uyğunluğunu asanlaşdırır.

14) Test

Contract tests: sxem etibarlılığı, defolt mövcudluğu, deny/allow məntiq.
Property-based: 'eRTP' hər hansı bir fich kombinasiyası üçün ağlabatan çərçivədən kənara çıxmır.
Replay: yeni konfiqurasiya (offline) → hesabatların yoxlanılması üzərində tarixi raundların qaçışı.
Chaos: Adapter, Jackpot Fid Lagi, Fic Bayraqlarını qaçırmaq.
Golden set: eRTP referans hesablamaları ilə oyunlar/variantlar dəsti.

15) Playbooks (runbooks)

1. rRTP həftə tRTP altında getdi

Nümunəni, bonus buy/side bets payını, jackpot və fiedin aktuallığını yoxlayın.
Mübahisəli fiqurları (bayraq) söndürün, provayderi xəbərdar edin, gücləndirilmiş log daxil edin.
Lazım olduqda müvəqqəti band/variant dəyişdirmək.

2. «Vicdansız RTP» haqqında oyunçuların şikayətləri

Verin 'as _ of' konfiqurasiya, ID bild, həftəlik rRTP və hesablama metodologiyası.
Oyunçu seqmentini məhdudiyyətlər/limitlər/məsuliyyətli oyun üçün yoxlayın.

3. UI etiketlərinin uyğunsuzluğu

Kontekstin konfiqurasiyası ilə 'rtp _ label' müqayisə edin, vitrini yuvarlayın, e2e validasiyasını başlatın.

4. Cekpot uğursuzluğu

uplift/etiket devre, separate accounting qeyd, oyunçu status xəbərdar saxlamaq.

16) Tipik səhvlər

tRTP və eRTP qarışdırın: təcrübə jackpot/fich asılı olduğu yerdə nəzəriyyə göstərmək.
Defolt yoxdur → Oyun «dəlik» kontekstlə başlayır.
Seçimlər/yurisdiksiyalar üzrə spesifikasiya olmadan «bütövlükdə provayderə».
Kiçik məlumatlarda rRTP ilə saxta alert → nümunə həddi yoxdur.
Audit və kanaryalar olmadan dəyişikliklər → bütün bazarlarda bir anda hadisələr.
eRTP → gözləntilər və fakt uyğunsuzluq komissiyalar/fees məhəl qoymayın.

17) Satış öncəsi yoxlama siyahısı

• Hər Variant/ID sertifikatı və sabit tRTP var.
• Hər bir kombinasiya üçün (tenant/region/channel) default_band verilir.
• eRTP (jackpot, fiches, fees) hesablanmış və tolerans keçir.
• RTP etiketləri və yurisdiksiya tələbləri düzgün UI-də əks olunur.
• rRTP/eRTP monitorinqi və nümunə həddi daxildir; alertlər qurulmuşdur.
• Yeni bandlar üçün kanarya; avtomatik cavab.
• Dəyişiklik auditi və tənzimləyici üçün hesabatların ixracı.
• Drift Playbook, mübahisəli qazanc, cekpot uğursuzluğu.
• Testlər: müqavilə/eşik/property/replay.

Nəticə

RTP konfiqurasiya modeli «oyun kartında faiz» deyil, risk və etimad idarəetmə sistemidir. Aydın qaydalar iyerarxiyası, determinant eRTP hesablanması, rRTP müşahidə, kanarya relizləri və ciddi audit mübahisəli mövzunu proqnozlaşdırıla bilən mühəndislik prosesinə çevirir - məhsul üçün əlverişli, oyunçular üçün başa düşülən və uyğunluq üçün təhlükəsiz.