よくある質問
ユーザー一意識別子の説明
- 初期化時には、一意の文字列を入力して一意のUIDを生成する必要があります。このUIDはプッシュ通知の身份認識コードであり、デバイスとは関係がありません。
- ユーザーが同じ
user_str
を使用する場合、同じユーザーとして認識されます。異なるブラウザやデバイスで購読すると、メッセージ送信のために購読情報が最新のものに置き換えられます。例えば、ユーザーAが同じuser_str
を使ってブラウザa1、a2、a3で順番に購読した場合、理論的には最後に購読したa3だけがメッセージを受信でき、同じユーザーが複数のメッセージを受信したり、過剰なメッセージ送信を防いだりすることができます。バックエンドでは、同じUIDの最新の購読情報だけを常に保存します。 - メッセージ購読はキャンセルでき、SDKは購読解除インターフェースを提供しています。この購読解除インターフェースはUIDと購読情報のバインド関係だけを解除し、ブラウザの通知権限は変更しません。
- 理論的には、
user_str
は実際のユーザーと一対一で対応する必要があります。特定の状況では、ユーザーが訪問者モードになる場合があります。開発者は実際の状況に基づいて明確に一意のuser_str
を生成する必要があります。SDKはデフォルトで自動処理を行わないため、開発者がuser_str
と実際のユーザーの関係を適切に処理していない場合に生じるプロセスのエラーを回避し、統計データが予期した状況と一致しないことを防ぎます。ユーザーが訪問者モードの場合、開発者は以下の関数を参照して一意の
user_str
を生成できます。この関数はユーザーのブラウザを一意の身份認識コードとして使用します。注意:この処理方法では、ユーザーがブラウザ、デバイスを変更したり、キャッシュをクリアしたりすると、新しいuser_str
が生成されます。
サンプル関数: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();
このコードブロックはフローティングウィンドウ内に表示されます
どのプラットフォームがWebPushをサポートしていますか?
オペレーティングシステム別のブラウザサポート状況
ブラウザ | Windows PC | macOS | Android | iOS(iPhone、iPad) |
---|---|---|---|---|
Chrome | 対応 | 対応 | 対応 | 非対応 |
Firefox | 対応 | 対応 | 対応 | 非対応 |
Safari | 非対応 | 対応 | 非対応 | 対応 |
Microsoft Edge | 対応 | 対応 | 非対応 | 非対応 |
Opera | 対応 | 対応 | 対応 | 非対応 |
注1: 2019年に更新されたMicrosoft Edge、Opera、Samsung Internet、Yandex、UC BrowserはすべてChromiumベースのブラウザであり、Engagelab内ではChromeとして識別されます。
注2: Internet Explorerは機能更新を受けなくなりました。Microsoftはブラウザ開発をEdgeプラットフォームに移行しています。
注3: シークレットモード、プライベートブラウジングモード、ゲストブラウザモードはWebプッシュ通知をサポートしていません。
ブラウザバージョン別のサポート状況
ブラウザ | Windows | MacOS | Android |
---|---|---|---|
Chrome | Chrome 42+ | Chrome 42+ | Chrome 105+ |
Firefox | Firefox v44+ | Firefox v44+ | Firefox v104+ |
Apple Safari | / | Safari V11.1+ | / |
Opera | Opera v29+ | Opera v29+ | Opera mobile v64+ |
Microsoft Edge | Edge v17+ | Edge v17+ | / |
SafariブラウザのWebプッシュ通知に関する質問
SafariブラウザのWebプッシュ通知は、macOS(V11.1+)およびiOS/iPadOS 16.4+をサポートしています。
Safariプッシュ通知はどの機能をサポートしていますか?
機能 | macOS(15-) | macOS(16+) | iOS/iPadOS 16.4+ |
---|---|---|---|
画像 | 非対応 | 非対応 | 非対応 |
アクションボタン | 非対応 | 非対応 | 非対応 |
起動URL | 対応 | 対応 | 対応 |
カスタムサイトアイコン | 対応 | 非対応 | 対応 |
iOSおよびiPadOSのユーザーはどのようにSafari Webプッシュ通知を受信できますか?
1. 開発者はどのように設定して、iOS/iPadOS 16.4+でユーザーがWeb通知を受信できるようにすることができますか?
iOS/iPadOS 16.4+では、Webプッシュ通知が利用可能になりました。ただし、ウェブサイトは適切なマニフェストファイルを持ち、通知が正常に機能するための正しい属性が設定されている必要があります。統合ページのhtmlに対応するコードを追加します:
マニフェストファイルを含めます:
{
"$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. iOSおよびiPadOSのユーザーがSafari Webプッシュ通知を購読して受信するには、Webアプリをホーム画面に追加する必要があります
モバイルSafari Webプッシュ通知を送信するには(iOSおよびiPadOS 16.4+に適用)、通知の受信者は次の操作を実行する必要があります:
- 16.4+を搭載したモバイルAppleデバイスのSafariブラウザを使用してウェブサイトを訪問します。
- モバイルデバイスのSafariブラウザの共有ボタンをタップします。
- 「ホーム画面に追加」オプションをタップします。
- デバイスにアプリケーションを保存します。
- ホーム画面からアプリケーションを開きます。
- 通知を購読します(ユーザーはネイティブの権限プロンプトが表示される前に購読ボタンをタップする必要があります)。これらの手順は、モバイルWebプッシュ通知を受信するために必要です。
この操作体験はエンドユーザーにとって比較的複雑であるため、通知を購読することの価値をエンドユーザーに理解してもらう必要があります。
3. ウェブサイトにバナー通知を追加して、ユーザーに「ホーム画面に追加」するよう誘導する
ウェブサイトにバナーを追加して、エンドユーザーにモバイルWebプッシュ通知の価値と購読方法を通知できます。
モバイルAppleデバイスに表示されるバナーをウェブサイトに追加することを推奨します。これにより、訪問者に共有ボタンと「ホーム画面に追加」オプションをタップするよう誘導できます。
ユーザーにこれらのガイドラインを提供するのに役立つ人気のオープンソースプロジェクトもあります:
ボトムバナーの例のGithubリンク:https://github.com/rajatsehgal/add-to-home-screen
ブラウザを閉じた場合、ユーザーは通知を受信できますか?
- engagelabチャネルを使用する場合、ウェブサイトを開いている必要があります。
- システムチャネルを使用する場合、ブラウザを閉じても通知を受信できます。プラットフォームによって動作が異なります。詳細については、次の表を参照してください:
ブラウザ | Windows | MacOS |
---|---|---|
Chrome | 対応、ブラウザプロセスがバックグラウンドで実行されている必要があります | 対応、ブラウザプロセスがバックグラウンドで実行されている必要があります |
Firefox | 対応、ブラウザプロセスがバックグラウンドで実行されている必要があります | 対応、ブラウザプロセスがバックグラウンドで実行されている必要があります |
Safari | / | 対応 |
Opera | 対応、ブラウザプロセスがバックグラウンドで実行されている必要があります | 対応、ブラウザプロセスがバックグラウンドで実行されている必要があります |
Microsoft Edge | 対応、ブラウザプロセスがバックグラウンドで実行されている必要があります | 対応、ブラウザプロセスがバックグラウンドで実行されている必要があります |
Windowsでは、すべてのウィンドウが閉じられても、ブラウザがバックグラウンドで実行されている場合はシステム通知を受信できます。ブラウザプロセスが閉じられている場合は、システム通知を受信できません。
Mac OS Xでは、すべてのウィンドウが閉じられても、ほとんどのブラウザプロセスはバックグラウンドで実行され続け、システム通知を受信できます。ブラウザプロセスが強制終了された場合は、通知を受信できません。Safariは実行していなくても通知を受信できます。これは、通知が直接オペレーティングシステムに送信されるためです。ユーザーは最初にSafari通知を登録する必要があります。その後、Safariが完全に無効にされていても通知を受信できます。
通知権限プロンプトに関する質問
ユーザーがWebプッシュプロンプトを却下した後、どのような場合に再度表示されますか?
ユーザーがネイティブの権限プロンプトで「ブロック」(Chrome)、「許可しない」(Safari)、または「決して許可しない」(Firefox)をクリックした場合、ユーザーがブラウザ設定で複数の手順を実行して購読を再設定したり権限をリセットしたりしない限り、ウェブサイトは再度プロンプトを送信できません。これが、EngageLabのプロンプトを使用することを推奨する理由です(設定に移動)。
ネイティブ権限プロンプト
Webプッシュ購読にはネイティブのブラウザ権限プロンプトが必要で、このネイティブのプロンプトはカスタマイズできません。ユーザーのブラウザ設定で設定された言語を使用します。HTTPSウェブサイトのみがネイティブのブラウザプロンプトを表示できます。
Chrome:ユーザーが購読する機会は3回です。ユーザーがネイティブのプロンプトで3回「X」をクリックすると、1週間はプロンプトが表示されません。このChromeの機能の詳細については、こちらを参照してください。
Firefox:Firefox 70以降、ユーザーが「閉じる」ボタンをクリックした後は、ブラウザの小さな通知アイコンをクリックして再度プロンプトを受信する必要があります。さらに、Firefox 72+では、ネイティブのブラウザプロンプトの表示がブロックされています。詳細については、こちらを参照してください。
Safari:Firefoxと同様に、通常権限を拒否するユーザーには静かなUIが追加され、プッシュが拒否されたサイトの自動プロンプトも提供されています(Safari 12.1+)。
EngageLabソフトプロンプト
ネイティブのポップアップには1回の機会しかないため、ユーザーに拒否されるとウェブサイトはユーザーから権限を取得できなくなります。したがって、EngageLabは「ソフトプロンプト」方式を使用してユーザーの権限を取得することを推奨します:
ユーザーがEngageLabのプロンプトで「許可」または「キャンセル」をクリックし(設定ガイドの適用に移動)、ネイティブのプロンプトを介してまだ購読されていない場合、EngageLabのプロンプトは再度ポップアップすることができます。
- ユーザーがEngagelabのプロンプトで「許可」をクリックすると、ネイティブのポップアップが呼び出されます。ただし、このときユーザーがネイティブのプロンプトで「キャンセル」をクリックすると、次回ウェブサイトに入ったときにEngagelabのプロンプトは依然としてユーザーにウェブサイト通知の権限を許可するかどうかを尋ねることができます。
- ユーザーがEngagelabのプロンプトで「許可」をクリックすると、ネイティブのポップアップが呼び出されます。このときユーザーがネイティブのプロンプトで「許可」をクリックすると、ユーザーはウェブサイトにWeb通知権限を許可したことになります。ユーザーがネイティブのプロンプトで「拒否」をクリックすると、ウェブサイトは再度ユーザーから権限を取得できなくなります。
- ユーザーがEngagelabのプロンプトで「キャンセル」をクリックすると、ユーザーは現時点でウェブサイトから通知を受信する意思がないと判断できます。この場合、ウェブサイトの通知メッセージを受け入れるかどうかを尋ねても拒否される可能性が高いため、ネイティブのポップアップは呼び出されません。次回ユーザーが訪問したとき、Engagelabのプロンプトは再度ユーザーの通知受信意思を確認できます。
通知が受信できない場合のトラブルシューティング方法
1. ウェブページの通知バーの権限を確認します。
2. ブラウザアプリケーションの通知権限が有効になっているかどうかを確認します。
Windowsの通知設定:
- フォーカスアシストをオフにします。詳細については、マイクロソフトの公式ドキュメントを参照してください。
- 設定>通知とアクション>アプリケーションやその他の送信者から通知を取得するをオンにするかどうかを確認します。サイトとブラウザも有効になっていることを確認してください。詳細については、マイクロソフトの公式ドキュメントを参照してください。
macOSの通知設定:
- システム環境設定>通知>Chromeまたは選択したブラウザで、通知を許可するスイッチがオンになっているかどうかを確認します。
- システム環境設定>通知>フォーカス>通知しないとスリープで、このモードがオンになっていないか、許可された通知時間内にあるかどうかを確認します。
- macOSの右上メニュー>上にスクロールで、一時的な「通知しない」通知設定もあります。
3. ブラウザメーカーの問題が不安定な場合は、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"
}
}
Safariブラウザで通知がポップアップできませんか?
ステップ1:Safariブラウザの権限を確認し、許可スイッチが有効になっているかどうかに注意してください。通常の状況は図のとおりです:
ステップ2:プッシュサービス状態とブラウザの通知権限を確認するをクリックします。通常の状況は図のとおりです:
ステップ3:Safariブラウザ>環境設定をクリックし、ウェブサイト>通知をクリックして、通知センターのウェブサイトが許可されているかどうかを確認します。通常の状況は図のとおりです。
注:
- プッシュを停止をクリックすると、オーロラのプッシュメッセージを受信できなくなり、ページをリフレッシュする必要があります。
- 1つのドメイン名に複数のhtmlページが構成されている場合は、通知センターのウェブサイト権限を削除しないでください。削除後、htmlページは通知を受信できなくなります(メインページを見つけて、再度ウェブサイトの通知権限を取得する必要があります)。
同じユーザーが複数のブラウザを使用している場合、メッセージを送信するとユーザーのデバイスにどのように表示されますか?
選択した配信戦略がシステムチャネルを優先する場合、メッセージはユーザーが最後に使用したブラウザメーカーのチャネルを介してのみ送信されます。ジグアングチャネルを介してのみ送信するオプションが選択されている場合、複数のメッセージが送信されます。
ユーザーがブラウザのキャッシュとクッキーをクリアした場合、このウェブサイトからWebPushを受信できますか?
ユーザーがオンラインの場合、ジグアングチャネルは依然としてプッシュ通知を受信できます。
ブラウザメーカーのチャネルの場合、ユーザーがブラウザのクッキーとキャッシュをクリアすると、通知の購読が解除されます。これは、購読ユーザーデータがブラウザのIndexedDBストレージに格納されているためです。このデータを削除すると、ブラウザは購読者を「忘れ」てしまいます。ただし、このデータをクリアしても、ユーザーがすでにそのブラウザで通知を受信する権限を付与している場合は削除されません。このとき、SDKを初期化する必要があります。これにより、ユーザーがウェブサイトに戻ったときに自動的に再購読されます。
ただし、ユーザーがブラウザの通知権限を「確認」または「ブロック」に変更した場合、自動的に再購読されません。
ユーザーがブラウザの通知設定から通知をクリアした場合も、自動的に再購読されません。
さまざまなブラウザで通知をクリアする方法:
Chrome:chrome://settings/content/notifications
Firefox:about:preferences#privacy > Permissions > Notifications
Safari:環境設定 > ウェブサイト > 通知 > 削除!
ユーザーが再購読すると、新しいRegistration IDレコードが受信されます。window.MTpushInterface.getRegistrationID()を使用してridを取得できます。
複数のメッセージを同じユーザーに同時に送信すると、すべてのメッセージが表示されますか?
メッセージの表示メカニズムは、さまざまなプッシュチャネルで異なります:
- EngageLabチャネル:上書きメカニズムはないため、同じユーザーに複数のメッセージを同時に送信すると、ユーザーにすべてのメッセージが同時に表示されます。通知センターは複数のメッセージを保持します。最新のメッセージを除く他のメッセージは折りたたまれます。
- Safari:上書きメカニズムはないため、同じユーザーに複数のメッセージを同時に送信すると、ユーザーにすべてのメッセージが同時に表示されます。通知センターは複数のメッセージを保持します。最新のメッセージを除く他のメッセージは折りたたまれます。
- Chrome:上書きメカニズムがあるため、同じユーザーに複数のメッセージを同時に送信すると、各通知は更新されたものに置き換えられ、最後に送信されたメッセージのみが表示されます。
- Edge:上書きメカニズムがあるため、同じユーザーに複数のメッセージを同時に送信すると、各通知は更新されたものに置き換えられ、最後に送信されたメッセージのみが表示されます。
- Firefox:上書きメカニズムがあるため、同じユーザーに複数のメッセージを同時に送信すると、各通知は更新されたものに置き換えられ、最後に送信されたメッセージのみが表示されます。
EngageLab WebPushはドメイン名の変更をサポートしていますか?
ブラウザは、購読者を特定のソース(ドメイン名/ウェブサイトURL)にバインドするようにWeb Pushを設定しています。
セキュリティ上の理由とブラウザの同一生成元ポリシーのため、ブラウザは購読者を他のソースに移動することを許可していません。これはEngageLabの制限ではなく、あるウェブサイトから別のウェブサイトに購読者を移動できると主張するどのサービスプロバイダーも、ユーザーがウェブサイトに購読していることを確認してください。
ウェブサイトを変更する場合は、新しいウェブサイトに新しいWebPushアプリケーションを設定し、ユーザーに新しいウェブサイトに再購読してもらうのが最善の解決策です。あるソースから別のソースに購読者をインポートすることはできません。
古いウェブサイト(古いWebPushアプリケーション)の購読者にプッシュ通知を送信し続けることができますが、ユーザーは新しいドメインからプッシュを受信するには新しいウェブサイトに再購読する必要があります。移行の推奨手順は以下のとおりです:
- 新しいサイトドメインに新しいWebPushアプリケーションを設定します。
- 古いサイトドメインを使用して古いWebPushアプリケーションからプッシュを送信し続けます。通知の「起動URL」で新しいサイトドメインを使用します。
- 2週間から2か月後(1日あたりの通知送信数と新しいウェブサイトの購読者数に応じて)、古いWebPushアプリケーションの使用を停止し、新しいWebPushアプリケーションのみを使用できます。
- 古いWebPushアプリケーションと新しいWebPushアプリケーションの両方から同じメッセージを送信すると、両方の下の購読者は重複したメッセージを受信します。これが上記の期間に従うことを推奨する理由です。
- 「移動しました。こちらをクリックして新しいウェブサイトを訪問し、更新を受け取るために再購読してください。」という内容のいくつかのメッセージを送信できます。これにより、ユーザーに再購読するために戻らないとサイトからのプッシュを受信できない可能性があることを思い出させるのに役立ちます。移行の開始時とアプリケーションから送信される最後のメッセージでこのような通知を送信することを推奨します。
- 残念ながら、すべてのウェブサイトとオーディエンスは異なります。短期的に一部の購読者を失う可能性があることを覚悟してください。
上記の移行手順を実行するときは、ユーザーエクスペリエンスに注意を払い、ユーザーに不便をかけないようにしてください。
EngageLab WebPushはPWAプッシュ通知をサポートしていますか?
1. PWAとは何ですか?
PWAプッシュとは、Progressive Web Apps(PWA)でWeb Push技術を使用してユーザーに通知を送信するプロセスを指します。PWAはウェブ技術を使用して構築されたアプリケーションで、ネイティブアプリケーションと同様の機能とユーザーエクスペリエンスを提供し、インストールする必要なくブラウザを介してアクセスできます。
PWAプッシュは、ブラウザが提供するWeb Push技術を通じて実装されます。Web Push技術により、ウェブアプリケーションはネイティブアプリのようにプッシュ通知を送信できます。アプリがアクティブでない場合や完全に閉じている場合でも可能です。
従来のアプリケーションとは異なり、PWAはアプリストアからダウンロードしてインストールする必要はありません。URLを介してブラウザで直接アクセスできます。さらに、PWAプッシュ通知はユーザーにタイムリーなメッセージアラートを提供し、ユーザーエクスペリエンスと関与を強化します。
まとめると、PWAプッシュはWeb Push技術を使用してプログレッシブウェブアプリケーションのユーザーに通知を送信する方法で、ユーザーの関与と対話を増やし、ネイティブアプリに近いユーザーエクスペリエンスを提供します。
2. EngageLab WebPushはPWAプッシュ通知をサポートしていますか?
EngageLab WebPushサービスはPWAプッシュ通知をサポートしています。EngageLab WebPushが提供するWeb SDKを使用して、PWAにWeb Push機能を統合する必要があります。ドキュメントのサンプルコードに従ってService Workerを登録し、Web Push機能を初期化します。統合が完了すると、EngageLab WebPush APIを使用してPWAユーザーにプッシュ通知を送信できます。
注:WebSDKがPWAをサポートするための2つの必要条件:
1. プログラムはW3C通知をサポートするブラウザで実行されている必要があります。2. 特定のドメイン名があり、HTTPSプロトコルを使用している必要があります。
3. PWAのサービスワーカーはEngageLab WebPushのサービスワーカーと競合しますか?
Progressive Web App(PWA)のサービスワーカーとEngageLab WebPushのサービスワーカーは競合する可能性があります。両方ともブラウザのバックグラウンドで動作し、同一生成元の場合、通常は1つのサービスワーカーだけがアクティブになることができます。
サービスワーカーはウェブサイトによってブラウザにインストールされるスクリプトで、オフライン体験、メッセージプッシュ、バックグラウンド同期などの機能をサポートします。サービスワーカーはその範囲内のページを制御するため、2つのサービスワーカーの範囲が重複する場合、競合が発生する可能性があります。
同じアプリケーション/ドメインに複数のサービスワーカーを登録しようとすると、後で登録されたサービスワーカーが前のものに置き換わる場合があります。または、2つのサービスワーカーの範囲が重複する場合、競合が発生する可能性があります。このような競合により、プッシュメッセージが1つのチャネルを介してのみ正常に機能するなど、予期しない動作が発生する可能性があります。
このような競合を回避するには、次の方法があります:
1. アプリケーションで1つのサービスワーカーのみを使用するようにします。EngageLabが提供するWebPush機能とPWA機能を同じサービスワーカースクリプトに統合できる場合は、1つのサービスワーカーに統合することを強く推奨します。
2. 2つの別々のサービスワーカーを使用する必要がある場合は、それらの範囲が重複しないように確認します。サービスワーカーを登録するときに異なる範囲パスを指定することで実現できます。
実装する前に、関連するドキュメントを注意深く読み、開発環境と運用環境の両方で徹底的なテストを実行して、サービスワーカーが調和して共存し、相互に干渉しないようにすることを推奨します。
4. iOSおよびAndroidデバイスにおけるPWA通知権限ポップアップ動作の違い
iOSシステムの制限(Safari/WebKitポリシー):
- プライバシー上の考慮から、iOSではユーザーのジェスチャー(クリックなど)が権限ポップアップをトリガーする必要があります
- これはすべてのPWAおよびウェブアプリケーションに適用される必須のWebKitポリシーです
- 初期PWAインストール後も、権限をリクエストするにはユーザーの操作が必要です
Androidシステムの特性:
- Chrome/WebViewはページ読み込み中に自動的な権限リクエストを許可します
- より緩やかな権限リクエストモデルに従います
- 一部のAndroidバージョンでは段階的な権限プロンプトもサポートしています
なぜ異なるブラウザに同じregidが存在するのですか?
A:同じアプリケーションに構成された統合ドメイン名が同じユーザーによってuserStrとして使用されている場合、同じブラウザを使用しているかどうかに関係なく、同じridが生成されます。
// 初期化前にイベントリスナーを登録
// ジグアングチャネルが切断されたときのコールバック
MTpushInterface.mtPush.onDisconnect(function () {
console.log("onDisconnect");
});
// プッシュメッセージを受信(web push、ブラウザベンダーチャネル)
MTpushInterface.onMsgReceive((msgData) => {
// msgDataの構造 {data:{xxx}, type:0}
// type:0はジグアングチャネル、type:1はシステムチャネル
console.log("Received push message:", msgData);
});
// プッシュ初期化
MTpushInterface.init({
appkey: "", // 必須、上記のアプリケーション情報を参照
user_str: visitorId, // 必須、ユーザー識別子
fail(err) {
console.log("Online push creation failed", err);
},
success(data) {
console.log("Online push created successfully", data);
},
webPushcallback(code, tip) {
console.log("User received status code and tip", code, tip);
},
swUrl: '', // デフォルト: "/sw.min." + sdkEnv.version + ".js"
canGetInfo(data) {
// ここで通知構成データを取得できます
// このコールバックの後、RegIdを取得できます
console.log(data); // 構成情報
console.log("Received RegId", MTpushInterface.getRegistrationID());
},
custom: (fuc) => {
// カスタム通知設定を使用する場合:
// 1. 手動でfuc()を呼び出して権限をリクエストします
// 2. カスタムコールバックを介してのみ取得できます
// 3. fuc()は通知権限をリクエストします
}
});
使用中にこのドキュメントでカバーされていない問題が発生した場合は、ご自由にカスタマーサービスにお問い合わせください。専門的なサポートとソリューションを提供させていただきます。