측정 프로토콜

측정 프로토콜은 언제 사용하나요?

온라인 행동과 오프라인 상담·매장 구매를 연결하거나, 서버에서 발생한 처리 결과, 자동 수집을 지원하지 않는 기기의 이벤트를 보낼 때 사용합니다. Measurement Protocol 개요는 이 방식이 gtag, GTM, Firebase의 자동 수집을 보완하며 대체하지 않는다고 명시합니다. 기존 태깅에서 얻은 사용자·세션 문맥을 적절히 연결해야 보고서가 끊기지 않습니다.

요청에는 어떤 정보가 필요한가요?

웹 스트림 요청은 측정 ID와 API 비밀키를 엔드포인트에 넣고, 본문에 client_id 또는 user_id와 events 배열을 보냅니다. Measurement Protocol 참조는 한 요청에 최대 25개 이벤트, 이벤트명과 매개변수 제한, session_id와 engagement_time_msec 같은 공통 매개변수를 설명합니다. API 비밀키는 브라우저 코드나 공개 저장소에 노출하지 않아야 합니다.

검증 성공과 보고 반영은 같은가요?

아닙니다. 요청이 HTTP로 접수되어도 이벤트 의미, 매개변수 형식, 세션 연결, 중복 여부가 올바르다는 보장은 없습니다. 기본 검증은 RELAXED이며 더 엄격한 ENFORCE_RECOMMENDATIONS 옵션을 사용할 수 있습니다. 개발 중에는 Validation Server와 DebugView, Realtime을 거쳐 표준 보고서 반영까지 확인합니다.

운영에서 무엇을 조심하나요?

브라우저 이벤트와 서버 이벤트가 같은 거래를 보내면 transaction_id나 이벤트 ID 기준의 중복 처리가 필요합니다. 과거 이벤트 전송 가능 시간, 타임스탬프, 동의·개인정보, 실패 재시도도 설계해야 합니다. 가상 예시로 CRM 계약 완료를 generate_lead로 보낼 때 웹 폼 제출 이벤트와 별개 단계임을 명시하고, 사용자 동의 범위 안에서 식별자를 연결합니다. 접근 권한이 없어 결과를 못 보면 이벤트 0건이 아니라 전송·수집 미검증입니다.

이벤트 수신을 어떻게 대조하나요?

서버 발송 로그의 요청 ID·이벤트 시각·응답 코드와 GA4의 DebugView·Realtime 표본을 연결합니다. 그 뒤 표준 보고서에서 기간별 수량을 확인하되 처리 지연을 감안합니다. 재시도 요청이 같은 거래를 중복 생성하지 않는지, 오프라인 시각이 보고 시간대에서 어느 날짜로 들어가는지도 테스트합니다.

자주 묻는 질문

측정 프로토콜이 웹 태그를 완전히 대체하나요?

아닙니다. 서버 간·오프라인 이벤트를 보완하는 방식이며 자동 태깅과 사용자·세션 문맥을 자동으로 대신하지 않습니다.

HTTP 요청이 성공하면 보고서도 정확한가요?

아닙니다. 접수 성공과 의미 검증, 중복 처리, 사용자·세션 연결, 최종 보고 반영은 별도로 확인해야 합니다.

출처와 확인 범위

1. GA4 Measurement Protocol 개요 · Google for Developers · 확인 2026-10-27

   Measurement Protocol은 서버 간·오프라인 이벤트를 보완하며 자동 태깅을 대체하지 않습니다.

   확인 범위: 사용자·세션 문맥 연결과 동의 처리가 별도로 필요합니다.

2. GA4 Measurement Protocol 참조 · Google for Developers · 확인 2026-10-27

   요청에는 API 비밀키와 이벤트 배열 등이 필요하며 이벤트·매개변수 제한과 검증 방식이 있습니다.

   확인 범위: HTTP 접수 성공만으로 보고 의미와 중복 처리가 정확하다는 뜻은 아닙니다.

함께 이해할 용어