FAQ

À propos de l'identifiant utilisateur unique user_str

1. Lors de l'initialisation, le développeur doit fournir une chaîne unique (user_str) afin de générer le code d'identifiant utilisateur unique (UID) de l'utilisateur. Cet UID est utilisé pour la reconnaissance de l'identité des notifications push et est indépendant de l'appareil de l'utilisateur.
   

2. Si un utilisateur s'abonne sur plusieurs navigateurs ou appareils en utilisant le même user_str, le système l'identifiera comme un seul et même utilisateur. Les nouvelles informations d'abonnement remplaceront les anciennes, garantissant que l'utilisateur reçoit les messages sur l'appareil ou le navigateur utilisé pour l'abonnement le plus récent. Cela évite qu'un même utilisateur reçoive des messages en double sur plusieurs appareils ou navigateurs. Le backend du système ne stocke que les informations d'abonnement les plus récentes pour chaque UID.
   

3. Les utilisateurs peuvent se désabonner à tout moment, et notre SDK fournit l'interface correspondante pour implémenter cette fonctionnalité. L'opération de désabonnement dissociera l'UID des informations d'abonnement, mais ne modifiera pas les paramètres d'autorisation des notifications du navigateur.
   

4. En théorie, user_str doit correspondre à une relation univoque avec le compte utilisateur. Dans certains scénarios, les utilisateurs peuvent être en mode invité. Dans ce cas, les développeurs doivent générer un user_str unique en fonction de la situation réelle. Notre SDK ne gère pas automatiquement cette étape afin d'éviter des données statistiques inexactes causées par une mauvaise gestion de user_str.
   

Pour les utilisateurs en mode invité, les développeurs peuvent utiliser l'exemple de fonction suivant pour générer un user_str basé sur l'unicité du navigateur de l'utilisateur. Cependant, veuillez noter que cette approche peut entraîner la génération d'un nouveau user_str si l'utilisateur change de navigateur, change d'appareil ou vide 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 prennent en charge Web Push ?

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 seront identifiés comme Chrome dans EngageLab.
Remarque 2 : Internet Explorer ne reçoit plus de mises à jour de fonctionnalités. Microsoft a déplacé le développement de son navigateur vers la plateforme Edge.
Remarque 3 : Le mode navigation privée, le mode de navigation privée et le mode invité du navigateur ne prennent pas en charge les notifications Web Push.

Prise en charge selon la version du navigateur

Problèmes de notifications Web Push liés au navigateur Safari

Les notifications Web Push sur Safari sont prises en charge sur macOS (11.1+) et iOS/iPadOS 16.4+.

Quelles fonctionnalités sont prises en charge par les notifications push Safari ?

Comment les utilisateurs sur iOS et iPadOS peuvent-ils recevoir des notifications push web Safari ?

1. Comment les développeurs doivent-ils configurer les paramètres afin que les utilisateurs puissent recevoir des notifications web sur iOS/iPadOS 16.4+ ?

Les notifications Web Push peuvent être utilisées sur iOS/iPadOS 16.4+. Cependant, le site web doit disposer d'un fichier manifest correct et des bonnes propriétés configurées pour que les notifications fonctionnent correctement. Ajoutez le code suivant au HTML de la page d'intégration correspondante : <link rel="manifest" href="manifest.json" />

Incluez le fichier manifest :

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

            

2. Pour que les utilisateurs puissent s'abonner et recevoir des notifications Web Push sur Safari mobile, ils doivent ajouter l'application web à l'écran d'accueil

L'envoi de notifications Web Push sur Safari mobile (pour iOS et iPadOS 16.4+) nécessite que les destinataires des notifications effectuent les actions suivantes :

• Visiter votre site web dans le navigateur Safari sur un appareil mobile Apple exécutant la version 16.4+.
• Appuyer sur le bouton Partager dans Safari sur 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 (avant que l'invite native d'autorisation n'apparaisse, ils doivent appuyer sur le bouton d'abonnement). Ces étapes sont nécessaires pour recevoir des notifications Web Push mobiles.

Comme ce parcours d'interaction est relativement complexe pour les utilisateurs finaux, vous devez les aider à comprendre les avantages de l'abonnement aux notifications.

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

Vous pouvez ajouter une bannière à votre site web pour informer les utilisateurs finaux de la valeur des notifications Web Push mobiles et les guider sur la manière de s'abonner.
Nous recommandons d'ajouter une bannière à votre site web qui s'affiche sur les appareils mobiles Apple et guide les visiteurs pour qu'ils appuient sur le bouton Partager puis sur l'option « Ajouter à l'écran d'accueil ».
Il existe également un projet open source populaire qui peut vous aider à fournir ces instructions aux utilisateurs :
Lien GitHub d'exemple de bannière en bas de page : https://github.com/rajatsehgal/add-to-home-screen

Les utilisateurs peuvent-ils recevoir des notifications si le navigateur est fermé ?

• Lors de l'utilisation du canal EngageLab, les notifications ne peuvent être reçues que lorsque le site web est ouvert.
• Lors de l'utilisation du canal système, les notifications peuvent être reçues même lorsque le navigateur est fermé, bien que le comportement diffère selon les plateformes. Voir le tableau ci-dessous pour plus de détails :

Sous Windows, si toutes les fenêtres sont fermées mais que le navigateur continue de s'exécuter en arrière-plan, les notifications système peuvent toujours être reçues. Si le processus du navigateur a été fermé, les notifications système ne seront pas reçues.
Sous macOS, même si toutes les fenêtres sont fermées, la plupart des processus de navigateur continuent de s'exécuter en arrière-plan, de sorte que les notifications système peuvent toujours être reçues. Si le processus du navigateur est forcé à quitter, les notifications système ne seront pas reçues. Safari n'a pas besoin d'être en cours d'exécution pour recevoir des notifications, car elles sont transmises directement au système d'exploitation. Les utilisateurs doivent d'abord enregistrer les notifications Safari, puis ils pourront toujours recevoir des notifications même si Safari est complètement fermé.

Problèmes liés aux invites d'autorisation de notification

Après qu'un utilisateur a fermé l'invite Web Push, quand l'invite réapparaîtra-t-elle ?

Si un utilisateur clique sur « Block » (Chrome), « Don't Allow » (Safari) ou « Never Allow » (Firefox) dans l'invite native d'autorisation, le site web ne pourra plus l'inviter à nouveau, sauf si l'utilisateur effectue plusieurs étapes dans les paramètres du navigateur pour s'abonner ou réinitialiser les autorisations. C'est pourquoi il est recommandé d'utiliser l'invite EngageLab (Accéder aux paramètres).

Invite native d'autorisation

Les abonnements Web Push nécessitent l'invite native d'autorisation du navigateur, et cette invite native ne peut pas être personnalisée. Elle utilise la langue définie dans les paramètres du navigateur de l'utilisateur. Seuls les sites web HTTPS peuvent afficher l'invite native du navigateur.

Chrome : vous disposez de 3 chances pour amener les utilisateurs à s'abonner. Après que l'utilisateur a cliqué sur le « X » de l'invite native d'autorisation pour la troisième fois, l'utilisateur ne recevra plus cette invite pendant une semaine. Pour plus d'informations sur cette fonctionnalité de Chrome, voir ici.
Firefox : à partir de Firefox 70, après qu'un utilisateur a cliqué sur le bouton de fermeture, il doit cliquer sur la petite icône de notification dans le navigateur pour recevoir à nouveau l'invite. De plus, pour Firefox 72+, l'invite native du navigateur a été bloquée à l'affichage. Pour plus de détails, voir ici.
Safari : similaire à Firefox, Safari a ajouté une interface plus discrète pour les utilisateurs qui refusent habituellement les autorisations et invite automatiquement les sites web dont les autorisations push ont été refusées, Safari 12.1+

Invite douce EngageLab

Étant donné que la popup native ne laisse qu'une seule chance, si l'utilisateur la refuse, le site web ne pourra plus demander d'autorisation à l'utilisateur. Par conséquent, EngageLab recommande d'utiliser une « invite douce » pour obtenir l'autorisation de l'utilisateur :
Si l'utilisateur clique sur « Allow » ou « Cancel » dans l'invite EngageLab (Accéder aux paramètres) et ne s'est toujours pas abonné via la popup de l'invite native, l'invite EngageLab peut réapparaître.

• Après que l'utilisateur a cliqué sur « Allow » dans l'invite EngageLab, la popup native sera déclenchée. Cependant, si l'utilisateur clique sur « Cancel » dans l'invite native à ce moment-là, lors de la prochaine entrée sur le site web, l'invite EngageLab apparaîtra toujours et demandera s'il souhaite autoriser les notifications du site web.
  
• Après que l'utilisateur a cliqué sur « Allow » dans l'invite EngageLab, la popup native sera déclenchée. Si l'utilisateur clique sur « Allow » dans l'invite native à ce moment-là, l'utilisateur autorise le site web à envoyer des notifications web ; si l'utilisateur clique sur « Deny » dans l'invite native à ce moment-là, le site web ne pourra plus obtenir à nouveau l'autorisation de l'utilisateur.
  
• Si l'utilisateur clique sur « Cancel » dans l'invite EngageLab, on peut considérer qu'il ne souhaite pas, pour le moment, recevoir de notifications du site web. Comme une demande à ce moment-là risque d'être refusée, nous ne déclencherons pas la popup native et, lors de la prochaine visite de l'utilisateur, nous pourrons lui redemander via l'invite EngageLab s'il souhaite recevoir des notifications.

Résolution des problèmes lorsque les notifications ne sont pas reçues

1. Vérifiez si les autorisations de notification sont activées pour la page web

2. Vérifiez si les autorisations de notification sont activées pour l'application du navigateur
Paramètres de notification Windows :

• Désactivez l'Assistant de concentration. Pour plus de détails, consultez la documentation officielle de Microsoft.
• Vérifiez Paramètres > Notifications et actions > Recevoir des notifications des applications et autres expéditeurs. Assurez-vous que votre site et votre navigateur sont également activés. Pour plus de détails, consultez la documentation officielle de Microsoft.

Paramètres de notification macOS :

• Dans Préférences Système > Notifications > Chrome ou le navigateur sélectionné, assurez-vous que Autoriser les notifications est activé.
• Dans Préférences Système > Notifications > Concentration > Ne pas déranger et veille, assurez-vous que ce mode n'est pas activé ou que vous vous trouvez dans une plage horaire autorisée pour les notifications.
• macOS dispose également d'un paramètre de notification temporaire Ne pas déranger dans le menu en haut à droite ; faites défiler vers le haut pour l'afficher.

3. Les canaux des éditeurs de navigateurs peuvent être instables ; passez donc à une priorité de diffusion via 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": "business info"
  }
}

            

Le navigateur Safari ne peut pas afficher les notifications ?

Étape 1 : Vérifiez les autorisations du navigateur Safari et assurez-vous que l'interrupteur d'autorisation est activé. Un état normal est illustré ci-dessous :

Étape 2 : Cliquez pour vérifier l'état du service push et les autorisations de notification du navigateur. Un état normal est illustré ci-dessous :

Étape 3 : Dans Safari, cliquez sur Préférences.

Cliquez sur Sites web > Notifications, et vérifiez si le site est autorisé dans le centre de notifications. Un état normal est illustré ci-dessous :

Remarque spéciale :

1. Cliquer sur Stop Push empêchera la réception des messages JPush, et la page devra être actualisée.
2. Si plusieurs pages HTML sont configurées sous un même domaine, ne supprimez pas l'autorisation du site web du centre de notifications. Après suppression, toutes les pages HTML cesseront de recevoir des notifications (l'utilisateur devra retrouver la page principale et obtenir à nouveau l'autorisation de notification du site web).

Si le même utilisateur utilise plusieurs navigateurs en même temps et qu'un message est envoyé à cet utilisateur, comment sera-t-il affiché sur l'appareil de l'utilisateur ?

Si la stratégie d'envoi sélectionnée consiste à prioriser le canal système, ce message ne sera diffusé que via le canal de l'éditeur du navigateur utilisé le plus récemment par l'utilisateur. Si l'envoi est sélectionné uniquement via le canal JPush, plusieurs messages seront alors diffusés.

Si l'utilisateur efface le cache et les cookies du navigateur, peut-il encore recevoir les notifications Web Push de ce site web ?

Lorsque l'utilisateur est en ligne, le canal JPush peut toujours recevoir des notifications push.
Pour les canaux des éditeurs de navigateurs, lorsque les utilisateurs effacent les cookies et le cache du navigateur, ils se désabonnent des notifications. Cela s'explique par le fait que les données utilisateur de l'abonné sont stockées dans le stockage IndexedDB du navigateur. La suppression de ces données amène le navigateur à « oublier » l'abonné. Cependant, l'effacement de ces données ne supprime pas l'autorisation déjà accordée à l'utilisateur de recevoir des notifications dans ce navigateur. À ce stade, l'initialisation du SDK est requise afin que l'utilisateur puisse être automatiquement réabonné lorsqu'il revient sur le site web.
Cependant, si l'utilisateur modifie l'autorisation de notification du navigateur sur « Ask » ou « Block », il ne sera pas automatiquement réabonné.
Si l'utilisateur efface les notifications depuis les paramètres de notification du navigateur, il ne sera pas non plus automatiquement réabonné.

Comment effacer les notifications dans chaque navigateur :

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

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

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

Lorsque l'utilisateur se réabonne, il obtient un nouvel enregistrement Registration ID. Vous pouvez utiliser window.MTpushInterface.getRegistrationID() pour obtenir le RID.

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

Le mécanisme d'affichage des messages varie selon le canal push :
Canal EngageLab : aucun mécanisme d'écrasement. Si plusieurs messages sont envoyés au même utilisateur au même moment, plusieurs messages seront affichés simultanément à l'utilisateur. Le centre de notifications conservera plusieurs messages ; à l'exception du message le plus récent, les autres seront réduits.
Safari : aucun mécanisme d'écrasement. Si plusieurs messages sont envoyés au même utilisateur au même moment, plusieurs messages seront affichés simultanément à l'utilisateur. Le centre de notifications conservera plusieurs messages ; à l'exception du message le plus récent, les autres seront réduits.
Chrome : dispose d'un mécanisme d'écrasement. Si plusieurs messages sont envoyés au même utilisateur au même moment, chaque notification sera remplacée par la notification mise à jour, et seul le dernier message envoyé sera affiché.
Edge : dispose d'un mécanisme d'écrasement. Si plusieurs messages sont envoyés au même utilisateur au même moment, chaque notification sera remplacée par la notification mise à jour, et seul le dernier message envoyé sera affiché.
Firefox : dispose d'un mécanisme d'écrasement. Si plusieurs messages sont envoyés au même utilisateur au même moment, chaque notification sera remplacée par la notification mise à jour, et seul le dernier message envoyé sera affiché.

EngageLab WebPush prend-il en charge le changement de domaine ?

Les navigateurs ont déjà implémenté Web Push de manière à lier les abonnés à une origine 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, les navigateurs n'autorisent pas le déplacement des abonnés vers une autre origine. Il ne s'agit pas d'une limitation d'EngageLab. Si un fournisseur affirme pouvoir déplacer des abonnés d'un site web à un autre, assurez-vous de bien confirmer que ce à quoi ils sont réellement abonnés est bien votre site web.
Si vous avez changé de site web, la meilleure solution consiste à configurer une nouvelle app WebPush pour le nouveau site web et à faire en sorte que vos utilisateurs s'abonnent au site web sous cette nouvelle app. Vous ne pouvez pas importer des abonnés d'une origine vers une autre.
Vous pouvez continuer à envoyer des notifications push aux abonnés de l'ancien site web (ancienne app WebPush), mais vos utilisateurs doivent se réabonner au nouveau site web afin de recevoir des notifications push depuis le nouveau domaine. Les étapes de migration recommandées sont les suivantes :

• Configurer une nouvelle app WebPush pour le nouveau domaine du site.
  
• Continuer à envoyer des notifications push depuis l'ancienne app WebPush en utilisant l'ancien domaine du site. Dans le « Launch URL » de la notification, utilisez le nouveau domaine du site.
  
• Après 2 semaines à 2 mois (selon le nombre de notifications que vous envoyez chaque jour et le nombre d'abonnés que vous gagnez sur le nouveau site web), vous pouvez cesser d'utiliser l'ancienne app WebPush et n'utiliser que la nouvelle app WebPush.
  
• Si vous envoyez le même message à la fois depuis l'ancienne app WebPush et la nouvelle app WebPush, les abonnés des deux recevront des messages en double. C'est pourquoi nous recommandons de suivre ce calendrier.
  
• Vous pouvez envoyer plusieurs messages tels que « Nous avons déménagé. Cliquez ici pour visiter notre nouveau site web et vous réabonner afin de rester informé. » Cela aidera à rappeler aux utilisateurs qu'ils risquent de ne plus recevoir de notifications push de votre site web s'ils ne reviennent pas et ne se réabonnent pas. Il est recommandé d'envoyer ce type de notification au début de la migration ainsi qu'avec le dernier message envoyé depuis l'app.
  
• Malheureusement, chaque site web et chaque groupe d'utilisateurs sont différents. Veuillez vous préparer à perdre des abonnés à court terme.
  

Lors de la mise en œuvre des étapes de migration ci-dessus, veillez à prêter attention à l'expérience utilisateur afin d'éviter tout désagrément pour les utilisateurs.

EngageLab WebPush prend-il en charge les notifications push PWA ?

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

Le push PWA désigne le processus d'utilisation de la technologie Web Push dans les Progressive Web Apps (PWA) pour envoyer des notifications aux utilisateurs. Une PWA est une application créée à l'aide de technologies web qui offre des fonctionnalités et une expérience utilisateur similaires à celles d'une application native, tout en restant accessible via un navigateur sans installation.
Le push PWA est implémenté via la technologie Web Push fournie par le navigateur. La technologie Web Push permet aux applications web d'envoyer des notifications push comme les applications natives, même lorsque l'application n'est pas active ou est complètement fermée.
Contrairement aux applications traditionnelles, les PWA n'ont pas besoin d'être téléchargées et installées depuis une boutique d'applications et peuvent être accessibles directement via une URL dans le navigateur. En même temps, le push PWA peut fournir des alertes de message en temps réel aux utilisateurs, améliorant ainsi l'expérience utilisateur et l'engagement.
En bref, le push PWA est une méthode qui utilise la technologie Web Push pour envoyer des notifications aux utilisateurs de Progressive Web Apps, afin d'améliorer l'engagement et l'interaction des utilisateurs tout en offrant aux applications web une expérience utilisateur plus proche de celle des applications natives.

2. EngageLab WebPush prend-il en charge le push PWA ?

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

Remarque : il existe deux conditions nécessaires pour que le Web SDK prenne en charge les PWA :

1. L'application s'exécute dans un navigateur, et le navigateur prend en charge les notifications W3C.
2. Il existe un nom de domaine spécifique, et il utilise le protocole HTTPS.

3. Le service worker de la PWA entrera-t-il en conflit avec le service worker EngageLab WebPush ?

Le service worker d'une PWA (Progressive Web App) et le service worker d'EngageLab WebPush peuvent entrer en conflit, car les deux s'exécutent en arrière-plan dans le navigateur et, pour une même origine, généralement un seul service worker peut être actif à la fois.

Les service workers sont des scripts installés par les sites web dans le navigateur et peuvent prendre en charge les expériences hors ligne, la messagerie push, la synchronisation en arrière-plan, etc. Comme les service workers contrôlent les pages dans leur périmètre, plusieurs service workers ne peuvent pas contrôler simultanément des pages sous le même périmètre.

Si vous essayez d'enregistrer plusieurs service workers sous la même application ou le même domaine, celui enregistré plus tard peut remplacer le précédent, ou des conflits peuvent survenir lorsque les périmètres des deux service workers se chevauchent. Ce conflit peut entraîner des comportements inattendus, par exemple un fonctionnement correct de la messagerie push via un seul canal.

Pour éviter ce conflit, vous pouvez :

1. Assurez-vous d'utiliser un seul service worker dans votre application. Si la fonctionnalité Web Push fournie par EngageLab et la fonctionnalité de votre PWA peuvent être implémentées via le même service worker, il est préférable de les combiner dans un seul script de service worker.

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

Avant la mise en œuvre, il est recommandé de lire attentivement la documentation correspondante et d'effectuer des tests suffisants dans les environnements de développement et de production afin de garantir que les service workers peuvent coexister sans interférer les uns avec les autres.

4. Différences de comportement de la popup d'autorisation des notifications dans l'app PWA sur les appareils iOS et Android

• Restrictions du système iOS (politique Safari/WebKit) :
  · Pour des raisons de confidentialité, iOS exige une action de l'utilisateur (comme un clic) avant qu'une popup d'autorisation puisse être déclenchée.
  · Il s'agit d'une politique WebKit obligatoire, qui s'applique à toutes les PWA et applications web.
  · Après la première installation d'une PWA, une interaction de l'utilisateur reste nécessaire avant de demander l'autorisation.

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

Pourquoi le registration ID peut-il être identique sur différents navigateurs ?

Réponse : Pour le même nom de domaine intégré configuré pour une application et le même userStr, le même RID sera généré, qu'il s'agisse ou non du même navigateur.

• Pour vérifier s'il s'agit du même utilisateur, utilisez la méthode suivante : affichez le code source HTML et recherchez la fonction d'initialisation.

              
              // Please register event listeners before initialization
// Callback when the JPush channel is disconnected
MTpushInterface.mtPush.onDisconnect(function () {
  console.log("onDisconnect");
});

// Receive push messages (web push, browser vendor channel)
MTpushInterface.onMsgReceive((msgData) => {
  // msgData data structure {data:{xxx},type:0} type:0 is the JPush channel, 1 is the system channel
  console.log("Received push message:", msgData);
});

// Push initialization
MTpushInterface.init({
  appkey: "", // Required. See above for how to get application information
  user_str: visitorId, // Required. User identifier used to identify the user
  fail(err) {
    console.log("Failed to create online push", err);
  },
  success(data) {
    console.log("Online push created successfully", data);
  },
  webPushcallback(code, tip) {
    console.log("Status code and prompt received by the user", code, tip);
  },
  swUrl: '', // Default "/sw.min." + sdkEnv.version + ".js". This configuration item is the service worker file address. The domain name must be the current domain name, and the path determines the service worker scope.
  canGetInfo(data) {
    // At this point, you can get some notification configuration data, and after this callback function you can get the RegId
    console.log(data); // Related configuration information
    console.log("Get RegId", MTpushInterface.getRegistrationID());
  },
  custom: (fuc) => {
    // When using a custom prompt configuration, you need to manually call fuc() to request notification permission.
    // The function to request notification permission can only be obtained through custom.
    // Calling fuc() will request notification permission
  },
});

            

Si vous rencontrez des problèmes pendant l'utilisation qui ne sont pas couverts dans ce document, n'hésitez pas à nous contacter à tout moment. Nous vous fournirons une assistance et des réponses professionnelles.