Intégration des missions avec le système bonus et le CRM

Les missions ne fonctionnent que lorsque la récompense est attribuée de manière prévisible et que la communication conduit le joueur d'un pas à l'autre. Le noyau est donc le groupe Mission Engine ↔ Bonus/Wallet ↔ CRM/CDP, plus RG/KYC et antifrod. Ci-dessous, un schéma d'intégration prêt à l'emploi avec des modèles de données et des pratiques éprouvées.

1) Objectifs d'intégration

Augmentation de l'engagement et ARPPU (net) : missions → progrès → récompenses → sessions répétées/dépôts.

Contrôle des marges : budget-pools, caps, « coût du bonus » par actif/payeur.

Personnalisation : missions et récompenses par segments CRM/CDP.

Conformité : Gates KYC/RG, géo-règles, audit.

Mesurabilité : A/B, post-effet, cannibalisation.

2) Architecture de flux

1. Event Ingest: `bet`, `win`, `deposit`, `mission_progress`, `mission_complete`.

2. Moteur de mission : vérification des conditions, comptage des points/statuts, déclencheurs de récompenses.

3. Reward Orchestrator : budget-chèque, RG/KYC, création de « reward _ task ».

4. Bonus/Wallet : cache, bonus-cache (vader), frispins, coupons ; Webhooks/SDK.

5. CRM/CDP : segments, campagnes de déclenchement, limites de fréquence, feuilles de suppression.

6. Analytics/DWH : événements bruts, vitrines, incréments, dashboards.

7. Anti-Fraud & RG : kaps, heuristiques/ML, hold-and-review.

3) Modèle de données et événements

Événements (minimum) :

`mission_view / join / progress / complete`
`points_awarded {rule_id, amount, caps}`
`reward_task. created / succeeded / failed / held`
`wallet_credit / bonus_issued / freespins_issued`
`kyc_status_changed / rg_event`
`crm_send / crm_open / crm_click / crm_unsub`

Exemple 'mission _ complete' :

json
{
"event": "mission_complete",  "ts": "2025-10-24T10:17:12Z",  "user": {"id":"u_123", "geo":"TR", "platform":"ios", "payer_flag":true},  "mission": {"id":"m_4521", "type":"turnover", "segment":"mid_core"},  "progress": {"value": 1000, "window":"2025-10-24"},  "context": {"session_id":"s_778"}
}

4) Carte des récompenses : Missions → système de bonus

Type de mission	Prix de base	Restrictions/drapeaux
Chiffre d'affaires/taux	Bonus cache € x	`wagering=10–20`, `expiry=72h`
Gain/multiplica. Frispins N par jeu	Jeu/fournisseur, pari, terme, géo-restrictions
Dépôt	Cache/cache intact	KYC L2 +, limites selon RG
Chaîne de T1...Tn	Prix Luth (types/rares)	Part des « rares », budget-cap
Action sociale	Coupons/FS	Dans les juridictions où il est autorisé

Règle de sélection : les missions de masse sont des récompenses peu coûteuses (FS/Bonus Cache), les « finisseurs « /chaînes profondes font partie du cache insipide pour la confiance.

5) Reward Orchestrator : budget, RG/KYC, idempotence

Idempotence : clé 'reward _ task _ id' + 'X-Request-Id' pour les appels externes.

Budgets : pools 'season _ sprint', 'onboarding', 'reengage' ; soft/hard cap; circuit-breaker 90%.

KYC/RG-gates : cache> € X - seulement L2 +, avec « cool _ off » actif dans « held ».

Audit : Journal WORM des corps sortants.

Exemple 'reward _ task. created`:

json
{
"type":"reward_task. created",  "reward_task_id":"rt_9a7",  "user_id":"u_123",  "origin":{"mission_id":"m_4521","threshold":"final"},  "reward":{"type":"bonus_cash","amount":5,"currency":"EUR","wagering":15,"expiry":"2025-10-27T00:00:00Z"},  "pool_id":"season_sprint",  "status":"pending"
}

6) Intégration avec portefeuille/service bonus

Webhook sortant (exemple) :


POST /wallet/bonus. issue
X-Request-Id: rid_7f5...
X-Timestamp: 1730061700
X-Signature: sha256=...

{
"user_id":"u_123",  "bonus": {"type":"bonus_cash","amount":5,"currency":"EUR","wagering":15,"expiry":"2025-10-27T00:00:00Z"},  "reason":"mission:m_4521"
}

Réponse du partenaire : '200 {"bonus_id":"b_331", "status ":" issued"} '→ 'reward _ task. succeeded`.

Erreurs 5xx → rétroaction avec le même 'X-Request-Id' ; 4xx → DLQ + manutention manuelle.

7) Lien avec le CRM/CDP

7. 1. Segmentation

Stage : D0-D7 (onbording), R7-R30 (re-engage), Core P30.

Monétisation : non payante/NPP/RPP/haute valeur.

Comportement : les finalistes de la T1/T2/T3, « coincés », « presque atteints ».

Risque : drapeaux RG, statut KYC.

7. 2. Déclencheurs de campagne

« Il reste 120 points », « + 2 positions » est in-app/push.

Post-mission : « le bonus est activé/expire dans 12 heures ».

Winback : n'a pas commencé la mission 48 h → une offre personnelle (si autorisée).

Suppression : dans 'cool _ off '/self-exclusion, pas de promo.

7. 3. Règles de fréquence

Max 1 push/4 h, 1 email/24 h par mission ; capping sur le canal et en général.

Quiet hours par heure locale, double opta-in/out.

8) Pipline de données dans le CRM

CDP-vitrine 'mission _ funnel _ daily' :

`eligible`, `viewed`, `joined`, `started`, `t1..tn`, `completed`, `rewarded`.
Les temps avant la T1/T2/... ; statut de bonus ; 'cost _ eur' ; 'net _ arppu'.

Exemple de déchargement dans le segment « presque atteint » :

sql
SELECT user_id
FROM mission_funnel_daily
WHERE mission_id =:m
AND started = true
AND completed = false
AND points_to_next <= 150
AND last_seen_at > now() - interval '24 hour'
AND rg_ok = true;

9) Antifrod et « fair play »

Caps : points/mise, points/min/heure/jour ; limite des microcrédits répétés.

Signaux : headless, proxy, duplications de 'device _ fp'.

Filtres comportementaux : variance minimale des taux ; modèles « parfaits » → hold.

Prix:> € X et top position - émission différée jusqu'à KYC.

Restrictions CRM : ne pas encourager les « éleveurs de lunettes » ; suppression по fraud-score.

10) L'économie des récompenses et le contrôle des marges

Indicateurs clés :

`Prize & Bonus Cost per Active` / `per Payor`
`ΔARPPU (net)` = ARPPU − (Prize+Bonus per payor)
'Net Uplif' = Recettes incrémentielles − Valeur (prix + opérations + frod)

Budget-suivi (sketch) :

sql
SELECT pool_id,    SUM(value) AS spent,    MAX(budget) AS limit,    SUM(value)/MAX(budget) AS fill
FROM reward_ledger
WHERE date(created_at)=current_date
GROUP BY pool_id;

11) A/B-tests d'intégration

Unité : utilisateur, sticky-assignment, stratification (payer/geo/platform).

Primary: participation_net, completion, `ΔARPPU (net)`.

Guardrails : plaintes/1k, fraud-flags, actionnements RG, alertes SRM.

CUPED : pré-valeur (ARPPU/points la semaine dernière) pour réduire la variance.

Interférence : leaders séparés/normalisation des lunettes.

12) modèles UX qui « tricotent » les missions, bonus et CRM

Un écran est un objectif : des règles claires, des progrès visibles.

Rétroaction immédiate : « + 10 points » et badge de progrès.

Visibilité des récompenses : ce qui a déjà été reçu, ce qui va brûler, ce qui va suivre.

Heidline par rédaction : « invitons » à participer, ne mettons pas la pression sur le dépôt.

Localisation : textes, devises, délais, juridictions.

13) Dashboards (quotidiennement)

1. L'entonnoir des missions : Reach → Join → Start → T1/T2/... → Complete → Rewarded.

2. Communications : send/open/click, opt-out, per-channel capping.

3. Monétisation : Δ ARPPU (net), Avg Deposit, Paying Share.

4. Coût : Prix/Bonus Cost %, Net Uplift, pools de budget.

5. Qualité : DLQ, retraits, erreurs HMAC, latency p95, drapeaux frod, déclencheurs RG.

6. Segments : novice/mid-core/haute valeur ; web/iOS/Android; géo.

14) Chèque de démarrage

Schéma des événements, versioning, contrats Web (HMAC, TTL, idempotence).
Missions de mapping → types de récompenses + budgets/capitaines.
KYC/RG-gates, hold-and-review des grands prix.
Intégration portefeuille/service bonus (sandbox → prod), retrai/DLQ.
Segments CRM/CDP, déclencheurs et règles de suppression, limites de fréquence.
Dashboards SLO et économie ; alerte SRM/DLQ/budget.
Plan A/B, CUPED, chefs de file séparés.
Runbook des incidents : replay des événements, délivrance manuelle, « gel » des règles.

15) Mini case (synthétique)

Lancé : « Onboard 7 jours », « Week-end Springs », « Retern 14 jours ».

Récompenses : T1/T2 - FS/Bonus Cache ; les finisseurs font partie du cache insipide.

CRM : déclencheurs « presque atteint », « bonus expiré », quiet-hours, capping.

6 semaines, 2 marques, holdout 15 %.

Résultats : participation_net 24 % → 33 % (+ 9 PP), complétion 42 % → 56 % (+ 14 PP), Δ ARPPU (net) + 2,8 € ; Prize&Bonus/Active +€0,8; DLQ <0,07%; fraud-flags <1% PF.

Solution : mise à l'échelle, augmentation de la « longue queue » des microprises et des textes locaux dans le CRM.

L'intégration des missions avec le système bonus et le CRM est une machine unique : événements et règles, budget-contrôle, portefeuille/bonus, personnalisation et communications sécurisées. Construisez-la sur l'idempotence, les jeux KYC/RG, les segments CRM et l'économie transparente - et les missions apporteront un incrément net stable plutôt que de « manger » des marges.