受信トレイビジョン
受信トレイビジョンを使えば、様々なメールクライアントやモバイル端末の視点からメールを確認できる。例えば、ダークモードとライトモードの違いをテストして、メールが意図した通りに表示されることを確認できる。
メールの内容がユーザープロファイルデータなどのテンプレート情報に依存している場合、受信トレイ Visionは機能しない可能性がある。この機能でメールを送信する際、Brazeは空のユーザーをテンプレート化する。
メールメッセージ内の任意のLiquidにデフォルト値を追加する。デフォルト設定がない場合、誤検知が発生したり、テストが失敗する可能性がある。
考慮事項
一般的に、メールの内容がユーザープロファイル情報などのテンプレート情報に依存している場合、そのメールはInbox Visionでは機能しない。これは、この機能を使ってメールを送信する際に、Brazeが空のユーザーをテンプレート化するためだ。
Inbox Visionを実行する前に、メール本文のLiquidにデフォルト値や任意の値を追加することで解決できる。Inbox Visionでのテストを終えると、元のメールメッセージが表示される。値が指定されていない場合、テストはプレビューを正常に表示できない可能性がある。
御社では、Inbox Visionでプレビューできるメールの数に制限がある。この内容は受信トレイの「メールプレビュー」タブで確認できる。
件名と有効な送信ドメインを含めることで、プレビューを表示できる。デスクトップとモバイルの表示の違いに注意せよ。プレビューを使って、メールが意図した通りに表示されることを確認する。
Inbox Visionでメールメッセージをテストするには:
- ドラッグアンドドロップエディターまたはHTMLメールエディターにアクセスする。
- エディタで「プレビュー」と&「テスト」を選択せよ。
- [受信トレイビジョン] を選択します。
- [受信トレイビジョンを実行] を選択します。これは最大で10分かかる。
- 次に、タイルを選択して、プレビューを詳細に表示します。これらのプレビューは、次のセクションにグループ化されています。Webクライアント、アプリケーションクライアント、およびモバイルクライアント。

- [受信トレイビジョンを実行] を選択します。これには、2 ~10 分かかることがあります。
受信トレイ Visionは、中止ロジックを含むメールメッセージをサポートしない。これらのメールは静的コンテンツとして表示されるからだ。
ユーザとしてプレビューする
ランダムユーザーとしてプレビューする場合、Inbox Visionはユーザー固有の設定や属性(名前や設定など)を保存しない。カスタムユーザーを選択すると、受信トレイのプレビューは他のプレビューと異なる場合がある。これは特定のユーザーデータを使用しているためだ。
コード解析
コード分析は潜在的なHTMLの問題を指摘し、発生回数を表示し、サポートされていないHTML要素を示す。
コード解析情報を見る
この情報は、受信トレイの「表示」タブで「リスト表示」を選択すると確認できる。リスト表示はHTMLメールテンプレートでのみ利用可能だ。ドラッグ&ドロップ式テンプレートでは、代わりにプレビューを使って問題を解決するのだ。

特定のクライアントでは、コード分析がプレビューより速く表示されることがある。これはBrazeがメールが届くまで待ってからスクリーンショットを撮るためだ。
スパム検査
スパムテストは、メールがスパムフォルダに入るか受信トレイに入るかを予測する。Brazeは主要なスパムフィルター(IronPort、SpamAssassin、Barracuda)と主要なISPフィルター(Gmail.com、Outlook.com)でテストを実行する。
スパムテストの結果の表示
スパムテストの結果を確認するには:
- Inbox VisionセクションのSpam Testingタブを選択します。スパムテスト結果テーブルには、スパムフィルター名、ステータス、タイプがリストされている。
- これらの結果を確認し、メールキャンペーンに必要な調整を行え。
- スパムテスト結果を再ロードするには、Re-run Testを選択します。
アクセシビリティ試験
アクセシビリティテストは、メール内の潜在的なアクセシビリティ問題を指摘し、どの要素が基準を満たしていないかを示す。Brazeは、選択されたWebコンテンツアクセシビリティガイドライン(WCAG)に対してコンテンツを分析する。これはW3Cが開発した国際的に認められた一連の基準であり、Webコンテンツをよりアクセシブルにすることを目的としている。
仕組み
Inbox Visionを実行すると、Brazeは自動的にWCAG 2.2 AA基準における一般的なアクセシビリティ問題(代替テキストの欠如、色のコントラスト不足、見出し構造の不備など)をチェックし、深刻度を分類して修正の優先順位付けを支援する。
アクセシビリティテストは、欧州アクセシビリティ法などの規制や法令に対する顧客のコンプライアンス対応を支援するために使用される可能性がある。ただし、顧客は、アクセシビリティテストの利用が顧客のコンプライアンス義務を満たすかどうかについて、Brazeが一切の表明または保証を行わないこと、およびこれに関連する一切の責任を否認することを認める。
アクセシビリティテスト結果の表示
アクセシビリティテストでは、各ルールについて「合格」「不合格」「再確認が必要」の結果がアクセシビリティテストタブに表示される。Brazeは各ルールを、WCAGの基盤となる4原則であるPOUR(知覚可能、操作可能、理解可能、堅牢)を用いて分類する。
POUR カテゴリー
受信トレイ・ビジョンは、問題を4つの基礎的なPOUR原則に基づいて分類する:知覚可能、操作可能、理解可能、堅牢です。
| 原則 | 定義 |
|---|---|
| 知覚可能 | 情報とユーザーインターフェイスコンポーネントは、ユーザーが認識できる方法でユーザーに表示できる必要があります。 ユーザーが提示されている情報を知覚できる必要があります (ユーザーの感覚すべてに対して知覚できないものであってはなりません)。 |
| 操作可能 | ユーザーインターフェースのコンポーネントとナビゲーションが操作可能である必要があります。 ユーザーがインターフェイスを操作できる必要があります (インターフェイスが、ユーザーが実行できないインタラクションを要求してはなりません)。 |
| 理解可能 | 情報とユーザーインターフェイスの操作が理解可能なものでなければなりません。 ユーザーは、ユーザーインターフェイスの操作と情報を理解できなければなりません (コンテンツや操作が、ユーザーが理解できないものであってはなりません)。 |
| 堅牢 | コンテンツは、支援技術を含むさまざまなユーザーエージェントが確実に解釈できるように十分に堅牢でなければなりません。 ユーザーは、技術の進歩に伴ってコンテンツにアクセスできる必要があります(技術やユーザーエージェントの進化に伴い、コンテンツにアクセスできるようにしておく必要があります)。 |
重大度レベル
Inbox Visionはアクセシビリティの問題を深刻度別に分類し、修正の優先順位付けを支援する。
| ステータス | 定義 |
|---|---|
| Critical | 障害を持つユーザーのコンテンツや機能へのアクセスをブロックできる問題。これらは最も重大であり、修正対象として優先される必要があります。 |
| 重大 | 著しい障壁が生じる可能性はあるが、アクセスを完全にブロックするとは限らない問題。これらの問題は速やかに対処する必要があります。 |
| 中程度 | 障害のあるユーザーに何らかの問題を引き起こす可能性があるが、アクセスを完全にブロックする可能性は低いと思われる問題。 |
| 軽微 | アクセシビリティへの影響が比較的小さく、ごくわずかな不都合しか生じない問題。 |
| レビューが必要 | 問題があるかどうかを検出できません。これは、テキストが背景イメージ上に配置されているためにコントラスト比を判断できない場合に発生します。自動判定できないため、手動で確認しなければならない。 |
| 合格 | WCAG A、AA、またはアクセシビリティのベストプラクティスに合格しました。 |
ドラッグ&ドロップエディタはドキュメント<title>要素の設定をサポートしていないため、アクセシビリティスキャナはこのチェックを常に失敗する。
この制限は今後の改善のためにトラッキングされている。これが業務フローやユーザーに影響を与える場合、フィードバックを共有してほしい。そうすれば影響の大きい修正を優先できるからだ。
自動アクセシビリティテストについて
自動アクセシビリティテストは、WCAG Level AA 標準に基づくalt テキストの欠落や低色コントラストなどの一般的な問題をキャッチするのに役立ちます。これは、より包括的なメッセージを構築するための強力な出発点です。
しかし、オートメーションはすべてを捕まえることはできない。いくつかの問題は、フォーカス順序が意味を持つかどうか、リンクやボタンが明確にラベル付けされているかどうか、または指示に従うことが容易かどうか、人間の目のようなものを必要とする。これらのチェックは、最終的な評決ではなく、診断ツールとして考えてください。フラグが設定された問題を手動で確認し、何かが「要レビュー」とマークされている場合は最善の判断を使用することをお勧めします。
追加のサポートのために、Braze でのアクセシビリティは、以下を含む、すべてのユーザーのコンテンツをより使いやすくするための実用的なヒントを共有します。
自動テストと思慮深い手動レビューを組み合わせると、より多くの問題が見つかり、すべてのユーザーのより良い体験ができるようになります。
ベストプラクティス
メール購読者リストを確認する
メールインサイトダッシュボードを参照し、サブスクライバーが最もよく利用しているデバイスタイプとプロバイダーを特定する。より詳細な情報、例えばブラウザやデバイスモデルなどが必要な場合、Currentsデータやクエリビルダーを活用すれば、ユーザーの最近のメールエンゲージメントに関するこのレベルの詳細情報を取得できる。
そうでない場合、Brazeは業界全体と専門家のデータに基づいて上位20件のプレビューをデフォルトで表示する。これはサブスクライバーがメールとエンゲージメントを行う場所の大部分をカバーしている。データ分析の結果、他のより人気のあるプレビューが示された場合、Inbox Visionを実行するたびにデフォルトのプレビューセットを定義できる。
意味のあるプレビューと影響を受けたプレビューを選択する
もしあなたのビジネスが主に米国を拠点としているなら、国際プレビューのような特定のGMX.deプレビューは、ごく少数のユーザーしか利用していない可能性がある。サブスクライバーに大きな影響力を持つ受信トレイを優先し最適化することを推奨する。プレビューは影響力の高い受信トレイに予約しておくべきだ。
特定のプレビューに影響する修正を行う際は、影響を受けるプレビューのみを選択し、未使用のプレビューを消費しないように注意せよ。
最終版のメールで受信トレイビジョンを実行する
メールメッセージが本番環境で使える状態、あるいはそれに近い状態になった時点で、Inbox Visionを実行することを提案する。これにより、生成されるプレビューの数を減らすことができる。メールはユーザーに送信される前に、最終決定されるまで何度も修正を重ねるからだ。
受信トレイビジョンを、編集や変更のたびに毎回実行すると、プレビューがすぐに消費されてしまう。まずメールに必要な変更をすべて加え、その後Inbox Visionを実行して、変更が各環境でのメール表示のプレビューをどのように行うかを確認することをお勧めする。
Brazeは実際のメールクライアントでテストを実行し、表示が正確であることを保証する。クライアントに問題が繰り返し発生する場合は、サポートチケットを開封。
GitHub でこのページを編集