データクレンジング手法にはいくつかの種類があり、それぞれ異なるカテゴリのデータ品質問題に対処します。最適な手法の選択は、エラーの種類、データ量、そして後工程のユースケースによって異なります。
は、同一の実体を表すレコードを特定し、統合または削除する手法です。完全一致のロジックだけでは重複を検出できない場合、同一住所の Jon Smith と John Smith, のように似ているが完全には一致しないレコードを比較する、あいまい照合が必要になります。B2Bデータベースでは、データ品質管理を積極的に行わないと、重複が連絡先の推定10%〜30%を占める可能性があります。重複を排除することで、キャンペーンの送信コストを削減し、配信メトリクスを改善することができます。
は、すべてのレコードにわたってデータを統一されたフォーマットに変換します。(555) 867-5309、555-867-5309、5558675309はいずれも同じ電話番号を表しますが、表記形式が異なります。標準化により、これらは1つの正規フォーマットに集約されます。このデータ標準化は、システム間でレコードを結合する際の前提条件です。標準化を行わなければ、電話番号に対する単純なSQL結合でも、3つの形式がそれぞれ異なるお客様として処理されてしまいます。
は、次の3つの方法のいずれかを使用して、nullまたは空のフィールドを解決します。
- は、統計的に導出されたルールベースの値を代入する手法です。郵便番号に基づいて欠損した都道府県フィールドを埋める場合などが、この例として挙げられます。
- は、フィールドを「不明」としてマークします。これにより、後工程のモデルがレコードを無視したりゼロに設定したりするのではなく、明示的に処理することができます。
- は、完全性が絶対条件となる場合に不完全なレコードを除外します。不完全なレコードが監査要件に違反する恐れがある財務報告などが、その典型例です。
最適な方法は、そのフィールドがユースケースにとってどれだけ重要かによって異なります。レコメンデーションモデルに向けて欠損している商品カテゴリを補完することは合理的です。しかし、プライバシーワークフローにおける欠損した同意フラグを補完することは合理的ではありません。
は、データが受け入れられるために満たすべき条件を定義します。生年月日フィールドには未来の日付を入力できません。メールアドレスは有効な構文パターンに一致している必要があります。国コードはISOの参照リストに存在している必要があります。データ検証はデータパイプラインの最初の関門であり、取り込み段階でエラーを検出することで、レポートテーブルやアクティベーションシステムへの波及を防ぎます。
は、統計的に発生しにくい値を洗い出し、真の極端値ではなくデータ入力エラーの可能性を示します。中央値が$45のデータセットで$1,000,000の取引金額が存在する場合は、確認が必要です。入力ミスや通貨換算の誤り、あるいは別途対処が必要な正当な例外ケースである可能性があります。重要なのは、異常値を見過ごしたり無条件に除外したりするのではなく、確認のために検出・提示することです。
は、複合フィールドを最小単位の要素に分解します。Full Name という単一フィールドを First Name と Last Name に分割することで、パーソナライゼーションや並べ替えを行うことができます。住所を番地、市区町村、都道府県、郵便番号に解析することで、地域別セグメンテーションを実現することができます。この手法はデータ変換と重複することが多いですが、スキーマ変更ではなくデータの正確性を高めるために実施されます。