Aller au contenu principal
10 min de lecture

Widgets d'intention de sortie

Pro Feature

Captez vos visiteurs avant qu'ils ne partent. Les widgets d'intention de sortie sont des popups définis par le client, déclenchés au moment précis où un visiteur signale qu'il s'apprête à quitter la page — avec une analyse intégrée de chaque affichage, clic et fermeture.

Les widgets d'intention de sortie sont disponibles dans les plans Pro, Scale et Enterprise. Mettez à niveau votre plan pour activer cette fonctionnalité.


Aperçu

Un widget est un petit overlay configurable rendu par le script de tracking Zenovay lorsqu'un signal d'intention de sortie est détecté. Vous concevez le contenu et définissez le ciblage, et Zenovay s'occupe de la diffusion, du plafonnement de fréquence et de l'analyse.

Quand les widgets se déclenchent

Le tracker utilise deux signaux de sortie spécifiques à l'appareil :

AppareilSignal
DesktopÉvénement mouseleave lorsque le curseur franchit le bord supérieur du viewport
Mobile / tabletteScroll rapide vers le haut (geste back-to-top) ou retour de la page depuis un onglet en arrière-plan via visibilitychange

Les deux signaux sont anti-rebond et respectent le plafond de fréquence configuré par widget, afin que le même visiteur ne voie pas le même widget deux fois dans une session.

Les widgets affichés par le tracker s'exécutent côté client. En mode cookieless, le tracker ne conserve pas d'identifiant de visiteur entre deux chargements de page, donc la déduplication entre onglets n'est qu'au mieux possible — un visiteur qui ouvre la même page dans deux onglets peut voir le widget dans chacun d'eux.


Configuration

Les widgets sont entièrement gérés depuis le tableau de bord Zenovay — aucune modification de code n'est nécessaire au-delà de l'installation préalable du script de tracking.

  1. Ouvrez votre tableau de bord et sélectionnez le site auquel vous souhaitez ajouter un widget.
  2. Ouvrez l'onglet Widgets.
  3. Cliquez sur New widget.
  4. Parcourez le builder en quatre étapes.

Le builder en 4 étapes

Étape 1 — Contenu

Définissez ce que le widget affiche.

  • Titre — l'accroche (max. 120 caractères)
  • Corps — le texte d'accompagnement (max. 500 caractères, texte brut)
  • CTA principal — libellé du bouton et URL de destination (ou un nom de goal_event si vous préférez enregistrer une complétion d'objectif plutôt qu'une redirection)

Étape 2 — Ciblage

Décidez qui voit le widget.

  • Motif de page — sur quelles URLs le widget s'exécute (voir Sémantique du ciblage)
  • Pays — liste de codes pays ISO 3166-1 alpha-2 (ex. US,DE,FR) ; laisser vide pour tous les pays
  • Appareil — un ou plusieurs parmi desktop, mobile, tablet
  • Plafond de fréquence — nombre maximal d'affichages par visiteur sur N jours (ex. une fois tous les 7 jours)
  • Nombre minimum de visites — ne se déclenche qu'à la N-ième consultation de la page par le visiteur sur ce site (nécessite le mode non-cookieless)

Étape 3 — Design

Stylisez le widget pour qu'il soit aligné avec votre marque.

  • Position, largeur, rayon de bordure (voir Énumérations de design)
  • Couleurs d'arrière-plan, de texte et de bouton (hex)
  • Image avec position au choix (haut, gauche, droite ou arrière-plan plein cadre)
  • Bouton secondaire (optionnel) — soit une action passive dismiss, soit un link secondaire

Étape 4 — Calendrier

  • Statutdraft, active ou paused
  • Date de début / Date de fin (optionnel) pour les campagnes à durée limitée

Cliquez sur Enregistrer : le widget est en ligne en moins d'une minute (le tracker recharge la liste des widgets actifs au prochain affichage de page).


Sémantique du ciblage

Motif de page

Par défaut, le champ motif de page est une correspondance par sous-chaîne sur le pathname du visiteur.

MotifCorrespond à
/blog/blog, /blog/post-1, /de/blog/x, /team-blog/about
/checkout/checkout, /checkout/payment, /api/checkout/v2
*toutes les pages

Pour un ciblage plus précis, utilisez des globs explicites :

MotifCorrespond à
/blog/*/blog/post-1, /blog/category/x (PAS /de/blog/...)
/checkout/*/payment/checkout/abc/payment, /checkout/xyz/payment
/products/[id]/products/123, /products/abc-def

La sous-chaîne est la valeur par défaut car la plupart des clients s'attendent à ce que "/blog" corresponde à toutes les pages de blog quel que soit le préfixe de langue. Utilisez les globs (*) lorsqu'il faut ancrer le début ou la fin du chemin.

Pays

Codes ISO 3166-1 alpha-2 séparés par des virgules :

US,CA,GB,DE,FR

La détection du pays utilise la géolocalisation IP du visiteur au moment du chargement de la page. Les visiteurs européens avec GPC activé ne sont pas enrichis, donc le ciblage par pays se rabat sur "tous les pays" pour ces visiteurs.

Appareil

Choisissez un ou plusieurs des trois groupes :

desktop
mobile
tablet

Le tracker classe les appareils selon le User-Agent et la largeur du viewport, à l'identique du reste du tableau de bord.

Plafond de fréquence

Défini par max_shows_per_n_days. Le tracker stocke un horodatage d'affichage par widget dans l'enregistrement visiteur (côté serveur, jamais en cookies/localStorage). Tant que frequency_cap_n_days n'est pas écoulé depuis le dernier événement shown pour ce couple widget × visiteur, le widget est supprimé.

Nombre minimum de visites

Définir min_visit_count > 1 exige que le tracker se souvienne du nombre de chargements de la page par ce visiteur. Comme le tracker Zenovay tourne en mode cookieless par défaut tant que le consentement n'a pas été donné, cette règle de ciblage retombe silencieusement sur "déclencher à la première visite" pour tout visiteur en mode cookieless.

Si vous dépendez de cette règle, assurez-vous que le tracker est chargé avec data-cookieless="false" (c'est-à-dire après consentement), sinon la règle est inopérante pour la grande majorité du trafic UE.


Énumérations de design

Les champs de design sont des énumérations verrouillées pour la sécurité — l'API n'accepte que les valeurs ci-dessous. Cela protège chaque widget servi par Zenovay contre l'injection CSS.

Position

center
top-banner
bottom-banner
top-right
top-left
bottom-right
bottom-left

top-banner et bottom-banner sont des bandes pleine largeur. Les quatre positions de coin sont des cartes plus petites, fixées.

Largeur

sm    (320px max)
md    (480px max)
lg    (640px max)
xl    (800px max)

Les largeurs sont responsives — elles s'adaptent aux viewports plus petits et ne dépassent jamais l'écran du visiteur.

Rayon de bordure

none
sm
md
lg
full

full arrondit le widget en pilule (utile uniquement avec une position bandeau).

Position de l'image

top
left
right
background

background place l'image en arrière-plan plein cadre avec un voile de contraste derrière le texte.

Action secondaire

dismiss
link

dismiss ferme le widget sans enregistrer de clic. link enregistre un événement secondary_clicked et navigue vers l'URL configurée.


Analyse

Chaque widget enregistre quatre types d'événements :

ÉvénementQuand il se déclenche
shownLe widget est devenu visible dans le viewport
clickedLe visiteur a cliqué sur le CTA principal
secondary_clickedLe visiteur a cliqué sur le bouton secondaire (configuré comme link)
dismissedLe visiteur a fermé le widget sans cliquer

Vue détaillée

Ouvrez n'importe quel widget depuis l'onglet Widgets pour voir :

  • CTRclicked / shown, avec comparaison à la moyenne du site
  • Graphique journalier — barres quotidiennes affichage / clic / fermeture avec sparklines
  • Funnel de conversionshown → clicked → goal completed (lorsque le CTA pointe vers un objectif suivi)
  • Top pages — les URLs où le widget s'est déclenché le plus souvent, avec le CTR par page
  • Répartition par appareil — répartition desktop / mobile / tablette pour les affichages vs clics

Toutes les métriques respectent les mêmes filtres de date et de segment que le reste du tableau de bord.


Confidentialité

Les événements d'analyse des widgets utilisent le même pipeline d'événements cookieless que le reste de Zenovay :

  • L'identifiant visiteur est un hash SHA-256 calculé côté serveur, salé quotidiennement sur (sous-réseau IP + User-Agent + sel du jour). Aucun cookie, aucun localStorage n'est écrit dans le navigateur du visiteur.
  • La déduplication entre onglets (afin que le même visiteur ne voie pas le widget deux fois dans deux onglets) est au mieux possible en mode cookieless — sans stockage persistant, deux onglets sont indissociables de deux visiteurs partageant la même empreinte IP/UA.
  • Les visiteurs avec Global Privacy Control (Sec-GPC: 1) ne sont pas enrichis — les champs pays et B2B sont supprimés côté serveur, mais le widget se déclenchera quand même si le motif de page, l'appareil et le plafond de fréquence sont respectés.
  • Aucun contenu de widget, aucun snapshot DOM et aucune saisie visiteur n'est collecté. Seuls les quatre types d'événements ci-dessus.

Si vous avez besoin d'un ciblage plus strict (par ex. n'afficher qu'aux utilisateurs connectés), conditionnez le widget à un événement personnalisé envoyé depuis votre propre code applicatif plutôt que de vous appuyer sur la persistance entre onglets.


Limites par plan

PlanWidgets par site
Free0 (verrouillé)
Pro3
Scale10
EnterpriseIllimité

Les limites sont appliquées côté API au moment de la création et remontées sous forme d'erreur dans le tableau de bord en cas de dépassement. Pour augmenter votre limite, mettez à niveau votre plan.


Accès API

Gérez les widgets de manière programmatique :

# Lister les widgets d'un site
GET /api/popup-widgets/:websiteId
Authorization: Bearer YOUR_API_KEY

# Récupérer un widget
GET /api/popup-widgets/:websiteId/:widgetId

# Récupérer l'analyse d'un widget
GET /api/popup-widgets/:websiteId/:widgetId/stats

# Créer
POST /api/popup-widgets/:websiteId

# Mettre à jour
PATCH /api/popup-widgets/:websiteId/:widgetId

# Supprimer
DELETE /api/popup-widgets/:websiteId/:widgetId

L'endpoint public utilisé par le tracker (GET /api/popup-widgets/active/:trackingCode) est appelé automatiquement par le script de tracking et ne nécessite pas d'authentification.


Bonnes pratiques

  1. Mettez en avant la valeur, pas la panique. "Économisez 20 % sur votre première commande" est nettement plus performant que "Attendez ! Ne partez pas !".
  2. Plafonner à au moins une fois par visiteur par semaine. Un widget à chaque visite devient une cible privilégiée des bloqueurs de publicité.
  3. Tester séparément sur mobile. Les signaux mobiles (scroll vers le haut + retour de visibilité) ne se déclenchent pas comme le mouseleave desktop. Un widget qui convertit sur desktop peut être invisible sur mobile.
  4. Associez le CTA à un objectif. En faisant pointer le CTA principal vers une URL suivie ou un goal_event, vous voyez le funnel complet shown → clicked → converted plutôt que les seuls clics.
  5. Mettez en pause avant d'itérer. Ne supprimez pas un widget que vous testez en A/B — mettez-le en pause pour que les analyses historiques restent attachées.

Étapes suivantes

  • Conversion Funnels - Suivez les parcours de conversion multi-étapes que le widget peut alimenter
  • Goals - Définissez les événements que le CTA de votre widget doit compléter
  • Incidents de conversion - Soyez alerté lorsque les conversions générées par les widgets chutent
Cette page vous a-t-elle été utile ?