Skip to main content
@dexnotify/web abonne le navigateur par le Web Push standard (VAPID), l’enregistre comme appareil, remonte clics, événements et conversions, et affiche les messages in-app. Il fonctionne sur Chrome, Edge, Firefox et Safari (macOS, et iOS 16.4+ pour un site ajouté à l’écran d’accueil). Sans dépendance.

Avant de commencer

  1. La plateforme Web de l’application configurée dans le dashboard : une paire VAPID (npx web-push generate-vapid-keys), l’expéditeur (mailto: ou https://) et l’origine du site. Voir Notifications push.
  2. Une clé SDK (portée sdk:device), préréglage « Clé SDK ». Elle est faite pour être publique : elle n’ouvre que les routes de l’appareil. Une clé serveur ne doit jamais aller dans une page.
  3. HTTPS : les service workers l’exigent (localhost passe en développement).

Installation

Servez ensuite le service worker depuis la racine du site, sous /dexnotify-sw.js. Deux façons :
Votre site a déjà un service worker ? Ajoutez-y la ligne importScripts(…) et passez son enregistrement : initialize({ serviceWorkerRegistration }).

Initialiser

Sans module, par une balise :
Avec Next.js ou Nuxt, appelez initialize dans un effet côté client : hors du navigateur, il ne fait rien. Aucune méthode ne rejette : les échecs passent par onError.

Demander l’autorisation

Les navigateurs pénalisent une demande non sollicitée, et Safari comme Firefox exigent un geste de l’utilisateur. Placez-la derrière un bouton :
Accordée, le navigateur est abonné et enregistré aussitôt. initialize({ requestPermission: true }) demande dès le chargement, à vos risques.
Sur le web, l’appareil naît de l’abonnement : avant l’autorisation, il n’existe pas encore. Les tags posés avant sont gardés et partent à ce moment-là.

Utilisateurs et tags

Événements et conversions

Les événements alimentent les segments et les déclencheurs in-app ; les conversions sont attribuées au dernier push ou in-app cliqué. Une session commence au chargement, puis après 30 minutes d’onglet caché.

Clics et abonnement

Le clic ouvre le lien web du message (webUrl, sinon deeplink s’il est une adresse https), ou reprend l’onglet du site.

Messages in-app

Les messages in-app publiés s’affichent seuls, selon leurs déclencheurs et leur audience. Ils sont rendus dans un Shadow DOM, que les styles du site n’atteignent pas ; le HTML d’un message tourne dans une iframe isolée, sans accès à la page.
initialize({ inAppMessages: false }) les désactive.

Consentement

Tant que le consentement manque, rien ne quitte le navigateur.