Automatyzacja wydarzeń i nagród - Zasady i haki internetowe

Gra oparta jest na dwóch „silnikach”: zdarzeniach (co zrobił użytkownik) i zasadach (co ma być dla niego). Aby działać na dużą skalę i bez błędów, potrzebujesz niezawodnego autobusu imprezowego, silnika zasad, mechanizmu dostawy/przyznawania i ścisłej ochrony przed oszustwami. Poniżej znajduje się praktyczna architektura, szablony i listy kontrolne.

1) Zdarzenie → zasada → architektura przepływu nagród

1. Ingest (wejście zdarzenia): SDK/web, serwer webhooks od dostawcy płatności/gier → API Gateway → kolejka/autobus (Kafka/Królik/Cloud Pub/Sub).

2. Normalizator: walidacja, wzbogacanie (geo, urządzenie, payer_flag), wersja schematu.

3. Zasady Silnik: punktowanie/XP, sprawdzanie misji/zadań, wyzwalacze nagród/powiadomień.

4. Orkiestrator nagród: obliczanie nagród, kontrola budżetu, bramki RG/KYC, tworzenie „zadania emisyjnego”, rejestrowanie.

5. Payout/Bonus Service: cache/bonus cache/freespins/kupony, zewnętrzne haki (portfel, dostawcy).

6. Powiadamiacz: push/in-app/email/instant messengers z limitami częstotliwości.

7. Storage/Analytics: surowe zdarzenia, sklepy, A/B, wpisy.

8. Anti-Fraud/RG: ustniki, heurystyka/ML, hold-and-review big prizes.

2) Model zdarzenia (minimalny zestaw)

json
{
"event_id": "d9e8-... -5c2", "event_name": "zakład", "wersja": "1. 2. 0 „,” ts': „2025-10-24T11:37:21Z,” „użytkownik”: {
"id':" u_123, "" geo ":" TR "," platforma ":" android "," payer_flag": true ", risk_flags": [" vp _ night "]
}, „kontekst”: {
"session_id": "s_789," "device_fp": "fp_...," "ip": "203. 0. 113. 24"
}, „ładunek użytkowy”: {
"game_id": "slot_wolf," "zakład": 0. 5, "wygraj': 1. 25, „waluta”: „EUR”, „dostawca”: „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 _ issued', 'rg _ event'.

3) Silnik reguły: jak opisać logikę

Koncepcje: reguły (jeśli/wtedy), segmenty, okna czasowe, ustniki, priorytety, wersioning.

Przykład reguły deklaracyjnej (styl YAML):

yaml rule_id: r_points_winmult_v2, gdy:
event_name: filtry stawek:
- ładunek użytkowy. zakład> = 0. 2
- użytkownik. geo in [„TR „, „BR”,” PE”]
- teraz między „2025-11-01” i „2025-11-30”
wynik:
wzór: "podłoga (ładunek użytkowy. wygrana/ładunek użytkowy. zakład) 3) "
czapki:
per_bet: 50 per_minute: 200 per_day: 1500 reward_trigger:
on_progress:
próg: [100, 300, 800]
nagroda: [{typ: "fs', wartość: 10}, {typ:" bonus_cash, "wartość: 2}, {typ:" łup ", rzadkość:" rzadki "}]
barierki ochronne:
kyc_min_level: 2 rg_limits_ok: prawdziwe budget_pool: „nov_season”
budget_soft_cap: 80000 metrów:
wersja: "2. 0"
eksperyment: „scoring_ab_2025w45”

4) Haki internetowe: integracja serwera z serwerem

4. 1. Wychodzące haki internetowe (od Ciebie do dostawców/portfel)

Metoda: 'POST https ://partner. przykład/wypłaty "

Бодбиса: 'X-Signature: HMAC-SHA256 (secret, body)' + 'X-Request-Id' (idempotency).

Retrai: wykładniczy backoff, 'max _ retries = 8', jitter, DLQ.

Idempotencja: powtórzyć ten sam 'X-Request-Id' → partner musi odpowiedzieć tym samym' payout _ id/status '.

Przykład ładunku:

json
{
„request_id": „rid_7f5...,” „user_id": „u_123,” „nagroda”: {„typ „: „gotówka”,” kwota”: 10. 00, "waluta": "EUR"}, "reason": "milestone_300_points," "kyc_level": 2", "ograniczenia": {"zakład": 0 ", expiry_at":" 2025-12-01T00: 00: 00Z "}
}

4. 2. Przychodzące haki internetowe (do Ciebie)

Zezwalaj tylko na listy IP/MTLS, sprawdź HMAC i lifetime podpisu ('X-Timestamp', ± 5 minut).

Przechowywać „surowe” ciało + nagłówki w sklepie audytowym (WORM).

Każdy podwójny/powtarzający się → sprawdź klucz idempotencji w log.

5) Niezawodność: „równomierny” przepływ bez podwójnych płatności

Przynajmniej raz na połknięcie + idempotent handlers → złoty standard.

Klucz idempotencji: 'hash (event_id + user_id + rule_id)' do punktacji; oddzielny klucz do wystawiania nagrody "reward _ task _ id'.

Dokładnie raz semantyka jest tylko logicznie realistyczna (poprzez idempotencję), a nie transportowa.

Kolejność zdarzeń: przechowywać 'event _ ts' i' ingest _ ts'; użyć okna ponownego zamawiania (na przykład 60 sekund) i powtórzyć z kolejki za pomocą klucza 'user _ id'.

Kolejka martwych listów (DLQ):

Piszemy tam wiadomości ze stałym błędem (tymczasowy schemat nie przeszedł, podpis jest nieprawidłowy, budżet jest zamknięty).
Usługa przeglądu DLQ z przyciskami regeneracji/drop/fix schematu.

6) Budżety i ochrona marginesu

Puli budżetowe: „nov _ season”, „daily _ sprint”, „vip _ weekend”.

Kwoty: miękki/twardy pułap, „wyłącznik” - przy osiągnięciu 90% budżetu, przenieść duże nagrody do stanu wstrzymania.

Pojedynczy koszt: „Nagroda i premia Koszt na aktywnego/płatnika”, Net Uplift.

Priorytety: RG i zgodność są ważniejsze niż promo - w przypadku konfliktu nagroda zostaje odroczona.

Przykład kontroli budżetu (szkic SQL):

sql
WYBIERZ pool_id, SUMA (kwota) JAKO WYDANE, BUDŻET JAKO LIMIT, SUMA (kwota )/budżet AS
OD reward_ledger
GDZIE pool_id =: pula i DATA (ts) = current_date
GRUPA WEDŁUG pool_id, budżet;

7) bramki RG/KYC/Geo (bezpieczeństwo i zgodność gracza)

KYC: minimum L2 dla pamięci podręcznej/dużych nagród; freespins są ważne z L1.

RG: sprawdzanie limitów depozytów, samodzielne wyłączenie, cool-off → nagrody są zamrożone do czasu zniesienia ograniczeń.

Geo: lista dozwolonych krajów dla każdej zasady przyznawania/puli.

Alerty progowe: gwałtowny wzrost „prawie osiągnięty” na poszczególnych rachunkach = powód do przeprowadzenia & przeglądu.

8) Zasady zwalczania nadużyć finansowych i telemetria

Czapki punktów w tempie/min/godzinę/dzień, minimalna zmienność zakładów, zakaz „idealnych” wzorów.

Sygnały techniczne: bezgłowa, powtarzające się device_fp, podsieci proxy.

Anomalie: „punkty/zakłady” i „punkty/min” - długie „ogony” na 99-percentylu.

Hold-and-review dla najlepszych zwycięzców: automatyczna kontrola KYC + ręczna recenzja.

9) Monitorowanie, mierniki i wpisy

SLO/SLA:

Połknięcie p95 ≤ 250 ms; zasady przetwarzania p95 ≤ 150 ms; aktualizacja rady przywódczej ≤ 2 s; wydanie nagrody ≤ 60 s.
Budżet błędu <0. 1% zdarzeń/dzień.

Wpisy:

SRM na eksperymenty (skew ruchu), wzrost DLQ, spadek podpisu walidacji HMAC, przekroczenie budżetu, duplikat idempotent przepięcia.

Deska rozdzielcza (dziennie):

Zdarzenia/s, opóźnienie, tolerancja błędów;
Lejek: wydarzenie → zasada → reward_task → reward_issued;
Koszt: Nagroda/Bonus za aktywny, Uplift netto;
Jakość: flagi oszustw, bloki KYC, wyzwalacze RG.

10) Weryfikacja i migracja

Każda reguła jest zmieniana ('rules. wersja ").

Nie można edytować aktywnej reguły bez nowej wersji; używać ficheflag i „gładkie ogrzewanie” (10% → 50% → 100%).

Schemat zdarzeń poprzez rejestr schematu; niezgodne ze wspólnym rynkiem zmiany - tylko w wersji głównej.

11) Testy automatyzacji A/B (krótkie)

Jednostka - użytkownik; przydział lepki; stratyfikacja (płatnik/geo/platforma).

Oddzielne lidery lub normalizacja punktów w celu wyeliminowania zakłóceń.

Podstawowy: participation_net, zakończenie, Net ARPPU; Poręcze: reklamacje/1k, flagi oszustw, wyzwalacze RG.

CUPED i covariates dla redukcji wariancji.

12) Przykłady: od reguły do wydania

12. 1. Mikropłatny wyzwalacz postępu

json
{
"typ": "reward_task. utworzony „,” reward_task_id": „rt_456,” „user_id":” u_123, „” pochodzenie „: {” rule _ id': „r _ points _ winmult _ v2”, „próg”: 300}, „nagroda”: {„typ”: „bonus_cash,” „kwota”: 2, „waluta”: „EUR”, „zakład”: 15}, „pool_id":” nov_season, „” status „:” oczekujące „,” created_at": „2025-10-24T11:38:30Z”
}

12. 2. Wychodzący hak na portfel


POST/portfel/kredyt
X-Request-Id: rid_7f5...
X-Timestamp: 1730061700
Podpis X: sha256 = 7b9a...

{„user_id":"u_123,” „kwota”: 2. 00, „waluta”:” EUR”, „powód „: „zasada: r _ points _ winmult _ v2”}

Sukces → 'reward _ task' = 'succeeded' i pisanie do 'reward _ ledger'.

Awaria (5xx/timeout) → przekaźnik z tym samym 'X-Request-Id'.

Dip (4xx) → DLQ + ręczne parsing.

13) Sklepienia i tabele (szkic)

sql
-- magazyn nagród
UTWÓRZ TABELĘ reward_ledger (
id KLUCZ PODSTAWOWY BIGSERIAL, TEKST reward_task_id UNIKALNY, TEKST user_id, TEKST pool_id, typ TEKST, wartość NUMERIC (18,2), waluta TEKST, koszt NUMERIC (18,2) DEFAULT 0, -- реалкнай стоимоска ла P&L status TEXT, -- succeeded/failed/held created_at TIMESTAMPTZ, updated_at TIMESTAMPTZ
);

-- odszkodowanie
TWORZENIE UNIKALNEGO INDEKSU uniq_reward_task NA reward_ledger (reward_task_id);

-- budżet
UTWÓRZ TABELĘ reward_budget (
pool_id KLUCZ PODSTAWOWY TEKSTU, NUMER BUDŻETU (18,2), wydane NUMERYCZNE (18,2), DATA OKRESU
);

14) Bezpieczeństwo i prywatność

Podpisy HMAC, MTLS, list IP.

Szyfrowanie w tranzycie/odpoczynku, rotacja klucza, sekrety w skarbcu.

Minimalizacja danych w ładunku użytkowym (PII oddzielnie, za pomocą łącza tokenowego, TTL).

Dzienniki audytu immutable (WORM).

Polityka zachowania i usposobienia (prawo do bycia zapomnianym, bezpieczne dla deduplikacji).

15) Lista kontrolna startu

Schematy i rejestr wydarzeń, umowy z hakami internetowymi (podpisy, TTL).
Kolejki, przekłady, DLQ, handlarze idempotent.
Czapki/barierki w przepisach, bramki KYC/RG.
Puli budżetowe, wyłączniki, wpisy o przelewach.
Deski rozdzielcze SLO + lejek nagrody.
Filtry A/B i monitorowanie SRM.
Spis wypadków (powtórka, zamrożenie, wydanie ręczne).

16) Mini Case (syntetyczny)

Powiązane wydarzenia od dostawców gier i portfel; w zestawie "win/bet' punktacja z ochraniaczami ust.

Webhooks podpisał HMAC, przekłada się do 8 prób, DLQ z recenzją co 2 h.

Przez 4 tygodnie: opóźnienie przetwarzania p95 180 ms; DLQ <0,06%; duplikat płatności 0; bandery oszustw − 0. 4 pp; ΔParticipation_net + 6,3 μ. п.; ΔARPPU (net) + €2,1 мра Nagroda & Bonus/Active + €0,7.

Wniosek: skalowanie zasad na nowe geo z lokalnymi pulami budżetowymi.

Automatyzacja nagród nie jest "wyślij push z freespins. "Jest to system inżynieryjny: niezawodne dostarczanie wydarzeń, ścisła weryfikacja zasad, idempotencja i podpisy, prywatnicy budżetu, bramy KYC/RG, przeciwdziałanie oszustwom i monitorowanie. Zbuduj ten ramy jednego dnia - i wszelkie misje, turnieje i „momenty łupów” będą działać przewidywalnie, na czas i z pozytywnym efektem netto.