데이터 품질을 모니터링하는 방법 - 자세한 가이드

데이터 수집에서 오류를 방지하는 것이 결과를 처리하는 것보다 쉽습니다. 비즈니스 결정의 현명함은 데이터 품질에 따라 다릅니다. 이 기사에서는 작업 명세서에서 완료된 보고서에 이르기까지 수집의 모든 단계에서 데이터 품질을 확인하는 방법을 알려줍니다.

불행히도 데이터를 저장하고 처리하는 데 상당한 리소스를 소비하는 많은 회사는 여전히 데이터 대신 직관과 자체 기대치를 기반으로 중요한 결정을 내립니다.

왜 그런 일이 발생합니까? 데이터에 대한 불신은 데이터가 의사 결정자의 기대와 상반되는 답변을 제공하는 상황에서 악화됩니다. 또한 과거에 데이터나 보고서에서 오류가 발생한 경우 직관을 선호하는 경향이 있습니다. 잘못된 데이터를 기반으로 내린 결정은 앞으로 나아가기보다는 뒤로 물러날 수 있기 때문에 이해할 수 있습니다.

다중 통화 프로젝트가 있다고 상상해보십시오. 귀하의 분석가는 한 통화로 Google Analytics를 설정했고 문맥 광고를 담당하는 마케터는 다른 통화로 Google Analytics로 가져오기 비용을 설정했습니다. 결과적으로 광고 캠페인 보고서에 비현실적인 광고 투자 수익률(ROAS)이 표시됩니다. 제 시간에 이 오류를 발견하지 못하면 수익성 있는 캠페인을 비활성화하거나 손실을 내는 캠페인에 대한 예산을 늘릴 수 있습니다.

또한 개발자는 일반적으로 매우 바쁘고 웹 분석을 구현하는 것은 이들에게 부차적인 작업입니다. 새로운 기능(예: 액세서리가 있는 장치의 새로운 디자인)을 구현하는 동안 개발자는 Google 애널리틱스에서 데이터가 수집되고 있는지 확인하는 것을 잊어버릴 수 있습니다. 그 결과 새로운 디자인의 효과를 평가할 때가 되었을 때 데이터 수집이 2주 전에 중단된 것으로 나타났습니다. 놀라다.

사양 단계에서 오류를 범했다고 상상해 보십시오. 발견하여 즉시 수정하면 비교적 저렴하게 수정할 수 있습니다. 구현 후, 보고서 작성 시 또는 의사 결정 시에도 오류가 발견되면 수정 비용이 매우 높아집니다.

데이터 수집은 일반적으로 5가지 주요 단계로 구성됩니다.

1. 비즈니스 과제를 공식화하십시오. 추천 블록에서 상품을 선택하기 위한 알고리즘의 효율성을 평가해야 한다고 가정해 보겠습니다.
2. 분석가 또는 데이터 수집을 담당하는 사람은 사이트에서 추적할 메트릭 시스템을 설계합니다.
3. 그 사람은 Google 애널리틱스와 Google 태그 관리자를 설정합니다.
4. 하나는 개발자가 구현할 참조 조건을 보냅니다.
5. 개발자가 메트릭을 구현하고 데이터 수집을 설정한 후 분석가는 보고서로 작업합니다.

거의 모든 단계에서 데이터를 확인하는 것이 매우 중요합니다. 기술 문서, Google 애널리틱스 및 Google 태그 관리자 설정, 그리고 물론 사이트 또는 모바일 애플리케이션에서 수집된 데이터 품질을 테스트해야 합니다.

각 단계로 이동하기 전에 데이터 테스트를 위한 몇 가지 요구 사항을 살펴보겠습니다.

• 도구 없이는 테스트할 수 없습니다. 최소한 브라우저에서 개발자 콘솔로 작업해야 합니다.
• 추상적인 예상 결과가 없습니다. 당신은 당신이 끝내야 할 것을 정확히 알아야합니다. 사이트와 사용자 상호 작용을 위해 수집해야 하는 특정 매개변수 세트가 항상 있습니다. 그리고 우리는 이러한 매개변수가 취해야 하는 값을 알고 있습니다.
• 특별한 지식이 필요합니다. 최소한 사용하는 웹 분석 도구에 대한 문서, 관행 및 시장 참가자의 경험에 익숙해야 합니다.

언급했듯이 사양에서 오류를 포착하면 오류를 수정하기가 훨씬 쉽습니다. 따라서 문서 확인은 데이터를 수집하기 훨씬 전에 시작됩니다. 문서를 확인해야 하는 이유를 알아보겠습니다.

문서 테스트 목적:

• 적은 노력으로 실수를 수정하십시오. 문서의 오류는 서면 텍스트의 오류일 뿐이므로 빠르게 수정하기만 하면 됩니다.
• 사이트/애플리케이션 아키텍처에 영향을 미칠 수 있는 향후 변경의 필요성을 방지합니다.
• 분석가의 평판을 보호하십시오. 개발에 오류가 있는 도구는 초안을 작성한 사람의 능력에 의문을 제기할 수 있습니다.

사양의 가장 일반적인 오류:

1. 오타. 개발자는 매개변수 이름을 읽지 않고 복사할 수 있습니다. 이것은 문법이나 철자 오류에 관한 것이 아니라 매개변수의 잘못된 이름이나 매개변수가 보유하는 값에 관한 것입니다.
2. 이벤트를 추적할 때 필드를 무시합니다. 예를 들어, 양식이 성공적으로 제출되지 않은 경우 오류 메시지가 무시될 수 있습니다.
3. 잘못된 필드 이름 및 향상된 전자 상거래 체계와 일치하지 않습니다. dataLayer 변수를 사용하여 향상된 전자 상거래를 구현하려면 명확한 문서가 필요합니다. 따라서 사양을 작성할 때 모든 필드를 두 번 확인하는 것이 좋습니다.
4. 다중 통화 사이트에 대한 통화 지원이 없습니다. 이 문제는 모든 수익 관련 보고서와 관련이 있습니다.
5. 적중 제한은 고려되지 않습니다. 예를 들어 카탈로그 페이지에는 최대 30개의 서로 다른 제품이 있을 수 있습니다. 모든 제품에 대한 조회수 정보를 동시에 전송하면 Google 애널리틱스의 조회수가 전송되지 않을 가능성이 높습니다.

기술 문서를 확인한 후 다음 단계는 Google 애널리틱스 및 Google 태그 관리자 설정을 확인하는 것입니다.

Google 애널리틱스 및 Google 태그 관리자 설정을 테스트하는 이유는 무엇입니까?

• 매개변수가 데이터 수집 시스템에 의해 올바르게 처리되는지 확인하십시오. Google Analytics 및 Google 태그 관리자는 사이트의 측정항목 구현과 동시에 구성할 수 있습니다. 그리고 분석가가 완료될 때까지 데이터는 Google Analytics에 표시되지 않습니다.
• 사이트에 포함된 메트릭을 더 쉽게 테스트할 수 있습니다. 개발자 작업의 일부에만 집중하면 됩니다. X의 마지막 단계에서 플랫폼 설정이 아닌 사이트에서 직접 오류의 원인을 찾아야 합니다.
• 개발자가 필요 없어 수리 비용이 저렴합니다.

Google 애널리틱스에서 가장 흔한 오류:

1. 맞춤 변수가 생성되지 않았습니다. 이는 최대 200개의 측정항목과 200개의 매개변수를 포함할 수 있는 Google 애널리틱스 360 계정과 특히 관련이 있습니다. 이 경우 하나를 놓치기 쉽습니다.
2. 지정된 액세스 범위가 잘못되었습니다. dataLayer 검토 단계 동안이나 전송 중인 조회수를 검토하여 이 오류를 포착할 수 없지만 보고서를 작성할 때 데이터가 예상대로 표시되지 않는 것을 볼 수 있습니다.
3. 기존 매개변수의 복제본을 얻습니다. 이 오류는 전송되는 데이터에 영향을 미치지 않지만 보고서를 확인하고 작성할 때 문제를 일으킬 수 있습니다.

Google 태그 관리자의 가장 일반적인 오류:

1. 유니버설 애널리틱스 태그 또는 Google 애널리틱스 설정 변수와 같은 매개변수가 추가되지 않았습니다.
2. 태그의 색인이 Google 애널리틱스의 매개변수와 일치하지 않아 값이 잘못된 매개변수로 전달될 위험이 있습니다. 예를 들어, 항목 평가 매개변수에 대해 GTM에서 사용자 매개변수 수의 인덱스를 지정했다고 가정합니다. 이 오류는 보고서를 작성할 때 즉시 발견될 수 있지만 더 이상 수집된 데이터에 영향을 줄 수 없습니다.
3. dataLayer에 잘못된 변수 이름이 지정되었습니다. dataLayer를 생성할 때 dataLayer 배열에서 변수를 찾을 이름을 지정해야 합니다. 다른 값을 입력하거나 쓰는 경우 이 변수는 dataLayer에서 읽지 않습니다.
4. 향상된 전자상거래 추적이 활성화되지 않았습니다.
5. 시작 트리거가 올바르게 구성되지 않았습니다. 예를 들어 X를 트리거하는 정규식이 잘못 작성되었거나 이벤트 이름에 오류가 있습니다.

테스트의 마지막 단계는 현장에서 직접 테스트하는 것입니다. 이 단계에서는 코드를 보고, 컨테이너가 어떻게 설치되었는지 확인하고, 로그를 읽어야 하므로 더 많은 기술 지식이 필요합니다. 따라서 지식을 갖고 올바른 도구를 사용해야 합니다.

임베디드 메트릭을 테스트하는 이유는 무엇입니까?

• 구현된 항목이 사양을 준수하는지 확인하고 오류를 기록합니다.
• 보낼 값이 적절한지 확인하십시오. 매개변수가 전송할 값을 전송하는지 확인하십시오. 예를 들어, 상품 카테고리는 이름을 대신 전달하지 않습니다.
• 구현 품질에 대해 개발자에게 피드백을 제공합니다. 이 피드백을 기반으로 개발자는 사이트를 변경할 수 있습니다.

가장 흔한 실수:

1. 모든 시나리오가 적용되는 것은 아닙니다. 예를 들어 제품, 카탈로그, 프로모션 또는 마스터 페이지의 장바구니에 항목을 추가할 수 있다고 가정해 보겠습니다. 진입점이 너무 많아서 놓칠 수 있습니다.
2. 작업이 모든 페이지에서 구현되는 것은 아닙니다. 즉, 일부 페이지 또는 일부 파티션/디렉토리의 경우 데이터가 전혀 수집되지 않거나 부분적으로만 수집됩니다. 이러한 상황을 방지하기 위해 체크리스트를 작성할 수 있습니다. 어떤 경우에는 하나의 기능에 대해 최대 100개의 검사를 수행할 수 있습니다.
3. 모든 매개변수가 구현되는 것은 아닙니다. 즉, dataLayer는 부분적으로만 구현됩니다.
4. 향상된 전자 상거래를 위한 dataLayer 체계가 손상되었습니다. 이는 장바구니에 항목 추가, 결제 단계 간 이동, 항목 클릭과 같은 이벤트에 특히 해당됩니다. 향상된 전자 상거래를 구현할 때 가장 일반적인 오류 중 하나는 Products 배열에 대괄호가 누락된 것입니다.
5. dataLayer는 null 또는 undefined 대신 빈 문자열을 사용하여 매개변수를 0으로 만듭니다. 이 경우 Google Analytics 보고서에는 빈 줄이 있습니다. null 또는 undefined를 사용하는 경우 이 옵션은 보내는 조회수에도 포함되지 않습니다.

데이터 테스트에 사용하는 도구:

• Google 애널리틱스 디버거 Chrome 확장 프로그램
• Google 태그 관리자에서 미리보기 모드를 활성화하는 데 사용할 수 있는 GTM 디버거
• 개발자 콘솔의 dataLayer 명령
• 개발자 콘솔의 네트워크 탭
• 구글 태그 어시스턴트 크롬 확장 프로그램

이러한 도구를 자세히 살펴보겠습니다.

시작하려면 브라우저에 이 확장 프로그램을 설치하고 활성화해야 합니다. 그런 다음 페이지 ID를 열고 콘솔 탭으로 이동합니다. 표시되는 정보는 확장 프로그램에서 제공한 것입니다.

이 화면은 조회수와 함께 전송되는 매개변수와 해당 매개변수에 대해 전송되는 값을 보여줍니다.

확장된 전자 상거래 블록도 있습니다. 콘솔에서 ec 로 찾을 수 있습니다.

또한 적중 크기 제한 초과와 같은 오류 메시지가 여기에 표시됩니다.

dataLayer의 구성을 확인해야 하는 경우 가장 쉬운 방법은 콘솔에 dataLayer 명령을 입력하는 것입니다.

다음은 전송되는 모든 매개변수입니다. 자세히 공부하고 확인할 수 있습니다. 사이트의 각 작업은 dataLayer에 반영됩니다. 7개의 개체가 있다고 가정해 보겠습니다. 빈 필드를 클릭하고 dataLayer 명령을 다시 호출하면 8번째 개체가 콘솔에 나타나야 합니다.

Google 태그 관리자 디버거에 액세스하려면 Google 태그 관리자 계정을 열고 미리보기 버튼을 클릭하세요.

그런 다음 사이트를 열고 페이지를 새로 고칩니다. 아래쪽 창에 해당 페이지에서 실행 중인 모든 태그를 보여주는 패널이 나타나야 합니다.

dataLayer에 추가된 이벤트는 왼쪽에 표시됩니다. 클릭하면 dataLayer의 실시간 구성을 확인할 수 있습니다.

모바일 브라우저 테스트 기능:

• 스마트폰과 태블릿에서 사이트는 적응 모드로 시작하거나 사이트의 별도 모바일 버전이 있을 수 있습니다. 데스크톱에서 사이트의 모바일 버전을 실행하면 휴대폰에서 동일한 버전과 다릅니다.
• 일반적으로 모바일 브라우저에는 확장 프로그램을 설치할 수 없습니다.
• 이를 보완하려면 사이트의 유니버설 애널리틱스 태그 또는 Google 애널리틱스 추적 코드에서 디버그 모드를 활성화해야 합니다.

모바일 애플리케이션 테스트의 특징:

• 애플리케이션 코드로 작업하려면 더 많은 기술 지식이 필요합니다.
• 적중을 가로채려면 로컬 프록시 서버가 필요합니다. 장치가 보내는 요청 수를 추적하기 위해 요청을 보낸 애플리케이션 또는 호스트 이름으로 요청을 필터링할 수 있습니다.
• 모든 조회는 측정 프로토콜 형식으로 수집되며 추가 처리가 필요합니다. 조회수가 수집되고 필터링되면 매개변수로 복사 및 구문 분석되어야 합니다. 조회 작성기, Google 스프레드시트의 수식, JavaScript 또는 Python 앱과 같은 편리한 도구를 사용하여 이를 수행할 수 있습니다. 그것은 모두 당신에게 더 편리한 것에 달려 있습니다. 또한 전송된 적중의 오류를 식별하려면 측정 프로토콜 매개변수에 대한 지식이 필요합니다.

1. USB를 통해 모바일 장치를 노트북에 연결합니다.
2. 기기에서 Chrome을 엽니다.
3. Chrome 개발자 콘솔에서 원격 기기 보고서를 엽니다.

1. 대화 상자에서 확인 을 클릭하여 장치 연결을 확인합니다. 그런 다음 검사할 탭을 선택하고 검사 를 클릭합니다.
2. 이제 브라우저에서와 같이 표준 모드에서 개발자 콘솔로 작업할 수 있습니다. 콘솔, 네트워크 및 기타와 같은 모든 친숙한 탭이 있습니다.

1. 모바일 애플리케이션으로 작업하려면 프록시 서버를 설치하고 실행해야 합니다. 찰스를 추천합니다.
2. 프록시 서버가 설치된 경우 애플리케이션이 연결하는 IP 주소를 확인하십시오.

3. 그런 다음 장치를 가져 와서 포트 8888을 사용하여 프록시 서버를 통해 Wi-Fi 연결을 구성하십시오. 이것은 Charles가 기본적으로 사용하는 포트입니다.

4. 그 후에는 조회수를 수집할 차례입니다. 애플리케이션에서 조회수는 수집을 위해 전송되지 않고 일괄 처리로 전송됩니다. 일괄 처리는 여러 요청을 보내는 데 도움이 되는 패키지된 요청입니다. 첫째, 애플리케이션 리소스를 절약합니다. 둘째, 네트워크 문제가 있는 경우 요청이 응용 프로그램에 저장되고 네트워크 연결이 다시 설정되는 즉시 하나의 공통 풀이 전송됩니다.

5. 마지막으로 수집된 데이터를 매개변수로 구문 분석(분해)하고, 순서대로 확인하고, 사양에 대해 확인해야 합니다.

이 단계가 가장 빠르고 쉽습니다. 동시에 Google Analytics에서 수집된 데이터가 의미가 있는지 확인합니다. 보고서에서 수백 가지의 다양한 시나리오를 확인하고 장치, 브라우저 등에 따라 지표를 볼 수 있습니다. 데이터에서 이상을 발견하면 특정 장치 및 특정 브라우저에서 스크립트를 재생할 수 있습니다.

또한 Google Analytics 보고서를 사용하여 dataLayer로 전송된 데이터의 완전성을 확인할 수 있습니다. 즉, 각 시나리오에 따라 변수가 채워지고 모든 매개 변수가 있는지 여부, 매개 변수가 올바른 값을 취하는지 여부 등입니다.

우리는 가장 유용한 보고서를 공유하고자 합니다(우리 의견으로는). 데이터 수집 체크리스트로 사용할 수 있습니다.

• 전자상거래 보고서:
  • 제품 성능
  • 제품 목록 성능
  • 내부 프로모션
• 행동 — 이벤트 — 인기 이벤트
• 획득 — 캠페인 — 비용 분석
• 맞춤 보고서 — 예를 들어 중복 주문을 표시하는 보고서

이러한 보고서가 인터페이스에서 어떻게 보이는지, 어떤 보고서에 먼저 주의를 기울여야 하는지 알아보겠습니다.

이 보고서에서 가장 중요한 탭은 쇼핑 행동입니다. 강화된 전자상거래의 각 단계에서 데이터 수집의 완전성을 분석합니다. 즉, Google Analytics가 상품 목록 보기, 클릭, 상품 상세 보기, 장바구니로/에서 상품 추가/삭제, 구매 자체를 전송하는지 알 수 있습니다.

여기서 우리는 무엇에 주목해야 할까요? 첫째, 열에 값이 0이면 매우 이상합니다. 둘째, 이전 단계보다 특정 단계에 더 많은 값이 있는 경우 데이터 수집에 문제가 있을 수 있습니다. 예를 들어, 항목의 고유 구매 수가 결제 수보다 많다고 가정해 보겠습니다. 그것은 이상하고주의를 기울일 가치가 있습니다.

또한 이 보고서의 다른 매개변수 간에 전환할 수 있으며 이 매개변수는 향상된 전자상거래로도 전송되어야 합니다. 예를 들어, 항목 범주를 기본 옵션으로 선택하면 특정 범주의 항목에 대한 판매가 있지만 이러한 항목에 대한 보기가 없고 장바구니에 추가되는 등이 표시되지 않을 수 있습니다.

먼저 Google Analytics로 전송되는 모든 매개변수를 살펴보고 각 매개변수가 어떤 값을 취하는지 확인해야 합니다. 일반적으로 모든 것이 괜찮은지 즉시 확인됩니다. 각 이벤트에 대한 보다 자세한 분석은 사용자 정의 보고서에서 수행할 수 있습니다.

비용 데이터를 Google Analytics로 가져오는 것을 확인하는 데 유용할 수 있는 또 다른 표준 보고서는 비용 분석입니다.

일부 소스 또는 광고 캠페인에 대한 비용이 있지만 세션이 없는 보고서를 종종 봅니다. 이는 UTM 태그의 문제 또는 오류로 인해 발생할 수 있습니다. 또는 Google Analytics의 필터가 특정 소스의 세션을 제외할 수 있습니다. 이러한 보고서는 수시로 확인해야 합니다.

중복 거래를 추적할 수 있는 맞춤 보고서를 강조하고 싶습니다. 설정은 매우 쉽습니다. 매개변수는 트랜잭션 ID여야 하고 키 차원은 트랜잭션이어야 합니다.

보고서에 둘 이상의 거래가 있는 경우 동일한 주문에 대한 정보가 두 번 이상 전송되었음을 의미합니다.

비슷한 문제를 발견하면 해결 방법에 대한 자세한 지침을 읽으십시오.

Google Analytics에는 보고서를 보지 않고도 중요한 변경 사항을 추적할 수 있는 매우 우수한 맞춤 알림 도구가 있습니다. 예를 들어 Google 애널리틱스 세션에 대한 정보 수집을 중단하면 이메일 알림을 받을 수 있습니다.

최소한 다음 네 가지 지표에 대한 알림을 설정하는 것이 좋습니다.

• 세션 수
• 이탈률
• 수익
• 거래 수

우리의 경험에 따르면 이것은 가장 어렵고 시간이 많이 걸리는 작업입니다. 실수가 가장 흔한 협소한 선입니다.

DataLayer 구현과 관련된 문제를 방지하려면 검사를 일주일에 한 번 이상 수행해야 합니다. 일반적으로 빈도는 사이트에서 변경 사항을 구현하는 빈도에 따라 달라집니다. 이상적으로는 중요한 변경 사항이 있을 때마다 dataLayer를 테스트해야 합니다. 이 작업을 수동으로 수행하는 것은 시간이 많이 걸리므로 프로세스를 자동화하기로 결정했습니다.

테스트를 자동화하기 위해 다음을 수행할 수 있는 클라우드 기반 솔루션을 구축했습니다.

• 사이트의 dataLayer 변수가 참조 값과 일치하는지 확인
• Google 태그 관리자 코드의 가용성 및 기능 확인
• 데이터가 Google Analytics 및 OWOX BI로 전송되는지 확인
• Google BigQuery에서 오류 보고서 수집

테스트 자동화의 장점:

• 테스트 속도를 크게 높입니다. 경험상 몇 시간 만에 수천 페이지를 테스트할 수 있습니다.
• 인적 요소를 배제하여 보다 정확한 결과를 얻을 수 있습니다.
• 더 적은 수의 전문가가 필요하므로 테스트 비용을 낮춥니다.
• 사이트를 변경할 때마다 테스트를 실행할 수 있으므로 테스트 빈도를 늘립니다.

우리가 사용하는 알고리즘의 단순화된 체계:

앱에 로그인할 때 확인하려는 페이지를 지정해야 합니다. CSV 파일을 업로드하거나 사이트맵에 대한 링크를 지정하거나 단순히 사이트 URL을 지정하면 됩니다. 이 경우 애플리케이션은 사이트맵 자체를 찾습니다.

그런 다음 테스트할 각 시나리오(페이지, 이벤트, 스크립트)에 대해 dataLayer 체계를 지정하는 것이 중요합니다(체크아웃과 같은 일련의 작업). 그런 다음 정규식을 사용하여 페이지 유형이 URL과 일치하도록 지정할 수 있습니다.

이 모든 정보를 수신한 후 애플리케이션은 모든 페이지와 이벤트를 예정대로 실행하고 각 스크립트를 확인하고 테스트 결과를 Google BigQuery에 업로드합니다. 이 데이터를 기반으로 이메일 및 Slack 알림을 설정합니다.

PS 전체 웹사이트 감사가 필요한 경우 OWOX BI에 컨설팅 서비스를 요청할 수 있습니다. 데모에 등록하면 가능성에 대해 논의하겠습니다.