Le payment mix

Il permet d’augmenter la réactivité des équipes en cas de frictions au moment du paiement, même sur des canaux de ventes à faibles volumes !

Payments analytics
FR
Published

August 7, 2024

Note

Le payment mix désigne la “part de marché” que représente chaque moyen de paiement dans les transactions d’un commerçant. On retrouve souvent le payment mix dans les dashboards sous la forme d’un camembert. Cette visualisation ne permet toutefois pas de suivre l’évolution du payment mix dans le temps, qui révèle bien des informations utiles aux commerçants.

La problématique du e-commerçant

Un e-commerçant propose ses produits dans 10 pays via un site web et une application (iOS et Android) où 5 moyens de paiements différents sont acceptés. Ses plateformes sont en constante évolution afin de maximiser leur taux de conversion, mais malgré les tests, cette forte agilité introduit parfois quelques bugs dans le parcours client.

Note

On appelle canal de vente la combinaison d’un pays, d’un device et d’un moyen de paiement. Notre e-commerçant dispose donc de 150 canaux de vente !

Comment détecter des frictions rencontrées par les clients au moment de procéder au paiement de leur commande sur 150 canaux de ventes ?

Notre e-commerçant a besoin d’automatiser cette détection car il est évidemment impensable de tester en permanence le paiement sur tous les canaux de ventes possibles.

The data zone

Voici toutes les caractéristiques des canaux de ventes de notre e-commerçant :

  • Pays : ES, CH, DE, FR, IT, PT, UK, DK, PL, BE

  • Device : desktop (web) et mobile (iOS ou Android)

  • Méthodes de paiement : Apple Pay, Carte bancaire, Klarna, PayPal, Carte cadeau

Toutes les méthodes de paiement sont disponibles sur tous les appareils (device) et dans tous les pays.

Notre client souhaite être en mesure de détecter toute variation importante de ses ventes d’une journée à l’autre, traduisant une modification du comportement de ses consommateurs. Ce changement, s’il est inattendu, peut être le symptôme d’une quelconque difficulté rencontrée par un consommateur au moment de payer une commande sur un des canaux de vente.

Important

L’objectif pour notre client est d’augmenter sa réactivité en cas de frictions anormales sur un de ses canaux de vente afin de maximiser son chiffre d’affaires en permanence.

Jeu de données associé

Pour traiter ce cas, nous allons avoir besoin d’un jeu de données contenant les volumes de ventes journaliers pour tous les canaux de notre client. L’idée étant de détecter une variation importante des volumes de vente d’une journée à une autre.

Les canaux de vente

TODO:

  • ajouter des journées avec volumes de vente importants (opérations marketing)

  • Augmenter la variance quotidienne

#standardSQL
SELECT *, 
-- generate reproductible, random and plausible payments volume data
(
  CAST(SUBSTR(CAST(FARM_FINGERPRINT(CONCAT(country_code, device, payment_method)) AS STRING), -2) AS INT64) -
  CAST(SUBSTR(CAST(FARM_FINGERPRINT(CONCAT(order_date)) AS STRING), -1) AS INT64)
) AS order_volume
FROM 
UNNEST(["ES", "CH", "DE", "FR", "IT", "PT", "UK"]) AS country_code,
UNNEST(["web", "iOS", "Android"]) AS device,
UNNEST(["apple_pay", "credit_card", "klarna", "paypal", "gift_card"]) AS payment_method,
UNNEST(GENERATE_DATE_ARRAY("2024-07-01", "2024-07-31", INTERVAL 1 DAY)) AS order_date
set.seed(123)
df <- expand.grid(country_code   = c("ES", "CH", "DE", "FR", "IT", "PT", "UK"),
                  device         = c("web", "iOS", "Android"),
                  payment_method = c("apple_pay", "credit_card", "klarna", "paypal", "gift_card"),
                  order_date     = seq.Date(as.Date("2024-07-01"), as.Date("2024-07-31"), by = "1 day")) %>% 
  group_by(country_code, device, payment_method) %>% 
  # generate reproductible, random and plausible payments volume data
  mutate(order_volume = sample(21:300, 1) - sample(0:20, n(), replace = TRUE)) %>% 
  ungroup() %>% 
  arrange(country_code, device, payment_method)

Les volumes de ventes journaliers en Juillet sur les 105 canaux de ventes.

ABCDEFGHIJ0123456789
country_code
<fct>
device
<fct>
payment_method
<fct>
order_date
<date>
order_volume
<int>
ESwebapple_pay2024-07-01186
ESwebapple_pay2024-07-02197
ESwebapple_pay2024-07-03190
ESwebapple_pay2024-07-04182
ESwebapple_pay2024-07-05189
ESwebapple_pay2024-07-06195
ESwebapple_pay2024-07-07180
ESwebapple_pay2024-07-08186
ESwebapple_pay2024-07-09195
ESwebapple_pay2024-07-10181
Next
123456
...
326
Previous
1-10 of 3,255 rows

Les volumes de ventes

2 scénarios générant des anomalies

Notre client a probablement déjà eu des volumes anormaux de ventes sur certains canaux. Pour les besoins de notre article, nous allons simuler ces anomalies en imaginant deux scénarios de problèmes techniques aux conséquences différents.

Incapacité de procéder au paiement

Dans ce type de situation, nous simulons des volumes nuls pour les paiements avec :

  • Klarna au UK sur le web le 2024-07-18 ;

  • PayPal en DE sur tout le périmètre mobile (iOS + Android) du 2024-07-08 au 2024-07-09 ;

  • Apple Pay en IT sur iOS du 2024-07-14 au 2024-07-20.

Très faibles chances de succès du paiement

Ici, nous simulons des volumes très faibles pour les paiements avec :

  • Apple Pay en FR sur iOS du 2024-07-14 au 2024-07-20 ;

  • Klarna en DE sur le web le 2024-07-18.

Note

En pratique, on observe un phénomène de report lorsque survient un problème technique avec un moyen de paiement : une partie des clients se rabattent sur une autre option pour finaliser leur commande, ce qui peut générer des anomalies à la hausse cette fois sur d’autres canaux de vente. Dans cet article, nous nous concentrons uniquement sur les canaux de ventes subissant une baisse anormale de leurs volumes.

Tour d’horizon des méthodes statistiques de détection d’anomalies

Nous n’allons pas développer ici un puissant algorithme de machine learning auto-encoder basé sur des réseaux de neurones… dommage, mais il existe des méthodes statistiques fiables et beaucoup plus simple à implémenter pour détecter des anomalies. Alors dans un premier temps, allons à l’essentiel et intéressons-nous à celles-ci :

Une distribution de moyenne μ (mu) et d’écart type σ (sigma)

La loi des grands nombres

Ce que cela signifie pour mon jeu de données

Que dit la règle des 3 sigmas et quand peut-on appliquer ?

Vérifier qu’elle est applicable à mon jeu de données

Implémentation en SQL

Backtesting

Mince, 3 sigma ne m’ont pas permis de détecter une anomalie.

Comment ajuster les seuils d’alerte

Ajustement par des règles métier (au minumum N observations ?) Ajustement par le nombre de sigma (voir probabilités associées)