受信トレイビジョン
インボックスビジョンを使用すると、さまざまなメール クライアントやモバイルデバイスの観点からメールs を表示できます。たとえば、暗いモードと明るいモードの違いをテストして、意図したとおりにメールのレンダリングを確認できます。
メール内容がユーザープロファイル情報などのテンプレート情報に依存している場合は、受信トレイ表示が機能しないことがあります。Braze テンプレート は、この機能のメールs を送信するときに空のユーザーを返します。
メールのリキッドにデフォルトを追加します。デフォルト sがなければ、偽陽性になったり、検査が失敗したりすることがあります。
考慮事項
通常、メール内容がユーザープロファイル情報などのテンプレート情報に依存している場合、受信トレイビジョンではメールは機能しません。これは、この機能を使用してメール s を送信すると、Braze テンプレート が空のユーザーを生成するためです。
これを解決するには、デフォルトまたは任意の値をメール メッセージのリキッドに追加してから、受信トレイビジョンを実行します。受信トレイ表示でテストを終了すると、元のメールが耳をアプリします。値が指定されていない場合、プレビューのレンダリングに失敗することがあります。
受信トレイビジョンでプレビューできるメール数には制限があります。これは、Inbox Vision のEmail Previews タブで監視できます。
プレビューs を表示するには、件名行と有効な送信ドメインを含めます。デスクトップとモバイルのレンダリングの違いに注意してください。プレビューsを使用して、意図したとおりにメール アプリイヤーを確認します。
受信トレイ表示でメールを確認するには:
- ドラッグアンドドロップエディターまたはHTMLメールエディターにアクセスする。
- エディタで、Preview & Test を選択します。
- [受信トレイビジョン] を選択します。
- [受信トレイビジョンを実行] を選択します。これには最大10分かかります。
- 次に、タイルを選択して、プレビューを詳細に表示します。これらのプレビューは、次のセクションにグループ化されています。Webクライアント、アプリケーションクライアント、およびモバイルクライアント。
- [受信トレイビジョンを実行] を選択します。これには、2 ～10 分かかることがあります。
受信トレイビジョンは、アボートロジックを含むメールメッセージをサポートしていません。これらのメールはスタティックコンテンツとしてレンダリングされるためです。
ユーザとしてプレビューする
ランダムユーザーとしてプレビューすると、受信トレイビジョンにはユーザー固有の設定や属性(名前や環境設定など)は保存されません。カスタムユーザーを選択した場合、受信トレイの表示プレビューは、特定のユーザーデータを使用するため、他のプレビューと異なる場合があります。
コード解析
コード解析では、潜在的なHTMLの問題が強調表示され、発生回数が表示され、サポートされていないHTML要素が示されます。
コード解析情報を見る
Inbox Visionタブでこの情報を検索するには、リストビューを選択します。一覧表示は、HTML メール テンプレート s でのみ使用できます。ドラッグアンドドロップテンプレートs では、代わりにプレビューs を使用して問題を解決します。
Brazeはメールが到着してからスクリーンショットを撮影するまで待機するため、コード解析は特定のクライアントのプレビューよりも早く耳元をアプリできます。
スパム検査
スパムテストでは、メールがスパムのフォルダまたは受信トレイに入るかどうかが予測されます。Brazeは、主要なスパム フィルター(IronPort、スパムAssassin、Barracuda)と主要なIサービスプロバイダー フィルターs(Gmail.com、Outlook.com)にわたってテストを実行します。
スパムテストの結果の表示
スパムの検査結果を確認するには:
- Inbox VisionセクションのSpam Testingタブを選択します。スパムテスト結果テーブルには、スパムフィルター名、ステータス、タイプがリストされている。
- これらの結果を確認し、メール キャンペーンを修正します。
- スパムテスト結果を再ロードするには、Re-run Testを選択します。
アクセシビリティ試験
アクセシビリティテストでは、メールのアクセシビリティに関する潜在的な問題が強調され、基準を満たさない要素が表示されます。Braze は、W3C によって開発された一連の国際的に認知された標準であるWebコンテンツアクセシビリティガイドライン(WCAG) に対してコンテンツを分析し、Webコンテンツをより利用しやすくします。
CDI の仕組み
受信トレイビジョンを実行すると、Braze はWCAG 2.2 AA ルールセット で一般的なアクセシビリティの問題(アルトテキストの欠落、カラーコントラストの不足、見出し構造の不適切など)を自動的に確認し、重要度を分類して、修正の優先順位付けに役立ちます。
アクセシビリティテストは、European Accessibility Actのようなお客様の規制または法律の遵守努力を支援するために使用することができます。ただし、お客様は、Brazeがアクセシビリティテストの使用がお客様の遵守義務を満たすかどうかに関して表明または保証を行わず、それに関して一切の責任を負いません。
アクセシビリティテスト結果の表示
アクセシビリティテストは、アクセシビリティテストタブで、合格、不合格、またはレビューが必要なルールごとに結果を生成します。Brazeは、WCAGの背後にある4つの原則であるPOUR(認識可能、操作可能、理解可能、ロバスト)を用いて、それぞれの規則を分類している。
POUR カテゴリー
Inbox Vision は、4 つの基本POUR の原則 の下で問題を分類します。知覚可能、操作可能、理解可能、堅牢です。
| 原則 | 定義 |
|---|---|
| 知覚可能 | 情報とユーザーインターフェイスコンポーネントは、ユーザーが認識できる方法でユーザーに表示できる必要があります。 ユーザーが提示されている情報を知覚できる必要があります (ユーザーの感覚すべてに対して知覚できないものであってはなりません)。 |
| 操作可能 | ユーザーインターフェースのコンポーネントとナビゲーションが操作可能である必要があります。 ユーザーがインターフェイスを操作できる必要があります (インターフェイスが、ユーザーが実行できないインタラクションを要求してはなりません)。 |
| 理解可能 | 情報とユーザーインターフェイスの操作が理解可能なものでなければなりません。 ユーザーは、ユーザーインターフェイスの操作と情報を理解できなければなりません (コンテンツや操作が、ユーザーが理解できないものであってはなりません)。 |
| 堅牢 | コンテンツは、支援技術を含むさまざまなユーザーエージェントが確実に解釈できるように十分に堅牢でなければなりません。 ユーザーは、技術の進歩に伴ってコンテンツにアクセスできる必要があります(技術やユーザーエージェントの進化に伴い、コンテンツにアクセスできるようにしておく必要があります)。 |
重大度レベル
Inbox Visionは、重要度別にアクセシビリティの問題を分類し、修復の優先順位付けに役立ちます。
| ステータス | 定義 |
|---|---|
| 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をすばやく消費できます。最初にメールに必要なすべての変更を行い、次に受信トレイビジョンを実行して、すべての変更が環境間でのメールのレンダリングにどのように影響するかをプレビューすることをお勧めします。
Braze は、実際のメール クライアントs を使用してテストを実行し、レンダリングがAC キュレートであることを確認します。クライアントに問題がある場合は、サポートチケットを開封します。
GitHub でこのページを編集