Skip to content

よくある質問

この記事では、キャンペーンに関するよくある質問への回答を提供します。

マルチチャネルキャンペーンを作成するにはどうすればよいですか？

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

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

いいえ、キャンペーンのコントロールグループは、メール A とメール B の比較など、単一チャネルのメッセージングを対象としています。代わりに、異なるチャネル、メッセージングコンテンツ、配信タイミングのテストにはキャンバスの使用をお試しください。

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

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

キャンペーンの開封率が低下したのはなぜですか？

開封率の低下は、必ずしも技術的な問題と相関しているわけではありません。メールのクリッピングにより、トラッキングピクセルが欠落する問題が発生している可能性があります。ただし、コンテンツやオーディエンスサイズの変更により、メールを開封するユーザーが減少している可能性もあります。

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

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

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

考えられる説明の1つは、キャンペーンまたはキャンバスで再エントリが有効になっていることです。これは、セグメントと配信設定の条件を満たすユーザーがメッセージを複数回受信できることを意味します。再エントリが有効になっていない場合、送信数とユニーク受信者数の差は、ユーザーがプラットフォームをまたいで複数のデバイスをプロファイルに関連付けていることが原因と考えられます。

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

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

マルチチャネルキャンペーンでは、Braze はユーザーごとではなくチャネルごとにコンバージョンをカウントします。ユーザーがコンバージョン期間内に1回のコンバージョンアクションを実行すると、Braze はそのコンバージョンをユーザーがメッセージを受信した各チャネルに帰属させます。つまり、ユーザーが複数のチャネル（例えば、メールとプッシュの両方）でメッセージを受信してコンバージョンした場合、Braze は各チャネルに1つずつ、複数のコンバージョンをカウントします。その結果、合計コンバージョン数がコンバージョンしたユニークユーザー数を超えることがあります。

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

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

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

ローカルタイムゾーン配信とは何ですか？

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

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

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

Braze はユーザーのデバイスからタイムゾーンを自動的に判定します。これにより、タイムゾーンの正確性とユーザーの完全なカバレッジが確保されます。User 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つは朝、もう1つは夕方）を作成し、最初のキャンペーンを既に受信したユーザーのみが2番目のキャンペーンを受信できるフィルターを追加したいとします。ローカルタイムゾーン配信では、一部のユーザーが2番目のキャンペーンを受信しない場合があります。これは、ユーザーのタイムゾーンが特定された時点で資格をチェックするため、スケジュールされた時間がそのユーザーのタイムゾーンでまだ到来していない場合、最初のキャンペーンを受信しておらず、2番目のキャンペーンの資格を満たさないためです。

最初のチェック時にはセグメントに含まれていたが、2回目のチェック時には含まれていないユーザーの視覚的な例として、以下のタイムラインを参照してください：

最初のチェック前にセグメントに入り、2回目のチェック前に離脱するユーザーのタイムライン。

タイムラインの説明
  1. ユーザー A が PST 午前6:59（サモア時間午前4:59）にセグメントに入ります。
  2. Braze がサモア時間午前7時にセグメントメンバーシップをチェックし、次の24時間以内にキャンペーンを受信する資格のあるユーザーを判定します。この時点でユーザー A はセグメントに含まれています。
  3. セグメントには24時間の期間があるため、ユーザー A は参加から24時間後の PST 午前6:59（サモア時間午前4:59）にセグメントを離脱します。
  4. ローカルタイムキャンペーンが PST 午前7時に送信されますが、ユーザー A は既にセグメントを離脱しています。

ローカルタイムゾーンキャンペーンをスケジュールするにはどうすればよいですか？

キャンペーンをスケジュールする際、指定した時間に送信することを選択し、ユーザーのローカルタイムゾーンでキャンペーンを送信を選択します。

Braze は、すべてのローカルタイムゾーンキャンペーンを24時間前にスケジュールすることを強くお勧めします。このようなキャンペーンは丸一日かけて送信する必要があるため、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時間以内のタイムスタンプを持つカスタム属性やイベントに依存している場合、DST の日にキャンペーンが資格を評価する時点で、それらのユーザーがまだ条件を満たしていない可能性があります。

例えば、ユーザーが通常 UTC 午後3時にカスタム属性の更新を受け取り、キャンペーンがニューヨーク（東部時間）の午前10:30に毎日実行されるとします。ニューヨークが標準時間（UTC-5）の間、東部時間午前10:30は UTC 午後3:30に相当するため、キャンペーンは属性がログされた後に実行されます。ニューヨークが夏時間（UTC-4）に移行すると、東部時間午前10:30は UTC 午後2:30に相当するため、春の時計が進む DST の日にはキャンペーンが UTC 午後3時の属性更新の前に実行される可能性があります。条件を満たす属性がまだ存在しないため、それらのユーザーはフィルタリングされます。再エントリが無効になっている場合、前日にエントリしたユーザーは再エントリできず、その日のエントリがゼロになります。

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

キャンペーンにエントリするユーザー数が予想と異なるのはなぜですか？

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

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

メールアドレスを CSV 形式でエクスポートオプションを選択すると、メールアドレスを持つユーザーのデータのみがダウンロードされます。例えば、100,000人のユーザーのセグメントがあり、そのうち50,000人のみがメールアドレスを持っている場合、メールアドレスを CSV 形式でエクスポートをクリックすると、エクスポートには50,000行のデータのみが含まれます。一方、ユーザーデータを CSV 形式でエクスポートを選択すると、すべてのユーザーデータがエクスポートされます。

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

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

入力フィールドと表示テキストで空白の表示が異なるのはなぜですか？

入力フィールドと表示テキストコンポーネントでは、CSS スタイリングにより空白の処理が異なります。デフォルトの white-space: normal CSS を持つテキストコンポーネントでは、連続する複数のスペースは表示時に1つのスペースに折りたたまれます。これはレンダリングされたテキストの標準的な HTML の動作です。

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

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

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

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

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

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

アクションベース

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

API トリガー

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

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

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

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

送信分析が設定した最大受信者数の制限と一致しないのはなぜですか？

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

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

不一致を避けるために、キャンペーンを起動する前に最大受信者数の制限を設定し、送信が進行中の間は変更しないようにしてください。

送信数が推定オーディエンスサイズよりも少ないのはなぜですか？

送信数が推定オーディエンスサイズよりも少なくなる要因はいくつかあります：

  • セグメントの再評価： 送信時に再評価するアクションベースまたはスケジュールされたキャンペーンでは、キャンペーンがキューに入れられた時点でセグメントに含まれていたユーザーが、メッセージが実際に送信される時点では条件を満たさなくなっている場合があります。
  • コントロールグループ： グローバルコントロールグループまたはキャンペーンレベルのコントロールグループが使用されている場合、オーディエンスの一部が配信から除外されます。
  • 配信タイミングと時間枠： ローカルタイムゾーンまたはスケジュールされたキャンペーンでは、ユーザーはエントリ時と送信時の両方で条件を満たす必要があります。特定のタイムゾーンのユーザーは配信時間枠の外に該当する場合があります。
  • レート制限： レート制限が適用されている場合、メッセージは時間をかけて配信され、一部の送信が遅延されるか、まだカウントに反映されていない場合があります。
  • メール配信フィルター： メールキャンペーンの場合、Braze はハードバウンスしたユーザー、メールの配信停止をしたユーザー、スパムとしてマークされたユーザー、プロファイルにメールアドレスがないユーザー、または必要なサブスクリプショングループに登録していないユーザーを除外します。これらのチェックは送信時に実行されるため、セグメントに含まれているユーザーでも、実際の送信数からは除外される可能性があります。
New Stuff!