Backend de CRM de prévention de l'attrition

Modèle Backend de CRM de prévention de l'attrition
Suivi du Signal d'Usage et Suivi de Win-Back

Q: À quoi ressemble un pipeline CRM de prévention du churn sain lorsque le travail est sensible et guidé par des délais ?

Un backend CRM de prévention du churn organise les données Utilisateur, Compte, UsageSignal, Alerte, CancellationReason et WinBackLog afin que les équipes puissent détecter des baisses d'utilisation, documenter les raisons de churn et exécuter des actions de suivi.

Q: Quels flux de travail CRM de prévention du churn bénéficient le plus de tâches structurées par rapport aux notes libres ?

Il inclut des classes Utilisateur, Compte, UsageSignal, Alerte, CancellationReason et WinBackLog, plus un diagramme ER, un bac à sable API et une invite pour un Agent IA.

Q: Quelle est la meilleure façon d'ajouter des champs de rapport CRM de prévention du churn sans ralentir le travail quotidien ?

Back4app fournit une base de données gérée, une authentification, des requêtes en temps réel et un schéma flexible pour que vous puissiez suivre les alertes de baisse d'utilisation, les raisons d'annulation et les logs de retour sans faire fonctionner votre propre backend.

Q: Comment afficher les alertes de baisse d'utilisation dans Flutter ?

Interrogez Alert et UsageSignal pour chaque compte, puis affichez severity, signalType, usageCount et baselineCount dans un tableau de bord de rétention.

Q: Comment puis-je créer une entrée de journal de reconquête à partir d'une action serveur Next.js ?

Utilisez une action serveur pour créer un objet WinBackLog lié à un compte et au propriétaire, puis mettez à jour le statut après l'appel de suivi.

Q: React Native peut-il stocker des données de désabonnement hors ligne ?

Oui. Activez le Local Datastore et épinglez les résultats des comptes et des UsageSignal afin que les représentants puissent examiner la santé des comptes sans connexion stable.

Q: Comment puis-je arrêter l'accès non autorisé aux raisons d'annulation ?

Utilisez des vérifications beforeSave Cloud Code et des règles ACL pour restreindre l'accès à CancellationReason et WinBackLog aux rôles de succès ou de support appropriés.

Q: Quelle est la meilleure façon d'inspecter l'utilisation des comptes sur Android ?

Interrogez les classes Account et UsageSignal pour montrer healthScore, usageCount et baselineCount pour chaque compte sur le terrain.

Un backend de CRM de prévention de l'attrition prêt pour la production sur Back4app avec des enregistrements User, Account, UsageSignal, CancellationReason, WinBackLog et Alert. Comprend un diagramme ER, un dictionnaire de données, un schéma JSON, un terrain de jeu API et une invite AI Agent pour un démarrage rapide.

Construire avec l'Agent IA Choisissez votre technologie

Principales leçons sur la rétention

Ce modèle vous offre un backend CRM de prévention du churn avec des enregistrements Account, UsageSignal, Alert, CancellationReason, et WinBackLog afin que les coordinateurs et agents puissent suivre le risque tôt.

Suivi de UsageSignal — Suivez les lignes UsageSignal pour les modèles de login_drop, seat_drop, et feature_drop pour chaque Account.
Capture de CancellationReason — Conservez des entrées CancellationReason structurées avec reasonCode et reasonNotes afin que les équipes puissent regrouper les causes de churn par compte.
Suivi du WinBackLog — Enregistrez les actions WinBackLog pour les enregistrements Account sauvegardés, le moment de contact, et le statut de suivi.
Flux de travail basés sur des alertes — Utilisez des enregistrements Alert liés aux lignes UsageSignal pour router les comptes à faible utilisation vers l'User assigné.
Backend CRM multiplateforme — Servez les outils web, mobiles et internes avec une API REST et GraphQL pour les activités Account, Alert, CancellationReason et WinBackLog.

Aperçu : CRM de prévention de désabonnement

Si l'accueil du CRM de prévention de désabonnement est désordonné, tout en aval en souffre - une capture propre à la porte d'entrée fait gagner des heures de reconstruction plus tard. Ce n'est rarement un seul bogue - c'est la dérive. Façonnez les entités principales sur Back4app pour gérer les questions de CRM de prévention de désabonnement avec une propriété plus claire, moins de tâches abandonnées et un historique prêt pour le client. Le schéma couvre User (nom d'utilisateur, email, rôle), Account (nom de la société, niveau de plan, score de santé, propriétaire, date de renouvellement), UsageSignal (compte, type de signal, nombre d'utilisations, nombre de référence, date du signal), CancellationReason (compte, code de raison, notes de raison, capturé par, capturé à), WinBackLog (compte, nom de la campagne, statut, dernier contacté à, prochaine étape à, propriétaire), et Alert (compte, usageSignal, type d'alerte, gravité, statut, assigné à) avec des contrôles d'authentification et de flux de travail intégrés. Connectez votre frontend préféré et commencez à gérer le risque de désabonnement plus rapidement.

Meilleur pour :

Tableaux de bord de prévention de désabonnement SaaSOutils CRM pour le succès clientProduits de suivi d'utilisationSystèmes de suivi des raisons d'annulationApplications de flux de reconquêteDes équipes choisissant BaaS pour des outils de rétention

Aperçu du backend CRM de prévention du désabonnement

Dans le CRM de prévention du désabonnement, les conversations les plus difficiles commencent par “quel chiffre est officiel ?” — un signe que le backend n'est pas encore autoritaire.

Attendez-vous au même suivi des comptes clients, détection de chute d'utilisation, acheminement d'alerte que vous partiez de Flutter, React, Next.js, ou un autre chemin supporté.

Fonctionnalités de prévention du churn

Chaque carte technologique dans ce hub utilise le même schéma de prévention du churn avec Utilisateur, Compte, UsageSignal, RaisonDeAnnulation, WinBackLog, et Alarme.

Suivi des comptes clients

Compte stocke companyName, planTier, healthScore, owner, et renewalDate.

Détection de la baisse d'utilisation

UsageSignal capture signalType, usageCount, baselineCount, et signalDate pour chaque compte.

Routage d'alerte

Alerte relie un Compte, UsageSignal, sévérité, statut, et assignéÀ.

Journalisation des raisons d'annulation

RaisonAnnulation stocke codeRaison, notesRaison, capturePar, et capturéÀ.

Historique du journal de récupération

JournalRécupération suit nomCampagne, statut, dernierContactéÀ, prochainÉtapeÀ, et propriétaire.

Pourquoi construire votre backend CRM de prévention du churn avec Back4app ?

Back4app vous fournit des primitives de compte, d'alerte, de raison et de réengagement afin que votre équipe puisse se concentrer sur les décisions de fidélisation au lieu de la maintenance des serveurs.

•Suivi des comptes et de l'utilisation: Les classes Account et UsageSignal maintiennent companyName, planTier, healthScore, owner, et renewalDate ensemble pour chaque compte.
•Flux de travail d'alerte et de raison: Les enregistrements Alert et CancellationReason permettent aux coordinateurs de passer d'une baisse d'utilisation à une raison de churn documentée sans jongler avec des tableurs.
•Flexibilité en temps réel + API: Utilisez Live Queries pour les changements d'Alert tout en gardant REST et GraphQL disponibles pour chaque tableau de bord et outil d'administration.

Construisez des flux de travail de prévention du churn rapidement avec un contrat backend unique sur toutes les plateformes.

Avantages de la rétention

Un backend de prévention du churn qui vous aide à agir sur les signaux de rétention sans reconstruire le flux de travail à chaque fois.

Intervention précoce sur les baisses d'utilisation

Travaillez à partir de UsageSignal et Alarme au lieu de scanner les journaux bruts pour chaque Compte.

Rapport clair des raisons de churn

Utilisez les entrées RaisonDeAnnulation pour séparer les problèmes de tarification, d'adoption et de support par compte.

La propriété du compte reste visible

Liez les enregistrements Compte et Alarme au bon Utilisateur pour le suivi.

Essais de sauvegarde structurés

Enregistrez chaque action WinBackLog afin que les équipes puissent comparer le calendrier et les résultats des prises de contact.

Données de rétention au même endroit

Stockez les détails sur User, Account, UsageSignal, Alert, CancellationReason et WinBackLog sans utiliser de tableurs séparés.

Flux de travail d'amorçage AI

Générez rapidement une structure backend et des conseils d'intégration avec une seule invite structurée.

Prêt à lancer votre CRM de prévention de l'attrition?

Laissez l'Agent AI Back4app structurer votre backend de prévention de l'attrition et générer des alertes UsageSignal, des captures de CancellationReason et le suivi de WinBackLog à partir d'une seule invite.

Construisez avec l'Agent AI Essayez le terrain de jeu API

Gratuit pour commencer — 50 invites d'agent IA/mois, sans carte de crédit requise

Churn Stack

Tout est inclus dans ce modèle de backend CRM de prévention de l'attrition.

Frontend

13+ technologies

Backend

Back4app

Base de données

MongoDB

Auth

Authentification intégrée + sessions

API

REST et GraphQL

Temps réel

Live Queries

Diagramme ER du compte

Modèle de relation d'entité pour le schéma backend CRM de prévention du churn.

Diagramme ER de compte

Voir la source du diagramme

Mermaid

erDiagram
    User ||--o{ Account : "owner"
    User ||--o{ CancellationReason : "capturedBy"
    User ||--o{ WinBackLog : "owner"
    User ||--o{ Alert : "assignedTo"
    Account ||--o{ UsageSignal : "account"
    Account ||--o{ CancellationReason : "account"
    Account ||--o{ WinBackLog : "account"
    Account ||--o{ Alert : "account"
    UsageSignal ||--o{ Alert : "usageSignal"

    User {
        String objectId PK
        String username
        String email
        String password
        String role
        Date createdAt
        Date updatedAt
    }

    Account {
        String objectId PK
        String companyName
        String planTier
        Number healthScore
        String ownerId FK
        Date renewalDate
        Date createdAt
        Date updatedAt
    }

    UsageSignal {
        String objectId PK
        String accountId FK
        String signalType
        Number usageCount
        Number baselineCount
        Date signalDate
        Date createdAt
        Date updatedAt
    }

    CancellationReason {
        String objectId PK
        String accountId FK
        String reasonCode
        String reasonNotes
        String capturedById FK
        Date capturedAt
        Date createdAt
        Date updatedAt
    }

    WinBackLog {
        String objectId PK
        String accountId FK
        String campaignName
        String status
        Date lastContactedAt
        Date nextStepAt
        String ownerId FK
        Date createdAt
        Date updatedAt
    }

    Alert {
        String objectId PK
        String accountId FK
        String usageSignalId FK
        String alertType
        String severity
        String status
        String assignedToId FK
        Date createdAt
        Date updatedAt
    }

Flux de travail de rétention

Flux d'exécution typique pour la connexion, la surveillance de l'utilisation, la création d'alerte, la capture de raisons et l'enregistrement de reconquête.

Diagramme ER de compte

Voir la source du diagramme

Mermaid

sequenceDiagram
  participant User
  participant App as SaaS Churn Prevention CRM App
  participant Back4app as Back4app Cloud

  User->>App: Sign in to the churn dashboard
  App->>Back4app: POST /login
  Back4app-->>App: Session token

  User->>App: Review at-risk accounts
  App->>Back4app: GET /classes/UsageSignal?include=account
  Back4app-->>App: UsageSignal rows with Account links

  User->>App: Open a usage drop alert
  App->>Back4app: GET /classes/Alert?include=account,usageSignal
  Back4app-->>App: Alert details and severity

  User->>App: Record a cancellation reason or win-back note
  App->>Back4app: POST /classes/CancellationReason and POST /classes/WinBackLog
  Back4app-->>App: Saved reasonCode and win-back objectId

Dictionnaire des champs

Référence complète au niveau des champs pour chaque classe dans le schéma de prévention du churn.

Champ	Type	Description	Requis
objectId	String	Auto-generated unique identifier	Auto
username	String	User login name
email	String	User email address
password	String	Hashed password (write-only)
role	String	Role of the user (admin, coordinator, agent)
createdAt	Date	Auto-generated creation timestamp	Auto
updatedAt	Date	Auto-generated last-update timestamp	Auto

7 champs dans User

Sécurité des comptes et autorisations

Comment la stratégie ACL et CLP sécurise les enregistrements d'utilisateur, les comptes, les signaux d'utilisation, les alertes, les raisons et les journaux de récupération.

Accès au compte limité au propriétaire

Seul l'utilisateur assigné peut mettre à jour ou supprimer un Compte ; les autres peuvent seulement lire ce que leur rôle permet.

Notes de rétention protégées

Les entrées Alerte, RaisonAnnulation et WinBackLog peuvent être restreintes aux rôles de succès, de support et d'opérations.

Surface de lecture contrôlée

Restreindre l'historique de désabonnement sensible à la bonne équipe tout en maintenant les résumés de santé du compte disponibles pour les coordinateurs.

Schéma JSON

Définition brute de schéma JSON prête à être copiée dans Back4app ou utilisée comme référence d'implémentation.

JSON

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223

224

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

{
  "classes": [
    {
      "className": "User",
      "fields": {
        "objectId": {
          "type": "String",
          "required": false
        },
        "username": {
          "type": "String",
          "required": true
        },
        "email": {
          "type": "String",
          "required": true
        },
        "password": {
          "type": "String",
          "required": true
        },
        "role": {
          "type": "String",
          "required": true
        },
        "createdAt": {
          "type": "Date",
          "required": false
        },
        "updatedAt": {
          "type": "Date",
          "required": false
        }
      }
    },
    {
      "className": "Account",
      "fields": {
        "objectId": {
          "type": "String",
          "required": false
        },
        "companyName": {
          "type": "String",
          "required": true
        },
        "planTier": {
          "type": "String",
          "required": true
        },
        "healthScore": {
          "type": "Number",
          "required": true
        },
        "owner": {
          "type": "Pointer",
          "required": true,
          "targetClass": "User"
        },
        "renewalDate": {
          "type": "Date",
          "required": true
        },
        "createdAt": {
          "type": "Date",
          "required": false
        },
        "updatedAt": {
          "type": "Date",
          "required": false
        }
      }
    },
    {
      "className": "UsageSignal",
      "fields": {
        "objectId": {
          "type": "String",
          "required": false
        },
        "account": {
          "type": "Pointer",
          "required": true,
          "targetClass": "Account"
        },
        "signalType": {
          "type": "String",
          "required": true
        },
        "usageCount": {
          "type": "Number",
          "required": true
        },
        "baselineCount": {
          "type": "Number",
          "required": true
        },
        "signalDate": {
          "type": "Date",
          "required": true
        },
        "createdAt": {
          "type": "Date",
          "required": false
        },
        "updatedAt": {
          "type": "Date",
          "required": false
        }
      }
    },
    {
      "className": "CancellationReason",
      "fields": {
        "objectId": {
          "type": "String",
          "required": false
        },
        "account": {
          "type": "Pointer",
          "required": true,
          "targetClass": "Account"
        },
        "reasonCode": {
          "type": "String",
          "required": true
        },
        "reasonNotes": {
          "type": "String",
          "required": false
        },
        "capturedBy": {
          "type": "Pointer",
          "required": true,
          "targetClass": "User"
        },
        "capturedAt": {
          "type": "Date",
          "required": true
        },
        "createdAt": {
          "type": "Date",
          "required": false
        },
        "updatedAt": {
          "type": "Date",
          "required": false
        }
      }
    },
    {
      "className": "WinBackLog",
      "fields": {
        "objectId": {
          "type": "String",
          "required": false
        },
        "account": {
          "type": "Pointer",
          "required": true,
          "targetClass": "Account"
        },
        "campaignName": {
          "type": "String",
          "required": true
        },
        "status": {
          "type": "String",
          "required": true
        },
        "lastContactedAt": {
          "type": "Date",
          "required": false
        },
        "nextStepAt": {
          "type": "Date",
          "required": false
        },
        "owner": {
          "type": "Pointer",
          "required": true,
          "targetClass": "User"
        },
        "createdAt": {
          "type": "Date",
          "required": false
        },
        "updatedAt": {
          "type": "Date",
          "required": false
        }
      }
    },
    {
      "className": "Alert",
      "fields": {
        "objectId": {
          "type": "String",
          "required": false
        },
        "account": {
          "type": "Pointer",
          "required": true,
          "targetClass": "Account"
        },
        "usageSignal": {
          "type": "Pointer",
          "required": true,
          "targetClass": "UsageSignal"
        },
        "alertType": {
          "type": "String",
          "required": true
        },
        "severity": {
          "type": "String",
          "required": true
        },
        "status": {
          "type": "String",
          "required": true
        },
        "assignedTo": {
          "type": "Pointer",
          "required": true,
          "targetClass": "User"
        },
        "createdAt": {
          "type": "Date",
          "required": false
        },
        "updatedAt": {
          "type": "Date",
          "required": false
        }
      }
    }
  ]
}

Construire avec l'Agent IA

Utilisez l'agent IA Back4app pour générer une application CRM de prévention du churn à partir de ce modèle, y compris le frontend, le backend, l'authentification, ainsi que les flux UsageSignal, Alert, CancellationReason et WinBackLog.

Back4app Agent IA

Prêt à construire

Créez un backend Back4app sécurisé pour un CRM de prévention du churn avec ce schéma et ce comportement exacts.

Schéma:
1. Utilisateur (utiliser Back4app intégré) : nom d'utilisateur, email, mot de passe, rôle ; objectId, createdAt, updatedAt (système).
2. Compte : nom de l'entreprise (String, requis), niveau de plan (String, requis), score de santé (Number, requis), propriétaire (Pointeur vers Utilisateur, requis), date de renouvellement (Date, requis) ; objectId, createdAt, updatedAt (système).
3. UsageSignal : compte (Pointeur vers Compte, requis), typeDeSignal (String, requis), nombreUtilisation (Number, requis), nombreDeBase (Number, requis), dateDeSignal (Date, requis) ; objectId, createdAt, updatedAt (système).
4. CancellationReason : compte (Pointeur vers Compte, requis), codeDeRaison (String, requis), notesDeRaison (String, optionnel), capturéPar (Pointeur vers Utilisateur, requis), capturéÀ (Date, requise) ; objectId, createdAt, updatedAt (système).
5. WinBackLog : compte (Pointeur vers Compte, requis), nomCampagne (String, requis), statut (String, requis), dernierContactéÀ (Date, optionnel), prochainÉtapeÀ (Date, optionnel), propriétaire (Pointeur vers Utilisateur, requis) ; objectId, createdAt, updatedAt (système).
6. Alerte : compte (Pointeur vers Compte, requis), signalD'utilisation (Pointeur vers UsageSignal, requis), typeD'alerte (String, requis), gravité (String, requis), statut (String, requis), attribuéÀ (Pointeur vers Utilisateur, requis) ; objectId, createdAt, updatedAt (système).

Sécurité :
- Seuls les utilisateurs attribués peuvent mettre à jour les enregistrements d'Alerte.
- Les coordinateurs peuvent créer des entrées de CancellationReason et WinBackLog pour les comptes qu'ils possèdent.
- Les entrées de UsageSignal peuvent être ingérées par des intégrations de confiance ou enregistrées par des agents autorisés.
- Maintenez l'activité du compte limitée par rôle et propriétaire.

Auth :
- Inscription, connexion, déconnexion.

Comportement :
- Lister les comptes, faire remonter les alertes de chute d'utilisation, capturer les raisons d'annulation et maintenir les journaux de récupération.
- Supporter le suivi des renouvellements et la planification des suivis pour les comptes à risque.

Livrer :
- Application Back4app avec schéma, CLPs, ACLs, vues de tableau de bord pour les comptes à risque, alertes, raisons et suivis de récupération.

Appuyez sur le bouton ci-dessous pour ouvrir l'Agent avec ce prompt de modèle pré-rempli.

Ceci est le prompt de base sans suffixe technologique. Vous pouvez adapter la pile frontend générée par la suite.

Déployer en quelques minutes50 prompts gratuits / moisAucune carte de crédit requise

API Sandbox

Essayez les points de terminaison REST et GraphQL contre le schéma de prévention du churn. Les réponses utilisent des données fictives et ne nécessitent pas de compte Back4app.

Chargement du terrain de jeu…

Utilise le même schéma que ce modèle.

Choisissez votre technologie

Développez chaque carte pour voir comment intégrer Compte, Nom et Niveau avec votre pile choisie.

Ce que vous obtenez avec chaque technologie

Chaque pile utilise le même schéma de backend de prévention du désabonnement et des contrats API.

Structure de données de rétention unifiée

Gérez Utilisateur, Compte, SignalUsage, Alerte, RaisonAnnulation, et WinBackLog avec un modèle.

Flux de travail d'alerte de chute d'utilisation

Suivez les baisses d'utilisation, routez les alertes et gardez la propriété de la réponse visible.

Historique des raisons d'annulation pour SaaS

Capturez des raisons structurées afin que l'analyse du churn reste cohérente entre les équipes.

Logs de reconquête pour le suivi

Stockez les actions de contact et les résultats pour chaque compte enregistré.

APIs REST/GraphQL pour les outils CRM

Intégrez des tableaux de bord, des applications mobiles et des outils d'administration avec des APIs flexibles.

Comparaison de la pile de désabonnement

Comparez la vitesse de configuration, le style SDK et le support de l'IA à travers toutes les technologies prises en charge.

Cadre	Temps de configuration	Avantage de rétention	Type de SDK	Support AI
Flutter	Environ 5 minutes	Base de code unique pour les tableaux de bord de rétention sur mobile et web.	SDK typé	Complet
React	Moins de 5 minutes	CRM web rapide pour le suivi de la santé des clients.	SDK Taper	Complet
React Natif	~3–7 min	Application de terrain multiplateforme pour les équipes de succès.	SDK Taper	Complet
Next.js	Configuration rapide (5 min)	Tableau de bord de rétention rendu sur serveur pour les équipes internes.	SDK Taper	Complet
JavaScript	~3–5 min	Intégration légère pour les widgets de santé de compte.	SDK Taper	Complet
Android	Environ 5 min	Application Android native pour le suivi de compte.	SDK tapé	Complet
iOS	Moins de 5 minutes	Application iOS native pour les représentants du succès client.	SDK tapé	Complet
Vue	~3–7 min	Interface web Reactive pour la prévention du churn.	SDK tapé	Complet
Angular	Configuration rapide (5 min)	Tableau de bord d'entreprise pour les opérations de rétention.	SDK tapé	Complet
GraphQL	Moins de 2 min	API flexible GraphQL pour l'analyse de rétention.	API GraphQL	Complet
REST API	Configuration rapide (2 min)	Intégration REST API pour les workflows de désabonnement.	REST API	Complet
PHP	~3 min	Service PHP côté serveur pour le traitement des alertes.	REST API	Complet
.NET	~3–7 min	Backend .NET pour l'automatisation de la rétention.	SDK tapé	Complet

Le temps de configuration reflète la durée estimée du démarrage du projet jusqu'à la première requête Account ou UsageSignal utilisant ce schéma de modèle.

FAQ sur le désabonnement

Questions fréquentes sur la création d'un backend CRM de prévention des désabonnements avec ce modèle.

À quoi ressemble un pipeline CRM de prévention du churn sain lorsque le travail est sensible et guidé par des délais ?

Quels flux de travail CRM de prévention du churn bénéficient le plus de tâches structurées par rapport aux notes libres ?

Quelle est la meilleure façon d'ajouter des champs de rapport CRM de prévention du churn sans ralentir le travail quotidien ?

Comment afficher les alertes de baisse d'utilisation dans Flutter ?

Comment puis-je créer une entrée de journal de reconquête à partir d'une action serveur Next.js ?

React Native peut-il stocker des données de désabonnement hors ligne ?

Comment puis-je arrêter l'accès non autorisé aux raisons d'annulation ?

Quelle est la meilleure façon d'inspecter l'utilisation des comptes sur Android ?

Fiable pour les développeurs du monde entier

Rejoignez des équipes expédiant des produits de prévention du désabonnement plus rapidement avec les modèles Back4app

Prêt à construire votre CRM de prévention du désabonnement ?

Commencez votre projet de prévention du désabonnement en quelques minutes. Aucune carte de crédit requise.

Choisissez la technologie

Modèle Backend de CRM de prévention de l'attritionSuivi du Signal d'Usage et Suivi de Win-Back