Affichez la preuve sociale là où le visiteur prend sa décision, et gardez-la hors des pages où elle le dérange. En pratique, les pages produit et tarifs en reçoivent le plus, les pages d'accueil et de catégorie un peu, et les pages de checkout, de compte et de documentation pas du tout. Le ciblage par URL et par appareil de Provedly permet d'exprimer facilement ces règles ; cet article porte sur les règles à écrire.
Les trois modes de ciblage
Chaque widget et chaque barre Provedly peut être limité de l'une de ces trois façons :
- All pages. Le réglage par défaut. Simple, et généralement mauvais pour les notifications dès qu'un site compte plus de quelques types de pages.
- Only these pages. Une liste d'autorisation. Idéale pour une preuve qui a sa place à un seul endroit, comme les notifications sur les pages produit ou un compteur sur une page de lancement.
- All except these. Une liste d'exclusion. Idéale pour des éléments affichés sur tout le site avec quelques exceptions, comme une barre de campagne qui ne doit pas apparaître sur le checkout ni sur les pages légales.
Le ciblage par appareil s'applique par-dessus, donc une règle peut différer entre ordinateur et mobile. Les détails techniques de l'écriture des motifs de chemin sont dans /docs.
Un guide page par page
| Type de page | Notifications | Compteur en direct | Barre CTA |
|---|---|---|---|
| Accueil | Plafond bas ou aucune | Seulement si le trafic le justifie | Pendant les campagnes |
| Catégorie / collection | Plafond bas | Rarement | Pendant les campagnes |
| Produit / fonctionnalité | Oui, réglages par défaut | Si la page est fréquentée | Pendant les campagnes |
| Tarifs | Oui, légèrement réduites | Si la page est fréquentée | Pendant les campagnes |
| Panier | Une au plus, tôt | Non | Seulement si la barre annonce une vraie échéance |
| Checkout | Non | Non | Non |
| Blog / documentation | Non | Non | Rarement |
| Compte / réglages | Non | Non | Non |
| Mentions légales / confidentialité | Non | Non | Non |
Le principe : la preuve a sa place là où le visiteur pèse un achat, et elle est absente là où il s'est déjà engagé ou fait tout autre chose.
Pourquoi le checkout doit rester calme.
Le checkout est l'endroit où il est le plus tentant d'ajouter de la preuve et où elle sert le moins. Le visiteur a déjà décidé ; ce dont il a besoin, c'est d'un formulaire qui fonctionne. Une notification qui glisse à l'écran pendant que quelqu'un tape son numéro de carte est au mieux une distraction et, sur mobile, elle peut masquer le champ qu'il remplit. Si vous voulez rassurer au checkout, faites-le dans la page elle-même, avec un texte statique. Laissez le widget de côté.
La même logique s'applique aux pages de compte et de réglages. Ces visiteurs sont déjà clients. Leur dire que d'autres achètent, c'est du bruit.
Adapter le type de preuve à la page
Chaque type de preuve répond à une question différente, et le ciblage fonctionne mieux quand la question correspond à la page.
Les notifications répondent à « est-ce que d'autres achètent ceci ? ». Elles ont leur place sur les pages consacrées à quelque chose de précis : un produit, un plan, une fonctionnalité. Les achats vérifiés du produit consulté en sont la forme la plus forte ; le mécanisme est expliqué dans /blog/how-verified-purchase-notifications-work.
Le compteur de visiteurs en direct répond à « y a-t-il quelqu'un d'autre ici en ce moment ? ». C'est un vrai décompte des visiteurs des 90 dernières secondes, qui se masque sous un minimum ; il n'a donc de sens que sur des pages assez fréquentées pour dépasser régulièrement ce minimum. Un compteur ciblé sur une page qui a rarement des visiteurs simultanés restera la plupart du temps invisible, ce qui est honnête mais peu utile. Voir /blog/live-visitor-counters-real-people.
Les barres CTA répondent à « y a-t-il une raison d'agir maintenant ? ». Pendant un lancement avec une vraie échéance, une barre peut tourner sur tout le site avec une liste d'exclusion. Hors campagne, une barre evergreen n'a sa place que là où s'applique son offre par visiteur. Les types de barres sont sur /features#bars.
Le ciblage par appareil
Sur mobile, chaque élément superposé prend plus de place par rapport au contenu. Ajustements raisonnables pour le mobile :
- Abaissez le plafond de notifications par session et élargissez l'intervalle, comme décrit dans /blog/notifications-per-visit-frequency.
- Envisagez de désactiver le compteur en direct sur mobile sauf si la page est très fréquentée ; un compteur plus une barre plus une notification sur un téléphone, c'est trop.
- Gardez les barres courtes. Une barre d'une ligne avec un seul appel à l'action fonctionne sur mobile ; une barre de deux lignes avec trois liens, non.
Comme les règles par appareil se cumulent avec les règles par URL, vous pouvez garder les réglages par défaut sur les pages produit en version ordinateur et une configuration réduite sur ces mêmes pages en version mobile, sans dupliquer les widgets.
Trois exemples de règles
Une boutique Shopify. Notifications : only these pages, sur /products/*, réglages par défaut sur ordinateur et plafond de 3 sur mobile. Compteur en direct : uniquement /products/* et uniquement sur ordinateur. Barre de campagne : all except /checkout*, /account*, /policies/*.
Le site marketing d'un SaaS. Notifications : uniquement /pricing et /features*, plafond de 3. Compteur en direct : /pricing uniquement, sur ordinateur uniquement. Barre evergreen pour une offre de bienvenue : dans l'app, sur la page de facturation uniquement, là où l'offre est appliquée.
Une page de lancement mono-produit. Notifications : uniquement la page de lancement, réglages par défaut. Compteur en direct : la page de lancement, sur les deux types d'appareils, puisque le trafic d'un lancement tend à être concentré. Barre de compte à rebours : la page de lancement, la page d'accueil et la page tarifs, exclue partout ailleurs.
Chacune de ces configurations place la preuve devant le visiteur au moment où elle est pertinente, et nulle part ailleurs.
Vérifier que le ciblage fonctionne
Après avoir enregistré vos règles, ouvrez les pages de la liste d'autorisation et quelques pages qui devraient être exclues. Le script du widget tient en une balise, donc une page qui ne doit rien afficher ne doit rien charger de visible non plus. Suivez ensuite la part de commandes assistées par la preuve dans le dashboard au cours des semaines suivantes. Si resserrer le ciblage ne change pas cette part, les pages retirées n'y contribuaient pas, et vous avez un site plus propre sans rien perdre. Si elle baisse, élargissez prudemment. La méthode de mesure est dans /blog/measuring-proof-assisted-orders.
Questions fréquentes
Faut-il afficher des notifications sur la page d'accueil ?
Un petit nombre peut fonctionner, puisque c'est sur la page d'accueil que beaucoup de visiteurs se font une première impression. Gardez un plafond bas et laissez les pages produit et tarifs porter l'essentiel.
Un même widget peut-il avoir des règles différentes selon l'appareil ?
Oui. Le ciblage par appareil s'applique en plus du ciblage par URL, donc un seul widget peut tourner avec une configuration réduite sur mobile sans qu'il en faille un second.
Et si mes pages produit ne partagent pas de préfixe d'URL ?
Utilisez une liste d'autorisation explicite des pages les plus importantes. Mieux vaut couvrir précisément dix pages importantes que se rabattre sur toutes les pages en espérant que ça marche.
Configurez vos règles de ciblage avec le plan gratuit : /register.