Test A/B d'un moyen de paiement
Lancez un test A/B pour un nouveau moyen de paiement dans le Dashboard.
Les tests A/B vous permettent de mesurer l’impact de la proposition de nouveaux moyens de paiement auprès d’un pourcentage d’acheteurs avant de les proposer à l’ensemble de vos clients. Vous pouvez effectuer des tests A/B sans rédiger une seule ligne de code.
Utilisez le test A/B pour :
- Tester les moyens de paiement différés comme Klarna, Affirm et Afterpay auprès d’un sous-ensemble de clients avant de les proposer à tous vos clients.
- Mesurez l’impact des règles de ciblage, comme la fixation d’un prix d’achat minimum pour certains moyens de paiement.
- Proposez progressivement un nouveau moyen de paiement à un pourcentage croissant de clients.
Vous devez utiliser le composant Payment Element Web ou Checkout avec des moyens de paiement dynamiques pour effectuer un test A/B. Vous pouvez consultez la liste des moyens de paiement pouvant faire l’objet d’un test A/B dans la section Moyens de paiement pris en charge.
Commencer votre test A/B
- Dans le Dashboard Stripe, ouvrez les paramètres des moyens de paiement puis cliquez sur Créer un test.
- Le Dashboard Stripe est le seul moyen de démarrer, d’arrêter et de gérer un test (il n’existe pas d’option d’API).
- Si vous disposez de plusieurs configurations de moyens de paiement, sélectionnez la configuration sur laquelle vous souhaitez réaliser un test avant de cliquer sur Créer un test. Vous ne pouvez réaliser qu’un seul test par configuration à la fois.
- Sélectionnez les moyens de paiement que vous souhaitez inclure dans le test.
- (Facultatif) Ajoutez des règles de moyens de paiement, telles que le montant de la transaction ou la devise de présentation, en tant que filtres supplémentaires pour contrôler si un moyen de paiement est admissible. Vous pouvez également créer des règles personnalisées à l’aide de la fonctionnalité indépendante.
- Nommez votre test et choisissez le pourcentage de trafic à inclure dans votre groupe de traitement.
- Répartition du trafic : Nous recommandons un taux de 50 % pour concilier le besoin d’obtenir des résultats rapides (les pourcentages faibles mettent plus de temps à produire des résultats statistiquement significatifs) et la gestion du risque lié aux mauvaises performances des tests. Vous pouvez opter pour un pourcentage plus faible ou plus élevé en fonction de votre tolérance au risque et de vos objectifs de test. Avec une répartition égale entre le traitement et le contrôle, une taille d’échantillon de 80 000 sessions offre une puissance suffisante pour détecter une variation du taux de conversion de 100 points de base avec un seuil de pertinence de 5 %.
- Tests aléatoires : Stripe présente de manière aléatoire les sessions de paiement des clients en fonction d’un identifiant unique, qui comprend l’agent utilisateur, l’adresse IP et la date. Résultat : le client se voit proposer le même ensemble cohérent d’options de moyens de paiement au cours d’une journée donnée, qu’il soit dans le groupe de traitement ou dans le groupe de contrôle. Pour éviter les cas de double comptage, par exemple en raison de l’actualisations de pages, nous regroupons quotidiennement les sessions pour chaque utilisateur individuel.
- Vérifiez, puis commencez votre test.
Note
Lorsque vous commencez un test, vous pouvez modifier le pourcentage d’attribution du trafic au groupe de traitement, mais vous ne pouvez pas activer ou désactiver les moyens de paiement pour vos groupes de contrôle ou de traitement. Pour modifier les paramètres des moyens de paiement après le début d’un test, vous devez d’abord arrêter le test.
Note
Si vous n’êtes pas prêt à débuter votre expérience, enregistrez-la en tant que brouillon et démarrez-la plus tard.
- (Recommandé) Si vous testez les moyens de paiement différé (BNPL), nous vous recommandons d’installer le composant Payment Method Messaging Element. Ce composant d’interface utilisateur intégrable permet à vos clients de consulter les options de paiements disponibles directement depuis vos pages de produit, de panier ou de paiement.
Gérer et mettre fin à un test A/B
- Pour afficher dans vos paramètres de moyens de paiement tous les tests en cours et passés, cliquez sur le menu déroulant () puis sélectionnez Gérer les tests.
- Lorsqu’un test est en cours, vous pouvez effectuer quatre actions :
- Ajuster l’attribution du trafic : Ajustez le pourcentage de trafic alloué à votre groupe de traitement, qui varie de 1 à 99 %.
- Voir le rapport du test.
- Interrompre ou reprendre un test : Si votre test est suspendu, seuls les moyens de paiement de contrôle sont accessibles pour les clients et votre rapport ne consigne aucune donnée de test.
- Mettre fin au test : à la fin du test, vous pouvez soit adopter les paramètres du traitement, soit revenir aux paramètres (de contrôle) précédents. Si votre expérience dure plus de 180 jours, nous y mettons fin en votre nom et activons vos paramètres de contrôle.
Note
Si vous disposez d’une intégration à la plateforme Connect et que vous sélectionnez la configuration du traitement, tout nouveau moyen de paiement dans le traitement est activé pour tous les utilisateurs.
Comprendre les résultats de votre test
Après le début de votre test, visualisez sa progression dans Dashboard Stripe.
Les tests A/B considèrent qu’un test est terminé lorsque deux conditions sont remplies :
- Les revenus moyens par session sont statistiquement significatifs. Nous considérons que les résultats sont statistiquement significatifs lorsqu’il y a moins de 5 % de probabilité que le résultat soit dû au hasard. Consultez la section Méthodologie du test.
- Le test a accumulé suffisamment de sessions. Il s’agit d’un nombre dynamique basé sur le pourcentage de traitement par rapport au contrôle que vous avez défini lors de la création du test.
Les résultats possibles du test sont les suivants :
- Revenu moyen par session : Le revenu moyen par session est le revenu total divisé par le nombre total de sessions. Il montre la différence de revenu par session entre votre groupe de traitement et votre groupe de contrôle et présente un résumé des résultats globaux de votre expérience. Le nombre total de sessions comprend à la fois les sessions qui ont abouti à un achat et celles pour lesquelles ça n’a pas été le cas. En raison des variations significatives des taux de conversion et des valeurs moyennes des commandes en fonction du moyen de paiement, nous recommandons d’utiliser le chiffre d’affaires moyen par session comme indicateur pour déterminer la réussite globale du test.
- Revenus pour 100 % des sessions : le montant total des revenus prévus si les moyens de paiement du groupe de traitement étaient proposés à 100 % du trafic dans le groupe de traitement et le groupe de contrôle.
- Recettes brutes : Revenu réel (montant total de l’achat). Il dépend principalement du pourcentage de traitement/contrôle que vous avez choisi.
- Taux de conversion : Le taux de conversion correspond au nombre de sessions incluant un achat divisé par le nombre total de sessions admissibles. Les sessions admissibles sont définies comme suit :
- Un ou plusieurs moyens de paiement du traitement étaient admissibles (par exemple, le client se trouvait dans un pays où le moyen de paiement est accepté)
- L’interface de paiement (Payment Element ou Checkout) a été affichée à l’acheteur
- Valeur moyenne de la commande : La valeur moyenne de la commande est le montant moyen des achats pour des sessions où le client a effectué un achat.
Pertinence statistique
Utilisez les indicateurs des tableaux de synthèse pour comprendre la pertinence statistique. Les indicateurs affichent une différence verte ou jaune lorsque le test a atteint au moins 80 % des sessions estimées nécessaires.
Il existe trois types d’indicateurs :
- Les indicateurs gris signifient que votre test n’a pas accumulé suffisamment de sessions pour déterminer de manière fiable une pertinence statistique.
- Les indicateurs verts montrent une augmentation statistiquement significative entre le groupe de traitement et le groupe de contrôle.
- Les indicateurs jaunes montrent une diminution statistiquement significative entre le groupe de traitement et le groupe de contrôle.
Avant d’atteindre la pertinence statistique
Après avoir atteint la pertinence statistique
Effectuer une analyse complémentaire
Vous pouvez télécharger des données brutes à partir de la page de rapport pour analyser plus en détail les résultats de votre test.
Note
Nous recommandons un regroupement par experiment_ pour éviter le double comptage des sessions, par exemple en cas d’actualisations de page. Cela est cohérent avec la façon dont le rapport de test A/B calcule le revenu moyen par session, le taux de conversion et la valeur moyenne de la commande.
| Dimension | Description |
|---|---|
| occurred_at_day | Date de la session, au format aaaaMMjj. |
| experiment_session_id | ID unique généré par Stripe pour chaque session de test. Une session est basée sur le UserAgent, l’adresse IP et la date. |
| is_treatment | Valeur booléenne indiquant si le résultat a été affecté au groupe de traitement (1) ou de contrôle (0). |
| converted | Valeur booléenne indiquant si la session a été convertie (1) ou non (0). |
| payment_method | Moyen de paiement utilisé pour effectuer l’achat. |
| converted_transaction_count | Nombre de conversions (donc de transactions) de la session utilisateur. Cette valeur est généralement de 1 ou 0. Cependant, plusieurs conversions peuvent se produire au cours d’une même session si un même acheteur effectue plusieurs achats au cours de la même journée. |
| rendered_transaction_count | Nombre d’affichages de la session utilisateur. Ce nombre peut être supérieur à 1 si un client se rend sur la page d’achat plusieurs fois (par exemple, s’il la recharge ou s’il y revient plus tard dans la journée). |
| amount_capturable | Montant total de la transaction. |
| currency | Devise utilisée pour cette transaction (par exemple, USD, GBP, EUR). |
| is_eligible_session | Valeur booléenne indiquant si la session était admissible (1) ou non (0) au test A/B. Si ce champ renvoie la valeur 0 (par exemple quand aucun moyen de paiement du groupe de traitement n’est admissible), alors cette session n’est incluse dans aucun des indicateurs fournis, comme la valeur moyenne des commande ou le taux de conversion. |
| buyer_countries | Le ou les pays associés à la session utilisateur. Dans la plupart des cas, un seul pays est indiqué, mais il peut y en avoir plusieurs si le client voyage ou modifie les paramètres de localisation de son navigateur. |
| control_payment_method_types | Liste des moyens de paiement de contrôle qui pouvaient être affichés dans cette session. |
| treatment_payment_method_types | Liste des moyens de paiement de traitement qui pouvaient être affichés dans cette session. |
| rendered_payment_methods | Liste des moyens de paiement disponibles dans la session utilisateur, y compris ceux masqués par un menu de débordement de type ‘show more‘ (permettant d’afficher des moyens de paiement supplémentaires). |
| visible_payment_methods | Liste des moyens de paiement visibles dans la session utilisateur (non masqués par un menu de débordement de type ‘show more‘). |
| connected_account_id | L’ID de compte connecté associé à la session. |
Méthodologie du test
Les tests A/B mesurent l’effet moyen du traitement (ATE) en comparant les résultats du traitement et du contrôle. Nous considérons qu’une expérience est statistiquement significative lorsqu’il y a moins de 5 % de probabilité que le résultat soit dû au hasard. En termes statistiques, nous utilisons un test Z pour calculer les différences entre le groupe de traitement et le groupe de contrôle au niveau de 5 %, ce qui revient mécaniquement à vérifier si l’intervalle de confiance à 95 % pour la différence comprend 0. Pour déterminer le nombre de sessions nécessaires pour détecter un impact, nous effectuons un calcul de puissance basé sur la répartition des pourcentages entre le groupe de traitement et le groupe de contrôle que vous avez choisie. Ce calcul de puissance indique le nombre de sessions nécessaires pour avoir une puissance de 80 % afin de détecter une différence de 1 % entre le traitement et le contrôle à un niveau de pertinence de 5 %.
Note
Pour vous fournir ce service de test A/B, nous avons besoin d’effectuer des analyses concernant les activités de vos clients à partir de vos données de transaction. Nous utilisons l’adresse IP et les informations de l’agent utilisateur de vos clients pour identifier le moment où un utilisateur qui s’est vu proposer un moyen de paiement sur une page du tunnel de paiement est allé jusqu’au bout du processus. En fonction de la législation qui s’applique à vous et à vos clients, il peut être nécessaire, si vous nous demandez d’entreprendre cette activité en votre nom, que vous preniez des mesures telles que la communication d’informations et le recueil du consentement des clients à cette activité. Consultez votre conseiller juridique pour vous assurer du respect de toutes les obligations qui vous incombent en vertu des lois applicables en matière de protection des données.
Moyens de paiement pris en charge
Options d’intégration
Vous pouvez accéder aux tests A/B si votre intégration utilise le composant Payment Element Web ou Checkout avec des moyens de paiement dynamiques.
Moyens de paiement pris en charge
Test A/B pour Connect Connect
Les tests A/B sont uniquement disponibles pour les plateformes Connect, et non pour les comptes connectés individuels. Lors de la configuration d’un test A/B, les moyens de paiement sélectionnés pour le contrôle et le traitement s’appliquent à tous les comptes connectés admissibles. Pour exclure des comptes connectés spécifiques, vous pouvez spécifier une liste d’identifiants de comptes au cours du processus de création du test.
Les plateformes peuvent permettre aux comptes connectés de personnaliser leurs paramètres de moyens de paiement afin d’activer ou de désactiver des moyens de paiement spécifiques. Si un compte connecté active ou désactive un moyen de paiement qui se trouve dans un groupe de traitement ou de contrôle, la préférence du compte connecté s’applique à la fois aux sessions de traitement et de contrôle. Par exemple, si une plateforme effectue un test avec Klarna activé et qu’un compte connecté a désactivé Klarna, Klarna n’est jamais affiché comme moyen de paiement disponible pour les utilisateurs du compte connecté.