受信トレイビジョン
受信トレイ表示では、プレビューに含めるメール クライアントをカスタマイズできます。GmailやYahooのような人気クライアントの一覧から選択するか、あなたのオーディエンスに合わせた独自の一覧を構築しましょう。
受信トレイ表示を使用するには、メールに件名を含める必要があります。メールがどのようにデスクトップとモバイルデバイスで異なるレンダリングを行うかを検討します。これらのプレビューs を確認すると、メール アプリが意図したとおりに耳に入っていることを確認できます。
各企業は、すべてのワークスペース s 間で共有される1 カレンダ月あたり750 プレビューを持ちます。それぞれのプレビューは、メール アプリが特定のメール クライアントと機器の組合せでどのように耳をすますかを示しています。たとえば、Gmail.com Chrome | Windows 10 は1 つのプレビューとしてカウントされます。プレビューのキャパシティに達したら、プレビューのキャパシティが再設定されるまで翌月まで待機する必要があります。この機能について不明な点がある場合は、アカウントマネージャーにお問い合わせください。
考慮事項
通常、メール内容がユーザープロファイル情報などのテンプレート情報に依存している場合、受信トレイビジョンではメールは機能しません。これは、この機能を使用してメール s を送信すると、Braze テンプレート が空のユーザーを生成するためです。
これを解決するには、デフォルトまたは任意の値をメール メッセージのリキッドに追加してから、受信トレイビジョンを実行します。受信トレイ表示でテストを終了すると、元のメールが耳をアプリします。値が指定されていない場合、プレビューのレンダリングに失敗することがあります。
受信トレイビジョンでプレビューできるメール数には制限があります。これは、Inbox Vision のEmail Previews タブで監視できます。
メールのプレビュー
Inbox Visionでメールメッセージをテストするには、次のようにする:
- ドラッグアンドドロップエディターまたはHTMLメールエディターにアクセスする。
- エディタで、Preview & Test を選択します。
- [受信トレイビジョン] を選択します。
- プレビュー 設定 s セクションでは、「選択を記憶する」を有効にすることで、プレビューをレンダリングするメール クライアントs を選択し、このグループを将来の実行のために保存できます。それ以外の場合は、s を最も人気のあるプレビューs の上位20 にBraze デフォルトします。これらのプレビューs はクライアントs でグループ化されます。

- [受信トレイビジョンを実行] を選択します。これには、2 ~10 分かかることがあります。

- 必要に応じて、テンプレートを変更します。
- 更新されたプレビューを表示するには、[テストを再実行] を選択します。
メールにアボートロジックが含まれている場合、これらのメールはスタティックコンテンツとしてレンダリングされるため、受信トレイビジョンはサポートされません。
スパム検査
スパムテストでは、メールがスパムのフォルダに入るか、顧客の受信トレイに入るかを予測しようとします。スパムテストは、IronPort、SpamAssassin、Barracudaなどの主要なスパムフィルタや、Gmail.com 、Outlook.com などの主要なインターネットサービスプロバイダ(ISP)フィルタで実行される。

スパムテストの結果の表示
スパムテストの結果を確認するには、次の手順を実行します。
- Inbox VisionセクションのSpam Testingタブを選択します。スパムテスト結果テーブルには、スパムフィルター名、ステータス、タイプがリストされている。
- これらの結果を確認し、メール キャンペーンを修正します。
- スパムテスト結果を再ロードするには、Re-run Testを選択します。
アクセシビリティ試験
受信トレイビジョンのアクセシビリティテストでは、メールに含まれている可能性があるアクセシビリティの問題がハイライトされ、どの要素がアクセシビリティ基準を満たしていないかがわかります。一部のWeb コンテンツアクセシビリティガイドライン(WCAG) に対してメールコンテンツを分析します。WCAG は、World Wide Web Consortium (W3C) が作成し、国際的に認知された技術標準のセットで、多くの人にとってアクセスしやすい Web コンテンツを作成するためのものです。
CDI の仕組み
Inbox Vision テストを実行すると、ツールはWCAG 2.2 AA ルールセット で一般的なメールアクセシビリティの問題(alt テキストの欠落、カラーコントラストの不足、見出し構造の不適切など)を自動的にチェックし、各問題の重大度を分類して、修正の優先順位付けに役立ちます。
アクセシビリティテストは、European Accessibility Actのような顧客の規制または法律の遵守努力を支援するために使用することができるが、顧客は、アクセシビリティテストの使用が顧客の遵守義務を満たすか否かに関して、ブレーズが表明または保証を行わないことを認識し、それに関して一切の責任を負わない。
アクセシビリティテスト結果の表示
アクセシビリティテストは、アクセシビリティテストタブで、合格、不合格、またはレビューが必要なルールごとに結果を生成します。各ルールは、WCAG の4つの主な原則であるPOUR (知覚可能、操作可能、理解可能、堅牢) を使用して分類されます。
POUR カテゴリー
問題は、4つの基本 POUR 原則に分類されます。これは、知覚可能、操作可能、理解可能、堅牢です。各原理は、アクセシブルなデザインの異なる側面に対応しています。
| 原則 | 定義 |
|---|---|
| 知覚可能 | 情報とユーザーインターフェイスコンポーネントは、ユーザーが認識できる方法でユーザーに表示できる必要があります。 ユーザーが提示されている情報を知覚できる必要があります (ユーザーの感覚すべてに対して知覚できないものであってはなりません)。 |
| 操作可能 | ユーザーインターフェースのコンポーネントとナビゲーションが操作可能である必要があります。 ユーザーがインターフェイスを操作できる必要があります (インターフェイスが、ユーザーが実行できないインタラクションを要求してはなりません)。 |
| 理解可能 | 情報とユーザーインターフェイスの操作が理解可能なものでなければなりません。 ユーザーは、ユーザーインターフェイスの操作と情報を理解できなければなりません (コンテンツや操作が、ユーザーが理解できないものであってはなりません)。 |
| 堅牢 | コンテンツは、支援技術を含むさまざまなユーザーエージェントが確実に解釈できるように十分に堅牢でなければなりません。 ユーザーは、技術の進歩に伴ってコンテンツにアクセスできる必要があります(技術やユーザーエージェントの進化に伴い、コンテンツにアクセスできるようにしておく必要があります)。 |
重大度レベル
受信トレイビジョンでは、修復作業の優先順位付けを支援するため、重大度別にアクセシビリティの問題が分類されます。
| ステータス | 定義 |
|---|---|
| Critical | 障害を持つユーザーのコンテンツや機能へのアクセスをブロックできる問題。これらは最も重大であり、修正対象として優先される必要があります。 |
| 重大 | 著しい障壁が生じる可能性はあるが、アクセスを完全にブロックするとは限らない問題。これらの問題は速やかに対処する必要があります。 |
| 中程度 | 障害のあるユーザーに何らかの問題を引き起こす可能性があるが、アクセスを完全にブロックする可能性は低いと思われる問題。 |
| 軽微 | アクセシビリティへの影響が比較的小さく、ごくわずかな不都合しか生じない問題。 |
| レビューが必要 | 問題があるかどうかを検出できません。これは、テキストが背景イメージ上に配置されているためにコントラスト比を判断できない場合に発生します。自動的に決定できないため、手動で確認する必要があります。 |
| 合格 | WCAG A、AA、またはアクセシビリティのベストプラクティスに合格しました。 |
現在、メールのドラッグ&ドロップエディターでは、ドキュメント <title> 要素の設定はサポートされていません。その結果、アクセシビリティスキャナは常にこのチェックに失敗します。
今後の改善のため、この制限を追跡しています。これがワークフローまたはユーザーに影響する場合は、 フィードバック を共有することで、最も影響の大きい修正を優先順位付けできます。
自動アクセシビリティテストについて
自動アクセシビリティテストは、WCAG Level AA 標準に基づくalt テキストの欠落や低色コントラストなどの一般的な問題をキャッチするのに役立ちます。これは、より包括的なメッセージを構築するための強力な出発点です。
しかし、オートメーションはすべてを捕まえることはできない。いくつかの問題は、フォーカス順序が意味を持つかどうか、リンクやボタンが明確にラベル付けされているかどうか、または指示に従うことが容易かどうか、人間の目のようなものを必要とする。これらのチェックは、最終的な評決ではなく、診断ツールとして考えてください。フラグが設定された問題を手動で確認し、何かが「要レビュー」とマークされている場合は最善の判断を使用することをお勧めします。
追加のサポートのために、Braze でのアクセシビリティは、以下を含む、すべてのユーザーのコンテンツをより使いやすくするための実用的なヒントを共有します。
自動テストと思慮深い手動レビューを組み合わせると、より多くの問題が見つかり、すべてのユーザーのより良い体験ができるようになります。
ベストプラクティス
メール サブスクライバー一覧を確認する
メール インサイト s ダッシュボード を参照して、サブスクライバーが係合している最も一般的なデバイスタイプとプロバイダを確認します。ブラウザ、デバイスモデルなど、より細かいものが必要な場合は、Currents データまたはQuery Builder を利用して、ユーザーの最近のメール エンゲージメントに関するこのレベルの詳細を取得できます。
それ以外の場合は、業界およびエキスパートの全般的なデータに基づいて上位20 プレビューにBraze デフォルトします。これは、サブスクライバーがメールs に関与している大部分を対象としています。データアナリシスが他の一般的なプレビューsを指している場合は、受信トレイビジョンを実行するたびにプレビューs のデフォルト集合を定義できます。
意味のあるプレビューと影響を受けるプレビューの選択
もしあなたの事業が主にアメリカにあるなら、GMX.deのような国際的なプレビューsのように、名目上のユーザーsだけで使われる特別なsがあるかもしれません。影響の大きい受信トレイのサブスクライバーには優先順位を付けて最適化し、影響の大きい受信トレイにはプレビューs を予約することをお勧めします。
特定のプレビューに影響する修正を行う場合は、影響を受けるプレビューのみを選択して、未使用のプレビューs を消費しないようにしてください。
最終メール版の受信トレイビジョンの実行
メールが本番稼働可能か、またはそれに近づいたときに受信トレイビジョンを実行することをお勧めします。これにより、生成されるプレビューの個数を減らすことができます。これは、メールが最終的にユーザーs に送信される準備が整うまでに、複数回の反復を繰り返すためです。
インボックスビジョンを1つのエディットまたは変更を行うたびに実行すると、プレビューsをすばやく消費できます。最初にメールに必要なすべての変更を行い、次に受信トレイビジョンを実行して、すべての変更が環境間でのメールのレンダリングにどのように影響するかをプレビューすることをお勧めします。
これらのプラクティスは、重複または未使用のプレビューを最小限に抑え、影響の大きいクライアント プレビューに焦点を当てることで、プレビューの節約に役立ちます。
GitHub でこのページを編集