====== Entretien des données dans CiviCRM ====== Lorsqu'on met en place une base de données CiviCRM, il faut prévoir des tâches de maintenance des données à faire régulièrement pour notamment : * Fusionner les contacts en double que CiviCRM n'a pas identifié * Corriger les problèmes de rebonds des courriels * Désactiver ou supprimer les informations obsolètes Les sous-sections suivantes décrivent avec plus de détails en quoi consistent ces tâches. ===== Dédoublonnage ===== Il existe 3 types de dédoublonnage qui correspondent à des mécanismes différents dans CiviCRM : non-supervisé, supervisé et général. On peut les trouver dans le menu Contacts -> Trouver et fusionner les contacts en double. **Non-supervisé** Cette règle sert à éviter la création de doublons lors de l'import de données ou lorsqu'un contact remplit un formulaire en ligne. Avant d'activer une telle règle, il faut d'abord s'assurer qu'elle ne fusionnera pas des contacts qui devraient rester distinct. Il est habituellement préférable de tolérer des duplicatas que d'attacher des dons, des adhésions ou des participations à un mauvais contact! Les champs nom et prénom ne peuvent pas suffire ici puisqu'il peut y avoir des homonymes. Par défaut, l'adresse de courriel est utilisée pour identifier chaque contact de manière unique, ce qui n'est pas toujours souhaitable. **Supervisé** Cette règle est appliquée automatiquement lorsqu'un contact est créé ou édité par l'interface. Une alerte sera affichée si le contact créé correspond à un contact existant. L'utilisateur peut ainsi choisir entre poursuivre la création du contact et éditer le contact trouvé. Parce qu'un contrôle humain s'impose à chaque fois que cette règle est appliquée, on peut se permettre d'établir ici des règles plus souples. Les homonymes, les courriels identiques, les fautes de frappes, par exemple, peuvent être interceptés par ce type de règle. Toutefois, pour des questions de performance, il peut être préférable de garder le nombre de règles à un minimum raisonnable. **Général** Ces règles sont créée selon les besoins pour permettre une vérification manuelle des contacts en double. Puisque ces règles ne sont appliquées que sur demande, il est possible de mettre en place ici des règles plus complexes qui peuvent être coûteuse en performance. Une règle complexe peut être cependant très longue a exécuter et il est préférable de l'appliquer que sur des sous-groupes de contacts. Il est nécessaire de mettre en place un processus manuel de vérification des doublons à intervalle régulier pour : * Garder l'historique de ces contacts à jour * Éviter de faire des appels ou envois postaux en double * Fausser les statistiques ===== Rebonds de courriels ===== Si un courriel rebondit, cela signifie qu'il ne rejoint pas le destinataire. Cela peut arriver pour différentes raisons et notamment : * L'adresse courriel a été mal saisie * L'adresse courriel est en panne (serveur de courriel brisé ou indisponible) * La boite courriel du destinataire est pleine et ne peut plus accepter de messages temporairement * Le destinataire a activé un message automatique d'absence (vacances) CiviCRM gère différemment chaque types de rebond -- cf. http://wiki.civicrm.org/confluence/display/CRMDOC/Bounce+Handling : * Les rebonds temporaire n'auront pas d'effet sur le dossier du contact : CiviCRM continuera d'envoyer des courriels à cette adresse * Plusieurs rebonds permanents auront pour effet de changer le statut d'une adresse de courriel à ''Suspendu'' Lorsqu'une adresse courriel est en mode ''Suspendu'', aucun courriel n'est envoyé à cette adresse tant que ce statut n'est pas retiré manuellement. Il est important de mettre en place une tâche manuelle de vérification des courriels marqués ''Suspendu'', soit après chaque envoi massif, soit à un intervalle régulier (une fois par mois) : * Utiliser le rapport ''Mail Bounce Report'' pour identifier les adresses courriels problématiquesé * Cocher la colonne ''Raison du renvoi'' pour obtenir des précisions. * Appeler ses contacts pour avoir l'heure juste et faire les correctifs : supprimer l'adresse courriel ou la réactiver en retirant son état ''Suspendu''. ===== Normalisation des données ===== Une base de données n'est utile que si ses données sont à jour et cohérentes. Une recherche ne peut fonctionner optimalement que si les valeurs recherchée ont été saisies systématiquement et (surtout) de manière uniforme. Lors de la création des champs personnalisés : quand une donnée peut faire l'objet d'une recherche ou d'une analyse statistique, il est recommandé d'utiliser une liste de choix plutôt qu'un champ de texte libre. Pour faciliter la saisie d'une donnée, il peut être intéressant de mettre en place des mécanismes de vérification ou remplissage automatique. Par exemple : * Synchroniser automatiquement les champ ''Préfixe'' et ''Sexe'' * Valider des adresses (à l'aide d'un service externe payant comme Postes Canada) ou remplir préalablement le code postal ou la région administrative en fonction de la ville (ou inversement) Enfin, CiviCRM propose une interface pour changer les valeurs de champ relié à 50 contacts à l'aide de la mise à jour en lot. Il est possible de définir les champs disponibles dans le formulaire de mise à jour et ainsi de corriger des problèmes ponctuels. ===== Nettoyage des données obsolètes ===== Certaines interfaces sont alourdies par des listes de choix qui grossissent un fil du temps. Pour ne plus être visibles sur les interfaces, les items suivants peuvent être rendus inactifs : * Les modèles de messages qui apparaissent lors de la génération de courriels ou PDF. * Les groupes, et notamment : * Les groupes dynamiques créés pour extraire des données ou obtenir une statistique utile pour fois seulement -- la suppression peut être préférable dans ce cas. * Les groupes de type ''Mailing List'' qui ne sont plus utilisés et qui continue d’apparaître dans l'outil CiviMail. * Les campagnes -- la date de fin, si elle est renseignée permet d'éviter cette opération.