ウェブサイトデータ分析：分析の前提 - データ品質 2

前回の記事では、データ品質の基本的な概念をいくつか紹介しました。データ品質管理は、データ ウェアハウスの基本的なリンクとして、上位レベルのデータ アプリケーションを保証するための基礎となります。データ品質保証には、主にデータプロファイリング、データ監査、データ修正の3つの部分が含まれます。前回の記事では、データプロファイリングの関連内容を紹介しました。データプロファイリングのプロセスからデータの要約統計情報が取得されたので、次のデータ統計情報を使用してデータの品質を監査し、データにダーティデータがあるかどうかを確認します。そのため、この記事では主にデータ監査の内容を紹介します。

データ品質の基本要素

まず、データの品質をどのように評価するか、つまり、どのようなデータが要件を満たすかということです。これは、データ品質の 4 つの基本要素を構成する 4 つの側面から考えることができます。

完全

データ記録と情報が完全かどうか、また不足している項目があるかどうか。

データ欠損には主にレコードの欠損とレコード内のフィールド情報の欠損が含まれ、どちらも不正確な統計結果を引き起こします。したがって、整合性はデータ品質の最も基本的な保証であり、整合性の評価は比較的簡単です。

一貫性

データが仕様通りに記録されているか、また、前後のデータセットや他のデータセットと整合性が取れているか。

データの一貫性には、主にデータ レコードの仕様とデータ ロジックの一貫性が含まれます。データ レコードの仕様は、主にデータのエンコードと形式に関する問題です。たとえば、Web サイトのユーザー ID は 15 桁の数字、製品 ID は 10 桁の数字、製品には 20 のカテゴリが含まれます。IP アドレスは 4 つの 0 ～ 255 の数字で構成され、「.」で区切られます。また、整合性のための空でない制約、一意の値制約など、いくつかのデータ制約が定義されています。データ ロジックは主に、PV>=UV、新規ユーザーの割合が 0 ～ 1 であるなど、指標の統計と計算の一貫性です。データ一貫性レビューは、データ品質レビューの重要かつ複雑な部分です。

正確さ

データに記録された情報やデータが正確であるか、異常な情報や誤った情報がないか。

一貫性の問題の原因は、データ記録のルールが異なることかもしれませんが、必ずしもエラーがあるわけではありません。精度は、データ記録のエラーに焦点を当てています。たとえば、文字データの文字化けも、精度評価カテゴリに含める必要があります。さらに、異常な値、異常に大きい値または小さい値、および妥当性要件を満たさない値があります。たとえば、訪問回数は整数でなければならず、年齢は一般に1〜100の間で、コンバージョン率は0〜1の間でなければなりません。明らかに異常ではない誤った値を検出することは難しいため、データの正確性を監査することは困難な場合があります。

適時性

データが生成されてから表示できるようになるまでの時間間隔は、データ遅延とも呼ばれます。

分析データに対するリアルタイム要件はそれほど高くありませんが、要件がないわけではありません。アナリストは、当日のデータを翌日まで表示できないことを受け入れることができますが、データが2、3日遅れたり、週次データ分析レポートが2週間後まで利用できなかったりすると、分析の結論は適時性を失っている可能性があり、アナリストの作業は無駄になります。同時に、一部のリアルタイム分析と意思決定では、時間または分レベルのデータが必要であり、これらの要件ではデータの適時性に対する要件が非常に高くなります。したがって、適時性もデータ品質の要素の 1 つとなります。

データ監査

データ品質の 4 つの要素に基づいて、データを監査し、データが完全性、一貫性、正確性、適時性の要件を満たしているかどうかを評価できます。データの適時性は主にデータの同期と処理の効率に関係しており、ETL タスクの監視によって確保されることが多いです。したがって、ここでのデータ監査は主にデータの完全性、一貫性、正確性の評価を指します。

完全

データ プロファイリングから取得したどのデータ統計がデータ整合性の監査に使用できるかを確認します。 1 つ目はレコードの整合性であり、これは通常、レコードの数と一意の値の数によって測定されます。たとえば、ウェブサイトのログレコードの数は比較的一定で、1,000万前後で変動しています。ある日のログレコードの数がわずか100万にまで減少した場合、レコードが欠落している可能性が非常に高いです。または、ウェブサイトのアクセスレコードは24時間配信されている必要があります。特定の時間にユーザーのアクセスレコードがまったくない場合は、その時点でウェブサイトに問題があったか、その時点でログレコードの送信に問題があった可能性が非常に高いです。たとえば、訪問者の地理的分布をカウントする場合、通常は全国の32の省と直轄市が含まれます。カウントされた省の一意の値の数が32未満の場合、データが欠落している可能性が非常に高いです。

一方、レコード内のフィールドのデータが欠落している場合は、統計情報内のヌル値（NULL）の数で確認できます。アクセスしたページのアドレスや購入した商品のIDなど、特定のフィールドの情報が理論上存在しなければならない場合、これらのフィールドのnull値の数は0としてカウントする必要があります。これらのフィールドのデータ整合性を確保するには、NOT NULL制約を使用できます。ユーザーのCookie情報など、nullを許可する一部のフィールドでは、存在しない可能性があります（ユーザーがCookieを無効にしています）が、null値の割合は基本的に一定です。たとえば、空のCookieを持つユーザーの割合は通常2％〜3％です。カウントされたnull値の数を使用して、null値の割合を計算することもできます。null値の割合が大幅に増加した場合、このフィールドのレコードに問題があり、情報が欠落している可能性が非常に高くなります。

一貫性

　　データ レコード形式に標準のエンコード ルールがある場合は、データ レコードの一貫性チェックは比較的簡単です。すべてのレコードがエンコード ルールを満たしているかどうかを確認するだけで済みます。最も簡単な方法は、フィールドの長さや一意の値の数などの統計を使用することです。たとえば、ユーザー ID が 15 桁でエンコードされている場合、フィールド内の最長文字数と最短文字数は 15 である必要があります。または、製品 ID が P で始まり、その後に 10 桁が続く場合、同じ方法を使用してチェックできます。フィールドが一意であることを保証する必要がある場合は、フィールドの一意の値の数が、ユーザーの登録済み電子メール アドレスなどのレコードの数と一致している必要があります。たとえば、地域内の省と市は統一的にコード化する必要があり、レコードは「上海市」ではなく「上海」、または「浙江省」ではなく「浙江」である必要があります。これらの一意の値は、32 の省と市の有効なリストにマッピングできます。マッピングを実現できない場合、フィールドは一貫性チェックに合格しません。

一貫性のある論理ルールの検証は比較的複雑です。多くの場合、指標の統計ロジックの一貫性には、基礎となるデータの品質の保証が必要です。同時に、統計ロジックの非常に標準化された標準的な定義も必要です。すべての指標の計算ルールは一貫していることが保証されなければなりません。よくあるミスとして、集計データとセグメント化されたデータを足し合わせた結果が一致しないということがあります。この問題の原因として最も可能性が高いのは、データをセグメント化する際に、特定のセグメント項目に明確に帰属できないデータを除外していることです。たとえば、アクセス元をセグメント化する際に、外部リンク、検索エンジン、広告などの確立されたソースカテゴリに明確に帰属できない非直接的なアクセス元がある場合、これらのデータを直接除外するのではなく、「不明なソース」という分類にして、ソースセグメント化後のデータを合計して全体のデータと一致するようにする必要があります。これらのデータ ロジックの一貫性を確認する必要がある場合は、A>=B、C=B/A の場合、C の値は [0,1] の範囲内である必要があるなど、いくつかの「有効性ルール」を確立できます。データがこれらのルールを満たせない場合は、一貫性チェックに合格しません。

正確さ

データの正確さは、個々のレコードに存在する場合もあれば、データセット全体に存在する場合もあります。データ セット全体のフィールドのデータにエラーがある場合 (一般的なレコード エラーの大きさなど)、このエラーは簡単に見つけることができます。このタイプの問題は、データ プロファイリングの平均値と中央値を使用して検出することもできます。データ セットに個別の外れ値がある場合は、最大統計と最小統計を使用してそれらを確認したり、ボックス プロットを使用して異常なレコードを一目で明確にしたりできます。

文字化けや切り捨てられた文字など、精度監査の問題もいくつかあります。分布は、このような問題を発見するために使用できます。一般的に、データレコードは基本的に正規分布または準正規分布に従います。そして、異常に小さい割合を持つデータ項目には問題がある可能性があります。たとえば、文字レコードは全体の0.1％しか占めていませんが、他の文字レコードは3％以上を占めています。この場合、この文字レコードは異常である可能性が非常に高くなります。一部のETLツールのデータ品質監査では、このような異常に小さい割合のレコード値が識別されます。特定の数値範囲を持つデータには、有効性制限を課すこともできます。有効な値の範囲を超えるデータ レコードはエラーとみなされます。

データが著しく異常ではない場合でも、記録された値が間違っている可能性はありますが、正常値に近いです。このタイプの精度テストは最も難しく、通常は他のソースまたは統計結果と比較することによってのみ発見できます。複数のデータ収集システムまたはWebサイト分析ツールが使用されている場合、異なるデータソースのデータを比較することで、データレコードの精度の問題を発見できます。

データ監査を通じて、データ プロファイリングの統計情報からいくつかのデータ品質の問題が発見されました。次のステップは、これらの問題に対処するためにデータをクリーンアップして修正することです。これについては、次の記事「データ修正」で紹介します。

出典: ウェブサイトデータ分析

元のリンク: http://webdataanalysis.net/data-collection-and-preprocessing/data-quality-2/

ウェブサイトデータ分析：分析の前提 - データ品質 1

原題: ウェブサイトデータ分析: 分析の前提 - データ品質 2

キーワード: ウェブサイト、前提、品質、記事、いくつか、基本、概念、制御、ウェブマスター、ウェブサイトのプロモーション、収益化