Skip to content

よくある質問

この記事ではキャンペーンに関するよくある質問にお答えします。

マルチチャネルキャンペーンはどのように作成しますか?

マルチチャネルキャンペーンを作成するには、[メッセージング] > [キャンペーン] を選択します。次に [キャンペーンを作成] > [マルチチャネル] を選択します。ここから次のメッセージングチャネルを選択できます。コンテンツカード、メール、LINE、プッシュ通知、SMS/MMS/RCS、Webhook、またはWhatsApp。

マルチチャネルキャンペーンにコントロールグループを追加できますか?

いいえ。キャンペーンのコントロールグループは、メール A 対メール B などの単一チャネルメッセージングを対象としています。別の方法として、キャンバスを使用して、さまざまなチャネル、メッセージングコンテンツ、配信のタイミングをテストしてみてください。

キャンペーンのテストと最適化を開始するには、どのような方法がありますか?

まず多変量キャンペーンや、複数のバリアントでキャンバスを実行することをお勧めします。例えば、多変量キャンペーンを実行して、コピーや件名が異なる 1 つのメッセージをテストできます。複数のバリアントがあるキャンバスは、ワークフロー全体をテストするのに役立ちます。

キャンペーンの開封率が下がったのはなぜですか?

開封率の低さと技術的な問題は必ずしも相関しません。メールのクリッピングの問題からトラッキングピクセルが欠落している可能性があります。しかし、コンテンツやオーディエンス数の変化によって、メールを開封するユーザーが減っている可能性もあります。

キャンペーンオーディエンスはどのように評価されますか?

デフォルトでは、キャンペーンはエントリ時にオーディエンスフィルターをチェックします。遅延のあるアクションベースのキャンペーンでは、送信時にセグメント基準を再評価して、メッセージの送信時にユーザーが引き続きターゲットオーディエンスに含まれていることを確認するオプションがあります。

特定のキャンペーンまたはキャンバスのユニーク受信者数と送信数に差があるのはなぜですか?

1 つの可能性として、キャンペーンまたはキャンバスで再適格性がオンになっていることが考えられます。つまり、セグメントと配信設定の条件を満たすユーザーは、メッセージを複数回受け取ることがあります。再適格性がオンになっていない場合、送信数とユニーク受信者数の違いについては、ユーザーがプラットフォームをまたぐ複数のデバイスをプロファイルに関連付けていることが考えられます。

たとえば、iOS と Web の両方のプッシュ通知を持つキャンバスがある場合、モバイルデバイスとデスクトップデバイスの両方を使用する特定のユーザーは複数のメッセージを受信する可能性があります。

マルチチャネルキャンペーンでは、なぜコンバージョン数がユニークユーザー数を上回ることがあるのですか?

マルチチャネルキャンペーンでは、Braze はユーザーごとではなくチャネルごとにコンバージョンをカウントします。ユーザーがコンバージョンウィンドウ内で単一のコンバージョンアクションを実行した場合、Braze はそのコンバージョンを、ユーザーがメッセージを受信した各チャネルにアトリビューションします。これは、ユーザーが複数のチャネル（例えばメールとプッシュ通知の両方）でメッセージを受け取りコンバージョンした場合、Braze は各チャネルごとに1回ずつ、合計で複数のコンバージョンをカウントすることを意味します。その結果、コンバージョン総数は、コンバージョンしたユニークユーザー数を上回る場合があります。

例えば、マルチチャネルキャンペーンでユーザーにメールとプッシュ通知の両方を送信し、そのユーザーが両方のメッセージを受信後かつコンバージョンウィンドウ内で1つのコンバージョンアクションを実行した場合、Braze はこれを2つのコンバージョンとしてカウントします。1つはメールに、もう1つはプッシュ通知にアトリビューションされます。これは同じユーザーによる単一のアクションであるにもかかわらずです。

キャンペーンで使用しているセグメントよりも到達可能なユーザー群が小さいのはなぜですか?

グローバルコントロールグループを設定している場合、到達可能なオーディエンスのうち一定の割合がキャンペーンを受け取れなくなります。したがって、キャンペーンで同じセグメントを使用している場合でも、セグメントの到達可能ユーザー数がキャンペーンの到達可能ユーザー数よりも大きくなることがあります。

ローカルタイムゾーン配信で何が可能になりますか?

ローカルタイムゾーン配信では、ユーザーの個々のタイムゾーンに基づいてセグメントにメッセージングキャンペーンを配信できます。ローカルタイムゾーン配信を使用しない場合、キャンペーンは Braze の貴社のタイムゾーン設定に基づいてスケジュールされます。

例えば、ロンドンに拠点を置く企業が午後 12 時にキャンペーンを送信すると、アメリカ西海岸では午前 4 時にユーザーに届きます。特定の国でのみ利用可能なアプリの場合、これはリスクではない可能性があります。それ以外の場合は、早朝にユーザー群にプッシュ通知を送らないようにすることを強くお勧めします。

Braze はユーザーのタイムゾーンをどのように認識しますか?

Braze はユーザーのタイムゾーンをデバイスから自動的に判別します。これにより、タイムゾーンの精度を確保してユーザーを完全にカバーすることができます。ユーザー API を通じて作成されたユーザーや、タイムゾーンなしで作成されたユーザーは、SDK によってアプリで認識されるまで、デフォルトのタイムゾーンとして貴社のタイムゾーンが使用されます。

会社のタイムゾーンはダッシュボードにある会社の設定で確認できます。

Braze はローカルタイムゾーン配信のユーザーをいつ評価しますか?

Braze は、ユーザーのエントリ資格を以下のタイミングで評価します。

  • サモア時間（UTC+13）または夏時間中は UTC+14
  • スケジュールされた日の現地時間

ユーザーがエントリ適格性を得るには、両方のチェックに合格する必要があります。例えば、2021 年 8 月 7 日午後 2 時（現地時間）にキャンバスの開始がスケジュールされている場合、ニューヨーク在住のユーザーを対象とするには、適格性について以下のチェックが必要です。

  • 2021 年 8 月 6 日午後 9 時、ニューヨーク
  • 2021 年 8 月 7 日午後 2 時、ニューヨーク

ユーザーはローンチ前に 24 時間そのセグメントに属していなければなりません。最初のチェックでユーザーが対象外の場合、Braze は 2 回目のチェックを試みません。

例えば、UTC 午後 7 時に配信がスケジュールされているキャンペーンの場合、タイムゾーン（サモアなど）が特定されるとすぐにキャンペーン送信のキューイングを開始します。つまり、キャンペーンを送信するのではなく、メッセージを送る準備をしています。適格性をチェックしたときにどのフィルターにも一致しないユーザーは、ターゲットオーディエンスに含まれません。

別の例として、同じ日に送信予定の 2 つのキャンペーン（朝と夕方に 1 つずつ）を作成し、ユーザーが最初のキャンペーンをすでに受信している場合にのみ 2 番目のキャンペーンを受信できるようにフィルターを追加したとします。すると、ローカルタイムゾーン配信の場合、一部のユーザーは 2 番目のキャンペーンを受け取れない場合があります。これは、ユーザーのタイムゾーンが識別されたときに適格性をチェックするためで、スケジュールされた時刻がユーザーのタイムゾーンでまだ到来していない場合、ユーザーは最初のキャンペーンを受け取っていないことになり、2 番目のキャンペーンの対象にはなりません。

ローカルタイムゾーンのキャンペーンをスケジュールする方法を教えてください。

キャンペーンをスケジュールするときは、指定した時刻に送信することを選択してから、[ユーザーのローカルタイムゾーンにあわせてキャンペーンを送信] を選択します。

Braze では、すべてのローカルタイムゾーンキャンペーンを 24 時間前までにスケジュールすることを強く推奨しています。このようなキャンペーンは 1 日全体を通じて送信する必要があるため、24 時間前にスケジュールすることで、メッセージがセグメント全体に届くようになります。ただし、必要に応じて 24 時間以内にスケジュールすることもできます。Braze は、送信時刻から 1 時間以上が経過しているユーザーに対してはメッセージを送信しないことに注意してください。

たとえば、午後 1 時に現地時間午後 3 時のキャンペーンをスケジュールした場合、キャンペーンは現地時間が午後 3 時から午後 4 時の間のすべてのユーザーに即座に送信されますが、現地時間が午後 5 時のユーザーには送信されません。さらに、キャンペーンで選択する送信時刻は、会社のタイムゾーンでまだ到来していない時刻でなければなりません。

24 時間以内にスケジュールされているローカルタイムゾーンのキャンペーンを編集しても、メッセージのスケジュールは変更されません。ローカルタイムゾーンのキャンペーンを後で送信するよう（例えば午後 6 時ではなく午後 7 時）に編集した場合、元の送信時刻が選択されたときにターゲットセグメントにいたユーザーは、引き続き元の時刻（午後 6 時）にメッセージを受信します。ローカルタイムゾーンをより早い時刻（例えば午後 5 時ではなく午後 4 時）に送信するよう編集しても、キャンペーンは元の時刻（午後 5 時）にすべてのセグメントメンバーに送信されます。

ユーザーがキャンペーンの再適格性を許可されている場合は、元の時刻（午後 5 時）に再度受け取ることになります。ただし、それ以降のキャンペーンでは、メッセージは更新された時刻にのみ送信されます。

ローカルタイムゾーンのキャンペーンの変更はいつ有効になりますか?

ローカルタイムゾーンキャンペーンのターゲットセグメントには、セグメント全体への配信を保証するために、時間ベースのすべてのフィルターに少なくとも 48 時間の期間を含める必要があります。例えば、次のフィルターで 2 日目のユーザーをターゲットにするセグメントがあるとします。

  • 過去 1 日以上前に初めてアプリを使用
  • 過去 2 日間以内に初めてアプリを使用

ローカルタイムゾーン配信は、配信時刻とユーザーのローカルタイムゾーンに基づいて、このセグメントのユーザーを逃す可能性があります。これは、ユーザーのタイムゾーンが配信をトリガーする前に、ユーザーがセグメントを離れる可能性があるからです。

開始前のスケジュールされたキャンペーンにどのような変更を加えることができますか?

キャンペーンがスケジュールされた後、メッセージ送信のキューに入れる前に、メッセージ本文以外の部分を編集する必要があります。すべてのキャンペーンと同様に、開始後のコンバージョンイベントは編集できません。

予定されていたキャンペーンを更新しましたが、開始されなかったのはなぜですか?

これは、キャンペーンが更新された正確な時刻に開始される予定になっている場合に起こりえます。例えば、現在午後 3 時 10 分で、午後 3 時 10 分にキャンペーンを開始するように変更し、[キャンペーンの更新] を選択した場合、現在は午後 3 時 10 分を過ぎており、スケジュールされた開始時間が過ぎていることを意味します。キャンペーンを同じ時間にスケジュールするのではなく、[キャンペーン開始後すぐに送信] を選択してください。

スケジュールされたキャンペーンのメッセージがキューに入れられる前の「セーフゾーン」とは何ですか?

メッセージの変更は、次の期間内に行うことをお勧めします。

  • 1 回限りのスケジュールキャンペーン：スケジュールされた送信時刻までに編集する。
  • 定期的なスケジュールキャンペーン：スケジュールされた送信時刻までに編集する。
  • ローカル送信時刻キャンペーン：スケジュールされた送信時刻の 24 時間前までに編集する。
  • 最適送信時刻キャンペーン：キャンペーンの送信がスケジュールされている日付の 24 時間前までに編集する。

これらの推奨期間外でメッセージを変更すると、送信メッセージに更新が反映されないことがあります。たとえば、現地時間の午後 12 時に送信されるようにスケジュールされているキャンペーンの 3 時間前に送信時間を編集した場合、次の状況が発生する可能性があります。

  • Braze は、送信時刻を 1 時間以上過ぎたユーザーにはメッセージを送信しません。
  • 事前にキューに入れられたメッセージは、調整後の時刻ではなく、元のキューに入れられた時刻に送信される可能性があります。

変更が必要な場合は、現在のキャンペーンを停止することを推奨します（これによりキューに追加されたメッセージはすべてキャンセルされます）。その後、キャンペーンを複製し、必要に応じて変更を加え、新しいキャンペーンを開始します。すでに最初のキャンペーンを受け取ったユーザーは、必要に応じてこのキャンペーンから除外してください。タイムゾーン送信に対応できるように、キャンペーンのスケジュール時間を再調整してください。

夏時間の日に、毎日スケジュールされたキャンペーンに誰もエントリしなかったのはなぜですか?

夏時間（DST）の切り替え日には、時計が 1 時間進められるか戻されるかによって、毎日スケジュールされたキャンペーンは通常より最大 1 時間早く、あるいは遅く実行されることがあります。セグメントがカスタム属性やカスタムイベントに依存しており、そのタイムスタンプがスケジュールされた送信時刻から 1 時間以内に設定されている場合、キャンペーンが夏時間適用日に適格性を評価する時点で、該当ユーザーはまだ条件を満たしていない可能性があります。

例えば、ユーザーが通常 UTC 午後 3 時にカスタム属性の更新を受け取り、キャンペーンがニューヨーク時間（東部時間）の毎日午前 10 時 30 分に実行されるとします。ニューヨークが標準時（UTC-5）の場合、東部時間午前 10 時 30 分は UTC 午後 3 時 30 分に相当するため、キャンペーンは属性が記録された後に実行されます。ニューヨークが夏時間（UTC-4）に移行すると、東部時間午前 10 時 30 分は UTC 午後 2 時 30 分に相当するため、夏時間開始日には UTC 午後 3 時の属性更新前にキャンペーンが実行される可能性があります。条件を満たす属性がまだ存在しないため、それらのユーザーは除外されます。再適格性がオフになっている場合、前日にエントリしたユーザーは再エントリできなくなり、その結果、その日のエントリ数はゼロになります。

これを避けるには、カスタム属性やイベントの更新が、キャンペーンのスケジュールされた送信時刻の 1 時間以上前に行われるようにしてください。

キャンペーンにエントリするユーザー数が予想数と一致しないのはなぜですか?

キャンペーンにエントリするユーザー数は、オーディエンスやトリガーの評価方法によって、予想数と異なる場合があります。Braze では、オーディエンスはトリガーの前に評価されます（属性の変更トリガーを使用する場合を除きます）。これにより、トリガーアクションが評価される前にユーザーが選択したオーディエンスに含まれていない場合、そのユーザーはキャンペーンから脱落します。

キャンペーン分析ページにある「ユーザーデータの CSV エクスポート」と「メールアドレスの CSV エクスポート」のオプションの違いは何ですか?

[CSV エクスポート メールアドレス] を選択すると、メールアドレスのあるユーザーのデータのみがダウンロードされます。例えば、10 万人のユーザーセグメントがあるが、そのうちメールアドレスを持っているのは 5 万人だけだとします。この状態で [CSV エクスポート メールアドレス] をクリックすると、エクスポートされるデータは 5 万行のみとなります。一方、[CSV エクスポート ユーザーデータ] を選択すると、すべてのユーザーデータがエクスポートされます。

API 識別子でキャンペーンを検索できますか?

できます。[キャンペーン] ページのフィルター api_id:YOUR_API_ID を使用して、API 識別子でキャンペーンを検索します。詳細については、「キャンペーンの検索」を参照してください。

入力フィールドと表示されたテキストでは、空白がなぜ違って見えるのですか?

入力フィールドと表示されるテキストコンポーネントでは、CSS のスタイル設定のため、空白の扱いが異なります。デフォルトの white-space: normal CSS が適用されたテキストコンポーネントでは、連続する複数のスペースは表示時に単一のスペースに縮小されます。これはレンダリングされたテキストに対する標準的な HTML の動作です。

入力フィールドは複数のスペースを入力した通りに正確に保持します。正確なデータ入力のためには、スペースの配置を正確に確認し編集する必要があるからです。これは、複数のスペースを含むテキストが、入力フィールド（すべてのスペースが保持される場所）で表示される場合と、ダッシュボードの他の部分（CSS によって複数のスペースが圧縮される可能性がある場所）で表示される場合とでは、異なるように見える可能性があることを意味します。

例えば、入力フィールドに複数のスペースを含むキャンペーン名や UTM パラメータを入力すると、すべてのスペースがそのまま保持されます。ただし、同じテキストが検索結果やキャンペーンリスト、その他のテキストコンポーネントに表示される場合、CSS の空白処理により複数のスペースが単一のスペースとして表示されることがあります。

API キャンペーンと API トリガーキャンペーンの違いは何ですか?

API トリガーキャンペーンでは、キャンペーンのコピー、多変量テスト、再適格性ルールを Braze ダッシュボード内で管理しながら、独自のサーバーやシステムからそのコンテンツの配信をトリガーできます。これらのメッセージには、リアルタイムでメッセージにテンプレート化される追加データを含めることもできます。

API キャンペーンは、API を用いて送信されたメッセージを追跡するために使用されます。一般的なキャンペーンとは異なり、メッセージ、受信者、スケジュールを指定するのではなく、API コールに識別子を渡します。

アクションベースキャンペーンと API トリガーキャンペーンの違いは何ですか?

アクションベース

アクションベースの配信キャンペーンまたはイベントトリガーキャンペーンは、トランザクションベースまたは成果ベースのメッセージに非常に効果的で、ユーザーが特定のイベントを完了した後に送信をトリガーすることができます。

API トリガー

API トリガーやサーバートリガーのキャンペーンは、より高度なトランザクションを処理するのに適しており、自社のサーバーやシステムからキャンペーンコンテンツの配信をトリガーすることができます。メッセージをトリガーする API リクエストには、リアルタイムでメッセージにテンプレート化される追加データを含めることもできます。

「リクエストタイムアウト」エラーのサポートチケットを送信する際に、何を含めるべきですか?

キャンペーンまたはキャンバスの作成・編集中に「リクエストタイムアウト」エラーが発生し、Braze サポートに連絡する必要がある場合は、解決を迅速化するために以下の情報を含めてください。

  • 画面録画：エラーが表示される前に行った手順（ページ遷移を含む）の録画。
  • タイムスタンプとタイムゾーン：エラーが発生した正確な時刻とタイムゾーン。
  • ブラウザとバージョン：使用しているブラウザ（例：Chrome 120、Safari 17）と、別のブラウザでエラーの再現を試みたかどうか。
  • 再現手順：エラーをトリガーするアクションの明確な説明（関連する特定のキャンペーンまたはキャンバスの設定を含む）。
  • ネットワークログ（オプション）：ブラウザの開発者ツール（[ネットワーク] タブ）を開き、エラーを再現し、ネットワークログを HAR（HTTP Archive）ログとしてエクスポートします。これにより、サポートチームがどの API コールがタイムアウトしているかを特定できます。

設定した最大受信者数の制限が送信分析に反映されないのはなぜですか?

アクティブなキャンペーンに最大受信者数の制限を追加または変更した場合、以下の理由により送信分析に反映されないことがあります。

  • 開始後に制限を追加した場合：キャンペーンの開始時に最大受信者数の制限が設定されていない場合、制限を適用する前にすでにキューに入れられたメッセージはそのまま送信されます。制限は、変更を保存した後にキューに入れられた送信にのみ適用されます。
  • レート制限との相互作用：キャンペーンにレート制限も設定されている場合、メッセージはより長い時間枠にわたって配信される可能性があります。最大受信者数の制限は、メッセージがキューに入れられるときに評価され、配信時ではありません。キューにメッセージがある状態で制限を変更した場合、それらのメッセージには元の制限が適用されます。
  • 定期キャンペーン：定期キャンペーンの場合、スケジュールされた各送信は最大受信者数の制限を独立して評価します。送信間で制限を変更しても、以前の送信数は遡って調整されません。

不整合を避けるために、キャンペーンを開始する前に最大受信者数の制限を設定し、送信が進行中の間は変更しないようにしてください。
Github   GitHub でこのページを編集
New Stuff!