FAQ

À propos de l'explication de l'identifiant utilisateur unique

1. Lors de l'initialisation, une chaîne unique doit être renseignée pour générer un UID unique. Cet UID est le code d'identification pour les notifications push et n'est pas lié à l'appareil.
   
   
2. Lorsqu'un utilisateur utilise le même user_str, il sera reconnu comme le même utilisateur. S'abonner sur différents navigateurs ou appareils remplacera l'information d'abonnement par la plus récente pour l'envoi de messages. Par exemple, l'utilisateur A s'abonne successivement avec le même user_str sur les navigateurs a1, a2 et a3. En théorie, seul le dernier navigateur abonné, a3, pourra recevoir les messages, évitant ainsi que le même utilisateur reçoive plusieurs messages et limitant l'envoi excessif de notifications. Le backend conserve toujours uniquement la dernière information d'abonnement pour le même UID.
   
   
3. Les abonnements aux messages peuvent être annulés, et le SDK fournit une interface d'annulation d'abonnement. Cette interface annule uniquement la relation de liaison entre l'UID et l'information d'abonnement, sans modifier les autorisations de notification du navigateur.
   
   
4. En théorie, le user_str doit correspondre de manière unique à chaque utilisateur réel. Dans certaines situations spécifiques, les utilisateurs peuvent être en mode visiteur. Les développeurs doivent explicitement générer un user_str unique selon leur situation réelle. Le SDK ne réalise pas de traitement par défaut automatique afin d'éviter des erreurs si les développeurs ne gèrent pas correctement la relation entre le user_str et les utilisateurs réels, ce qui pourrait entraîner des écarts dans les statistiques.

   Lorsque les utilisateurs sont en mode visiteur, les développeurs peuvent se référer à la fonction suivante pour générer un user_str unique. Cette fonction utilise le navigateur de l'utilisateur comme code d'identification unique. Notez que cette méthode fera qu'un même utilisateur générera un nouveau user_str en changeant de navigateur, d'appareil ou en vidant le cache.
   Exemple de fonction :

   function randomUid() { const keyStr = 'mtWebPushRandomUid'; let uid = window.localStorage.getItem(keyStr); if (!uid) { uid = new Date().getTime().toString(36) + Math.floor(Math.random() * 10000000).toString(36); window.localStorage.setItem(keyStr, uid); } return uid; } var user_str = randomUid();

                 
                 function randomUid() {
    const keyStr = 'mtWebPushRandomUid';
    let uid = window.localStorage.getItem(keyStr);
    if (!uid) {
        uid = new Date().getTime().toString(36) + Math.floor(Math.random() * 10000000).toString(36);
        window.localStorage.setItem(keyStr, uid);
    }
    return uid;
   }
   var user_str = randomUid();
   
               

   Afficher ce bloc de code dans la fenêtre flottante

Quelles plateformes supportent WebPush ?

Prise en charge des navigateurs par système d'exploitation

Remarque 1 : Microsoft Edge (mis à jour en 2019), Opera, Samsung Internet, Yandex et UC Browser sont tous des navigateurs basés sur Chromium et sont identifiés comme Chrome dans Engagelab.
Remarque 2 : Internet Explorer ne reçoit plus de mises à jour de fonctionnalités. Microsoft a transféré le développement du navigateur vers la plateforme Edge.
Remarque 3 : Le mode navigation privée, le mode invité et le mode incognito ne supportent pas les notifications push web.

Prise en charge selon la version du navigateur

Questions relatives aux notifications push web sur le navigateur Safari

Les notifications push web sur Safari sont supportées sur macOS (V11.1+) ainsi que sur iOS/iPadOS 16.4+.

Quelles fonctionnalités sont supportées par les notifications push Safari ?

Comment les utilisateurs sur iOS et iPadOS reçoivent-ils les notifications push web Safari ?

1. Comment les développeurs peuvent-ils permettre aux utilisateurs de recevoir des notifications web sur iOS/iPadOS 16.4+ ?

Sur iOS/iPadOS 16.4+, les notifications push web sont disponibles. Cependant, le site web doit avoir le fichier manifest approprié et être configuré avec les bons attributs pour que les notifications fonctionnent correctement. Ajoutez le code correspondant dans le html de la page d'intégration :

Inclure le fichier manifest :

              
              {
    "$schema": "https://json.schemastore.org/web-manifest-combined.json",
    "display": "standalone",
    "start_url": "/webpush/index.html",
    "name": "Exemple Engagelab WebPush",
    "short_name": "Engagelab",
    "icons": [
        {
            "src": "/icon-large-cb438cac.png",
            "type": "image/png",
            "sizes": "1024x1024"
        }
    ]
}

            

2. Pour que les utilisateurs s'abonnent et reçoivent les notifications push web Safari mobile, ils doivent ajouter l'application Web à l'écran d'accueil

Pour envoyer des notifications push web Safari mobile (applicable à iOS et iPadOS 16.4+), les destinataires doivent effectuer les actions suivantes :

• Visiter votre site web avec le navigateur Safari sur un appareil Apple mobile avec la version 16.4+.
• Appuyer sur le bouton de partage du navigateur Safari de l'appareil mobile.
• Appuyer sur l'option “Ajouter à l'écran d'accueil”.
• Enregistrer l'application sur l'appareil.
• Ouvrir l'application depuis l'écran d'accueil.
• S'abonner aux notifications (ils doivent appuyer sur le bouton d'abonnement avant que l'invite d'autorisation native n'apparaisse). Ces étapes sont nécessaires pour recevoir les notifications push web mobiles. Comme cette expérience d'interaction est relativement complexe pour les utilisateurs finaux, vous devez les aider à comprendre les avantages de s'abonner aux notifications.

3. Ajoutez une bannière sur votre site web pour guider les utilisateurs vers "Ajouter à l'écran d'accueil"

Une bannière peut être ajoutée à votre site pour informer vos utilisateurs de la valeur des notifications push web mobiles et leur expliquer comment s'abonner.
Nous recommandons d'ajouter une bannière sur votre site web qui s'affiche sur les appareils Apple mobiles, guidant les visiteurs à appuyer sur le bouton de partage puis sur l'option "Ajouter à l'écran d'accueil".
Un projet open-source populaire peut également vous aider à fournir ces instructions aux utilisateurs :
Exemple de bannière en bas de page lien Github : https://github.com/rajatsehgal/add-to-home-screen

Si le navigateur est fermé, l'utilisateur peut-il recevoir la notification ?

• En passant par le canal EngageLab, vous devez ouvrir le site web pour recevoir les notifications.
• En passant par le canal système, vous pouvez recevoir des notifications même si le navigateur est fermé. Les comportements diffèrent selon les plateformes. Pour plus d'informations, consultez le tableau ci-dessous :

Sur Windows, si toutes les fenêtres sont fermées mais que le processus du navigateur tourne toujours en arrière-plan, il peut recevoir les notifications système. Si le processus du navigateur est fermé, il ne recevra pas les notifications système.

Sur Mac OS X, même si toutes les fenêtres sont fermées, la plupart des processus navigateurs restent actifs en arrière-plan, ils peuvent donc recevoir les notifications système. Si le processus du navigateur est forcé à quitter, ils ne recevront plus de notifications système. Safari peut recevoir des notifications sans être lancé, car elles sont envoyées directement au système d'exploitation. Les utilisateurs doivent d'abord enregistrer les notifications Safari, puis ils pourront les recevoir même si Safari est complètement arrêté.

Questions relatives à l'invite d'autorisation de notification

Quand l'invite s'affichera-t-elle à nouveau après que l'utilisateur ait refusé l'invite push web ?

Si un utilisateur clique sur "Bloquer" (Chrome), "Ne pas autoriser" (Safari) ou "Ne jamais autoriser" (Firefox) lors de l'invite d'autorisation native, le site web ne pourra plus afficher d'invite, sauf si l'utilisateur effectue une procédure en plusieurs étapes dans les paramètres du navigateur pour s'abonner ou réinitialiser les autorisations. C'est pourquoi il est recommandé d'utiliser les invites EngageLab (accéder aux paramètres).

Invite d'autorisation native

Un abonnement push web nécessite une invite d'autorisation native du navigateur, qui n'est pas personnalisable. Elle utilise la langue définie dans les paramètres du navigateur de l'utilisateur. Seuls les sites HTTPS peuvent afficher les invites natives du navigateur.

Chrome : Vous avez 3 chances pour que l'utilisateur s'abonne. Après que l'utilisateur ait cliqué 3 fois sur "X" lors de l'invite native, il ne recevra plus d'invites pendant une semaine. Pour plus d'informations sur cette fonctionnalité Chrome, voir ici.
Firefox : À partir de Firefox 70, après avoir cliqué sur le bouton "fermer", l'utilisateur doit cliquer sur la petite icône de notification dans le navigateur pour recevoir à nouveau une invite. De plus, à partir de Firefox 72+, l'invite native du navigateur est bloquée, pour plus de détails voir ici.
Safari : Similaire à Firefox, une interface plus discrète a été ajoutée pour les utilisateurs qui refusent généralement les autorisations, et des invites automatiques sont proposées pour les sites ayant été refusés, Safari 12.1+

Invite douce EngageLab

Comme la pop-up native n'offre qu'une seule chance, si elle est refusée par l'utilisateur, le site web ne pourra plus obtenir d'autorisation, c'est pourquoi EngageLab recommande d'utiliser la méthode 'invite douce' pour obtenir l'autorisation de l'utilisateur :
Si un utilisateur clique sur "Autoriser" ou "Annuler" sur l'invite EngageLab (accéder au guide de paramétrage) mais n'est toujours pas abonné via l'invite native, l'invite EngageLab pourra s'afficher à nouveau.

• Si un utilisateur clique sur "Autoriser" sur l'invite EngageLab, la pop-up native s'affichera, mais s'il clique sur "Annuler" sur l'invite native, l'invite EngageLab s'affichera à nouveau lors de la prochaine visite pour demander l'autorisation de notification.
  
• Si un utilisateur clique sur "Autoriser" sur l'invite EngageLab, la pop-up native s'affichera, et s'il clique sur "Autoriser" sur l'invite native, l'utilisateur a autorisé les notifications web ; s'il clique sur "Refuser" sur l'invite native, le site ne pourra plus obtenir d'autorisation.
  
• Si un utilisateur clique sur "Annuler" sur l'invite EngageLab, on peut en déduire qu'il ne souhaite pas recevoir de notifications du site à ce moment-là. Si on lui demande à nouveau, il est probable qu'il refuse, donc la pop-up native ne sera pas affichée, et lors de la prochaine visite, l'invite EngageLab pourra à nouveau demander l'autorisation.

Méthodes de dépannage en cas de non-réception des notifications

1. Vérifiez l'autorisation dans la barre de notification de la page web.

2. Vérifiez si l'autorisation de notification de l'application navigateur est activée. Paramètres de notification Windows :

• Désactivez l'assistance de concentration. Pour plus d'informations, voir documentation officielle Microsoft .
  
• Paramètres > Notifications et actions > activez l'obtention de notifications des applications et autres expéditeurs. Assurez-vous que votre site et votre navigateur sont également activés. Pour plus d'informations, voir documentation officielle Microsoft .
  

Paramètres de notification macOS :

• Dans Préférences Système > Notifications > Chrome ou le navigateur sélectionné, assurez-vous que l'autorisation de notifications est activée.
• Dans Préférences Système > Notifications > Concentration > Ne pas déranger et sommeil, assurez-vous que ce mode n'est pas activé ou que vous êtes dans la période autorisée pour les notifications.
• macOS dispose également d'un réglage temporaire "ne pas déranger" dans le menu en haut à droite > faites défiler vers le haut.

3. Le canal du fabricant du navigateur est instable, il est donc préférable de privilégier le canal EngageLab.

              
              {
    "from":"web_push",
    "to":{
        "registration_id":[
            "xxx"
        ]
    },
    "body":{
        "platform":"web",
        "notification":{
            "web":{
                "title":"web_push",
                "alert":"Hi,MTPush !",
                "url":"http://www.google.com",
                "extras":{
                    "web-key1":"web-value1"
                }
            }
        },
        "options":{
            "time_to_live":30,
            "third_party_channel":{
                "w3push":{
                    "distribution":"mtpush"
                }
            }
        },
        "request_id":"12345678",
        "custom_args":"informations business"
    }
}

            

Comment résoudre le problème de Safari qui n'affiche pas les notifications ?

Étape 1 : Vérifiez les autorisations du navigateur Safari, assurez-vous que l'interrupteur d'autorisation est activé, la situation normale est illustrée ci-dessous :

Étape 2 : Cliquez sur Vérifier l'état du service push et l'autorisation de notification du navigateur, la situation normale est illustrée ci-dessous :

Étape 3 : Cliquez sur Safari - préférences > sites web > notifications pour vérifier si le site du centre de notifications est autorisé, la situation normale est illustrée ci-dessous.

Remarque :

1. Cliquez sur arrêter le push, le message push Aurora ne sera plus reçu, et la page doit être rafraîchie.
   
2. Un nom de domaine est configuré avec plusieurs pages html. Ne supprimez pas les autorisations du site du centre de notifications. Après suppression, les pages html ne recevront plus de notifications. (Vous devez retrouver la page principale et obtenir à nouveau l'autorisation de notification du site)
   

Si le même utilisateur utilise plusieurs navigateurs, comment un message sera-t-il affiché sur l'appareil de l'utilisateur s'il lui est envoyé ?

Si la stratégie de distribution choisie privilégie les canaux système, alors le message ne sera envoyé que via le canal du fabricant du navigateur utilisé le plus récemment par l'utilisateur. Si l'option est d'envoyer exclusivement via le canal Jiguang, alors plusieurs messages seront envoyés.

Si un utilisateur vide le cache et les cookies du navigateur, peut-il toujours recevoir les WebPush de ce site ?

Lorsque l'utilisateur est en ligne, le canal Jiguang peut toujours recevoir les notifications push.
Pour les canaux des fabricants de navigateurs, lorsque les utilisateurs effacent les cookies et le cache de leur navigateur, ils se désabonnent des notifications. En effet, les données d'abonnement sont stockées dans l'IndexedDB du navigateur. La suppression de ces données fait que le navigateur "oublie" l'abonné. Cependant, effacer ces données ne retire pas les autorisations déjà accordées pour recevoir des notifications dans ce navigateur. À ce moment, une initialisation du SDK est nécessaire pour que les utilisateurs soient automatiquement réabonnés lors de leur retour sur le site.
Mais si les utilisateurs modifient les autorisations de notification du navigateur en "Demander" ou "Bloquer", ils ne seront pas automatiquement réabonnés.
Si les utilisateurs suppriment les notifications dans les paramètres du navigateur, ils ne seront pas non plus automatiquement réabonnés.

Comment effacer les notifications dans différents navigateurs :

• Chrome : chrome://settings/content/notifications
  

• Firefox : about:preferences#privacy > Permissions > Notifications

• Safari : Préférences > Sites web > Notifications > Supprimer !

Lors du réabonnement, les utilisateurs recevront un nouvel identifiant d'enregistrement. Vous pouvez utiliser window.MTpushInterface.getRegistrationID() pour obtenir le rid.

Si plusieurs messages sont envoyés au même utilisateur en même temps, tous les messages seront-ils affichés ?

Les mécanismes d'affichage des messages varient selon les canaux push :

• Canal EngageLab : Il n'y a pas de mécanisme d'écrasement, donc si plusieurs messages sont envoyés au même utilisateur en même temps, tous les messages seront affichés simultanément. Le centre de notifications conservera plusieurs messages ; à l'exception du plus récent, les autres seront regroupés.
• Safari : Il n'y a pas de mécanisme d'écrasement, donc si plusieurs messages sont envoyés au même utilisateur en même temps, tous les messages seront affichés simultanément. Le centre de notifications conservera plusieurs messages ; à l'exception du plus récent, les autres seront regroupés.
• Chrome : Il existe un mécanisme d'écrasement, donc si plusieurs messages sont envoyés au même utilisateur en même temps, chaque notification sera remplacée par la plus récente, et seul le dernier message envoyé sera affiché.
• Edge : Il existe un mécanisme d'écrasement, donc si plusieurs messages sont envoyés au même utilisateur en même temps, chaque notification sera remplacée par la plus récente, et seul le dernier message envoyé sera affiché.
• Firefox : Il existe un mécanisme d'écrasement, donc si plusieurs messages sont envoyés au même utilisateur en même temps, chaque notification sera remplacée par la plus récente, et seul le dernier message envoyé sera affiché.

Le WebPush EngageLab supporte-t-il le changement de nom de domaine ?

Les navigateurs ont conçu le Web Push de façon à lier les abonnés à une source spécifique (nom de domaine/URL du site web).
Pour des raisons de sécurité et en raison de la politique de même origine du navigateur, il n'est pas possible de transférer les abonnés d'une source à une autre. Ce n'est pas une limitation d'EngageLab ; tout fournisseur prétendant pouvoir transférer des abonnés d'un site à un autre, assurez-vous qu'ils s'abonnent à votre site.
Si vous changez de site, la meilleure solution est de créer une nouvelle application WebPush pour le nouveau site et d'inviter vos utilisateurs à s'abonner à ce site via cette nouvelle application. Vous ne pouvez pas importer les abonnés d'une source à une autre.
Vous pouvez continuer à envoyer des notifications push aux abonnés de l'ancien site (ancienne application WebPush), mais vos utilisateurs devront se réabonner sur le nouveau site pour recevoir les notifications du nouveau domaine. Les étapes recommandées pour la migration sont les suivantes :

• Créez une nouvelle application WebPush pour le nouveau domaine du site.
  
• Continuez à envoyer des notifications depuis l'ancienne application WebPush en utilisant l'ancien domaine. Dans l'URL de lancement des notifications, utilisez le nouveau domaine.
  
• Après 2 semaines à 2 mois (selon le nombre de notifications envoyées par jour et le nombre d'abonnés sur le nouveau site), vous pouvez arrêter d'utiliser l'ancienne application WebPush et n'utiliser que la nouvelle.
  
• Si vous envoyez le même message depuis les deux applications WebPush, les abonnés des deux recevront des messages en double. C'est pourquoi nous recommandons de respecter ces délais.
  
• Vous pouvez envoyer quelques messages indiquant "Nous avons déménagé, cliquez ici pour visiter notre nouveau site et vous réabonner afin de rester informé". Cela aidera à rappeler aux utilisateurs que s'ils ne reviennent pas se réabonner, ils risquent de ne plus recevoir de notifications. Il est conseillé d'envoyer ce type de notification au début du déménagement et avec le dernier message envoyé depuis l'application.
  
• Malheureusement, chaque site et audience est différent. Prévoyez de perdre certains abonnés à court terme.
  Lors de l'exécution de ces étapes de migration, veillez à l'expérience utilisateur pour éviter toute gêne.

Le WebPush EngageLab supporte-t-il les notifications push PWA ?

1. Qu'est-ce qu'un PWA ?

Le push PWA désigne l'utilisation de la technologie Web Push dans les Progressive Web Apps (PWA) pour envoyer des notifications aux utilisateurs. Un PWA est une application construite avec des technologies web offrant des fonctionnalités et une expérience utilisateur similaires à celles des applications natives, tout en étant accessible via un navigateur sans installation.
Le push PWA est mis en œuvre grâce à la technologie Web Push fournie par les navigateurs. Cette technologie permet aux applications web d'envoyer des notifications comme les applications natives, même si l'application n'est pas active ou complètement fermée.
Contrairement aux applications traditionnelles, les PWA n'ont pas besoin d'être téléchargées et installées depuis les app stores ; elles sont accessibles directement via une URL dans le navigateur. De plus, les notifications push PWA fournissent des alertes en temps réel, améliorant l'expérience et l'engagement utilisateur.
En résumé, le push PWA est une méthode utilisant la technologie Web Push pour envoyer des notifications aux utilisateurs de progressive web apps, augmentant l'engagement et offrant une expérience proche des applications natives.

2. Le WebPush EngageLab supporte-t-il les notifications push PWA ?

Le service WebPush EngageLab prend en charge les notifications push PWA. Vous devez intégrer la fonctionnalité Web Push dans votre PWA en utilisant le Web SDK fourni par EngageLab WebPush, en suivant le code exemple de la documentation pour enregistrer le Service Worker et initialiser la fonction Web Push. Une fois l'intégration terminée, vous pouvez utiliser l'API EngageLab WebPush pour envoyer des notifications push à vos utilisateurs PWA.

Remarque : Deux conditions sont nécessaires pour que le WebSDK supporte le PWA :
1. Le programme fonctionne dans un navigateur prenant en charge les notifications W3C ; 2. Il existe un nom de domaine spécifique et il utilise le protocole HTTPS.

3. Le service worker du PWA sera-t-il en conflit avec celui de WebPush EngageLab ?

Le service worker d'une Progressive Web App (PWA) et celui de WebPush EngageLab peuvent potentiellement entrer en conflit, car tous deux fonctionnent en arrière-plan du navigateur, et pour une même origine, un seul service worker peut généralement être actif à la fois.

Les service workers sont des scripts installés par les sites web dans le navigateur qui peuvent gérer l'expérience hors ligne, le push de messages, la synchronisation en arrière-plan, etc. Comme un service worker contrôle les pages dans son périmètre, plusieurs service workers ne peuvent pas contrôler les mêmes pages simultanément.

Si vous essayez d'enregistrer plusieurs service workers dans la même application/domaine, le dernier enregistré peut remplacer le précédent, ou il peut y avoir des conflits si leurs périmètres se chevauchent. Ces conflits peuvent entraîner des comportements inattendus, comme des messages push ne fonctionnant correctement que via un seul canal.

Pour éviter ces conflits, vous pouvez :

1. Veiller à n'utiliser qu'un seul service worker dans votre application. Si les fonctionnalités WebPush EngageLab et celles de votre PWA peuvent être implémentées dans le même script, il est préférable de les fusionner dans un seul service worker.

2. Si vous devez utiliser deux service workers distincts, assurez-vous que leurs périmètres ne se chevauchent pas. Cela peut se faire en spécifiant des chemins de périmètre différents lors de l'enregistrement.

Avant toute implémentation, il est recommandé de lire attentivement la documentation et de réaliser des tests approfondis en développement et production pour garantir que les service workers coexistent sans interférer.

4. Différences de comportement de la pop-up d'autorisation de notification PWA sur iOS et Android

• Restrictions système iOS (politiques Safari/WebKit) : · Pour des raisons de confidentialité, iOS requiert un geste utilisateur (ex : clic) pour déclencher la pop-up d'autorisation
  · Il s'agit d'une politique WebKit obligatoire pour tous les PWA et applications web
  · Après l'installation initiale du PWA, une interaction utilisateur est également requise pour demander les autorisations

• Caractéristiques système Android : · Chrome/WebView permet de demander automatiquement l'autorisation lors du chargement de la page
  · Suit un modèle d'autorisation plus souple
  · Certaines versions Android prennent même en charge des invites d'autorisation progressives

Pourquoi différents navigateurs ont-ils le même regid ?

R : Si un nom de domaine intégré est configuré pour la même application et que le même userStr est utilisé par le même utilisateur, le même rid sera généré, quel que soit le navigateur utilisé.

              
              // Enregistrez les écouteurs d'événements avant l'initialisation
// Callback lors de la déconnexion du canal JPush
MTpushInterface.mtPush.onDisconnect(function () {
  console.log("onDisconnect");
});

// Réception des messages push (web push, canal fabricant navigateur)
MTpushInterface.onMsgReceive((msgData) => {
  // Structure msgData {data:{xxx}, type:0} 
  // type:0 = canal JPush, type:1 = canal système
  console.log("Message push reçu :", msgData);
});

// Initialisation du push
MTpushInterface.init({
  appkey: "", // Obligatoire, voir les informations de l'application ci-dessus
  user_str: visitorId, // Obligatoire, identifiant utilisateur
  fail(err) {
    console.log("Échec de la création du push en ligne", err);
  },
  success(data) {
    console.log("Push en ligne créé avec succès", data);
  },
  webPushcallback(code, tip) {
    console.log("Code de statut reçu par l'utilisateur et astuce", code, tip);
  },
  swUrl: '', // Par défaut : "/sw.min." + sdkEnv.version + ".js"
  canGetInfo(data) {
    // Données de configuration des notifications disponibles ici
    // RegId disponible après ce callback
    console.log(data); // Informations de configuration
    console.log("RegId reçu", MTpushInterface.getRegistrationID());
  },
  custom: (fuc) => {
    // Lors de l'utilisation d'une configuration de notification personnalisée :
    // 1. Appeler manuellement fuc() pour demander l'autorisation
    // 2. Disponible uniquement via le callback personnalisé
    // 3. fuc() demande les autorisations de notification
  }
});

            

Si vous rencontrez des problèmes non couverts dans ce document lors de l'utilisation, n'hésitez pas à contacter le service client, nous vous fournirons un accompagnement professionnel et des solutions.