データ品質を監視する方法—詳細ガイド

データ収集のエラーを防ぐことは、その結果に対処するよりも簡単です。 ビジネス上の意思決定の賢明さは、データの品質によって異なります。 この記事では、作業範囲記述書から完成したレポートまで、収集のすべての段階でデータの品質を確認する方法について説明します。

残念ながら、データの保存と処理にかなりのリソースを費やしている多くの企業は、データではなく直感と独自の期待に基づいて重要な意思決定を行っています。

なぜそれが起こるのですか？ データの不信感は、データが意思決定者の期待と矛盾する答えを提供する状況によって悪化します。 さらに、過去に誰かがデータやレポートでエラーに遭遇した場合、彼らは直感を好む傾向があります。 誤ったデータに基づいて行われた決定は、あなたを前進させるのではなく、後退させる可能性があるため、これは理解できます。

複数通貨のプロジェクトがあると想像してください。 アナリストは1つの通貨でGoogleAnalyticsを設定し、コンテンツターゲット広告を担当するマーケティング担当者は別の通貨でGoogleAnalyticsにインポートするコストを設定しました。 その結果、広告キャンペーンレポートに非現実的な広告費用対効果（ROAS）が表示されます。 時間内にこのエラーに気付かない場合は、収益性の高いキャンペーンを無効にするか、赤字キャンペーンの予算を増やすことができます。

さらに、開発者は通常非常に忙しく、Web分析の実装は彼らにとって二次的なタスクです。 新しい機能（たとえば、アクセサリを備えたユニットの新しい設計）を実装している間、開発者はデータがGoogleAnalyticsで収集されていることを確認するのを忘れる可能性があります。 その結果、新しい設計の有効性を評価する時期になると、2週間前にデータ収集が中断されたことが判明しました。 サプライズ。

仕様段階でエラーが発生したと想像してください。 あなたがそれを見つけてすぐにそれを修正するならば、修正は比較的安いでしょう。 実装後、レポート作成時、または意思決定時にエラーが明らかになった場合、それを修正するためのコストは非常に高くなります。

データ収集は通常、5つの主要なステップで構成されます。

1. ビジネス上の課題を策定します。 推奨ブロックで商品を選択するためのアルゴリズムの効率を評価する必要があるとします。
2. アナリストまたはデータ収集の責任者は、サイトで追跡されるメトリックのシステムを設計します。
3. その人はGoogleAnalyticsとGoogleTagManagerを設定します。
4. 1つは、開発者が実装するための参照条件を送信します。
5. 開発者がメトリックを実装してデータ収集を設定した後、アナリストはレポートを操作します。

これらのほとんどすべての段階で、データを確認することが非常に重要です。 技術文書、Google Analytics、Google Tag Managerの設定、そしてもちろん、サイトやモバイルアプリケーションで収集されたデータの品質をテストする必要があります。

各ステップに進む前に、データテストのいくつかの要件を見てみましょう。

• ツールなしではテストできません。 少なくとも、ブラウザで開発者コンソールを操作する必要があります。
• 予想される抽象的な結果はありません。 あなたはあなたが最終的に何をすべきかを正確に知る必要があります。 ユーザーがサイトを操作するために収集する必要のある特定のパラメーターのセットが常にあります。 そして、これらのパラメーターがとるべき値を知っています。
• 特別な知識が必要です。 少なくとも、使用するWeb分析ツールのドキュメント、実践、および市場参加者の経験に精通している必要があります。

すでに述べたように、仕様に含まれていると、エラーを修正するのがはるかに簡単になります。 したがって、ドキュメントのチェックは、データを収集するずっと前に開始されます。 ドキュメントを確認する必要がある理由を理解しましょう。

ドキュメントのテストの目的：

• 少しの努力で間違いを修正します。 ドキュメントのエラーは、書かれたテキストのエラーにすぎないので、あなたがしなければならないのは、簡単な編集をすることだけです。
• サイト/アプリケーションアーキテクチャに影響を与える可能性のある将来の変更の必要性を防ぎます。
• アナリストの評判を守ります。 開発に誤りのある楽器は、それを起草した人の能力に疑問を投げかける可能性があります。

仕様の最も一般的なエラー：

1. タイプミス。 開発者は、パラメーターを読み取らずにパラメーターの名前をコピーできます。 これは、文法やスペルの誤りではなく、パラメーターの誤った名前またはこれらのパラメーターが保持する値に関するものです。
2. イベントを追跡するときにフィールドを無視します。 たとえば、フォームが正常に送信されなかった場合、エラーメッセージが無視されることがあります。
3. 無効なフィールド名と拡張eコマーススキームとの不一致。 dataLayer変数を使用して拡張eコマースを実装するには、明確なドキュメントが必要です。 したがって、仕様を作成するときは、すべてのフィールドを2回チェックすることをお勧めします。
4. 複数通貨サイトの通貨サポートはありません。 この問題は、すべての収益関連のレポートに関連しています。
5. ヒット制限は考慮されません。 たとえば、カタログページに最大30の異なる製品が存在する可能性があるとします。 すべての商品のビューに関する情報を同時に転送すると、Googleアナリティクスのヒットが転送されない可能性があります。

技術文書を確認した後の次のステップは、GoogleAnalyticsとGoogleTagManagerの設定を確認することです。

なぜGoogleAnalyticsとGoogleTagManagerの設定をテストするのですか？

• パラメータがデータ収集システムによって正しく処理されていることを確認してください。 GoogleAnalyticsとGoogleTagManagerは、サイトでの指標の実装と並行して構成できます。 そして、アナリストが完了するまで、データはGoogleAnalyticsに表示されません。
• サイトに埋め込まれたメトリックのテストを容易にします。 開発者の作業の一部に集中するだけで済みます。 Xの最終段階では、プラットフォーム設定ではなく、サイトで直接エラーの原因を探す必要があります。
• 開発者を巻き込む必要がないため、修理コストが低くなります。

Google Analyticsで最も一般的なエラー：

1. カスタム変数は作成されませんでした。 これは、最大200の指標と200のパラメータを持つことができるGoogleアナリティクス360アカウントに特に関係があります。 その場合、見逃しがちです。
2. 指定されたアクセススコープが無効です。 dataLayerのレビューフェーズ中、または送信しているヒットをレビューすることによってこのエラーをキャッチすることはできませんが、レポートを作成すると、データが期待どおりに表示されないことがわかります。
3. 既存のパラメーターの複製を取得します。 このエラーは送信されるデータには影響しませんが、レポートの確認と作成時に問題が発生する可能性があります。

Googleタグマネージャーで最も一般的なエラー：

1. UniversalAnalyticsタグやGoogleAnalytics設定変数などのパラメーターは追加されていません。
2. タグのインデックスがGoogleAnalyticsのパラメータと一致しないため、値が間違ったパラメータに渡されるリスクがあります。 たとえば、アイテム評価パラメーターにGTMのユーザー数パラメーターのインデックスを指定したとします。 このエラーは、レポートを作成するときにすぐに見つかる可能性がありますが、収集されたデータに影響を与えることはできなくなります。
3. dataLayerで指定された変数名が無効です。 dataLayerを作成するときは、変数がdataLayer配列に含まれる名前を必ず指定してください。 別の値を入力または書き込む場合、この変数がdataLayerから読み取られることはありません。
4. 拡張eコマーストラッキングが有効になっていません。
5. 開始トリガーが正しく構成されていません。 たとえば、Xをトリガーするための正規表現が正しく記述されていないか、イベント名にエラーがあります。

テストの最終段階は、サイトで直接テストすることです。 この段階では、コードを監視し、コンテナーがどのようにインストールされているかを確認し、ログを読み取る必要があるため、より技術的な知識が必要です。 したがって、知識が豊富で、適切なツールを使用する必要があります。

埋め込まれたメトリックをテストする理由

• 実装されているものが仕様に準拠していることを確認し、エラーがあれば記録します。
• 送信する値が適切かどうかを確認してください。 パラメータが送信される値を送信していることを確認します。 たとえば、商品のカテゴリは代わりにその名前を渡しません。
• 実装の品質について開発者にフィードバックを提供します。 このフィードバックに基づいて、開発者はサイトに変更を加えることができます。

最も一般的な間違い：

1. すべてのシナリオが網羅されているわけではありません。 たとえば、商品、カタログ、プロモーション、またはマスターページのカートにアイテムを追加できるとします。つまり、アイテムへのリンクがある場所ならどこにでも追加できます。 エントリポイントが非常に多いため、何かを見逃す可能性があります。
2. タスクはすべてのページに実装されているわけではありません。 つまり、一部のページまたは一部のパーティション/ディレクトリでは、データがまったく収集されないか、部分的にしか収集されません。 このような状況を防ぐために、チェックリストを作成することができます。 場合によっては、1つの関数に対して最大100個のチェックを行うことができます。
3. すべてのパラメーターが実装されているわけではありません。 つまり、dataLayerは部分的にしか実装されていません。
4. 拡張eコマースのdataLayerスキームが壊れています。 これは、カートへのアイテムの追加、チェックアウトステップ間の移動、アイテムのクリックなどのイベントに特に当てはまります。 拡張eコマースを実装する際の最も一般的なエラーの1つは、 Products配列に角かっこがないことです。
5. dataLayerは、nullまたはundefinedの代わりに空の文字列を使用して、パラメーターをゼロにします。 この場合、GoogleAnalyticsレポートには空の行が含まれています。 nullまたはundefinedを使用する場合、このオプションは送信するヒットに含まれません。

データのテストに使用するツール：

• Google AnalyticsDebuggerChrome拡張機能
• GTMデバッガー。これを使用して、Googleタグマネージャーでプレビューモードを有効にできます。
• 開発者コンソールのdataLayerコマンド
• 開発者コンソールの[ネットワーク]タブ
• GoogleタグアシスタントChrome拡張機能

これらのツールを詳しく見てみましょう。

開始するには、この拡張機能をブラウザにインストールして有効にする必要があります。 次に、ページIDを開き、[コンソール]タブに移動します。 表示される情報は、拡張機能によって提供されます。

この画面には、ヒットとともに送信されるパラメーターと、それらのパラメーターに対して送信される値が表示されます。

拡張されたeコマースブロックもあります。 あなたはecとしてコンソールでそれを見つけることができます：

さらに、ヒットサイズの制限を超えた場合などのエラーメッセージがここに表示されます。

dataLayerの構成を確認する必要がある場合、これを行う最も簡単な方法は、コンソールでdataLayerコマンドを入力することです。

送信されるすべてのパラメーターは次のとおりです。 それらを詳細に調べて検証することができます。 サイトでの各アクションは、dataLayerに反映されます。 7つのオブジェクトがあるとしましょう。 空のフィールドをクリックしてdataLayerコマンドを再度呼び出すと、8番目のオブジェクトがコンソールに表示されます。

Google Tag Manager Debuggerにアクセスするには、Google Tag Managerアカウントを開き、[プレビュー]ボタンをクリックします。

次に、サイトを開いてページを更新します。 下のペインに、そのページで実行されているすべてのタグを示すパネルが表示されます。

dataLayerに追加されたイベントが左側に表示されます。 それらをクリックすることで、dataLayerのリアルタイム構成を確認できます。

モバイルブラウザテストの機能：

• スマートフォンやタブレットでは、サイトをアダプティブモードで起動することも、サイトの別のモバイルバージョンを使用することもできます。 デスクトップでモバイルバージョンのサイトを実行している場合、携帯電話の同じバージョンとは異なります。
• 一般に、拡張機能はモバイルブラウザにインストールできません。
• これを補うには、UniversalAnalyticsタグまたはサイトのGoogleAnalyticsトラッキングコードでデバッグモードを有効にする必要があります。

モバイルアプリケーションテストの機能：

• アプリケーションコードを操作するには、より技術的な知識が必要です。
• ヒットをインターセプトするには、ローカルプロキシサーバーが必要です。 デバイスが送信するリクエストの数を追跡するために、アプリケーションまたは送信先のホストの名前でリクエストをフィルタリングできます。
• すべてのヒットは測定プロトコル形式で収集され、追加の処理が必要です。 ヒットが収集およびフィルタリングされたら、それらをコピーしてパラメータに解析する必要があります。 これを行うには、便利なツールを使用できます。ヒットビルダー、Googleスプレッドシートの数式、JavaScriptまたはPythonアプリです。 それはすべてあなたにとってより便利なものに依存します。 さらに、送信されたヒットのエラーを特定するには、測定プロトコルパラメータの知識が必要です。

1. USB経由でモバイルデバイスをラップトップに接続します。
2. デバイスでGoogleChromeを開きます。
3. Chromeデベロッパーコンソールで、リモートデバイスレポートを開きます。

1. ダイアログボックスの[ OK ]をクリックして、デバイスへの接続を確認します。 次に、検査するタブを選択して、[検査]をクリックします。
2. これで、ブラウザと同様に、開発者コンソールを標準モードで操作できます。 コンソール、ネットワークなど、おなじみのタブがすべて表示されます。

1. モバイルアプリケーションを使用するには、プロキシサーバーをインストールして実行する必要があります。 チャールズをお勧めします。
2. プロキシサーバーがインストールされたら、アプリケーションが接続するIPアドレスを確認します。

3. 次に、デバイスを取り出し、ポート8888を使用してプロキシサーバー経由でWi-Fi接続を構成します。これはCharlesがデフォルトで使用するポートです。

4. その後、ヒットを収集する時が来ました。 アプリケーションでは、ヒットは収集ではなくバッチに送信されることに注意してください。 バッチは、複数のリクエストを送信するのに役立つパッケージ化されたリクエストです。 まず、アプリケーションリソースを節約します。 次に、ネットワークに問題がある場合、要求はアプリケーションに保存され、ネットワーク接続が再確立されるとすぐに1つの共通プールが送信されます。

5. 最後に、収集されたデータをパラメーターに解析（分解）し、順番にチェックして、仕様と照合する必要があります。

このステップは最も速くて簡単です。 同時に、GoogleAnalyticsで収集されたデータが理にかなっていることを確認します。 レポートでは、何百もの異なるシナリオを確認し、デバイスやブラウザーなどに応じてインジケーターを確認できます。データに異常が見つかった場合は、特定のデバイスおよび特定のブラウザーでスクリプトを再生できます。

また、Google Analyticsレポートを使用して、dataLayerに転送されたデータの完全性を確認することもできます。 つまり、各シナリオに応じて、変数が入力され、すべてのパラメーターが含まれているかどうか、パラメーターが正しい値をとっているかどうかなどが示されます。

（私たちの意見では）最も有用なレポートを共有したいと思います。 それらをデータ収集チェックリストとして使用できます。

• eコマースレポート：
  • 製品のパフォーマンス
  • 製品リストのパフォーマンス
  • 内部プロモーション
• 行動—イベント—トップイベント
• 買収—キャンペーン—コスト分析
• カスタムレポート—たとえば、重複した注文を表示するレポート

これらのレポートがインターフェイスでどのように表示されるか、およびこれらのレポートのどれに最初に注意を払う必要があるかを見てみましょう。

このレポートで最も価値のあるタブは、買い物行動です。 強化されたeコマースの各段階でのデータ収集の完全性を分析します。 つまり、Google Analyticsが商品リストの表示、クリック、商品の詳細の表示、バスケットへの商品の追加/バスケットからの商品の削除、および購入自体を転送するかどうかを確認できます。

ここで何に注意を払うべきですか？ まず、いずれかの列にゼロの値がある場合、それは非常に奇妙です。 次に、ある段階で前の段階よりも多くの値がある場合、データの収集で問題が発生する可能性があります。 たとえば、アイテムの一意の購入数がチェックアウト数よりも多いとします。 それは奇妙で、注意を払う価値があります。

このレポートの他のパラメータを切り替えることもできます。これらのパラメータは、拡張eコマースにも送信する必要があります。 たとえば、メインオプションとして[アイテムカテゴリ]を選択した場合、特定のカテゴリのアイテムの売上はあるが、これらのアイテムのビューはなく、カートへの追加もありません。

まず、Google Analyticsに送信されるすべてのパラメーターを調べて、各パラメーターがどのような値をとるかを確認する必要があります。 通常、すべてが大丈夫かどうかはすぐにわかります。 各イベントのより詳細な分析は、カスタムレポートで実行できます。

GoogleAnalyticsへの経費データのインポートをチェックするのに役立つもう1つの標準レポートはCostAnalysisです。

ソースや広告キャンペーンに費用がかかるが、セッションがないという報告をよく目にします。 これは、UTMタグの問題またはエラーが原因である可能性があります。 または、Google Analyticsのフィルターは、特定のソースからのセッションを除外する場合があります。 これらのレポートは時々チェックする必要があります。

重複するトランザクションを追跡できるカスタムレポートを強調したいと思います。 設定は非常に簡単です。パラメータはトランザクションIDであり、キーディメンションはトランザクションである必要があります。

レポートに複数のトランザクションがある場合、これは同じ注文に関する情報が複数回送信されたことを意味することに注意してください。

同様の問題を見つけた場合は、修正方法に関するこれらの詳細な手順をお読みください。

Google Analyticsには、レポートを表示せずに重要な変更を追跡できる非常に優れたカスタムアラートツールがあります。 たとえば、Google Analyticsセッションに関する情報の収集を停止すると、電子メール通知を受け取ることができます。

少なくとも次の4つのメトリックの通知を設定することをお勧めします。

• セッション数
• バウンス率
• 収益
• トランザクション数

私たちの経験では、これは最も困難で時間のかかる作業であり、間違いが最も一般的な狭い線です。

dataLayerの実装に関する問題を回避するには、少なくとも週に1回チェックを実行する必要があります。 一般に、頻度は、サイトに変更を実装する頻度によって異なります。 理想的には、重要な変更を行うたびにdataLayerをテストする必要があります。 これを手動で行うには時間がかかるため、プロセスを自動化することにしました。

テストを自動化するために、次のことを可能にするクラウドベースのソリューションを構築しました。

• サイトのdataLayer変数が参照値と一致するかどうかを確認します
• GoogleTagManagerコードの可用性と機能を確認してください
• データがGoogleAnalyticsとOWOXBIに送信されていることを確認します
• GoogleBigQueryでエラーレポートを収集する

テスト自動化の利点：

• テストの速度を大幅に向上させます。 私たちの経験では、数時間で何千ものページをテストできます。
• 人的要因が除外されているため、より正確な結果が得られます。
• 必要なスペシャリストが少なくなるため、テストのコストを削減できます。
• サイトを変更するたびにテストを実行できるため、テストの頻度を増やします。

使用するアルゴリズムの簡略化されたスキーム：

アプリにログインするときは、確認するページを指定する必要があります。 これを行うには、CSVファイルをアップロードするか、サイトマップへのリンクを指定するか、または単にサイトURLを指定します。この場合、アプリケーションはサイトマップ自体を検出します。

次に、テストする各シナリオ（ページ、イベント、スクリプト（チェックアウトなどの一連のアクション））のdataLayerスキームを指定することが重要です。 次に、正規表現を使用して、ページタイプがURLと一致することを指定できます。

このすべての情報を受け取った後、アプリケーションはスケジュールどおりにすべてのページとイベントを実行し、各スクリプトをチェックして、テスト結果をGoogleBigQueryにアップロードします。 このデータに基づいて、メールとSlackの通知を設定します。

PS完全なWebサイト監査が必要な場合は、OWOXBIにコンサルティングサービスをリクエストできます。 デモにサインアップして、可能性について話し合います。