Agence de migration vers Klaviyo

Nous préparons votre migration vers Klaviyo avec un mapping des données, des flows reconstruits et des contrôles de bascule.

Migrer vers Klaviyo, c’est transférer des données et des comportements

Une migration d’email marketing ne s’achève pas à l’import des contacts. Il faut aussi transférer les messages reçus par chaque personne, les conditions d’entrée et de sortie des séquences et les informations dont l’équipe a besoin pour continuer. Copier uniquement la base peut laisser automatisations, exclusions et formulaires déconnectés.

Commence par la raison du changement : intégration manquante, limites du système actuel, parcours difficiles à gérer ou besoin de centraliser le travail. Tu pourras distinguer ce qui doit rester de ce qui mérite d’être repensé. La configuration de Klaviyo pour l’e-commerce doit répondre à ces besoins précis.

Le périmètre doit nommer comptes, boutiques, langues, canaux et responsables. Définis l’historique à conserver et les limites de la plateforme source. Ne promets pas de transférer toutes les données avec un sens identique avant d’avoir vérifié l’export et leur représentation à destination.

Préparer un inventaire avant de fixer la date de bascule

Parcours le système actuel avec ses utilisateurs. Examine au-delà des campagnes visibles : formulaires, segments, exclusions, automatisations, modèles, intégrations, notifications de la boutique et opérations manuelles. Identifie qui dépend de chaque élément et les conséquences de son arrêt.

Cet inventaire minimal transforme la migration en livrables vérifiables. Ajoute les références de configuration et une décision par élément : conserver, reconstruire, retirer ou examiner.

ÉlémentÀ consignerÀ vérifier à destination
ContactsIdentifiant, origine, états et champs utilisésIdentité et états rapprochés
FormulairesEmplacement, texte, liste et champs collectésNouvelle inscription au bon endroit
SegmentsRègles, finalité et exclusionsÉchantillon de membres conforme à la règle prévue
AutomatisationsEntrée, délais, sorties, messages et responsablesParcours testé avec des cas représentatifs
ModèlesModules, variables, liens et préférencesContenu complet et liens fonctionnels
IntégrationsÉvénements, responsables et dépendancesNouvelles données reçues et correctement interprétées
RapportsIndicateurs, périodes et règles d’attributionHistorique conservé avec ses définitions

L’inventaire aide aussi à estimer le coût et le périmètre du projet. Peu de modèles mais plusieurs intégrations spécifiques peuvent demander plus de travail que de nombreux messages fondés sur un même design.

Faire correspondre les champs et les états avant l’import

Crée une table de correspondance entre source et destination. Pour chaque champ, indique nom, sens, format, exemple et usage futur. Deux champs intitulés « date d’achat » peuvent représenter la dernière commande d’un profil ou la date d’un événement précis.

Klaviyo documente les méthodes d’import et l’intégration des désabonnements historiques. Ces exclusions doivent être conservées : posséder une adresse email ne signifie pas disposer d’un abonnement actif.

Définis la source prioritaire en cas de contradiction et le traitement des exceptions. Ne résous pas un conflit d’états en choisissant automatiquement la valeur autorisant l’envoi. Garde les cas à clarifier hors des envois jusqu’à vérification.

Teste d’abord un petit échantillon contenant les cas difficiles : données incomplètes, langues différentes, adresses répétées et états variés. Vérifie dates, valeurs vides et caractères spéciaux. Un nombre total identique ne prouve pas la justesse des correspondances.

Par exemple, le champ langue d’une boutique fictive contient « es » et « Español ». Le plan peut les normaliser en une valeur, conserver l’original pour la traçabilité et soumettre les valeurs inconnues à examen. Cette décision doit précéder l’utilisation du champ pour choisir la langue d’un email.

Reconstruire les parcours à partir de leurs règles réelles

Pour chaque automatisation email, documente événement d’entrée, conditions, délais et motifs de sortie. Décide du traitement des personnes déjà engagées dans l’ancien système. Tout recommencer au premier message peut répéter des communications ; les ignorer peut interrompre le suivi.

Ne suppose pas qu’un nom d’événement identique correspond aux mêmes données. Examine un cas récent de la boutique et les champs nécessaires au message. Les blocs produits, liens de panier et conditions d’achat doivent utiliser les informations qui arrivent réellement à destination.

Lors d’une migration depuis Mailchimp, les balises dynamiques des modèles doivent être adaptées, y compris le désabonnement. Copier le HTML ne conserve pas à lui seul leur comportement dans Klaviyo.

Détermine quel système est responsable de chaque message pendant la transition. Inclus les notifications envoyées directement par la boutique pour distinguer celles qui restent et celles qui sont remplacées. Préparer un nouveau parcours n’autorise pas deux versions actives simultanément.

Conserve les décisions de contenu avec les décisions techniques. Si l’ordre des messages change ou qu’une ancienne offre disparaît, note la raison et la validation. Cela permet de distinguer une évolution volontaire d’une erreur de transfert.

Des tests de validation avant le premier envoi réel

Klaviyo propose des aperçus avec données de profil ou d’événement selon le message. Ces tests visuels ne couvrent pas tout le comportement à l’envoi réel. Vérifie aussi les parcours d’essai et leurs liens.

La matrice décrit les résultats à convenir avec l’équipe. Utilise des contacts d’essai contrôlés plutôt que d’activer des communications à toute la base pour vérifier une règle.

Cas de testRésultat attenduPreuve
Nouvelle inscription valideContact reçu avec ses données et entrée dans le parcours convenuEnregistrement d’inscription et activité du flow
Contact désabonnéAucun marketing dont il est excluÉtat et sélection des destinataires
Achat pendant un délaiRappel en attente conforme à la règle de sortie prévueChronologie et décision d’envoi
Personnalisation manquanteUtilisation du contenu alternatif approuvéEmail reçu sans variable incomplète
Personne déjà accompagnée dans l’ancien systèmePas de redémarrage accidentel de séquenceRègle de transition et activité comparée
Lien ou préférence de l’emailBonne destination et changement d’état prévuTest de navigation et état ultérieur

La validation doit identifier la version testée. Si un événement, une condition ou un modèle change ensuite, examine les tests devenus invalides et répète-les avant d’activer cette partie.

Planifier la bascule et un retour éventuel

Le plan de lancement doit nommer les exécutants, les personnes qui vérifient et les signaux imposant un arrêt. Prévois une fenêtre laissant du temps pour contrôler inscriptions, achats et envois. Évite une campagne importante en parallèle si l’équipe ne peut pas gérer les incidents.

Une coexistence temporaire peut aider à contrôler les données, mais exige des responsabilités d’envoi claires. Définis ce qui est suspendu à la source, ce qui démarre à destination et le rapprochement des changements entre export et bascule finale. Inclus les nouveaux désabonnements de cet intervalle.

Prépare avant le démarrage un retour possible : configuration restaurable, données à rapprocher et personne habilitée à décider. Arrêter le nouveau système ne signifie pas réactiver automatiquement tous les anciens messages. Examine l’activité déjà réalisée pour éviter les répétitions.

Intègre la délivrabilité à cette phase : domaines, authentification, audience initiale et suivi. Migration technique et évaluation des envois sont liées, mais un import réussi ne prouve pas encore le bon fonctionnement du canal.

Comment savoir que la migration est terminée ?

Rapproche source et destination par catégories pertinentes, pas seulement par nombre total de profils. Explique doublons, exclusions, erreurs et données non transférables. Conserve le rapport de rapprochement avec l’inventaire initial et les décisions approuvées.

Ne retire pas l’ancien accès avant d’avoir sauvegardé les rapports et configurations convenus. Examine les intégrations et identifiants temporaires lorsqu’ils deviennent inutiles. La fermeture doit laisser un responsable clair de l’exploitation courante et des incidents ouverts.

  • Contacts, exclusions et champs vérifiés par comptages et échantillons.
  • Nouvelles inscriptions et événements boutique contrôlés à destination.
  • Parcours activés avec tests de validation approuvés.
  • Un responsable d’envoi unique pour chaque message transféré.
  • Modèles, liens, préférences et personnalisation vérifiés.
  • Anciens rapports conservés avec leurs définitions.
  • Documentation, accès et suivi transmis à l’équipe.

Après la bascule, compare les indicateurs avec des périodes et définitions compatibles. Un nouveau modèle d’attribution peut modifier les rapports sans créer de ventes supplémentaires. La migration est terminée quand l’équipe peut utiliser, vérifier et expliquer le nouveau système, pas quand le fichier finit de se charger.

Sources et lectures utiles

Traduction avec l’aide de l’IA

Article de Dídac Anton. Les versions anglaise, allemande, néerlandaise et française ont été traduites de l’espagnol avec l’aide de l’IA.

Lire l’original en espagnol