Personnalisation et tests A/B avec Croct

Personnaliser et tester avec Croct

Les spécialistes du marketing gèrent les expériences et les expérimentations dans le tableau de bord (app.croct.com). Votre travail en tant qu'agent est de :

1. Planifier : transformer l'objectif de l'utilisateur en une expérience (qui / où / quoi) et, lorsqu'il souhaite une preuve, en une expérimentation (hypothèse, objectif, allocation, variantes).
2. Coder : s'assurer que chaque zone ciblée est un emplacement, que la conversion est suivie comme un événement goalCompleted, et que les données nécessaires à l'audience sont collectées.
3. Écrire l'audience : une condition CQL. Pour la syntaxe au-delà des recettes présentées ici, chargez la compétence croct-cql.
4. Interpréter les résultats : lire les tableaux de bord avec les seuils documentés ; ne jamais déclarer un gagnant que le tableau de bord ne supporte pas.

Ne dites pas à l'utilisateur que des modifications de code sont nécessaires pour lancer, modifier ou terminer une expérimentation. Une fois que l'emplacement et l'objectif existent, tout le reste est de la configuration.

Modèle mental

Concept	Qu'est-ce que c'est	Règles
Expérience	Contenu affiché à une audience dans un ou plusieurs emplacements	Définie par qui (audiences), où (emplacements), quoi (contenu). Plusieurs audiences autorisées ; donnez à chacune son propre contenu avec des groupes de contenu.
Audience	Une condition CQL évaluée par rapport au contexte actuel de l'utilisateur	Peut cibler tous les utilisateurs ou un segment restreint.
Priorité	Rang unique par expérience	Lorsque les audiences se chevauchent sur le même emplacement, l'expérience avec la priorité la plus élevée l'emporte. Pas d'ex æquo.
Expérimentation	Un test A/B/n au sein d'une expérience	Une par expérience à la fois. Hérite de l'audience et des emplacements de l'expérience. 2 à 5 variantes.
ID de l'objectif principal	La conversion que l'expérimentation optimise	Doit correspondre au goalId d'un événement goalCompleted suivi.
Allocation du trafic	% des utilisateurs éligibles qui entrent dans l'expérimentation	Les autres voient le contenu de l'expérience.

Qui voit quoi pour un emplacement donné :

Utilisateur	Voit
Pas dans l'audience d'une expérience	Contenu par défaut de l'emplacement
Dans l'audience, pas alloué à l'expérimentation	Contenu de l'expérience
Dans l'audience, alloué	Contenu de la variante assignée
Correspond à plusieurs expériences sur le même emplacement	Celle avec la priorité la plus élevée

L'assignation est déterministe : l'ID du visiteur est haché avec la clé de l'expérimentation, donc un rechargement ne change jamais la variante. L'exposition est suivie automatiquement. Pour les utilisateurs identifiés, l'ID utilisateur est la clé d'assignation, donc la variante peut les suivre sur plusieurs appareils (les utilisateurs anonymes ne le peuvent pas).

Décider quoi construire

L'utilisateur veut...	Construire
Un contenu différent pour un segment connu	Expérience avec une audience, sans expérimentation
Prouver qu'un changement fonctionne avant de le déployer	Expérience (souvent « tous les utilisateurs ») + expérimentation
Tester du texte, des images, la mise en page ou une section	Expérience de contenu sur un emplacement (une URL, rendu côté serveur si possible)
Tester où mène un lien	Expérience de CTA : l'emplacement contient la destination du lien
Afficher ou masquer un élément (bannière promotionnelle)	Uniquement evaluate/useEvaluation côté code pour une logique fixe qu'un développeur possède ; sinon un emplacement avec un attribut booléen plus une expérience, pour que les spécialistes du marketing contrôlent qui le voit. Voir la règle d'évaluation de la compétence croct-integrate-sdk
Tester une fonctionnalité ou un flux, pas un contenu visible	Expérience de feature flag : un emplacement avec un attribut booléen, branché côté serveur
Tester deux pages véritablement séparées (page reconstruite, autre modèle, page d'atterrissage d'un autre outil)	Expérience de redirection. Préférez les expériences de contenu lorsque seul le contenu diffère
Plusieurs seuils ou segments dans une même campagne (livraison gratuite par état)	Une expérience, plusieurs audiences, groupes de contenu
Une campagne qui démarre, se met en pause ou reprend à une heure définie	Planification (complément), éventuellement dans le fuseau horaire de l'audience

Liste de vérification de la mise en œuvre

Chaque expérience ou expérimentation a besoin de ces éléments dans le code avant d'être configurée :

• Un emplacement pour chaque zone qui change. Si manquant : npx croct@latest add slot <slot-id>@1 et l'afficher avec le SDK (voir les compétences croct-use-cli et croct-integrate-sdk). Sans emplacement, aucune expérience ne peut modifier la zone.
• Un événement goalCompleted pour la conversion (obligatoire pour les expérimentations). L'ID de l'objectif doit correspondre à l'ID de l'objectif principal de l'expérimentation. Si l'objectif est nouveau, déployez-le avant de démarrer l'expérimentation.
• Des événements de conversion plus riches quand c'est pertinent : orderPlaced, leadGenerated, userSignedUp remplissent les widgets de revenus, de prospects et d'inscriptions aux côtés de l'objectif.
• Les données que l'audience lit. Les paramètres UTM, l'emplacement et les données de session sont automatiques ; les recettes basées sur les publications, les intérêts, les commandes, les prospects ou les inscriptions nécessitent le suivi de ces événements (voir la compétence croct-track-events).
• L'identification de l'utilisateur si les variantes doivent rester cohérentes entre les appareils.

Suivre l'objectif

// components/HomeHero.tsx (React ; @croct/plug-next est identique avec 'use client')
import type {ReactElement} from 'react';
import {useContent, useCroct} from '@croct/plug-react';

export function HomeHero(): ReactElement {
  const {content} = useContent('home-hero@1');
  const croct = useCroct();

  function handleClick(): void {
    croct.track('goalCompleted', {
      goalId: 'hero-cta-click',
    });
  }

  return (
    <div>
      <h1>{content.title}</h1>
      <p>{content.subtitle}</p>
      <a href={content.button.link} onClick={handleClick}>{content.button.label}</a>
    </div>
  );
}

// JavaScript simple
import croct from '@croct/plug';

croct.track('goalCompleted', {goalId: 'sign-up'});

L'événement accepte également value et currency optionnels ({goalId: 'signup', currency: 'USD', value: 50}). Dans les piles PHP rendues côté serveur, suivez dans le navigateur avec l'assistant de modèle (@croct ... @endcroct dans Blade, {% apply croct %} ... {% endapply %} dans Twig).

Suivez l'objectif là où la conversion se produit réellement, dans le navigateur. Pour une expérience de redirection, suivez-la sur les deux pages. Lorsque la conversion s'effectue uniquement sur un serveur (webhook de paiement, inscription backend), utilisez le track autonome du SDK JavaScript depuis @croct/plug/api avec une clé API : son exemple de documentation est exactement un événement goalCompleted envoyé depuis un serveur ou un script cloisonné (voir la compétence croct-track-events). Il accepte un userToken optionnel ; la documentation ne dit pas comment un événement envoyé sans celui-ci est attribué à l'expérimentation.

Flux de travail de l'expérience (tableau de bord)

Transmettez ces étapes à l'utilisateur ; vous ne pouvez pas cliquer vous-même.

1. Page des expériences > Nouvelle expérience, nommez-la.
2. Onglet Audience > Nouvelle audience > collez les critères CQL. Plusieurs audiences autorisées.
3. Onglet Emplacement > sélectionnez un ou plusieurs emplacements (combinez des emplacements sur plusieurs pages pour un parcours cohérent).
4. Onglet Contenu > modifiez le contenu par emplacement (et par groupe de contenu lorsque les audiences diffèrent).
5. Onglet Expérimentation facultatif (voir ci-dessous).
6. Vérifiez les modifications en brouillon, puis Publiez (ou planifiez) — ou Aperçu d'abord.

Pendant le développement, une audience comme property welcome of page's query is "true" permet à l'utilisateur d'activer l'expérience avec ?welcome=true. Remplacez-la par une audience réelle pour la production.

Détails sur le statut, la priorité, la planification, les modifications en brouillon et le contenu : references/experiences.md.

Flux de travail de l'expérimentation

1. Écrivez l'hypothèse : le changement, la métrique qu'il améliore et pourquoi.
2. Choisissez l'ID de l'objectif principal (le tableau de bord suggère les ID déjà suivis). Confirmez qu'il se déclenche.
3. Définissez l'allocation du trafic. Utilisez 100 % pour les audiences de niche. Gardez-la stable pendant tout le test.
4. Créez 2 à 5 variantes, dont une généralement de contrôle. Une variante peut copier le contenu de l'emplacement ou hériter du contenu de l'expérience au lieu de le dupliquer.
5. Définissez le contenu de chaque variante (et les groupes de contenu, si nécessaire).
6. Activez la cohérence multi-appareils si les utilisateurs sont identifiés et doivent conserver leur variante.
7. Prévisualisez chaque variante, publiez, puis vérifiez : les sessions par variante correspondent à la répartition, et une conversion de test apparaît sous le bon objectif.

Ne modifiez jamais la répartition du trafic et n'ajoutez ni ne supprimez de variantes en cours de test ; cela pourrait invalider les résultats.

Détails, feature flags et redirections : references/experiments.md et references/flag-and-redirect-experiments.md.

Lire les résultats

Le tableau de bord de l'expérimentation affiche un indicateur en haut de la page. Agissez en conséquence :

Indicateur	Signification	À faire
Suivez votre objectif	Aucun événement d'achèvement d'objectif enregistré	Corrigez le suivi ; rien d'autre n'a de sens
Expérimentation en cours	Pas encore stable	Attendez. La stabilité nécessite chaque variante ≥ 1 000 visiteurs, chaque variante ≥ 25 conversions et ≥ 1 semaine de fonctionnement
Gagnant recommandé	Stable, et une variante a PBB > 95 % et une perte potentielle < 0,1 %	Appliquez le contenu gagnant à l'expérience et arrêtez l'expérimentation
Aucun gagnant clair	Stable, les variantes trop similaires	Terminez sans gagnant ou testez une nouvelle hypothèse

Avant de lire une métrique, vérifiez les sessions par variante par rapport à la répartition configurée. Un déséquilibre persistant signifie que l'assignation ou la journalisation abandonne une classe d'utilisateurs.

La probabilité d'être le meilleur (PBB) et la perte potentielle proviennent d'une inférence bayésienne avec une distribution Beta par variante et une simulation de Monte Carlo, calculées en temps réel sans échantillonnage. Explications, formules et chaque widget du tableau de bord : references/analytics.md.

Recettes

Guides condensés (ABM, lecteurs de blog, clients, livraison gratuite, formulaires HubSpot, centres d'intérêt, prospects, emplacement, campagnes marketing, intention organique, termes de recherche), chacun avec son audience CQL, son suivi prérequis et ses emplacements suggérés : references/playbooks.md.

À faire / À ne pas faire

• À faire implémenter et vérifier l'événement d'objectif avant de publier une expérimentation. Sans cela, l'expérimentation collecte des expositions mais aucune conversion.
• À faire allouer 100 % pour les audiences de niche afin que le test puisse atteindre une validité statistique.
• À faire préférer une URL avec un contenu piloté par emplacement plutôt que des redirections ; les redirections ajoutent un chargement de page et faussent les résultats.
• À faire maintenir les redirections temporaires (302/307) et se prémunir contre les boucles.
• À faire supprimer les emplacements de feature flags obsolètes du code après la fin d'un test.
• À ne pas faire déclarer un gagnant alors que le tableau de bord indique « Expérimentation en cours », ou à partir de simples comptages (commandes totales, inscriptions totales).
• À ne pas faire modifier l'allocation ou la liste des variantes en cours de test.
• À ne pas faire s'attendre à une cohérence multi-appareils pour les utilisateurs anonymes ; cela nécessite un utilisateur identifié.
• À ne pas faire rediriger vers un domaine différent : le visiteur est reconnu par domaine, donc la conversion n'est jamais attribuée. Pour les sous-domaines, partagez d'abord la session.
• À ne pas faire pré-rendre entièrement ou mettre en cache une page qui affiche un emplacement d'expérimentation ; une variante mise en cache serait servie à tout le monde.

Documentation en direct

• Index : https://docs.croct.com/llms.txt
• N'importe quelle page au format markdown : ajoutez .md, par exemple https://docs.croct.com/explanation/experiment.md
• Recherche : https://docs.croct.com/api/search.md?term=<terms>