Customer.io pour SaaS : setup, événements, segmentation

TL;DR. À notre avis, Customer.io est un outil lifecycle bien adapté aux SaaS B2B qui veulent des flows comportementaux basés sur les events produit. Son atout principal : l'envoi d'events depuis votre produit (JavaScript, mobile, serveur) et la segmentation sur ces données. Sa limite, toujours selon notre lecture : plus long à configurer qu'un Klaviyo pré-câblé pour l'e-commerce, avec un minimum de compétences techniques pour tirer parti de la couche events. Ce guide couvre le setup initial, l'architecture des events, la segmentation comportementale, et la comparaison honnête avec Klaviyo.

Customer.io est une plateforme de messagerie pilotée par les données. Elle décrit son approche autour de personnes, d'events et de segments qui déclenchent des automations. À notre avis, si votre activation dépend de ce que votre utilisateur fait dans votre interface, elle est probablement mieux adaptée à votre cas qu'un outil e-commerce comme Klaviyo.

Customer.io vs Klaviyo : positionnement honnête

La première question que posent les équipes SaaS : "Est-ce qu'on peut faire ça avec Klaviyo ou il faut vraiment Customer.io ?"

Notre lecture, hors ligne tarifaire (les écarts sont des appréciations, à vérifier sur votre cas) :

Verdict, à notre avis : si votre lifecycle dépend des actions dans un produit digital, Customer.io est un bon candidat. Si vous vendez en e-commerce sur Shopify, Klaviyo est le choix naturel. Une équipe SaaS qui utilise Klaviyo parce qu'elle a démarré avec une boutique accepte une dette technique qui peut coûter en flexibilité. Pour la séquence d'onboarding elle-même, voir Onboarding email SaaS : 7 emails sur 14 jours.

Setup initial : les 5 étapes

Étape 1 : créer un workspace et configurer le sender domain

Après création du compte, première action : configurer votre sender domain (domaine d'envoi dédié). Customer.io envoie depuis votre domaine. Configurer SPF, DKIM, et DMARC avant d'envoyer un seul email.

Dans Customer.io, aller dans Settings > Workspace Settings > Email, puis Add sending domain, et suivre les instructions DNS (une configuration automatique via Entri existe aussi). À moins d'utiliser un serveur SMTP personnalisé, Customer.io demande d'authentifier le domaine avant d'utiliser l'expéditeur ; la vérification peut prendre jusqu'à 72 heures (documentation). À notre avis, ne passez pas à l'étape 2 avant que le domaine soit vérifié. Pour la configuration SPF, DKIM et DMARC, consultez notre guide de configuration DNS complet.

Étape 2 : installer le tracking snippet ou connecter via API

Customer.io propose deux modes de tracking :

Mode JavaScript (snippet) : le client JavaScript actuel de Customer.io s'installe en copiant le snippet de l'intégration dans le head du site, et expose cioanalytics.identify(), cioanalytics.track() et cioanalytics.page() (documentation). Le snippet « classique » (méthodes _cio.identify(), _cio.track(), _cio.page()) est décrit par Customer.io comme plus ancien, sans certaines fonctions récentes : Customer.io recommande le client actuel à toute personne qui démarre (documentation du snippet classique). Les exemples ci-dessous utilisent le client actuel.

Mode serveur (HTTP API et bibliothèques) : envoyer les events et les profils depuis votre backend. Customer.io propose des intégrations serveur (Node.js, Python, Go, HTTP API) et des SDK mobiles.

Mode hybride, à notre avis : snippet côté frontend pour les events de navigation et d'interaction, intégration serveur pour les events business (paiement, activation feature, invitation collaborateur).

Étape 3 : identifier les utilisateurs

La méthode identify est fondamentale chez Customer.io : elle donne à une personne une identité unique, et Customer.io associe automatiquement l'activité anonyme antérieure à la personne identifiée.

cioanalytics.identify("user_12345", {   // identifiant unique de la personne
  email: "user@company.com",            // nécessaire pour envoyer des emails
  created_at: 1716422400,               // timestamp
  plan: "trial",
  company_size: "11-50",
  role: "head_of_marketing"
});

Toute personne a besoin d'au moins un identifiant (un id ou un email) (documentation sur les attributs). Customer.io recommande d'appeler identify sur chaque page où l'utilisateur est connecté, pour qu'il soit toujours identifié quelle que soit sa page d'arrivée. À la déconnexion, la méthode reset anonymise de nouveau la session.

Étape 4 : tracker les events

Un event Customer.io est une action de l'utilisateur dans le produit que vous voulez pouvoir utiliser pour déclencher des automations ou construire des segments.

cioanalytics.track("integration_connected", {
  integration_name: "Shopify",
  first_time: true
});

Nommage des events : à notre avis, un format snake_case cohérent. Exemples : trial_started, first_flow_activated, team_member_invited, subscription_upgraded, feature_x_used. Un format incohérent dans la nomenclature des events crée des problèmes de segmentation à long terme.

Propriétés des events : chaque event peut porter des propriétés. Ces propriétés sont utilisables dans les conditions de segmentation et les conditions de workflow. Exemple : cioanalytics.track("plan_viewed", { plan_name: "team", billing_period: "annual" }).

Étape 5 : vérifier que les events arrivent

Dans Customer.io, ouvrir le profil d'une personne de test et consulter son activité. Vous devez voir chaque event envoyé avec ses propriétés. Si les events n'apparaissent pas, déboguer avec l'onglet Network du navigateur (chercher les requêtes vers les domaines customer.io). L'intégration JavaScript propose aussi un bouton Test connection à l'installation.

Architecture des events : ce qu'il faut tracker (et ce qu'il ne faut pas)

La question "quels events tracker" est plus importante que le comment. Un mauvais tracking plan crée des segments inexploitables et des automations qui se déclenchent au mauvais moment.

Framework pour choisir les events à tracker :

1. Les events d'activation : les actions qui correspondent à votre activation milestone (voir article onboarding SaaS). Ce sont les premiers events à tracker.

2. Les events de lifecycle : events qui marquent un changement d'étape dans la relation avec le produit. Trial started, trial converted, subscription upgraded, subscription cancelled, account reactivated.

3. Les events de comportement produit : actions qui signalent l'engagement dans une feature clé. Feature used, report generated, integration connected, collaborator invited. Ne tracker que les features pour lesquelles vous avez une action lifecycle associée.

4. Les events à ne pas tracker : chaque page vue, chaque clic sur un bouton de navigation, chaque scroll. Ces events créent du bruit sans valeur pour la segmentation. À notre avis, Customer.io est un outil lifecycle plutôt qu'un outil d'analytics produit, et le tracking très granulaire a sa place ailleurs.

Segmentation comportementale : les segments à construire en priorité

Customer.io distingue trois types de segments (documentation) :

Segments manuels : les personnes y entrent et en sortent quand vous les ajoutez ou les retirez (import CSV, étape d'automation ou API). À utiliser pour des cas ponctuels (liste d'invités à un webinar, utilisateurs bêta testeurs).

Segments data-driven : les personnes y entrent et en sortent automatiquement selon des conditions sur les données que vous envoyez (attributs, events). C'est, à notre avis, le type principal pour le lifecycle.

Segments snapshot : mêmes conditions qu'un segment data-driven, mais l'appartenance est figée au moment de la création jusqu'à ce que vous l'actualisiez.

Les 6 segments data-driven à créer en priorité (exemples de définitions, à adapter à votre modèle de données) :

Segment 1 : Trials actifs non-activés
- Condition : plan = "trial" AND event "activation_milestone" NOT performed in the last 14 days
- Usage : cibler les trials en risque d'abandon pour les flows de nurturing.

Segment 2 : Trials activés (aha moment atteint)
- Condition : plan = "trial" AND event "activation_milestone" performed at least once
- Usage : séquence de conversion vers payant.

Segment 3 : Clients payants à risque de churn
- Condition : plan != "trial" AND last event performed more than 21 days ago AND subscription end in next 30 days
- Usage : intervention CS proactive.

Segment 4 : Utilisateurs très engagés (candidats expansion)
- Condition : plan = "starter" AND core feature event performed more than 3 times in the last 7 days AND team_size < 3
- Usage : campagne upsell team plan.

Segment 5 : Comptes dormants récupérables
- Condition : plan = "paid" AND last event performed 30 to 90 days ago
- Usage : flow winback SaaS avec incentive (audit gratuit, onboarding call offert).

Segment 6 : Champions (high engagement + long tenure)
- Condition : plan = "paid" AND created_at older than 180 days AND core feature event performed more than 10 times in the last 30 days
- Usage : programme de référence, témoignages, case studies.

Workflows : les 4 automations à construire en premier

Dans sa documentation actuelle, Customer.io parle d'« automations » pour ses workflows. Une automation démarre sur un trigger, notamment : attribut ou segment, event, formulaire, date importante, objet ou webhook. Quand une personne entre dans une automation, elle démarre un « journey » (documentation).

Automation 1 : onboarding trial (déclenché par l'event "trial_started")

La séquence des 7 emails détaillée dans l'article dédié. Dans Customer.io, la configurer comme une automation déclenchée par event, avec des conditions de sortie (event "subscription_upgraded" = sortie immédiate).

Automation 2 : churn prevention (déclenchée si l'utilisateur entre dans le segment 3)

Séquence de 3 emails sur 10 jours : Email 1 (J0) "On a noté que vous n'avez pas utilisé [Marque] depuis 3 semaines. Tout va bien ?", Email 2 (J5) "Un point de 20 minutes pour débloquer votre usage ?", Email 3 (J10) "Votre abonnement se renouvelle dans [X] jours. Voici ce que vous avez accompli avec [Marque]."

Automation 3 : Campaign upsell (ciblant le segment 4)

Email mensuel aux utilisateurs très engagés sur le plan starter : "Vous avez atteint [X] fois votre limite mensuelle ce mois. Voici ce que le plan [supérieur] vous donnerait."

Automation 4 : winback (déclenchée si l'utilisateur entre dans le segment 5)

Séquence de 4 emails sur 21 jours : reminder de valeur, use case frais, incentive (mois offert ou onboarding call), fermeture avec question directe sur la raison de l'inactivité.

Gestion des unsubscribes et conformité

Par défaut, un client globalement désinscrit ne reçoit plus d'emails, de push ni de SMS pour une automation ou un broadcast (FAQ des abonnements).

Distinction importante : désinscrit contre supprimé. Une personne qui se désinscrit n'est pas retirée de l'espace de travail : Customer.io positionne ses attributs pour indiquer la désinscription (page vie privée). Supprimer une personne supprime aussi ses données, et Customer.io précise qu'il n'existe aucun moyen de récupérer les données d'une personne supprimée (documentation). À notre avis, désinscrivez plutôt que supprimer, sauf demande d'effacement.

Transactionnel vs marketing : Customer.io définit les messages transactionnels comme ceux que l'audience attend et accepte implicitement (reçus d'achat, réinitialisation de mot de passe). Par défaut, ils partent aussi aux désinscrits, et vous pouvez désactiver ce comportement dans les réglages du message ou le surcharger par l'API. Utilisez cette classification avec rigueur : à notre avis, un email marketing présenté comme transactionnel expose à un risque de non-conformité (RGPD, ePrivacy) à faire valider par votre conseil juridique.

Pricing : comment Customer.io facture

La grille tarifaire de Customer.io, relue le 3 novembre 2026, repose sur le nombre de profils (personnes et objets) et sur le volume d'emails. Le plan Essentials démarre à 100 $ par mois, facturé mensuellement, avec 5 000 profils et 1 million d'emails par mois. Le plan Premium démarre à 1 000 $ par mois, facturé annuellement, avec des volumes de profils et d'emails sur mesure. Le plan Enterprise est sur devis. La grille affiche aussi 0,009 $ par profil supplémentaire sur Essentials et 0,12 $ par tranche de 1 000 emails supplémentaires. Les prix peuvent changer : vérifiez sur la page avant de décider.

Que vous restiez sur Customer.io ou envisagiez un autre outil, un audit emailing gratuit de 30 minutes, sans engagement, aide à clarifier si votre setup d'events et de segmentation tient la route.

FAQ

Customer.io peut-il gérer des emails transactionnels en plus du marketing ?

Oui. Customer.io propose une API transactionnelle pour les messages adressés à une personne que vous déclenchez vous-même, comme les emails de réinitialisation de mot de passe ou de confirmation (documentation). À notre avis, l'avantage est que l'envoi passe par le même domaine et le même suivi que le marketing.

Peut-on utiliser Customer.io pour de l'email B2C e-commerce ?

À notre avis, techniquement oui, mais Klaviyo propose des intégrations e-commerce natives (Shopify, BigCommerce, Magento) que sa documentation cite, ce qui le rend plus direct pour le DTC. Pour un e-commerce headless avec envoi des events par API, Customer.io peut convenir, avec un investissement technique plus lourd.

Combien de temps pour avoir un setup Customer.io fonctionnel ?

Aucune documentation ne chiffre cette durée. Estimation de notre part, à valider sur votre projet : un setup minimal (tracking snippet + identify + quelques events + 1 automation d'onboarding) se compte en jours, un setup complet (tracking plan, backfill d'events, segments, 4 automations) en semaines. À notre avis, la partie la plus longue est la définition du tracking plan et des segments business plutôt que la technique.

→ Réserver un audit Customer.io ou setup SaaS lifecycle

Pour aller plus loin

• Onboarding email SaaS : 7 emails sur 14 jours
• Subject lines : 50 templates e-commerce
• A/B test Klaviyo : méthode subject, contenu, heure d'envoi
• Deliverability email : le guide complet anti-spam
• Lifecycle marketing : la méthode pour faire de l'email 35 % du CA
• Scorecard lifecycle email : évaluez votre setup sur 50 points

Charlotte Rodrigues, CRM Lead chez Deliver.