Personnalisation côté serveur

Personyze s’installe généralement sous forme d’extrait JavaScript : il se charge dans le navigateur du visiteur, décide quoi afficher et l’affiche dans la page. C’est le bon choix pour la plupart des sites.

Mais le même moteur de décision répond via HTTP : votre propre serveur peut donc demander « que doit voir ce visiteur ? » et afficher lui-même la réponse. Rien ne se charge dans le navigateur, et la page arrive déjà personnalisée.

Est-ce pour vous ?

Utilisez la personnalisation côté serveur quand :

Vous générez les pages sur le serveur et ne voulez pas du bref affichage du contenu par défaut avant que la personnalisation s’applique. Une variante générée côté serveur est simplement la page — il n’y a rien à remplacer ni à masquer.
Vous voulez tester en A/B quelque chose d’invisible. Un autre algorithme de classement, un autre prix, une autre réponse d’API. Il n’y a aucun élément de la page à modifier : un outil visuel n’a donc rien sur quoi travailler.
Il n’y a pas de navigateur. Une application native, une borne, un décodeur, une chaîne d’envoi d’e-mails, un outil de support. Tout ce qui peut faire une requête HTTPS peut être personnalisé.
L’extrait est bloqué. Les bloqueurs de publicité, les politiques de sécurité du contenu strictes et les proxys d’entreprise arrêtent tous les scripts tiers. Un appel côté serveur, c’est votre serveur qui parle au nôtre.

Restez sur l’extrait navigateur quand vous personnalisez des éléments visibles d’un site web ordinaire et que vous voulez créer des campagnes dans l’éditeur visuel sans faire appel à un développeur. Vous pouvez aussi faire les deux : les appels côté serveur et les sessions navigateur partagent un même profil visiteur et une même affectation A/B, tant que les deux identifient la personne de la même façon.

Fonctionnement

Un seul endpoint HTTPS fait tout. Vous indiquez à Personyze ce que le visiteur vient de faire, et il vous indique ce qui doit se passer ensuite :

Votre serveur appelle Personyze quand il s’apprête à afficher quelque chose — une page, une liste de produits, une réponse d’API.
Personyze répond avec des ID d’actions : les campagnes qui correspondent à ce visiteur en ce moment, et ce qu’il doit voir.
Votre code décide de ce que signifie chaque ID. L’action 88 peut vouloir dire « afficher la bannière de livraison gratuite » ou « utiliser l’algorithme de classement B ». Vous associez les ID à des comportements dans votre propre code, ou vous lisez le contenu prêt à l’emploi dans la réponse.
Vous indiquez à Personyze ce que vous avez fait. C’est ce qui rend les rapports et les résultats A/B réels.

Tout ce que vous configurez déjà dans le panneau continue de s’appliquer : audiences, règles de ciblage, planification, répartitions A/B et rapports.

Lancer un test A/B

Configurez le test dans le panneau exactement comme pour un test sur site — une campagne de test A/B, une action par variante, et vos critères de victoire. Pour un test purement côté serveur, les actions n’ont besoin d’aucun contenu : l’ID suffit à indiquer à votre code quelle branche suivre.

Ensuite, dans votre code : appelez Personyze au point de décision, choisissez la branche selon l’ID d’action renvoyé, et signalez le résultat.

C’est Personyze qui affecte les visiteurs aux branches — pas vous. Il conserve l’affectation et maintient chaque visiteur dans la même branche d’une visite et d’un appareil à l’autre, tant que vous l’identifiez de façon cohérente. Si votre code répartit aussi le trafic, les deux systèmes ne sont plus d’accord sur qui est dans quelle branche, et les résultats perdent tout sens.

Deux points que l’on oublie, à vérifier avant le lancement :

Signalez que vous avez affiché la variante. Une action jamais signalée semble ne jamais avoir été exécutée. Sa branche ne perd pas le test — elle semble n’avoir reçu aucun trafic, et le test ne peut jamais aboutir.
Signalez le résultat sous la forme que mesure votre critère de victoire. Un test évalué sur les achats n’est pas influencé par des clics signalés. Faites correspondre le signal au critère choisi, sinon la branche semble n’avoir rien produit.

Les résultats apparaissent dans le panneau exactement comme pour les tests sur site — significativité, amélioration par rapport au groupe témoin, et gagnant — et peuvent aussi être lus par programmation si vous les voulez dans votre propre tableau de bord.

Bibliothèques officielles

Vous pouvez appeler l’endpoint directement avec n’importe quel client HTTP. Des bibliothèques sont disponibles pour les environnements courants et gèrent les détails faciles à rater — conserver la session, expirer rapidement, et ne jamais laisser un appel de personnalisation faire tomber la page qu’il personnalise :

Node.js / TypeScript — npm install @personyze/node, avec des helpers pour Express et Next.js.
PHP — composer require personyze/personyze.
Python — pip install personyze, avec des helpers pour Django et Flask.

Chacune est une fine surcouche autour du même endpoint : rien ne vous est caché, et vous pouvez repasser au HTTP brut dès que nécessaire.

Performances et sécurité

Un appel de personnalisation se trouve sur le chemin du rendu d’une page : les bibliothèques utilisent donc par défaut un délai d’expiration d’une seconde et un mode fail open (échec ouvert) : si Personyze est lent ou injoignable, votre code reçoit une réponse vide et affiche sa version par défaut. Votre page n’attend jamais après nous, et ne casse jamais à cause de nous.

L’appel est authentifié avec une clé API, en HTTPS. Gardez-la sur votre serveur — elle donne un accès complet à votre compte, contrairement à l’extrait du traqueur, qui est public par conception.

Ce qu’il vous faut pour commencer

Une clé API. Dans le panneau : Paramètres → Intégrations → API complète.
Un ID visiteur stable. Votre propre ID utilisateur, un ID d’appareil, un hachage — tout ce que vous pouvez reproduire pour la même personne la fois suivante. C’est ce qui permet à une personne de rester dans une même branche A/B d’une visite à l’autre.
Un endroit où conserver une session. Personyze renvoie une valeur de session avec chaque réponse ; renvoyez-la lors de l’appel suivant. L’endroit où vous conservez déjà l’état de session est le bon.

Étapes suivantes

La documentation technique complète — formats de requête et de réponse, vocabulaire des commandes, recette A/B et exemple complet — se trouve dans le guide développeur : Personnalisation côté serveur et tests A/B.

Si vous hésitez sur l’intérêt du côté serveur pour votre cas, contactez le support et décrivez ce que vous voulez personnaliser ; la réponse est souvent courte.