Article Deliver · 2026-05-23 · Charlotte Rodrigues

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

TL;DR. Customer.io est l'outil lifecycle de référence pour les SaaS B2B qui veulent des flows comportementaux basés sur les events produit. Son atout principal : la gestion native des events produit et la segmentation comportementale en temps réel. Sa limite principale : plus long à configurer qu'un Klaviyo pré-câblé pour l'e-commerce, et il nécessite un minimum de compétences techniques pour tirer le meilleur 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 n'est pas un ESP de plus. C'est une plateforme lifecycle pensée pour les produits dont la valeur se construit dans l'usage, pas dans la commande. Si votre activation dépend de ce que votre utilisateur fait dans votre interface, Customer.io est probablement mieux adapté à 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 ?"

Réponse directe :

Critère	Customer.io	Klaviyo
Designed for	SaaS, apps, produits digitaux	E-commerce, DTC
Events produit natifs	Oui (tracking code simple)	Possible via API, moins fluide
Segmentation comportementale	Temps réel sur tous les events	Temps réel sur les events Shopify, plus laborieux pour events custom
Conditions de workflow complexes	Très granulaires (if/else sur n'importe quel event)	Solide mais moins flexible sur les events custom
Templates email	Basiques nativement, imports custom possibles	Bon drag-and-drop, templates DTC natifs
Intégration Shopify / WooCommerce	Possible mais pas optimisée	Natif, la meilleure du marché
Pricing	Volume-based (messages envoyés)	Contact-based
Courbe d'apprentissage	Modérée à élevée	Modérée
Support FR	Anglais uniquement	Anglais en priorité

Verdict : si vous faites du SaaS ou si votre lifecycle dépend des actions dans un produit digital, Customer.io est le bon outil. Si vous faites de l'e-commerce sur Shopify, Klaviyo n'a pas de concurrent sérieux.

Les SaaS qui utilisent Klaviyo pour leur lifecycle ne le font pas parce que c'est le meilleur outil pour leur cas : ils le font parce qu'ils ont commencé avec Klaviyo pour leur boutique et qu'ils n'ont pas eu le temps de migrer. Ce n'est pas une erreur fatale, mais c'est une dette technique qui coûte en flexibilité.

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 > Email Settings > Sending Domains. Suivre les instructions DNS. Ne pas passer à l'étape 2 avant que le domaine soit vérifié.

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

Customer.io propose deux modes de tracking :

Mode JavaScript (snippet) : coller le snippet Customer.io dans le <head> de votre application. Il expose les méthodes _cio.identify(), _cio.track(), et _cio.page(). C'est le mode recommandé pour les SaaS avec une application web.

Mode API HTTP : envoyer les events et les profils directement depuis votre backend via l'API REST Customer.io. Mode recommandé si vous voulez tracker des events serveur-side (paiements, actions backend) ou si votre application est mobile-first.

Mode hybride (recommandé) : snippet côté frontend pour les events de navigation et d'interaction, API côté backend pour les events business (paiement, activation feature, invitation collaborateur).

Étape 3 : identifier les utilisateurs

La méthode _cio.identify() est le coeur du tracking. Elle lie les events anonymes à un profil connu.

_cio.identify({
  id: "user_12345",           // identifiant unique obligatoire
  email: "user@company.com",  // obligatoire pour les emails
  created_at: 1716422400,     // timestamp Unix, obligatoire
  plan: "trial",
  company_size: "11-50",
  role: "head_of_marketing"
});

Règle d'or : appeler _cio.identify() dès que l'utilisateur se connecte, à chaque session. Customer.io ne demande pas de re-identifier si les attributs n'ont pas changé, mais identifier à chaque connexion garantit que les attributs sont à jour.

É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.

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

Nommage des events : utiliser 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 : _cio.track("email_sent", { template_id: "welcome", recipient_count: 150 }).

Étape 5 : vérifier que les events arrivent

Dans Customer.io, aller dans Customers > chercher un utilisateur de test > onglet Activity. Vous devez voir chaque event envoyé avec son timestamp et ses propriétés. Si les events n'apparaissent pas dans les 5 minutes, déboguer avec l'onglet Network du navigateur (chercher les requêtes vers track.customer.io).

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 :

Les events d'activation : les actions qui correspondent à votre activation milestone (voir article onboarding SaaS). Ce sont les premiers events à tracker.
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.
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.
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. Customer.io n'est pas un outil d'analytics produit : c'est un outil lifecycle. Le tracking granulaire appartient à Mixpanel ou Amplitude.

Segmentation comportementale : les segments à construire en priorité

Customer.io permet deux types de segments :

Segments manuels : listes statiques d'utilisateurs. À utiliser pour des cas ponctuels (liste d'invités à un webinar, utilisateurs bêta testeurs).

Segments dynamiques : basés sur des conditions sur les attributs et les events. Se mettent à jour en temps réel. C'est ce que vous utiliserez pour 95 % de vos besoins lifecycle.

Les 6 segments dynamiques à créer en priorité :

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

Customer.io appelle ses automations "Campaigns" (basées sur des segments) ou "Journeys" (basées sur des déclencheurs d'events ou de temps).

Automation 1 : Journey 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 un Journey avec des conditions de sortie (event "subscription_upgraded" = sortie immédiate).

Automation 2 : Journey churn prevention (déclenché 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 : Journey winback (déclenché 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é

Customer.io gère les unsubscribes automatiquement. Un contact qui clique sur "Se désinscrire" dans un email Customer.io est automatiquement supprimé (unsubscribed) et ne reçoit plus aucun email.

Distinction importante : unsubscribed vs deleted. Un contact unsubscribed est toujours dans votre base Customer.io, ses events sont conservés, il peut être réactivé s'il re-consent. Un contact deleted est supprimé définitivement avec tous ses events (et ne peut pas être récupéré). Ne pas supprimer les contacts : unsubscriber uniquement.

Transactionnel vs marketing : Customer.io permet de marquer certains emails comme "transactionnels" (confirmation de commande, reset de mot de passe). Ces emails partent même aux contacts unsubscribed. Utiliser cette classification avec rigueur : un email marketing déguisé en transactionnel est une violation RGPD.

Pricing : comment Customer.io facture

Customer.io facture par messages envoyés (email, SMS, push), pas par contact. Avantage : vous ne payez pas pour une base de 50 000 contacts si vous n'envoyez que 10 000 emails par mois. Inconvénient : si votre volume d'envoi est élevé, le coût monte plus vite qu'un modèle contact-based.

Ordre de grandeur 2026 : plan Essentials à partir de 100 $/mois pour 5 000 contacts tracked et envois illimités. Plan Premium (actions avancées, objets custom, webhooks) à partir de 500 $/mois. Volumes au-dessus de 200 000 contacts tracked : tarification sur devis.

FAQ

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

Oui. Customer.io a une API transactionnelle qui envoie des emails 1:1 (reset de mot de passe, confirmation d'achat, notifications de compte) en dehors des automations. Avantage : tout le sending passe par le même domaine et le même monitoring. Inconvénient : pour des volumes transactionnels très élevés (> 1 M emails/mois), des outils spécialisés comme Postmark ou Amazon SES sont plus économiques.

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

Techniquement oui. Pratiquement, l'absence d'intégration native Shopify/WooCommerce et des templates e-commerce pré-construits rend Customer.io moins adapté que Klaviyo pour le DTC. Customer.io peut fonctionner pour un e-commerce headless avec une API custom bien configurée, mais c'est un investissement technique plus lourd.

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

Un setup minimal (tracking snippet + identify + 5 events + 1 journey onboarding) prend 2 à 3 jours pour un développeur front. Un setup complet (tracking plan défini, events backfill, segments dynamiques, 4 automations) prend 2 à 3 semaines. La partie la plus longue n'est pas la technique : c'est la définition du tracking plan et des segments business.

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

Charlotte Rodrigues, CRM Lead chez Deliver by Make Sense.

Charlotte Rodrigues · CRM Lead, Deliver by Make Sense. Une question sur cet article ? charlotte@agence-deliver.com

Besoin d'appliquer ça à votre stack ?

30 minutes avec Charlotte. On audit votre setup CRM en direct, on chiffre l'opportunité, vous repartez avec un plan d'attaque.

Réserver 30 minutes →