妥当性：設定シナリオ

これらのシナリオがカバーする内容

このページでは、DQS妥当性分析の3つの実世界の設定を解説します。各シナリオは特定のビジネス問題を取り上げ、使用する正確な設定を示し、結果の読み方を説明します。

これらのウォークスルーは、メインの妥当性記事の概念を基にしています。妥当性指標、診断フロー、パターン設定に不慣れな方は、まずそちらをお読みください。

シナリオ1：カスタムテキストフィールドでのセカンダリメール検証

問題

あなたの組織はContactオブジェクトのカスタムSecondary_Email__cテキストフィールドにセカンダリメールアドレスを保存しています。標準のSalesforce Emailフィールドと異なり、テキストフィールドには組み込みのフォーマット検証がありません。ユーザーは何でも貼り付け、入力、インポートします。マーケティングは再エンゲージメントキャンペーンでこれらのセカンダリアドレスを使いたいと考えていますが、構造的に妥当なアドレスが何件あるかは誰も知りません。マーケティングが現実的なキャンペーン予測を立て、運用チームがクレンジングの範囲を決められるよう、具体的な数字が必要です。

**なぜ標準のEmailフィールドではないのか？**SalesforceのネイティブEmailフィールドタイプは入力時にフォーマットを検証します。標準Emailフィールドの値は既に基本的なフォーマットチェックを通過しています。DQSのメール検証は、Salesforceの組み込み徹底なしにメールアドレスを保存するカスタムTextフィールドで有用です。

設定

ContactオブジェクトでFormat Validationモードを使い、Secondary_Email__cフィールドを対象とします。看板となる妥当性率と使用可能なレコード数が必要です。プレースホルダ検出やノイズ分析は、メールアドレスがフォーマットに一致するかしないかのどちらかであるため、ここでは関連性がありません。

Emailパターンは組み込みプリセットです。正規表現を書く必要はありません。パターンピッカーから「Email」を選択すると、正規表現が自動的に適用されます。

サンプル結果

評価された総Contactレコード：50,000件。

結果の読み方

看板から始めます。妥当性71%。つまり29%のセカンダリメールアドレスがフォーマットチェックに失敗しています。Secondary_Email__cが入力済みの50,000件のContactのうち、構造的に妥当なアドレスを持つのは35,500件だけです。

29%の無効が実際にはどのようなものか：「@」記号が欠けた値（john.company.com）、ドメイン拡張子が欠けた値（john@company）、ダブルドットを含む値（john@company..com）、スペースを含む値（john @company.com）などです。これはテキストフィールドなので、Salesforceは入力時にすべてを受け入れました。これらのアドレスに送信されるキャンペーンはすべてバウンスします。

**キャンペーンの計算が変わります。**マーケティングは50,000件のセカンダリアドレスに基づいて再エンゲージメントのリーチを予測してきました。実際の到達可能な母集団は35,500件です。開封率、クリック率、コンバージョン予測はすべて、水増しされた合計ではなく、妥当なベースに対して再計算する必要があります。

**ここではFormat Validationで十分な理由。**このシナリオではAdvancedモードは必要ありません。問いはシンプルです。「何件のセカンダリメールが妥当なフォーマットに一致するか」。妥当性率とValid件数がその問いに答えます。後で正確な無効件数を伴うクレンジングプロジェクトの範囲を決める必要があれば、完全な内訳のためにAdvanced Format Validationに切り替えましょう。

次に行うこと

Valid件数（35,500）をキャンペーン計画の実際の到達可能な母集団として使います。残り14,500件のクレンジングプロジェクトの範囲を設定します。エクスポートし、最も一般的なフォーマットエラーを特定し、データエンリッチメントまたは手動修正で修正します。Secondary_Email__cにSalesforce入力規則を追加して将来の入力でメールフォーマットを徹底するか、プロセスが許せばフィールドをEmailタイプに変換することを検討しましょう。

シナリオ2：Fixed Lengthでの製品コード検証

問題

あなたの会社はOpportunity ProductオブジェクトのカスタムProduct_Code__cフィールドで8文字の製品コードを使っています。これらのコードは在庫検索、価格ルール、ERPインテグレーションを駆動します。ERP同期は毎週約5%のレコードで失敗しており、インテグレーションチームは不正な製品コードを疑っています。どれほどのコードがフォーマットチェックに失敗しているかを確認し、正確なクレンジング範囲を得る必要があります。

設定

Opportunity ProductオブジェクトでAdvanced Format Validationモードを使い、Product_Code__cフィールドを対象とします。インテグレーションチームが修復プロジェクトで正確なレコード数を得られるよう、完全なvalid/invalid内訳が必要です。

Fixed Lengthパターンは自動的に正規表現^.{8}$を生成します。正確に8文字でない値はすべて検証に失敗します。

サンプル結果

基礎指標：

高度指標：

評価された総レコード：10,000件。

結果の読み方

**5.8%の無効がインテグレーションチームの推定を確認します。**10,000件のうち580件の製品コードが8文字フォーマットに一致しません。これらがERP同期を破綻させているレコードです。

**Invalid件数（580）がクレンジング範囲です。**インテグレーションチームは具体的な数字を得ました。各同期失敗を個別に調査するのではなく、580件のレコードを取り出し、フォーマットエラーを分類し、一括修正できます。製品コードフィールドでよくある問題には、コピーペーストエラーによる切り詰められたコード（5〜7文字）、末尾スペース付きのコード（見えないスペースのため9文字）、ユーザーが追加したダッシュやプレフィクス付きのコード（「PC-12345678」）があります。

**Noise率（0.4%）は低いものの注目に値します。**40件のレコードがノイズパターンを含みます。繰り返し文字（「XXXXXXXX」）、キーボード入力（「asdfghjk」）、特殊文字列です。これらの40件のレコードはフォーマットエラーではありません。たまたま正確に8文字の長さのジャンクエントリです。妥当性率は長さチェックを通過するためこれらを妥当として数えましたが、別の理由でERP検索に失敗するゴミデータです。Noise Rateはフォーマットチェックが見逃すものを捕捉します。

**ここではInclude Blanks ONが重要です。**Include Blanksを有効にすると、Product_Code__cが空のレコードは無効として数えられます。この設定をオフのままにしていたら、それらの空レコードは評価から完全に除外され、Invalid件数はERP同期に失敗しているレコードの真の数より低くなっていたでしょう。空の製品コードも不正なものと同じ方法でインテグレーションを破綻させるため、空欄を含めることで正確な失敗範囲が得られます。

次に行うこと

580件の無効レコードをインテグレーションチームのためにエクスポートします。エラーをタイプ別に分類します。切り詰められたコード、追加の文字、末尾スペースです。データ更新ジョブを使って一括修正します。40件のノイズレコードについては、源を調査します。特定のインポートやユーザーから来ている場合、その根本原因に対処します。クレンジング後、新しい不正エントリを防ぐためにProduct_Code__cに8文字長を徹底するSalesforce入力規則を追加します。新しい妥当性率を確認するために再スキャンします。

シナリオ3：Web-to-Leadの会社名ノイズ検出

問題

あなたのWeb-to-leadフォームはCompanyフィールドを必須にしています。Leadの量は十分です。四半期あたり20,000件の新規Leadです。しかしSDRチームは、多くのLeadに「asdf」「test」「xxx」「na na na」などのゴミの会社名があると報告しています。これらのLeadはSDRの時間を浪費し、セグメンテーションを汚染します。基本的な完全性チェックは98%のLeadにCompany値があることを示します。ジャンクエントリが技術的には「入力済み」であるため、98%は誤解を招くと疑っています。

設定

LeadオブジェクトでAdvanced Format Validationモードを使い、Companyフィールドを対象とします。健全な完全性スコアの背後に隠れるゴミを定量化するためにNoise Rateが必要です。

フォーマットパターンとしては、会社名には厳格なフォーマットルールはありません。会社名は自由入力です。値に少なくとも1つの英数字が含まれていることを確認する最小限のテキスト検証を使います。

このスキャンの真の価値はフォーマット検証ではなくノイズ指標にあります。特定の会社名フォーマットを徹底しているわけではないので、カスタムパターンは意図的に緩いものです。Noise RateとNoisy Records件数にアクセスするために、スキャンをAdvancedモードで実行します。

サンプル結果

基礎指標：

高度指標：

評価された総Leadレコード：20,000件。

結果の読み方

**97.5%の妥当性は想定内であり、重要ではありません。**パターンが1つの英数字しか要求しないため、ほとんどすべての値が緩いフォーマットチェックを通過します。500件の無効レコードは特殊文字や空白のみのエントリです。「---」「…」「!!!」のような値です。これらは容易に特定して削除できます。

**Noise率（12%）が真の発見です。**2,400件のLeadがノイズパターンを含む会社名を持っています。これらは繰り返し文字（「aaaa」「xxxxx」）、連続する特殊文字（「!@#$%」）、制御文字を含むエントリです。英数字を含むためフォーマットチェックを通過しますが、値はゴミです。

真のデータ品質の姿：

SDRチームの指摘は正しいです。Lead品質の問題は現実のものです。20,000件のうち2,900件（14.5%）のLeadが使えない会社データを持っています。それは適切にルーティング、エンリッチメント、セグメンテーションできないLeadにSDRの時間の14.5%が浪費されているということです。

**完全性対妥当性のギャップ。**完全性はLeadの98%にCompany値があると言います。妥当性は97.5%がフォーマットチェックを通過すると言います。Noise Rateは通過した値の12%がゴミであると言います。各次元が問題の異なる層を明らかにします。完全性だけではNoise Rateが捕捉するジャンクを見逃します。

次に行うこと

無効とノイズの合計2,900件のレコードのクレンジングキューを構築します。500件の純粋に無効なレコードについては、自動削除または隔離します。2,400件のノイズレコードについては決定します。他に有用なデータのないLeadは自動削除するか、電話やメールデータがまだ使える場合は手動レビューのためにフラグ付けします。

源を修正します。ジャンクはWebフォームから来ています。クライアントサイド検証を追加します。最小文字数、繰り返し文字パターンのブロック、ボット防止のためのCAPTCHAを検討します。フォーム変更の実装後、次四半期にスキャンを再実行し、Noise Rateをこのベースラインと比較します。

設定の選択

次の表を使って妥当性分析の正しい出発点を選びましょう。

6つの妥当性指標、パターンタイプ、ノイズ検出の詳細の完全なリファレンスについては、メインの妥当性記事に戻ってください。

自社のデータ品質を測定する準備ができましたか？AI対応度診断を受けて妥当性スコアなどを確認しましょう。