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分に相当する。したがって、夏時間開始日の午後3時UTCの属性更新前にキャンペーンを実行できる。条件を満たす属性がまだ存在しないため、それらのユーザーは除外される。再応募を無効にすると、前日に入力したユーザーは再応募できなくなる。その結果、その日のエントリ数はゼロになる。

これを避けるには、カスタム属性やイベントの更新が、キャンペーンのスケジュールされた送信時刻の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リクエストには、リアルタイムでメッセージにテンプレート化される追加データを含めることもできる。
Github   GitHub でこのページを編集
New Stuff!