Prevedere attività e trigger partecipativi

1) Attività

È necessario prevedere quando un giocatore con una forte probabilità di entrare (o, al contrario, può «spegnersi») e quale stimolo aumenterà la possibilità di partecipare a una missione/qualificatore/torneo, rispettando l'onestà e l'onestà e il Resource Gaming (RG).

Domande chiave:

«Quando suona di solito?» (pattern temporanei)
«Cosa fa scattare la partecipazione?» (contenuto, formato, premio, durata)
«Come si fa a non surriscaldarsi?» (frequenza dei tocchi, vincoli RG, bilancio economico)

2) Segnali di dati

Comportamento: ritmo di ingresso (ore/giorni), lunghezza e ritmo delle sessioni, frequenza di partecipazione agli eventi.

Contenuti: provider/generi preferiti, novità, varietà.

Economia promo: reazioni a bust/token/cosmetici di stagione.

I segnali sono chat, clip, reazioni (se disponibili).

Contesto: dispositivo, canale, zona temporale, festività/eventi locali.

RG: limiti di tempo/deposito, segni di stanchezza, «segnali di pausa».

Tutti i fili sono aggregati, senza PII oltre il minimo regolatorio.

3) Fithering (esempi)

Stagionalità/ritmo: one-hot ore 0-23, giorni della settimana; Correzione automatica delle laghe (ACF/PACF).

Probabile «finestra di accesso» P (active	ora, giorno) una finestra scivolosa di 4-8 settimane.
Propensione a partecipare: conversione a partire dalle visualizzazioni del banner di registrazione e di partenza.
Tempo fino alla sessione successiva: mediana degli intervalli ponderata esponenzialmente.
Sensibilità agli stimoli: uplift per tipo di trigger (formato, durata, cosmetici).
Tensione RG: percentuale di sessioni lunghe, avvisi, «ritmo di stanchezza».

4) Pila modello

1. Serie temporali per attività:

Prophet/NeuralProphet, LSTM/Temporal Fusion Trasformer per pattern di gruppo;
Semplici profili di stagione per la rete.

2. Survival/Time-to-Event:

Cox/Weibull/RSF fino alla sessione successiva; il rischio dì spegnersi "(churn-hazard).
3. Propensity partecipazione (P (join))

GBDT/TabTransformer: possibilità di partecipare alla presentazione della proposta.

4. Modellazione Uplift (CATE):

Two-Model/T-Learner, X-Learner, DR-Learner per scegliere quale trigger/contenuto dà un aumento.

5. Regole di orchestrazione:

contestuale bandito (LinUCB/Thompson) per la selezione online canale x contenuto x tempo all'interno dei caps.

5) Tipi di trigger partecipativo

Contenuti: formato torneo (sprint 20-30 min, maratona), provider preferiti, «novità della settimana».

«Partenza tra 15 minuti», «qualificatore serale», corrispondenza con la probabile finestra d'ingresso.

Premi (cosmetici/token): senza pay-to-win; le rarità sono comuni a tutti.

Social: amici online, community challenge, attività co-up (etico, senza pressione).

Missione di crociera, missione di riscaldamento breve.

6) Orchestrazione dei tocchi (canale x tempo x frequenza)

Canali: in-app, tasca, email, web-inbox; Priorità in-app per la posta elettronica.

Selezione del tempo: intersezione p (active nei seguenti 90-120 minuti) con pianificazione delle iventi.

Frequenza/cap: massimo N tocchi/settimana, M/giorno; cooldown rigoroso tra i trigger.

Modalità silenziosa: finestre utente notturne «silenzioso» → inbox nell'app.

7) Onestà, compilazione, RG

Nessuna influenza su RTP/Possibilità. I trigger cambiano la strada, non la vincita.

Trasparenza: pagina «Come selezioniamo le notifiche»: finestre di attività, limiti di frequenza, disattivazione - 1 clic.

Guardie RG: in caso di stanchezza/limitazione, riduciamo la frequenza, offriamo una pausa, non chiamiamo formati lunghi.

Alloggio/opt-out - rispettato immediatamente; «silenzio intelligente» dopo la denuncia.

8) Anti-spam e anti-abuse

Rate limiting per utente e canale.

La deduplicazione del significato è di non far trapelare un motivo simile.

Budget economico: cap per l'emissione di token/cosmetici per stagione.

Giustizia: il valore superiore del premio è uguale; la personalizzazione riguarda l'appropriatezza.

9) KPI e metriche di controllo

Finestra Hit Rate - Percentuale di tocchi nella sessione attiva di un minuto.

Join Uplift: aumento della partecipazione vs controllo.

D7/D30 Retention uplift è vicino alla linea di destinazione.

Fatige: Aumento di scartoffie/mute/denunce; Mute Rate

Metriche RG: riduzione delle sessioni ultraveloci, percentuale di pause morbide.

Prize ROY/Emision to GGR - in modo che l'economia promozionale sia sostenibile.

Integrale Revenue/User-Week (se applicabile e regolabile).

10) A/B-pattern

1. Le finestre di avviso sono T-30/15/5 min fino all'inizio del qualificatore.

2. Durata formato: sprint 20 min vs 35 min per slot serali.

3. Tipo di contenuto: provider vs preferito «novità della settimana».

4. Canale: in-app vs pass; un pasticcio con riferimenti vs profondi senza.

5. Politica Uplift: target solo uplift-positivi vs ampia copertura.

6. Combo-trigger: missione-riscaldamento torneo vs subito torneo.

11) Modelli JSON

Profilo delle predizioni per giocatore:

json
{
"user_id": "u_29104",  "next_active_window": {"start": "2025-10-24T17:00:00Z", "end": "2025-10-24T19:00:00Z", "p_active": 0. 72},  "p_join_by_trigger": {
"sprint_20min": 0. 41,   "marathon_60min": 0. 18,   "new_provider_event": 0. 36
},  "uplift_by_trigger": {
"sprint_20min": 0. 12,   "new_provider_event": 0. 07
},  "rg_flags": {"fatigue": false, "limit_time": false},  "cooldowns": {"push": true, "in_app": false}
}

Soluzione del tocco orchestrale:

json
{
"decision_id": "dec_2025_10_24_1630",  "user_id": "u_29104",  "touch": {
"channel": "in_app",   "time": "2025-10-24T17:05:00Z",   "trigger": "sprint_20min",   "creative": "evening_sprint_card_v3"
},  "fairness": {"reward_cap_equivalent": true},  "rg": {"suggest_break": false}
}

12) Pseudocode orchestrazione

python ctx = build_context(user_id)
p_active = activity_model. predict_window(ctx, horizon_hours=4)
p_join = propensity_model. score_triggers(ctx)
uplift = uplift_model. estimate(ctx, triggers=p_join. keys())

RG e vincoli di frequenza if ctx. rg. fatigue or over_frequency_cap(user_id):
schedule_silent_inbox(user_id); exit()

selezione della finestra e del trigger win = best _ time _ window (p _ active, events _ schedule)
trigger = argmax(uplift, mask=channel_caps(user_id))

touch = compose_touch(user_id, channel="in_app", window=win, trigger=trigger)
if economy_budget_ok(trigger) and not in_quiet_hours(user_id, touch. time):
deliver(touch); log(touch)

13) pattern UX

Il cartellino della lobby è: «Sera sprint 20 minuti, partenza 15 minuti, trucco Rare».

Tempo stimato: «≈20-25 minuti» + indicatore di difficoltà.

Le opzioni di controllo sono «Ricorda dopo», «Ignora questo argomento», «Non parlare per una settimana».

I VFX silenziosi sono brevi, non invasivi, senza un suono ossessivo.

14) Piano di implementazione

1. MVP (2-4 settimane): finestre di attività coorte + propensity semplice; un canale (in-app), una frequenza cap, una schermata di trasparenza.

2. v0. 9: modello survival tempo di accesso succo + inbox; uplift di base per 2-3 trigger.

3. v1. 0: bandito contestuale, calendario completo degli eventi, bilancio delle emissioni, integrazione RG, rapporti di onestà.

4. Più avanti: «orari della settimana», missioni crociate, geo-iventi, MLOs-automazione della deriva.

15) Checchlist prima del lancio

Nessuna influenza su RTP/Possibilità; Il valore dei premi è uguale.
I limiti di frequenza e la modalità silenziosa sono attivati.
Le guardie RG sono attive; c'è un veloce opt-out.
Il bilancio economico è confermato; L'anti-spam funziona.
Il piano A/B e la soglia di successo KPI sono definiti.
La schermata «Come funziona» e il login delle soluzioni sono pronti.

Prevedere attività e trigger è tempo x contenuto x canale sotto i connazionali RG e onesti. Le serie temporali e le serie survival danno «quando», propensity e uplift - «cosa chiamare», il bandito - «come adattare online». Con la frequenza, la trasparenza e il budget sostenibile, i promozionali ottengono meno rumore, più partecipazione e un'economia di stagione prevedibile.