L’aide serveur affecte avant le rendu, sans clignotement. L’API reçoit les événements de vos serveurs. Les déploiements suivent les garde-fous et reviennent seuls en arrière.
// proxy.ts : affectation avant le rendu const { setCookie, assignments } = assignRequest({ cookieHeader, url, userAgent, config, // GET /api/v1/config, gardé en mémoire consent, // choix du visiteur }); assignedVariants(assignments); // { "date-livraison": "b" }
Aucune dépendance à un framework : la même fonction sert dans un proxy Next.js, un serveur Node ou en périphérie de réseau.
Les difficultés les plus courantes quand l’expérimentation passe des mains du marketing à celles des équipes techniques.
Chaque chiffre ci-dessous est celui que le produit applique.
GET /api/v1/config, cache de 60 secondes.En savoir plus Un moteur vérifiableMéthodes publiées, testées contre leurs valeurs de référence. Le détail de chaque calcul est documenté.O’Brien-Fleming, mSPRT, Khi-deux, Holm et Rétrécissement bayésien.En savoir plus Le script envoie expositions et conversions depuis le navigateur. L’API reçoit ce que seul le serveur connaît : commandes confirmées, montants, mesures. Réponse 202 avec le décompte des événements acceptés et refusés.
Horodatage jusqu’à 5 minutes dans le futur et 7 jours dans le passé. Une clé secrète présentée à l’API publique est refusée.
POST /api/v1/events x-probant-key: "pk_…" { "events": [ { "type": "conversion", "visitorId": "…", "metric": "commande", "value": 89.9 } ] }
Au palier 50 %, la valeur du taux de retour passait de 7,8 % sur l’originale à 14,5 % chez les visiteurs exposés. Dès que toute la fourchette a dépassé la limite de +25 %, le déploiement est revenu à l’originale : le 10 nov. à 05:12, sans intervention.
La part exposée ne fait que monter : un visiteur exposé à un palier l’est encore aux suivants. Personne ne revient à l’originale après avoir vu la nouvelle version, sauf retour arrière.
Boutique de démonstration Maison Lune, fictive · déploiement rejoué par le moteur
Le cycle d’une fonctionnalité testée puis déployée, sans changer de système en route.
Chaque test occupe une tranche de sa couche. Probant refuse une tranche qui en chevauche une autre.
L’aide serveur lit la configuration gardée en mémoire et renvoie la variante de chaque test, ou la raison de l’exclusion : holdout, tranche, adresse ou appareil.
Le script mesure dans le navigateur ; l’API reçoit les commandes confirmées par vos serveurs.
Verdict, fourchette, gain corrigé et contrôles, calculés sur les agrégats par variante.
La part exposée passe dans la configuration ; les garde-fous sont relus à chaque contrôle, avec retour arrière automatique.
Une fois la variante servie à tous, le code de l’originale peut partir : un flag oublié est un chemin de code que plus personne ne teste.
Il ne masque jamais la page : chaque modification s’applique dès que son élément existe, puis à chaque redessin, avant l’affichage suivant. Pour un affichage sans aucun clignotement, l’affectation se fait côté serveur et le rendu reçoit directement la bonne variante.
Oui. Les deux lisent le même cookie (probant_id) et le même hachage : MurmurHash3 sur 10 000 seaux, avec un sel par espace, par couche et par test. Rien n’est stocké côté serveur pour retrouver la variante d’un visiteur.
Oui, par l’API des événements : 500 événements et 256 Ko au plus par envoi, horodatés jusqu’à 7 jours dans le passé. Chaque événement est validé seul : un événement fautif n’empêche pas les autres.
La configuration se garde en mémoire (60 secondes de cache). Dans l’exemple de la documentation, l’aide serveur garde la configuration précédente si Probant ne répond pas, pour que le site n’attende jamais.
Pas encore. L’aide serveur ne dépend d’aucun framework : en attendant le paquet, ses fichiers se copient dans votre projet, comme l’indique la documentation.
Créez votre espace, ou explorez d’abord la démo avec les données d’une boutique fictive.