バナー
バナーを使えば、ユーザーにパーソナライズされたメッセージングを作成することができ、同時にメールやプッシュ通知など、他のチャネルのリーチを広げることができる。アプリやWebサイトに直接バナーを埋め込むことができるので、自然な感覚でユーザーとエンゲージメントできる。

前提条件
バナーの有無はBrazeパッケージによって異なる。まずはアカウントマネージャーまたはカスタマーサクセスマネージャーにご相談を。
なぜバナーを使うのか?
バナーによって、マーケティングチームやプロダクトチームはアプリやWebサイトのコンテンツをダイナミックにパーソナライズすることができ、リアルタイムのユーザーの適格性や行動を反映させることができる。インラインでメッセージを持続的に表示し、ユーザーセッションの開始時に自動的に更新される、文脈に応じた非侵入型のエクスペリエンスを提供する。
バナーがアプリやWebサイトに統合された後、マーケターはドラッグ&ドロップの簡単なエディターを使ってバナーをデザインし、立ち上げることができるため、継続的な開発者の支援が不要になり、複雑さが軽減され、効率が向上する。
| ユースケース | 説明 |
|---|---|
| 発表 | 今後のイベントや方針変更などのお知らせをアプリ体験の最前線に置いておく。 |
| パーソナライズされたオファー | 各ユーザーの閲覧履歴、カート内容、サブスクリプション層、ロイヤルティステータスに基づいてパーソナライズされたプロモーションやインセンティブを表示する。 |
| 新規ユーザーのエンゲージメントを狙う | 新規ユーザーのオンボーディングフローとアカウントセットアップを案内する。 |
| 販売・プロモーション | 特集コンテンツ、トレンド商品、継続中のブランドキャンペーンを、ユーザー体験を中断させることなく、持続的かつ直接的にホームページで紹介する。 |
機能
バナーの特徴は以下の通りである:
- 簡単なコンテンツ構築:画像、テキスト、ボタン、メールキャプチャフォーム、カスタムコードなどをサポートする視覚的なドラッグ&ドロップエディターを使ってバナーを作成し、プレビューできます。
- フレキシブルな配置である:バナーを表示できるアプリケーションや Web サイト内の複数の場所を定義することで、特定のコンテキストやユーザーエクスペリエンスへの正確なターゲティングが可能になります。
- ダイナミックなパーソナライゼーション:Brazeの内蔵パーソナライゼーションツールとLiquidロジックを使用して、コンテンツが常に最新でパーソナライズされた状態に保たれるように、バナーは新しいユーザーセッションごとにダイナミックに更新される。
- ネイティブの優先順位付け:複数のバナーが同じプレースメントをターゲットにしている場合の表示優先度を設定することで、適切なメッセージを適切なタイミングでユーザーに届けることができる。
- カスタムHTMLのサポート:高度なカスタマイズや既存のWebスタイルとのシームレスな統合のためにカスタムHTMLブロックを組み込む。
横断幕について
配置 ID
バナープレイスメントとは、Braze SDKで作成したアプリやWebサイトの特定の場所にバナーを表示すること。
一般的な場所としては、ホームページのトップ、商品詳細ページ、チェックアウトフローなどがある。プレースメントが作成されると、バナーキャンペーンでバナーを割り当てることができる。
ワークスペースごとに作成できるプレースメント数に決まった制限はなく、経験に応じていくつでもプレースメントIDを作成できる。それぞれの配置は、ワークスペース内で一意でなければならない。1つのプレースメントIDは、同時に最大10キャンペーンまで参照できる。
バナーキャンペーンを開始した後にプレースメントIDを変更することは避ける。
バナーの優先順位
複数のキャンペーンが同じプレースメントIDを参照する場合、バナーは優先順位の高い、中、低い順に表示される。デフォルトでは、新しく作成されたバナーは「中」に設定されているが、バナーキャンペーンを作成または編集する際に優先順位を手動で設定することができる。
複数のバナーが同じ優先順位に設定されている場合、ユーザーが対象となる最新のバナーが最初に表示される。
配置のリクエスト
アプリやWebサイトでプレースメントを作成すると、アプリからBrazeにリクエストが送信され、各プレースメントのバナーメッセージがフェッチされる。
- 1回のリフレッシュ・リクエストにつき、最大10プレーまでリクエストできる。
- Brazeは、各プレイスメントについて、ユーザーが受け取る資格がある最優先のバナーを返す。
- 一度のリフレッシュで10個以上のプレースメントがリクエストされた場合、最初の10個だけが返され、残りは削除される。
例えば、アプリは更新リクエストで3つのプレースメントを要求するかもしれない:homepage_promo cart_abandonment seasonal_offer 。各リクエストは、その配置に最も関連するバナーを返す。
リフレッシュ要求のレート制限
古いSDKバージョン(Swift 13.1.0以前、Android 38.0.0以前、Web 6.1.0以前、React Native 17.0.0以前、Flutter 15.0.0以前)の場合、リフレッシュリクエストはユーザーセッションにつき1回のみ許可される。
新しい最小SDKバージョン(Swift 13.1.0+、Android 38.0.0+、Web 6.1.0+、React Native 17.0.0+、Flutter 15.0.0+)を使用している場合、過剰なポーリングを防ぐために、リフレッシュリクエストはトークンバケットアルゴリズムによってコントロールされる:
- 各ユーザーセッションは、5つのリフレッシュ・トークンで始まる。
- トークンは180秒(3分)に1個の割合で補充される。
requestBannersRefresh 、トークンを1回消費する。トークンがないときに更新を試みると、SDKはリクエストを行わず、トークンが補充されるまでエラーを記録する。これは、セッション中やイベントトリガーによる更新の際に重要である。ダイナミックな更新(例えば、ユーザーが同じページでアクションを完了した後)を実装するには、カスタムイベントが記録された後にrefreshメソッドを呼び出すが、ユーザーが別のバナーキャンペーンの資格を得る前に、Brazeがイベントを取り込んで処理するために必要な遅延に注意すること。
メッセージング
バナーメッセージはHTMLコンテンツとしてアプリやWebサイトに配信され、通常はiframe内にレンダリングされる。これにより、バナーがデバイス間で一貫してレンダリングされるようになり、スタイルやスクリプトを他のコードから分離することができる。
Iframeは、コードベースの変更を必要とせず、ダイナミックなパーソナライズされたコンテンツ更新を可能にする。各iframeは、キャンペーンターゲティングとパーソナライゼーションロジックを使用して、各ユーザーセッションのHTMLを取得し、表示する。
寸法とサイズ
バナーの寸法とサイズについて知っておくべきことは以下の通りだ:
- コンポーザーでは、さまざまなディメンションのバナーをプレビューできますが、その情報は保存されず、SDK に送信されません。
- HTML は、レンダリングされるコンテナの全幅を使用します。
- 固定ディメンションの要素を作成し、そのディメンションをコンポーザーでテストすることをお勧めします。
制限事項
各ワークスペースは、最大200のアクティブなバナーキャンペーンをサポートすることができる。この制限に達した場合、新しいキャンペーンを作成する前に、既存のキャンペーンをアーカイブするか非アクティブにする必要がある。
また、バナーメッセージは以下の機能をサポートしていない:
- キャンバス統合
- API トリガーキャンペーンとアクションベースのキャンペーン
- コネクテッドコンテンツ
- プロモーションコード
- ユーザーコントロールによる解雇
catalog_items:rerenderタグを使用している。
次に何をすべきかの優先順位を決める手助けをしたい?連絡先banners-feedback@braze.com.
次のステップ
バナーについて理解したところで、次のステップに進む:
GitHub でこのページを編集