[GA4>M 활용] GA4 구성 시 피해야 할 실수 5가지 (2부) : 맞춤 측정기준부터 내부 트래픽까지
핵심 요약 (한 줄 답변)
GA4 데이터 품질을 유지하려면 ① 이벤트마다 별도의 매개변수 이름을 만들지 말고, ② 데이터 보관 기간을 미리 14개월로 변경하며, ③ 운영·테스트 환경의 데이터를 분리해야 합니다. 또한 ④ 내부 트래픽과 원치 않는 추천을 제외하고, ⑤ SPA에서는 이벤트가 실행될 때마다 최신 매개변수 값을 보내야 합니다.
이 글에서 알 수 있는 것
- GA4 맞춤 측정기준 한도를 낭비하지 않는 매개변수 설계 방법
- 탐색 분석에서 과거 데이터가 보이지 않는 이유와 해결 방법
- 운영 사이트와 테스트 사이트의 데이터를 분리해야 하는 이유
- 사내 접속과 결제·로그인 도메인이 성과 데이터에 미치는 영향
- SPA에서 이전 페이지 정보가 계속 수집되는 문제의 해결 방법
✳️ 난이도 : 중급 | 소요 시간: 약 8분 | 대상 : GA4를 직접 설정하거나 데이터 오류를 점검하는 마케터·데이터 분석가·개발자·쇼핑몰 운영자
“GA4는 설치했는데, 왜 시간이 지날수록 데이터가 이상해질까?”
GA4를 처음 설치했을 때는 이벤트가 정상적으로 들어오는지만 확인하기 쉽습니다. 하지만 실제 데이터 품질은 이벤트가 수집된 이후의 설정과 운영 방식에 따라 크게 달라집니다.
처음에는 문제가 없어 보여도 이벤트와 매개변수가 늘어나면 맞춤 측정기준 한도에 도달할 수 있습니다. 데이터 보관 기간을 변경하지 않으면 탐색 분석에서 과거 데이터를 확인하기 어려워지고, 테스트 사이트와 사내 직원의 접속이 섞이면 실제 고객 성과도 왜곡됩니다.
이 글에서는 앞선 1부에 이어 GA4를 구성할 때 자주 발생하는 나머지 다섯 가지 실수와 해결 방법을 정리합니다. 원문 2부에서 다루는 항목은 맞춤 측정기준, 데이터 보관, 운영·테스트 환경, 내부 트래픽·추천, 구성 태그의 매개변수 값 문제입니다.
한눈에 보는 GA4 설정 실수 5가지
| # | 실수 | 발생하는 문제 | 해결 방법 |
| 6 | 이벤트마다 고유한 매개변수 이름 사용 | 맞춤 측정기준 한도를 빠르게 소진 | 같은 의미는 공통 매개변수로 통일 |
| 7 | 데이터 보관 기간을 기본값으로 유지 | 탐색 분석에서 오래된 데이터 확인 불가 | 속성 생성 직후 14개월로 변경 |
| 8 | 운영·테스트 사이트가 같은 속성으로 데이터 전송 | 테스트 이벤트와 실제 성과가 혼합 | 운영용과 테스트용 GA4 속성 분리 |
| 9 | 내부 트래픽과 원치 않는 추천 미설정 | 사용자 수·전환·유입 경로 왜곡 | 내부 트래픽 필터와 원치 않는 추천 설정 |
| 10 | Google 태그에 동적 값을 고정 설정 | SPA에서 이전 페이지 값이 계속 전송 | 이벤트 실행 시점에 최신 값을 다시 전달 |
실수 6. 이벤트마다 고유한 매개변수 이름을 만드는 것
GA4에서 이벤트마다 서로 다른 매개변수 이름을 만들면 맞춤 측정기준 한도를 빠르게 소진합니다. 같은 의미의 데이터는 하나의 공통 매개변수 이름으로 통일해야 합니다.
예를 들어 웹사이트에서 클릭된 위치를 수집한다고 가정해 보겠습니다.
다음처럼 이벤트마다 별도의 매개변수를 만들 수 있습니다.
| 이벤트 | 비권장 매개변수 |
| 상담 신청 버튼 클릭 | consulting_button_position |
| 뉴스레터 신청 클릭 | newsletter_button_position |
| 자료 다운로드 클릭 | download_button_position |
| 회원가입 버튼 클릭 | signup_button_position |
각 매개변수를 GA4 보고서나 탐색 분석에서 사용하려면 맞춤 측정기준으로 등록해야 합니다. 이벤트가 늘어날수록 맞춤 측정기준도 계속 추가되기 때문에 한도에 빠르게 도달합니다.
GA4 표준 속성에서는 현재 이벤트 범위 맞춤 측정기준 50개, 사용자 범위 맞춤 측정기준 25개, 항목 범위 맞춤 측정기준 10개를 만들 수 있습니다. Google 역시 맞춤 정의를 만들기 전에 기존에 제공되는 측정기준과 측정항목을 먼저 사용하도록 권장합니다.
같은 의미는 하나의 매개변수로 통일하세요
위의 매개변수는 모두 ‘버튼이 클릭된 위치’라는 같은 의미를 가집니다. 따라서 다음과 같이 하나의 공통 매개변수로 설계하는 것이 좋습니다.
| 항목 | 권장 설정 |
| 이벤트 이름 | 실제 사용자 행동에 따라 구분 |
| 공통 매개변수 | interaction_position |
| 매개변수 값 | header, body, footer, popup 등 |
예를 들면 다음과 같습니다.
{
event: "consulting_request",
interaction_position: "header"
}{
event: "newsletter_signup",
interaction_position: "footer"
}
이벤트 이름은 다르지만 위치를 나타내는 매개변수는 모두 interaction_position으로 통일됩니다. 이렇게 하면 맞춤 측정기준 하나만 등록해 여러 이벤트의 클릭 위치를 함께 분석할 수 있습니다.
매개변수 이름을 정하기 전 확인할 사항
- GA4에 이미 제공되는 기본 측정기준이 있는가?
- 다른 이벤트에서도 같은 의미로 사용할 수 있는가?
- 이벤트 이름이 달라져도 매개변수의 의미는 동일한가?
- 사내 이벤트·매개변수 명명 규칙에 포함되어 있는가?
- 담당자가 바뀌어도 의미를 이해할 수 있는 이름인가?
✅ 핵심 : 이벤트마다 새로운 매개변수 이름을 만드는 것이 아니라, 같은 의미에는 같은 이름을 사용하는 데이터 설계 규칙이 필요합니다.
매개변수 이름과 고유 값의 개수는 다른 문제입니다
매개변수 이름의 수뿐 아니라 하나의 측정기준에 너무 많은 고유 값이 들어가는 것도 주의해야 합니다.
예를 들어 사용자 ID, 주문번호, 전체 타임스탬프처럼 값이 거의 매번 달라지는 항목을 맞춤 측정기준으로 등록하면 고유 값이 지나치게 많아질 수 있습니다. 이런 고카디널리티 측정기준은 보고서에서 데이터가 (other) 행으로 묶이는 원인이 될 수 있습니다.
따라서 매개변수를 설계할 때는 다음 두 가지를 함께 확인해야 합니다.
- 매개변수 이름을 불필요하게 많이 만들고 있지 않은가?
- 하나의 측정기준에 지나치게 많은 고유 값이 들어가지는 않는가?
실수 7. 데이터 보관 기간을 기본값으로 두는 것
GA4 탐색 분석에서 장기간 데이터를 비교하려면 이벤트 데이터 보관 기간을 14개월로 변경해야 합니다. 기본 설정인 2개월을 그대로 두면 탐색 분석에서 오래된 사용자·이벤트 수준 데이터를 사용할 수 없습니다.
GA4에는 크게 두 가지 형태의 분석 기능이 있습니다.
| 구분 | 주요 용도 | 데이터 보관 설정의 영향 |
| 표준 보고서 | 트래픽·사용자·이벤트 현황 확인 | 집계된 표준 보고서는 동일한 방식으로 만료되지 않음 |
| 탐색 분석 | 자유 형식, 경로, 유입경로, 세그먼트 분석 | 속성의 데이터 보관 기간에 따라 조회 가능 범위 제한 |
표준 GA4 속성의 이벤트 데이터 보관 기간은 2개월 또는 14개월로 설정할 수 있습니다. 탐색 분석의 날짜 범위는 해당 속성의 데이터 보관 설정에 영향을 받습니다.
예를 들어 현재가 12월인데 데이터 보관 기간이 2개월로 설정되어 있다면, 탐색 분석에서 상반기 사용자 행동을 다시 분석하기 어려울 수 있습니다.
데이터 보관 기간 변경 방법
① GA4 왼쪽 하단의 [관리] 로 이동합니다.
② 속성의 [데이터 수집 및 수정] 메뉴를 확인합니다.
③ [데이터 보관] 을 선택합니다.
④ 이벤트 데이터 보관 기간을 14개월로 변경합니다.
⑤ 설정을 저장합니다.
메뉴 이름은 GA4 화면 업데이트에 따라 일부 달라질 수 있지만, 데이터 보관 설정은 속성의 관리 영역에서 변경할 수 있습니다.
데이터 보관 기간은 언제 변경해야 하나요?
GA4 속성을 생성한 직후 변경하는 것이 가장 좋습니다.
데이터가 이미 오래된 뒤 보관 기간을 늘린다고 해서 이전에 보관 대상에서 제외된 데이터를 모두 복구할 수 있는 것은 아닙니다. 따라서 장기적인 전환 분석이나 사용자 행동 분석을 계획하고 있다면 데이터가 쌓이기 전에 설정해야 합니다.
✅ 핵심 : 탐색 분석을 장기간 활용할 계획이라면 데이터가 필요해진 뒤가 아니라, GA4를 처음 설정할 때 보관 기간부터 14개월로 변경하세요.
실수 8. 운영 사이트와 테스트 사이트의 데이터를 한 속성에 보내는 것
운영 사이트와 개발·테스트 사이트의 데이터를 동일한 GA4 속성으로 전송하면 테스트 이벤트가 실제 사용자 성과에 포함될 수 있습니다. 가장 안전한 방법은 운영용 속성과 테스트용 속성을 분리하는 것입니다.
웹사이트를 운영하다 보면 일반적으로 여러 환경이 존재합니다.
- 실제 고객이 방문하는 운영 환경
- 기능을 개발하는 개발 환경
- 배포 전 기능을 확인하는 스테이징 환경
- 이벤트 태그를 검수하는 테스트 환경
이 환경들이 모두 같은 GA4 측정 ID를 사용하면 다음과 같은 문제가 발생할 수 있습니다.
- 개발자가 반복한 페이지 조회가 실제 조회수에 포함됨
- 테스트 주문이 실제 구매 이벤트에 포함됨
- 테스트 회원가입이 실제 전환으로 집계됨
- 동일한 이벤트가 여러 환경에서 발생해 중복처럼 보임
- 테스트용 URL이 콘텐츠 보고서에 노출됨
- 광고 성과와 자연 유입 데이터가 왜곡됨
비교나 세그먼트만으로 해결하기 어려운 이유
일부에서는 호스트 이름이나 페이지 URL을 기준으로 비교·세그먼트를 만들어 테스트 데이터를 제외합니다.
하지만 비교와 세그먼트는 이미 수집된 데이터에서 특정 조건만 골라 보는 분석 기능입니다. 테스트 데이터가 속성에 들어오는 것 자체를 막아주지는 않습니다.
즉, 필터 조건을 빠뜨리거나 다른 담당자가 기본 보고서를 확인하면 테스트 데이터가 포함된 결과를 볼 수 있습니다.
가장 권장되는 환경 구성
| 환경 | 권장 GA4 구성 |
| 운영 사이트 | 운영 전용 GA4 속성 |
| 개발·스테이징 사이트 | 테스트 전용 GA4 속성 |
| GTM 컨테이너 | 환경별 측정 ID 분기 |
| 배포 전 검수 | 테스트 속성의 실시간 보고서와 DebugView 사용 |
운영과 테스트 속성을 분리하면 테스트 이벤트를 자유롭게 실행해도 실제 성과 데이터에 영향을 주지 않습니다.
속성을 분리하기 어려운 경우
불가피하게 하나의 속성을 사용해야 한다면 최소한 다음 조치를 적용해야 합니다.
- 개발 환경에서는 디버그 모드를 사용합니다.
- GA4에 개발자 트래픽 데이터 필터를 만듭니다.
- 필터 상태를 바로 ‘활성’으로 바꾸지 말고 먼저 ‘테스트’로 검증합니다.
- 테스트가 완료된 후 제외 필터를 활성화합니다.
GA4는 디버그 모드에서 발생한 개발자 트래픽을 제외할 수 있는 데이터 필터를 제공합니다. 다만 제외 필터를 활성화하면 해당 데이터는 처리되지 않으며 이후 복구할 수 없으므로 테스트 상태에서 먼저 확인해야 합니다.
✅ 핵심 : 운영 데이터와 테스트 데이터를 나중에 구분하려 하지 말고, 수집 단계에서부터 서로 다른 속성으로 분리하세요.
실수 9. 내부 트래픽과 원치 않는 추천을 제외하지 않는 것
회사 직원의 접속과 결제·로그인 과정에서 발생하는 외부 도메인을 그대로 수집하면 사용자 수, 전환율, 유입 경로, 광고 기여도가 왜곡됩니다. 내부 트래픽과 원치 않는 추천은 각각 별도로 설정해야 합니다.
두 설정은 모두 데이터 품질과 관련되어 있지만 해결하려는 문제는 다릅니다.
| 구분 | 의미 | 대표 사례 |
| 내부 트래픽 | 고객이 아닌 회사 내부 구성원의 방문 | 직원, 개발자, 대행사, 운영 담당자 |
| 원치 않는 추천 | 실제 유입처로 판단하면 안 되는 외부 도메인 | PG사, 본인인증, 외부 로그인, 예약·결제 모듈 |
내부 트래픽을 제외해야 하는 이유
회사 직원은 일반 고객보다 사이트에 훨씬 자주 접속합니다.
콘텐츠를 검수하기 위해 같은 페이지를 반복해서 열고, 문의 기능을 확인하며, 테스트 구매나 회원가입을 실행할 수도 있습니다.
이 데이터가 그대로 수집되면 다음 지표가 달라집니다.
- 사용자 수와 세션 수 증가
- 페이지 조회수 증가
- 내부 검색어 왜곡
- 전환 이벤트 증가
- 참여율과 평균 참여 시간 변화
- 특정 지역이나 기기의 비중 증가
특히 방문자 수가 많지 않은 B2B 사이트나 초기 서비스에서는 직원 몇 명의 반복 접속만으로도 전체 지표가 크게 달라질 수 있습니다.
내부 트래픽 제외 방법
일반적인 설정 순서는 다음과 같습니다.
- 웹 데이터 스트림의 Google 태그 설정에서 내부 트래픽 규칙을 정의합니다.
- 회사나 작업 환경의 IP 주소를 등록합니다.
- GA4 관리 메뉴에서 내부 트래픽 데이터 필터를 만듭니다.
- 필터를 ‘테스트’ 상태로 적용합니다.
- 탐색 분석에서 필터 대상 데이터가 올바른지 확인합니다.
- 검증이 끝난 후 ‘활성’ 상태로 변경합니다.
GA4의 내부 트래픽 필터는 traffic_type 매개변수와 일치하는 이벤트를 제외하는 방식으로 동작합니다. 제외 필터는 데이터에 영구적으로 적용되므로 먼저 테스트 상태로 검증해야 합니다. Google 지원
원치 않는 추천이란 무엇인가요?
사용자가 쇼핑몰에서 결제를 진행한다고 가정해 보겠습니다.
- 사용자가 검색광고를 통해 쇼핑몰에 방문합니다.
- 상품을 장바구니에 담습니다.
- 외부 PG사 페이지로 이동해 결제를 완료합니다.
- 결제 후 쇼핑몰의 완료 페이지로 돌아옵니다.
이때 설정이 잘못되어 있으면 GA4는 최초 광고가 아니라 PG사 도메인을 마지막 유입처로 인식할 수 있습니다.
비슷한 문제는 다음 과정에서도 발생합니다.
- 소셜 로그인
- 본인인증
- 외부 예약 서비스
- 간편결제
- 타사 장바구니
- 외부 회원 인증
- 별도 결제 도메인
원치 않는 추천 설정의 목적
원치 않는 추천 목록에 도메인을 등록하면 해당 도메인을 새로운 추천 유입처로 사용하지 않도록 처리할 수 있습니다. 즉, 결제나 인증 과정에서 잠시 거쳐 간 도메인이 실제 마케팅 유입처를 덮어쓰는 문제를 줄이는 설정입니다.
단, 원치 않는 추천 설정은 해당 사용자의 이벤트를 삭제하는 기능이 아닙니다. ‘내부 트래픽 제외’와 ‘원치 않는 추천’은 서로 다른 기능이므로 목적에 맞게 각각 설정해야 합니다.
✅ 핵심 : 직원 방문은 내부 트래픽 필터로 제외하고, 결제·로그인 도메인은 원치 않는 추천으로 설정해 실제 고객과 실제 유입처가 유지되도록 해야 합니다.
실수 10. Google 태그에 동적 매개변수를 고정값처럼 설정하는 것
SPA에서 페이지나 사용자 상태에 따라 바뀌는 값을 Google 태그의 초기 설정에만 넣으면, 이후 이벤트에도 이전 값이 계속 전달될 수 있습니다. 동적으로 변하는 값은 이벤트가 실행될 때마다 최신 값으로 평가해 보내야 합니다.
이 문제는 특히 SPA(Single Page Application) 에서 자주 발생합니다.
SPA는 사용자가 다른 화면으로 이동해도 브라우저 전체 페이지를 다시 불러오지 않습니다. 주소와 화면 내용만 변경되기 때문에 처음 페이지가 열릴 때 설정한 값이 계속 남아 있을 수 있습니다.
어떤 문제가 발생하나요?
사용자가 다음 순서로 이동한다고 가정해 보겠습니다.
- /home 페이지 방문
- /product 페이지 이동
- /checkout 페이지 이동
- 구매 버튼 클릭
하지만 페이지가 새로고침되지 않고, 페이지 관련 매개변수를 초기 설정에서만 읽었다면 구매 이벤트에 다음과 같은 잘못된 정보가 포함될 수 있습니다.
{
event: "purchase",
page_location: "/home"
}
실제 구매가 발생한 페이지는 /checkout이지만 초기 페이지인 /home이 계속 전달되는 것입니다.
이 문제는 다음과 같은 동적 값에서 발생할 수 있습니다.
- 현재 페이지 URL
- 페이지 제목
- 콘텐츠 카테고리
- 로그인 여부
- 회원 등급
- 상품 ID
- 장바구니 금액
- 가상 페이지 이름
- 이전 페이지 정보
해결 방법
동적으로 변하는 값은 다음 중 한 가지 방식으로 구성해야 합니다.
- GA4 이벤트 태그의 이벤트 매개변수에 직접 추가
- GTM의 이벤트 설정 변수를 사용해 공통 매개변수 구성
- 이벤트 발생 시점에 데이터 레이어의 최신 값을 다시 읽기
- SPA 화면 전환 시 가상 page_view 이벤트 전송
GTM에서는 무엇을 확인해야 하나요?
SPA에서 GTM을 사용한다면 다음 흐름으로 점검하는 것이 좋습니다.
- 화면 전환 시 데이터 레이어 이벤트가 발생하는지 확인합니다.
- 화면 전환 이후 URL과 페이지 제목이 갱신되었는지 확인합니다.
- 갱신된 값이 GTM 변수에 들어오는지 확인합니다.
- GA4 이벤트 태그가 해당 시점의 최신 변수를 사용하는지 확인합니다.
- Tag Assistant와 GA4 DebugView에서 실제 전송값을 검증합니다.
Google 태그의 전역 설정이나 set 명령으로 지정된 값은 이후 페이지 내 이벤트에 연결될 수 있습니다. 동적 값은 가능한 한 이벤트 명령이나 이벤트 태그에서 명시적으로 보내는 것이 안전합니다. Google for Developers
✅ 핵심 : 페이지가 새로고침되지 않는 SPA에서는 ‘처음 읽은 값’이 아니라, 각 이벤트가 발생한 순간의 최신 값을 전송해야 합니다.
결론 : GA4 데이터 품질은 설치 이후의 운영 방식이 결정한다
GA4 설정은 태그를 설치하고 이벤트가 들어오는 것을 확인했다고 끝나는 작업이 아닙니다.
이벤트와 매개변수의 명명 규칙, 데이터 보관 기간, 운영·테스트 환경, 내부 접속, 외부 결제 도메인, SPA의 페이지 전환 방식까지 함께 관리해야 신뢰할 수 있는 데이터가 만들어집니다.
“GA4 데이터 오류는 분석 단계가 아니라 수집·설정 단계에서 시작된다.”
특히 다음 세 가지는 GA4 속성을 만들거나 개편할 때 바로 점검하는 것이 좋습니다.
- 데이터 보관 기간이 14개월로 설정되어 있는가?
- 운영 사이트와 테스트 사이트가 분리되어 있는가?
- 내부 트래픽과 결제·로그인 도메인이 올바르게 처리되어 있는가?
이미 잘못 수집된 데이터를 보고서에서 완벽하게 되돌리기는 어렵습니다. 따라서 문제가 발생한 뒤 보고서에서 보정하는 것보다, 데이터를 수집하기 전에 규칙을 세우는 것이 중요합니다.
자주 묻는 질문 FAQ
Q. GA4 맞춤 측정기준은 몇 개까지 만들 수 있나요?
A. GA4 표준 속성에서는 이벤트 범위 맞춤 측정기준 50개, 사용자 범위 25개, 항목 범위 10개를 만들 수 있습니다. 이벤트마다 별도의 매개변수를 만들지 말고, 같은 의미의 데이터는 공통 매개변수로 통일하는 것이 좋습니다.
Q. 매개변수를 수집하면 모두 맞춤 측정기준으로 등록해야 하나요?
A. 아닙니다. 모든 매개변수를 반드시 등록할 필요는 없습니다. 하지만 GA4 보고서나 탐색 분석에서 해당 매개변수를 측정기준으로 사용하려면 일반적으로 맞춤 정의가 필요합니다. 먼저 GA4에 동일한 기본 측정기준이 제공되는지 확인하세요.
Q. GA4 데이터 보관 기간을 14개월로 변경하면 표준 보고서도 달라지나요?
A. 데이터 보관 설정은 주로 탐색 분석에서 사용하는 사용자·이벤트 수준 데이터의 조회 가능 기간에 영향을 줍니다. 표준 보고서의 집계 데이터와 탐색 분석의 데이터 보관 방식은 다릅니다. 장기 탐색 분석이 필요하다면 14개월로 설정하는 것이 좋습니다.
Q. 테스트 사이트는 별도의 GA4 속성을 꼭 만들어야 하나요?
A. 필수 규칙은 아니지만 데이터 오염을 가장 확실하게 막는 방법입니다. 동일한 속성을 사용해야 한다면 개발자 트래픽 필터를 먼저 테스트 상태로 적용하고, 실제 데이터가 잘못 제외되지 않는지 검증해야 합니다.
Q. 내부 트래픽 필터를 적용하면 과거 직원 데이터도 삭제되나요?
A. 아닙니다. 데이터 필터는 활성화 이후 들어오는 데이터에 적용됩니다. 이미 수집된 과거 데이터를 자동으로 삭제하거나 수정하지 않습니다. 또한 활성 상태에서 제외된 데이터는 복구할 수 없으므로 먼저 테스트 상태로 확인해야 합니다.
Q. 결제 대행사 도메인은 내부 트래픽으로 제외해야 하나요?
A. 아닙니다. 결제 대행사나 외부 로그인 도메인은 일반적으로 ‘원치 않는 추천’으로 설정합니다. 내부 트래픽 필터는 직원이나 개발자처럼 고객이 아닌 내부 방문을 제외하는 기능입니다.
Q. 원치 않는 추천에 도메인을 등록하면 해당 방문이 삭제되나요?
A. 방문이나 이벤트가 삭제되는 것은 아닙니다. 해당 도메인을 새로운 추천 유입처로 판단하지 않도록 처리해, 결제·인증 과정의 외부 도메인이 원래 유입 경로를 덮어쓰는 문제를 줄입니다.
Q. SPA에서는 페이지 조회를 어떻게 수집해야 하나요?
A. 브라우저 기록 변경을 감지하는 향상된 측정을 사용하거나, 화면 전환 시 가상 page_view 이벤트를 직접 전송할 수 있습니다. 어떤 방식을 사용하든 page_location, page_title, page_referrer가 화면 전환 이후의 최신 값인지 확인해야 합니다.
요약 (한 장 정리)
- 실수 6 : 이벤트마다 고유한 매개변수 이름 생성 → 같은 의미는 공통 매개변수 이름으로 통일
- 실수 7 : 데이터 보관 기간을 기본 2개월로 유지 → 속성 생성 직후 14개월로 변경
- 실수 8 : 운영·테스트 사이트 데이터를 같은 속성에 전송 → 운영용과 테스트용 GA4 속성 분리
- 실수 9 : 내부 트래픽과 원치 않는 추천 미설정 → 직원 접속은 내부 필터, 결제·로그인 도메인은 원치 않는 추천으로 설정
- 실수 10 : SPA의 동적 값을 초기 설정에만 저장 → 이벤트 발생 시점마다 최신 매개변수 값을 전송
작성 : 디애널리틱스(The Analytics) · 구글애널리틱스를 활용하여 기업의 마케팅 성과를 향상시키는 방법을 연구합니다.