Skip to main content

フローを作成する際に従うべきベストプラクティスにはどのようなものがありますか?

  1. トリガーイベントが Install/ Sign up/ またはユーザーのプロファイルを作成するイベントであるオンボーディングフローでは、ターゲットオーディエンスを常に “All users” にしてください。これが難しい場合は、条件として ID exists を追加してください。この設定により、更新頻度の制約を回避でき、プロファイル作成時であってもこれらの値の更新がほぼリアルタイムになります。
  2. Has done event や Conditional Splits などの Condition ステージの直前に Wait ステージを使用することは避けてください。代わりに、条件ステージ内の Keep evaluating for で同じ期間を定義してください。これにより、コンテキストに応じて該当するブランチでユーザーを動的に移動させることができます。
  3. ステージの設定がほぼ同じになる場合は、ステージにカーソルを合わせてステージをコピー&ペーストし、手作業を省きましょう。
  4. キャンペーンでパーソナライズを使用して、パフォーマンスを向上させましょう。
  5. ユーザーへのスパムを避けるため、Exit on Conversion を使用して、フローのコンテキストに合わなくなったユーザーを削除しましょう。

フロー内でパーソナライズするにはどうすればよいですか?

フロー内でパーソナライズするには、次のようにします。
  • ポイントチャネルキャンペーン (Push、SMS、Email など) のメッセージフィールドに @ を入力します。パーソナライズエディターが表示されます。
  • ユーザー属性とイベント属性を使用してメッセージをパーソナライズできます。
  • イベントベースのパーソナライズは、Event-triggered Flows、または Condition stages の Yes Branch の下に追加されたコミュニケーションでのみ可能です。

フロー内で作成できるバージョン数に制限はありますか?

いいえ、フロー内で作成できるバージョン数に制限はありません。対象となる変更を行ってフローを公開するたびに、新しいバージョンが作成されます。

フローの新しいバージョンはどのように作成され、既存のユーザーにどのような影響がありますか?

フローの新しいバージョンは、次のいずれか 1 つ以上に変更があった場合に作成されます。
  • Target Audience Condition
  • Entry Condition
  • Tracked Conversion Goals
  • キャンバスへのステージの追加または削除など
フローが公開されると、新しいバージョンがアクティブになり、以前のバージョンはリタイアされます。以前のバージョンのフローにいるすべてのアクティブユーザーは、そのバージョンでトリップを継続します。フローの新規ユーザーは (以前のいずれのバージョンでもアクティブでない場合) 新しいバージョンに移動します。 詳細については、Flows のバージョン管理を参照してください。

ユーザーがフローに再エントリーしないようにするにはどうすればよいですか?

ユーザーの再エントリーを防止する、またはエントリー回数の上限を定義するには、フロー作成の 2 番目のステップでユーザーエントリー制限を追加します。ユーザーエントリー制限は When users enter the flow ステップで指定します。

Keep Evaluating For とはどういう意味ですか?どのように機能しますか?

Keep Evaluating For オプションは、条件が追加されたステージで利用できます。これは、条件ステージで定義されたチェックについてユーザーを評価する最大期間を示します。ユーザーは定義された条件を満たした時点で Yes パスから抜けることができるため、この期間は動的です。この動的な評価により、コミュニケーションのタイミングをより適切に、コンテキストに沿って調整できます。 カートを放棄したユーザーをターゲットにするフロー (フローのオーディエンスは、商品をカートに追加したもののまだ購入していないユーザー) の例を考えてみます。この Flow には次のステージがあります。
  1. Push Notification ステージ
  2. Has done event ステージ - Has Executed Product Purchase at least 1 time として定義され、このステージに入ったユーザーを 1 時間評価し続けます。
John は次のようなユーザーです。
  • 午前 10 時にフローに入る
  • 最初のプッシュ通知を受信し、午前 10 時 10 分に Has done ステージに入る
このステージは John を 1 時間評価するため、John は午前 11 時 10 分まで指定された条件について評価され、ステージの Yes パスまたは No パスのいずれかに進みます。 次のシナリオが考えられます。
  • John が午前 10 時 9 分にイベントを実行していた場合、ステージに入るとすぐに Yes パスに沿ってステージから抜けます。
  • John が午前 11 時にイベントを実行した場合、午前 11 時までステージで待機し、午前 11 時に Yes パスに沿って進みます。
  • John が午後 12 時にイベントを実行した場合、評価期間中にステージで指定された基準を満たさなかったため、午前 11 時 10 分までステージで待機した後、No パスに沿って進みます。

フローの Condition Split ステージでは、ユーザーはどのように評価されますか?

フローの Condition Split ステージでは、評価期間全体を通じて、最初のブランチで定義された条件に基づいてユーザーが評価されます。ユーザーがこれらの条件を満たした場合、Branch 1 に進みます。 条件を満たさない場合、MoEngage は評価期間の終了まで待機し、定義された期間内にユーザーが Branch 1 の条件に一致するかどうかを確認します。その後、MoEngage は条件分岐内の他のすべてのブランチを検討し、ユーザーは定義された条件に最初に一致したパスに進みます。 評価プロセスでは、条件分岐内のブランチに優先順位が付けられます。最初のブランチの優先度が最も高く、後続のブランチになるほど優先度は低くなります。デフォルトブランチの優先度は最も低くなります。 カートを放棄したユーザーをターゲットにするフロー (フローのオーディエンスは、商品をカートに追加したもののまだ購入していないユーザー) の例を考えてみます。この Flow には、次のブランチを持つ Conditional Split があります。
  1. Branch 1 - Electronics をカートのウィッシュリストに追加したユーザーを振り分けます。このブランチの優先度が最も高くなります。
  2. Branch 2 - Fashion アイテムをカートのウィッシュリストに追加したユーザーを振り分けます。このブランチの優先度は 2 番目に高くなります。
  3. Default ブランチ - その他すべてのユーザーを許可します。このステージは 10 分間評価し続けるよう定義されています。
  4. Has done event ステージ - Has Executed Product Purchase at least 1 time として定義され、このステージに入ったユーザーを 1 時間評価し続けます。
John は次のようなユーザーです。
  • 午前 10 時にフローに入る
  • 午前 10 時に条件分岐ステージに到達する
  • 10 分以内にいずれかのブランチに進むことができる
次のシナリオを考えてみます。
  • John が午前 10 時 5 分に Fashion を、午前 10 時 6 分に Electronics をウィッシュリストに追加した場合、Branch 1 の優先度が最も高いため、午前 10 時 6 分に Branch 1 に進みます。
  • John が午前 10 時 8 分に Fashion をウィッシュリストに追加した場合、Branch 1 の優先度が最も高いため、午前 10 時 10 分まで Branch 1 について評価されます。Branch 1 の条件を満たさないため、午前 10 時 10 分に Branch 2 と Default ブランチについて評価されます。Branch 2 の条件を満たしている場合、Branch 2 は 2 番目に優先度が高いため、午前 10 時 10 分に Branch 2 に進みます。
  • John が午前 10 時 10 分まで何もウィッシュリストに追加しなかった場合、Branch 1 の優先度が最も高いため、午前 10 時 10 分まで Branch 1 について評価されます。Branch 1 の条件を満たさないため、午前 10 時 10 分に Branch 2 と Default ブランチについて評価されます。Branch 2 の条件も満たさないため、午前 10 時 10 分に Default ブランチに進みます。

定期フローが、選択した Start Date に最初のキャンペーンを送信しなかったのはなぜですか?

Daily、Weekly、Monthly のフローでは、MoEngage は最初の送信日時を、Start Date と Send Time 以降で繰り返しパターンに一致する最も早い日時として計算します。必ずしも Start Date 当日になるとは限りません。選択した日がそのサイクル内ですでに過ぎている場合、MoEngage は遅れて送信するのではなく、最初の送信を次に一致するサイクルに移動します。 たとえば、Start Date が 7 月 22 日で、毎月 21 日に繰り返す Monthly フローは、7 月 21 日がすでに過ぎているため、7 月 21 日には送信されません。代わりに 8 月 21 日に送信されます。 これは想定どおりの動作です。公開前に計算された日付を確認するには、フローの最初のキャンペーンが送信される正確な日時を確認するにはどうすればよいですか? を参照してください。

フローの最初のキャンペーンが送信される正確な日時を確認するにはどうすればよいですか?

At fixed time で Daily、Weekly、または Monthly のスケジュールを設定すると、MoEngage はスケジュールパネルの下部に確認用の行を表示します。例: “Campaign will be next sent on Sat Aug 22 2026 11:30 PM.” この行には Start Date、Send Time、繰り返し設定が反映されるため、MoEngage が実際に送信する日時が常に表示されます。 定期フローについて計算された最初の送信日を示す確認用の行 公開前にこれを確認してください。スケジュールの不一致がユーザーに影響する前に検出する最も簡単な方法です。

Weekly フローの最初の送信が想定より早かったり遅かったりしたのはなぜですか?

Weekly フローの最初の送信は、Start Date 以降で Repeat on で選択した曜日が次に来る日です。この間隔は Repeat every の周期と一致する必要はありません。 たとえば、Start Date が水曜日で、Repeat on で月曜日と金曜日を選択したとします。最初の送信は、たとえ 1~2 日後であっても、この 2 つの曜日のうち次に来る方になります。“Repeat every N weeks” の周期は、その最初の送信から適用が始まります。最初の送信がどれだけ早く行われるかには影響しません。

オーディエンスが大規模なスケジュール (定期) フローにユーザーがエントリーしないのはなぜですか?

定期 (スケジュール) フローでは、1 回の実行で最大 1,000 万人のユーザーがエントリーします。ターゲットオーディエンスが 1,000 万人を超える場合、その上限を超えたユーザーはフローにエントリーしません。 より大規模なオーディエンスにリーチするには、オーディエンスをそれぞれ最大 1,000 万人のセグメントに分割し、別々のフローで実行してください。この上限の詳細については、フローの作成を参照してください。