テストアラート

アラートの作成の3番目のステップで、公開する前にアラートをテストできます。このオプションでは、公開する前に選択したチャネルでアラートをテストできます。以下に示します。

info

Note

このステップは推奨されます(ただしオプション)API統合が正しく設定され、パーソナライズが適切に表示されることを確認するためのものです。

公開前にアラートをテストする方法は?

ダッシュボードからコピーしたリクエストにいくつかの値を渡す必要があります。それらは、Authorization Header、MOE-APPKEY、リクエスト属性、およびパーソナライズ属性(ある場合)です。

ビルド認証ヘッダー

MoEngageは基本認証を使用します。Workspace ID と API Secret を使用して、HTTP Auth Header を生成します。詳細は こちら を参照してください。

Copy Request

ダッシュボードのテストリクエストセクションからサポートされている言語のサンプルリクエストをコピーし、クリップボードアイコンを使用して外部コンソールでテストすることもできます。

Copy Workspace ID

リクエストヘッダー MOE-APPKEY には、あなたの MoEngage アカウントのワークスペース ID 値を含める必要があります。

テストアラートID

ダッシュボードにテストアラートIDが提供されており、このテストアラートリクエストを外部コンソールに送信します。この値はリクエストに自動的に渡されます。

注意 : これは公開されたアラートのアラートIDとは異なります。

テストアラート参照名

テストアラート参照名は、ダッシュボードでアラートを追加する際に構成され、このテストアラートリクエストを外部コンソールに送信します。この参照名はアラートをテストするために使用できます。

info

Information

これは公開されたアラートの参照IDとは異なります。

属性

リクエストに渡す必要がある属性は次のとおりです:

リクエストフィールド 必須 Description

MOE-APPKEY

Yes

これはあなたのMoEngageアカウントのワークスペースIDです。ワークスペース ID は、あなたの MoEngage ワークスペースを一意に識別します。この値はテストリクエストに自動的に入力されます(複数の言語でサポートされています)。

認証 はい これは、認証のために渡す必要があるBase64エンコードされた認証ヘッダー(APPID:APISECRET)です。

alert_id

Yes

これは外部コンソールからのリクエストをテストするために生成されたテストアラートIDです。この値はリクエストに自動的に入力されます。

alert_reference_name

No

アラートを作成する際に追加できる参照IDです。

user_id

No

このフィールドはあなたのブランドによって提供されており、テストされているリクエストに貼り付ける必要があります。このフィールドはクライアントIDで、アラートが送信されるユーザーを特定します。これは、ユーザーにイベントをマッピングするために不可欠です。

無効なユーザーIDまたは存在しないユーザーIDが共有され、APIリクエストに有効な受取人の詳細が含まれている場合、有効な受取人の詳細を使用して新しいユーザープロフィールが作成されます。

ユーザーIDがリクエストに存在しない場合でも、受取人の詳細が利用可能であればリクエストは処理されます。ただし、イベントはMoEngageのいかなるユーザーにもログされません。詳細については、 アラートを送信するためのユーザー識別 を参照してください。

transaction_id

Yes

このフィールドはブランドによって提供され、テストされるリクエストに貼り付ける必要があります。このフィールドは、アラートがユーザーに送信されるトランザクションを特定します。Moengageは、ユニークに生成されたリクエストIDに対してトランザクションIDを保存します。ユーザーに送信するリクエストごとに transaction_id が一意であることを確認してください。これは冪等性をサポートするためにも使用されます。

ペイロード

Yes

このフィールドには、ユーザーの詳細とパーソナライズ属性を含むチャネルレベルのペイロードが含まれています。ペイロードは次の構造を持っています:

"payloads": {
" ": {
"recipient": " ",

"locale": "<ユーザーに送信する必要のあるロケールバージョン>"
"personalized_attributes": {

}

ペイロード内の 受信者 フィールドは、アラートを送信するユーザーを特定します。詳細については、 アラート送信のためのユーザー識別 を参照してください。

アラートを送信するためのユーザー識別

APIはリクエストで共有されたユーザーの識別情報を処理し、通信を送信する必要があるユーザーを特定します。以下に示すように。

UserCreation.png

チャネルレベルのペイロードの受取人フィールドが最初に確認され、そこに提供された受取人の値に基づいて、指定されたモバイル番号/メールIDまたはプッシュトークンにアラートが送信されます。受取人の詳細が利用できない場合、 user_id をリクエストに渡す必要があります。そうしないと、リクエストは却下されます。もし user_id ユーザープロフィール のIDフィールド)がペイロードに利用可能で、指定されたチャネルの受信者の詳細(携帯番号/メールID/アクティブプッシュトークン)がユーザープロフィールに利用可能な場合、アラートが送信されます。

受取人の詳細が利用可能で、新しい user_id が共有される場合、受取人の詳細を使用して新しいプロフィールが作成されます。

info

Note

  • ユーザープロファイルに利用可能な最近アクティブなデバイストークンは、プッシュチャネルのアラートを送信するために考慮されるのは5つのみです。
  • 受取人の詳細は、ユーザ属性が有効になっている場合、ユーザープロフィールから取得されます。詳細については、 ユーザー属性の有効化 を参照してください。

リクエストに必要な情報がすべて追加されたら、外部コンソールからリクエストを送信します。

Testing the request in Postman

Postmanでテストするには、次の手順を実行してください:

      1. クリックしてください copy & open Postman cURLをコピーしてPostmanにインポートするアイコン。
      2. 認証セクションを使用して認証情報を追加します。 ワークスペースIDをユーザー名として、APIキーをパスワードとして追加します。
      3. インポートされたcURLにはペイロードの詳細が含まれます。メールID、電話番号、その他の属性(user_id、transaction_id、パーソナライズ、該当する場合)を追加してください。
      4. Postmanで送信をクリックします。これにより、Send Inform APIにリクエストが送信されます。

応答、エラーコード、およびサンプル応答に関する情報は、 Inform API Response を参照してください。

アラートをテストした後、テストアラートログにはリクエストのステータスに関する詳細が表示されます。詳細については、 テストアラートログ を参照してください。

この記事は役に立ちましたか?
0人中0人がこの記事が役に立ったと言っています

How can we improve this article?