ドメインを数える前にビジネス上の質問を定義する
請求と運用では、同じ「ドメイン」という言葉で異なるものを説明することがよくあります。請求システムは契約単位をカウントし、運用インベントリは検証済みのドメインをリストし、レポート システムはトラフィックで観察されたドメインを記録します。どれか 1 つのシステムが間違っていなくても、これらの合計は異なる可能性があります。調整は、メトリック、その時間枠、およびカウントされる単位を定義することから始まり、すべての合計を強制的に一致させるのではなく、それぞれの違いを説明します。
Azure のマルチテナント ID ガイダンス ID と認可を商用ライセンスから区別し、アプリケーションまたは専用システムでライセンス ロジックを管理することを推奨します。この区別は直接関係しています。認証されたユーザーまたは構成されたドメインは、請求可能な資格を自動的に確立しません。この原稿は調整方法を提案するものであり、 EmailAuth特定の請求モデル、在庫 API、または分析機能を実装するとは主張しません。
安定した顧客とドメイン関係を確立する
各システムが提供する、承認された顧客 ID、運用テナント ID、請求先アカウント参照、およびドメイン インベントリ ID を記録します。表示名を安定したキーとは別にしてください。顧客は、組織の名前を変更したり、複数のドメインを使用したり、別個の運用テナントやトレーニング テナントを設定したりできます。ドメインは、時間の経過とともに顧客関係の間を移動することもあります。調整には、現在の文字列の一致のみではなく、発効日と所有権の履歴が必要です。
RFC 7643 サービスプロバイダーのリソース識別子と、そのアイデンティティスキーマ内の外部から提供された相関識別子を区別します。これは、識別子の役割が重要である理由の一例であり、SCIM がドメインの課金を定義するという主張ではありません。提案されたマッピングにも同じ注意を払ってください。どのシステムが各キーを所有しているのか、またどのフィールドが単にシステム間でレコードを関連付けているのかを特定します。電子メールのサフィックスや行を最後に編集した人から顧客の所有権を推測しないでください。
再現可能なメトリクス定義を作成する
報告される合計ごとに、カウントされるエンティティ、包含基準、除外基準、ステータス ルール、有効時間、および重複排除方法を定義します。 「月末のアクティブな顧客ドメイン」には、アクティブ、顧客、ドメインの正確な意味が必要です。保留中の検証、一時停止されたテナント、サブドメイン、エイリアス、試用アカウント、または最近廃止された記録は含まれますか?これらは承認すべきビジネス定義であり、仮定すべき技術的な事実ではありません。各レポートに使用されるルールのバージョンを保持します。
ドメインのインベントリ数と、観測された送信者のカバレッジを区別します。構成されたドメインでは、その期間中にトラフィックが生成されない場合がありますが、レポート ソースでは認識されない送信者または過去の送信者が観察される可能性があります。認証レポートは、必ずしもすべてのメッセージまたはすべての構成済みサービスの完全な調査であるとは限りません。有用なメトリクスは、観測結果の欠如をドメインが未使用であること、または請求されるべきではないことの証拠として扱うのではなく、利用可能なソースと適用範囲の警告を示します。
調整調整の前に生の合計を保持する
承認された範囲とタイムスタンプの下で各ソースの元の合計を保持します。次に、相違点を説明する調整カテゴリ (一致しない顧客マッピング、保留中のアクティブ化、廃止のタイミング、重複した表現、履歴の再割り当て、ソースのラグ、または真の未解決の例外) を表示します。ダッシュボードの見た目に一貫性を持たせるために、未加工の合計を黙って変更しないでください。調整記録は、最終的な数値を説明可能かつ再現可能にするものです。
ここではソース抽出物は収集されませんでした。承認された実装では、ソース バージョンを保持するか、行の選択に使用される識別子とクエリ ロジックをエクスポートします。作業データセット内の個人データと財務データを最小限に抑えます。請求先アカウントの参照は、支払い資格情報や不要なトランザクションの詳細を運用レポートにコピーすることなく、承認された内部識別子で表すことができます。調整の目的は、より広範な顧客データの共有を許可するものではありません。
ドメインと送信者のカバレッジを個別にモデル化する
RFC 9989 ドメインを評価し、 アライメント 電子メール認証における関係。これは、プラットフォームの請求可能なドメイン単位を定義するものではありません。 1 つの可視 From ドメインを持つ顧客は複数の送信サービスを使用することができますが、1 つのサプライヤーが多数の顧客ドメインに送信することができます。したがって、ドメイン数は送信者レベルの運用ドリルダウンに代わることはできません。データ ディクショナリではこれらのディメンションを区別してください。
RFC 9990 定義する DMARC 集約レポートとそのレポート検出および配信メカニズム。このようなレポートは運用分析の観察に貢献できますが、その存在と範囲は記録する必要があります。すべての受信者がレポートする、すべてのレポート期間が完了する、またはすべての運用上の送信者が保持されたデータセットに現れると推測しないでください。指標では、完全な分母を作成するのではなく、欠落している期間とソースの制限にラベルを付ける必要があります。
調整ワークシート
メトリック名、ルールのバージョン、レポートのカットオフ、ソース システム、未加工合計、ソース カバレッジ、抽出参照を含むワークシートを作成します。顧客からテナントおよびテナントからドメインへのマッピング ルール、発効日、ステータス定義、および重複排除基準を追加します。例外台帳では、それぞれの不一致または係争中のアイテム、責任のある所有者、必要な証拠、および決定ステータスを特定する必要があります。機密性の高い請求書やアカウントの詳細を埋め込む代わりに、非機密の参照を使用してください。
出力セクションでは、未処理の合計および分類された調整とともに、調整された合計を保持する必要があります。送信者レベルのドリルダウンを追加して、送信者の数が課金資格であるかのように見せかけることなく、観測されたどのサービスが各ドメインの運用カバレッジに寄与しているかを説明します。レビュー担当者は、承認されたルールと保持されているソース資料から結果を再現できる必要があります。このワークシートは提案されたものであり、実際の顧客データは入力されていません。
架空の診断: 一致しない 3 つの合計
架空のサービスには、120 の契約ドメイン ユニット、126 の運用インベントリ行、および月に保持されたレポート データで観察された 98 のドメインがあります。これらの数値は例示的なものであり、測定値ではありません。チームは最初に、在庫合計を請求数で上書きしたいと考えています。提案された調整では、代わりに、それぞれの数字が何を表しているのか、どの記録が違いを説明しているのかを尋ねています。
架空の演習では、一部のインベントリ行がアクティブ化または履歴レコードを保留している一方で、一部の構成済みドメインでは利用可能なレポートにトラフィックが観察されていない可能性があります。これらは考えられるカテゴリーであり、合計を解決するための発明された証拠ではありません。チームは元の数値を保持し、承認済みステータスとタイミング ルールを適用し、一致しないアイテムを調査します。数字を一致させるためだけに、請求書を発行したり、ドメインを削除したり、顧客の資格を変更したりすることはありません。
適切な所有者とともに例外を確認する
商業所有者は、契約上の包含および請求ルールを決定します。操作所有者は、構成状態とドメインの依存関係を確認します。 Analytics オーナーがクエリ ロジックとソース カバレッジについて説明します。セキュリティまたはアイデンティティの所有者は、テナントのマッピングとアクセス境界を確認します。 1 人のダッシュボード オペレーターが 4 つすべてを黙って決定するべきではありません。調整結果により請求額の調整、テナントの変更、またはドメインの廃止が必要となる場合に必要な承認を文書化します。
報告の修正を運用上のアクションから分離します。重複行は、基になるリソースの削除を承認せずに、承認されたルールに基づいてメトリックから除外できます。不足している請求マッピングには、請求を承認せずにフラグを付けることができます。明らかに未使用のドメインでも、運用上重要なままである可能性があります。この分離により、有用な分析作業が、顧客のアクセス、構成、または財務に対する未確認の変更になることを防ぎます。
定義をバージョン化し、不確実性を維持する
メトリクスの定義が変更された場合は、その理由と、以前の期間が再計算されたかどうかを記録します。重複排除またはステータス ルールを変更すると、顧客の行動に変化を与えることなく、報告される傾向が変わる可能性があります。比較可能なバージョンを保存するか、不連続点に明示的にラベルを付けます。定義の変更が考慮されるまでは、成長、解約、またはカバレッジの改善の証拠として修正された合計を提示しないでください。
カタログには、生の合計、カバレッジの警告、送信者レベルのドリルダウンを含む再現可能なメトリック定義が必要です。その元の証拠は未解決のままです。架空の合計は完全な調整ではなく、ソース データの代替でもありません。人間の専門家によるレビュー、ソースの適用性、生産ルート、アクセシビリティ、所有者の公開も未解決のままです。公開可能なサンプルには、承認された保持入力、承認された定義、および再現可能な計算が必要ですが、個別に承認および実行されない限り、請求や運用上の変更が暗示されることはありません。