Puanlama kurallarının A/B testleri

Puanlama, herhangi bir oyunlaştırmanın kalbidir. Puanların tam olarak nasıl sayıldığı, oyuncu davranışını, katılım yapısını ve ekonomisini (ARPPU, bonus kemikler) belirler. Aşağıda, yeni puan kuralını geçerli bir şekilde test etmek ve metrik büyümenin bir eser değil, gerçek olduğundan emin olmak için pratik bir reçete bulunmaktadır.

1) Tam olarak neyi test ediyoruz

Kural örnekleri:

Bahis miktarına göre: Her 1 € bahis için 1 puan.
Win/bet çarpanı ile: puan = ⌊ çarpan × k ⌋, bahis başına bir kap.
Hibrit: devir başına puan + "seri" için destek (üst üste N dönüş), dakika/saat başına büyük harf.
Görevler: Artan karmaşıklıkla görevleri (T1...Tn) tamamlamak için noktaları düzeltin.

Hipotez (örnek): "Çarpan + başlık modeli, Net ARPPU'yu (ödüllerden/bonuslardan sonra) kötüleştirmeden participation_net ve tamamlama oranını artıracaktır".

2) Deneysel ünite ve randomizasyon

Ünite: kullanıcı (oturum değil, cihaz değil).

Dağıtım: sabit tuzlarla statik karma (user_id - kova); 50/50 veya A/B/C için 33/33/33 kesirler.

Tabakalaşma (önerilen): ödeyen-statü (yeni ödeme/yeniden ödeme/ödemeyen), platform, geo.

Yapışkan atama: Kullanıcı test sırasında her zaman aynı kuralı görür.

Test SRM (Örnek Oran Uyumsuzluğu) - Grupların gerçek paylarını günlük olarak beklenen paylara (ki-kare) karşı kontrol edin. SRM - trafik sızıntısı sinyali, hatalı filtreleme, hatalar.

3) Metrikler ve "noktaların hunisi"

Etkinlik ve katılım

Erişim: olayı kimlerin gördüğünü paylaşın.

Participation_gross: girildi/isteğe bağlı.

Participation_net: ilerleme/ideal başladı.

Tamamlama: Tamamlandı/başladı.

Kalite ve para

Δ DAU/WAU и yapışkanlık (DAU/WAU).

Oturum başına Avg Bahisleri, Avg Bahis Boyutu.

ARPPU (net) = ARPPU − (ödeyen başına Ödül + Bonus Maliyeti).

Avg Mevduat, Pay ödeme.

Net Yükselme: (ek gelir) − (ödüller + bonuslar + işletme + dolandırıcılık sızıntıları).

Gardereils

1.000 kullanıcı için şikayetler/teknik destek, KYC reddetmeleri, anormal bahis kalıpları, RG bayrakları (limitler, kendini dışlama).

4) Süre, mevsimsellik ve yenilik

Minimum 2 tam iş döngüsü (örn. Hafta sonunu yakalamak için 2 hafta).

Yenilik etkisini düşünün: ilk 48-72 saatin bir sıçraması. Aşamalar halinde düzeltin ve analiz edin (D0-D2, D3-D7, D8 +).

Büyük tanıtımlarla geçmeyin veya gruplarda "eşit gürültü" planlamayın.

5) Örnekleme kapasitesi ve hacmi (hesaplama örneği)

Amaç: Δ farkını ortalama "kullanıcı başına puan" (veya Net ARPPU) ile tespit etmek.

İki örneklemli t testi için formül (gruplar halinde eşit olarak):

[
n_{\text{na grup}} =\frac {2, (z_{1-\alpha/2}+z_{1-\beta}) ^ 2 ,\sigma ^ 2} {\Delta ^ 2}
]

Örnek: Δ = 5 puan, σ = 120, α = 0 yakalamak istiyoruz. 05 (iki taraflı), güç %80 (β = 0. 2).

(z_{1-α/2}=1{,}96), (z_{1-β}=0{,}84) - toplam 2. 8. kare 7. 84.

(\sigma ^ 2 = 14,400).

(n =\frac {2\times 7 {,} 84\times 14,400} {25 }\yaklaşık\frac {225,792} {25 }\yaklaşık 9,032) grup başına.

💡 Toplam: Grup başına ~ 9,100 kullanıcı (reddetme ve antifraud marjı ile).

6) Dağılımı azaltmak: testi'daha ucuz "hale getirmek

CUPED: Test öncesi eş değişkenler için regresyon ayarı (örneğin, geçen hafta için puan/oranlar).

Kovaryatlar: payer-flag, cironun log-dönüşümleri, aktivite, platform, geo.

Hata kümeleme: kullanıcı düzeyinde (içinde tekrarlanan oturumlar).

7) Müdahale ve "boğazlar"

Puan kuralı, test katılımcılarından daha fazlasını etkileyebilir:

Sosyal karşılaştırma (ortak lider kurulu) - "yayılma".
Paylaşılan jackpotlar/ortak görevler - çapraz etki.

Çözümler:

Liderlik tablolarını gruplara göre ayırın veya puanların gizli normalleştirilmesi.
Trafik/coğrafi kümeler tarafından küme randomizasyonu (daha pahalı ama daha temiz).
Protokol başına (ITT) + hassas tahliller.

8) Antifraud ve ağız dolusu kurallar

Gözlüklerdeki herhangi bir değişiklik optimizasyonu teşvik eder: mikro bahisler, botovodstvo, "gözlük çiftlikleri".

Minimum koruma:

Dakika/saat/gün başına ve bir bahis için Cap puanları.
Bahislerin minimum oynaklığı ("ideal" dizilerin yasaklanması).
Başsız/tekrarlanan parmak izlerinin tespiti, proxy.
Büyük ödüller + KYC gecikmeli doğrulama.
Analytics: "Puanlar/bahisler've" puanlar/dak "dağılımını karşılaştırın, yazı arayın.

9) Olaylar ve veri şeması (minimum)

Olaylar:

'session _ start {user_id, ts, platform}'
'event _ view {user_id, event_id, ts}'
'event _ join {user_id, event_id, ts}'
'points _ given {user_id, event_id, rule_id, miktar, kaynak, ts}'
'mission _ progress {user_id, mission_id, adım, değer, ts}'
'mission _ complete {user_id, mission_id, ts}'
'bet {user_id, game_id, bahis, kazan, ts}'
'keposit {user_id, miktar, ts}'

Referans kitapları:

'rules {rule_id, name, params, caps_minute, caps_hour, caps_day, version}'
'atamalar {user_id, test_id, grup, assigned_at}'

10) Analiz için SQL eskizleri

SRM kontrolü (grup tahsisi):

sql
SELECT group, COUNT () AS users
ATAMALARDAN
WHERE test_id =: test
GRUP GRUP GRUP;
-- beklenen kesirlere karşı ileri ki-kare

Gruba Göre Katılım/Tamamlanma:

sql
AS OLARAK UYGUN İLE (
KULLANıCILARDAN user_id SEÇ
WHERE last_active_at> =: start - INTERVAL '14 gün'
), AS'ye katıldı (
user_id 'TAN AYRI event_join SEÇ
WHERE event_id =: event AND ts BETWEEN: start AND: end
), AS (
user_id 'TAN AYRI mission_progress SEÇ
WHERE ts BETWEEN: start AND: end VE mission_id IN (: görevler)
), AS (tamamlanmış
user_id 'TAN AYRI mission_complete SEÇ
WHERE ts BETWEEN: start AND: end VE mission_id IN (: görevler)
)
SELECT a. group, COUNT (DISTINCT j. user_id)::float/COUNT (DISTINCT e. user_id) AS participation_gross, COUNT (DISTINCT s. user_id)::float/COUNT (DISTINCT e. user_id) AS participation_net, COUNT (DISTINCT c.) (COUNT c. user_id)::float/NULLIF (COUNT (DISTINCT s. user_id),0)) AS completion
UYGUN OLANDAN e
JOIN atamaları a USING (user_id)
LEFT JOIN, j USING'e katıldı (user_id)
LEFT JOIN STARTED s USING (user_id)
LEFT JOIN completed c USING (user_id)
WHERE a. test_id =: test
GROUP BY a. group;

Net ARPPU ve ödüllerin/bonusların değeri:

sql
Ödeme yapanlarla AS (
Ödemelerden AYRI user_id SEÇ
WHERE ts BETWEEN: start VE: end
), rev AS (
SELECT user_id, SUM (gr) AS gr
Gelirden
WHERE ts BETWEEN: start VE: end
GRUP user_id
), AS maliyetleri (
SELECT user_id, SUM (ödül + bonus) AS maliyet
promo_costs'dan
WHERE ts BETWEEN: start VE: end
GRUP user_id
)
SELECT a. group, AVG (COALESCE (r. gr, 0) - COALESCE (c. Maliyet, 0)) FILTER (WHERE p. user_id IS NOT NULL) AS net_arppu
ATAMALARDAN a
LEFT JOIN payors p USING (user_id)
LEFT JOIN rev r USING (user_id)
SOL KATILIM maliyetleri c KULLANIM (user_id)
WHERE a. test_id =: test
GROUP BY a. group;

CAPPED (örnek):

sql
- pre_value: gözlük/ön test geliri; değer: test sırasında
SELECT grubu, AVG (değer - teta pre_value) AS cuped_mean
GELEN (
SELECT a. group, x.user_id, x.value, x.pre_value, (SELECT COVAR_SAMP (değer, pre_value )/ VAR_SAMP (pre_value)
x) Teta OLARAK
ATAMALARDAN a
JOIN x ON x.user_id = a. user_id
WHERE a. test_id =: test
) t
GRUP GRUP GRUP;

11) Kısmi etkiler ve heterojenlik

HET efektlerini kontrol edin:

Yeni başlayanlar vs çekirdek, düşük değerli vs yüksek değerli, farklı platformlar/geo.
Bazen yeni gözlük formülü balinaları değiştirmeden orta çekirdeği "aydınlatır" - bu istenen sonuçtur.
"P-hacking'i yakalamamak için segmentleri önceden kaydedin.

12) Sık tuzaklar

1. Tüm gruplar için ortak bir lider kurulu - müdahale.

2. Test sırasında ödül yapısının değiştirilmesi - kıyaslanamazlık.

3. Gözlüklerin mikro bahisleri - geçersiz yükseltme.

4. ETL'deki SRM ve yüzen filtreler - önyargılı tahminler.

5. Ödüller/bonuslar düşülmeden "kirli" ARPPU'ya güvenmek.

6. Doğru sıralı istatistikler olmadan dalgalanmalar nedeniyle erken durdurma.

13) Bayes vs frekans ve sıralı kararlar

Çerçeve: Bayesian yaklaşımını (metriklerde arka fark, "B, A'dan daha iyidir" olasılığı), özellikle zaman içinde izlerken kullanabilirsiniz.

Dikkat: Gözlük kuralları için haydutlar, onaylanmış bir yükseltmeden sonra uygundur - çalışma aşamasında, ilk doğrulamada değil.

14) Sorumlu oyun ve uyum

Şeffaf kurallar ve büyük harfler: Oyuncu nasıl puan kazandığını anlamalıdır.

Etkinlik ve para yatırma limitleri, "duraklar've RG istemleri.

Oyun tarzı için gizli "cezalar" yok.

15) Mini Kasa (Sentetik)

Bağlam: Haftalık etkinlik, A = "1 € bahis için puan", B = "kazan/bahis çarpanı ile puan, cap = 50/bahis".

Boyut: 2 × 10.000 kullanıcı, ödeme yapan statüsüne göre katmanlaştırılmış. SRM - yaklaşık.

Sonuçlar:

Participation_net: A %17,3 - B %22,1 (+ 4,8 п. п.) .
Tamamlama: A %38,9 - B %44,0 (+ 5,1 п. п.) .
Net ARPPU: 41 €. 2 - B €43. 5 (+ €2. 3) ödeyen kişi başına Ödül + Bonus ≈ €6 ile. 4 (değişmemiş).
Complaints/1k: değişmemiş; Kapaklar nedeniyle ↓0,3 pp dolandırıcılık bayrakları.
Sonuç: Kural B - kazanan; Ödüllerin "uzun kuyruğu'ile ölçeklendirir ve ağız muhafızlarını kurtarırız.

16) Puan A/B Başlatma Kontrol Listesi

Birim = kullanıcı, yapışkan atama, tabakalaşma.
Girişimi kaldırmak için ayrı leadboards/normalization.
Gözlük, anti-bot sinyalleri, KYC için büyük kazananlar için açık kapaklar.
Hipotezlerin ve metriklerin ön kaydı (birincil/ikincil/korkuluklar).
Kapasite ve süre planı, mevsimsellik dikkate alınır.
CUPED/kovaryatlar bağlı, boru hattı SRM-uyarıları.

Rapor: ödül/ikramiye sonra para artış, kuyruk sonrası etkisi.

[Дашборд "Erişim - Katılım - İlerleme - Tamamlanma - Değer".

---

Puanlama kuralı bir davranış kaldıracıdır. Doğru tasarlanmış bir A/B testi (SRM olmadan, sahteciliği önleme ve eş değişkenli), oyuncu güvenini ve kampanya ekonomisini korurken, katılımı, tamamlamayı ve Net ARPPU'yu güvenli bir şekilde artırmanıza olanak tanır.