GA4에서 세션 소스/매체에 (not set)이 보이는 이유

세션 소스/매체에 (not set)이 보인다면

GA4에서 보고서 → 획득 → 트래픽 획득을 열고 측정기준을 "세션 소스/매체"로 바꿔보면, (not set) 행이 눈에 띕니다. 유입 경로를 분석하려고 보고서를 열었는데, 정작 어디서 왔는지 모르는 데이터가 상당량을 차지하고 있으면 당황스럽습니다.

여기서 먼저 짚어야 할 점이 있습니다. 세션 소스/매체의 (not set)은 direct/(none)과 다릅니다. direct/(none)은 "유입 경로 정보(referrer, UTM)가 없는 트래픽"이고, (not set)은 "GA4가 해당 세션의 소스/매체 값 자체를 아직 확정하지 못했거나, 확정할 수 없는 상태"입니다. direct/(none)이 많은 경우에 대해서는 GA4 direct/none 트래픽 가이드에서 별도로 다루고 있습니다.

이 글에서는 세션 소스/매체에 (not set)이 나타나는 실제 원인을 하나씩 짚고, 각각 어떻게 대응하면 되는지를 초보자 눈높이에서 정리합니다.

원인 1. 데이터 처리가 아직 끝나지 않았다 (어제·당일 데이터)

가장 흔하고, 가장 먼저 의심해야 할 원인입니다.

GA4는 데이터를 실시간으로 완전하게 처리하지 않습니다. 이벤트가 수집된 후 GA4 내부에서 세션을 구성하고, 각 세션에 소스/매체를 할당하는 과정이 별도로 진행됩니다. 이 처리에는 24~48시간이 걸릴 수 있습니다.

그래서 "어제" 또는 "오늘" 날짜의 데이터를 보면 (not set) 비중이 유독 높게 나타납니다. GA4가 아직 해당 세션들의 소스/매체를 확정하지 못했기 때문입니다. 며칠 후 같은 날짜 데이터를 다시 확인하면 (not set)이 줄어들고, 실제 소스/매체 값으로 채워져 있는 것을 볼 수 있습니다.

확인 방법

트래픽 획득 보고서에서 날짜 범위를 바꿔가며 비교합니다.

• 어제/오늘 데이터: (not set) 비중이 높다면 → 처리 지연일 가능성이 큽니다.
• 3~7일 전 데이터: (not set)이 거의 없다면 → 처리 지연이 원인이었음이 확인됩니다.
• 3~7일 전 데이터에서도 (not set)이 많다면 → 다른 원인을 점검해야 합니다.

대응

데이터 분석을 할 때 최소 2~3일 전까지의 데이터를 기준으로 보는 습관을 들이면 됩니다. 어제/오늘 데이터는 참고용으로만 활용하고, 정확한 소스/매체 분석은 데이터 처리가 완료된 시점의 데이터로 합니다.

원인 2. 브라우저 비활성 상태에서 세션이 재개되었다

사용자가 사이트를 방문한 뒤 브라우저 탭을 그대로 둔 채 30분 이상 아무 행동도 하지 않으면, GA4는 해당 세션이 종료된 것으로 판단합니다(GA4의 세션 타임아웃 기본값은 30분입니다). 이후 사용자가 같은 탭으로 돌아와서 다시 클릭이나 스크롤 등 행동을 시작하면, GA4는 새로운 세션을 시작합니다.

문제는 이 새 세션이 시작되는 시점에 session_start 이벤트가 발생하지만, 사용자가 이미 사이트 안에 있는 상태이므로 외부 유입 정보(referrer)가 존재하지 않는다는 점입니다. 일반적인 새 세션이라면 외부에서 들어오면서 referrer나 UTM이 붙지만, 비활성 탭 복귀는 외부 유입이 아니기 때문에 GA4가 소스/매체를 결정할 근거가 없습니다.

이 경우 GA4는 소스/매체를 direct/(none)이 아닌 (not set)으로 처리하는 경우가 있습니다. GA4의 세션 처리 로직에서 이런 "탭 복귀" 세션은 일반적인 유입과 다르게 취급되기 때문입니다.

어떤 상황에서 자주 발생하는가

• 콘텐츠가 긴 블로그나 뉴스 사이트에서 사용자가 글을 열어두고 나중에 돌아오는 패턴
• 업무용 웹 앱에서 탭을 오래 열어두는 습관이 있는 사용자
• 모바일에서 앱 전환 후 브라우저로 복귀하는 경우

대응

이 원인은 사용자 행동 패턴에 의한 것이므로 완전히 방지할 수 없습니다. 다만, GA4 관리자 설정에서 세션 타임아웃 시간을 조정하면 빈도를 줄일 수 있습니다. 기본값인 30분이 사이트 특성에 비해 너무 짧다면 늘려볼 수 있지만, 타임아웃을 늘리면 세션 수가 줄어들고 세션당 체류 시간이 늘어나므로 다른 지표에도 영향을 줍니다. 신중하게 판단해야 합니다.

원인 3. Measurement Protocol로 전송된 이벤트

Measurement Protocol은 서버에서 GA4로 직접 이벤트를 전송하는 방식입니다. 브라우저의 gtag.js나 GTM을 통하지 않고, 서버 코드에서 GA4 수집 엔드포인트로 HTTP 요청을 보내는 구조입니다.

오프라인 전환 추적, 서버 사이드 이벤트, CRM 연동 등에서 사용됩니다. 예를 들어 "결제 완료" 이벤트를 결제 서버에서 직접 GA4로 전송하는 경우가 대표적입니다.

문제는 Measurement Protocol로 전송되는 이벤트에는 브라우저 세션 정보가 포함되지 않을 수 있다는 점입니다. 서버에서 보내는 요청이므로 referrer도 없고, 브라우저 쿠키 기반의 세션 ID도 없거나 올바르게 연결되지 않을 수 있습니다. GA4 입장에서는 이 이벤트가 어떤 세션에 속하는지, 어떤 소스/매체를 통해 유입된 사용자의 행동인지를 알 수 없으므로 (not set)으로 처리합니다.

확인 방법

개발팀에 Measurement Protocol을 사용하는 이벤트가 있는지 확인합니다. 또는 GA4 보고서에서 (not set) 세션의 이벤트 이름을 살펴봅니다. 특정 이벤트(예: purchase, refund, 커스텀 서버 이벤트)에만 (not set)이 집중되어 있다면 Measurement Protocol이 원인일 가능성이 높습니다.

GA4의 탐색(Explore) 보고서에서 행에 "세션 소스/매체"와 "이벤트 이름"을 함께 배치하면, (not set) 세션에서 어떤 이벤트가 발생하는지 확인할 수 있습니다.

대응

Measurement Protocol로 이벤트를 전송할 때 session_id와 client_id를 올바르게 포함시키면, GA4가 해당 이벤트를 기존 브라우저 세션에 연결할 수 있습니다. 서버에서 이벤트를 보내기 전에 브라우저 측에서 client_id와 session_id를 서버로 전달하는 구조를 만들어야 합니다.

다만 이 작업은 개발 리소스가 필요하며, 모든 경우에 완벽하게 연결할 수 있는 것은 아닙니다. Measurement Protocol을 통한 이벤트에서 (not set)이 나타나는 것은 어느 정도 구조적 한계로 받아들여야 할 수 있습니다.

원인 4. 잠재고객 트리거 이벤트

GA4에서 잠재고객(Audience)을 설정할 때, 사용자가 해당 잠재고객 조건을 충족하면 자동으로 이벤트를 발생시키는 잠재고객 트리거 기능이 있습니다. 예를 들어 "7일 이내 3회 이상 방문한 사용자"라는 잠재고객을 만들고 트리거를 설정하면, 조건을 충족하는 순간 GA4가 자동으로 이벤트를 기록합니다.

이 이벤트는 사용자의 실제 행동(클릭, 페이지뷰 등)이 아니라 GA4 시스템이 내부적으로 생성하는 이벤트입니다. 따라서 특정 세션에 귀속되지 않으며, 세션 소스/매체 정보가 존재하지 않습니다. 결과적으로 (not set)으로 표시됩니다.

확인 방법

GA4 관리자 화면에서 속성 → 데이터 표시 → 잠재고객으로 이동하여, 잠재고객 트리거가 설정된 항목이 있는지 확인합니다. 트리거 이벤트 이름은 보통 잠재고객 생성 시 직접 지정하므로, 해당 이벤트 이름이 (not set) 세션에 집중되어 있는지 탐색 보고서에서 확인할 수 있습니다.

대응

잠재고객 트리거 이벤트는 구조적으로 세션 소스/매체가 없는 것이 정상입니다. 이 이벤트가 (not set) 비중을 높이고 있다면, 트래픽 획득 보고서를 분석할 때 해당 이벤트를 필터로 제외하거나, 탐색 보고서에서 잠재고객 트리거 이벤트를 별도로 분리하여 분석하는 것이 맞습니다.

잠재고객 트리거가 꼭 필요하지 않다면 비활성화하는 것도 방법입니다. 하지만 Google Ads 리마케팅 등에서 활용 중이라면 함부로 끄지 않도록 주의합니다.

원인 5. 그 외 원인들

위 4가지 외에도 세션 소스/매체가 (not set)으로 나타날 수 있는 상황이 있습니다.

추적 코드 설치 누락

특정 페이지에만 GA4 추적 코드가 설치되지 않았다면, 해당 페이지에서 시작된 세션은 소스/매체 정보가 불완전하게 수집될 수 있습니다. 특히 랜딩 페이지, 서브도메인, 결제 페이지 등 별도로 관리되는 페이지가 누락되는 경우가 많습니다.

확인: GTM 미리보기 모드로 각 페이지를 이동하면서 GA4 태그가 실행되는지 점검합니다.

GA4 속성 간 데이터 스트림 설정 문제

하나의 사이트에 여러 GA4 속성이 연결되어 있거나, 데이터 스트림 설정이 잘못된 경우에도 세션 정보가 올바르게 연결되지 않을 수 있습니다.

확인: GA4 관리자 → 데이터 스트림에서 활성 스트림이 올바른지, Measurement ID가 중복 설치되어 있지 않은지 확인합니다.

데이터 필터 또는 보고서 필터의 영향

GA4에서 데이터 필터(내부 트래픽 제외 등)를 적용했거나, 보고서에 특정 필터를 걸었을 때 세션 정보가 왜곡되어 보이는 경우가 있습니다. 필터 자체가 (not set)을 만드는 것은 아니지만, 필터가 적용된 상태에서 보고서를 보면 일부 세션의 소스/매체가 누락된 것처럼 보일 수 있습니다.

확인: 보고서에 적용된 필터와 비교 조건을 제거한 뒤 다시 확인합니다.

(not set) 대응 정리

분석 관점에서의 대응

실무에서 (not set)을 다루는 원칙

1. 먼저 날짜를 확인합니다. (not set) 비중이 높다고 느껴지면 가장 먼저 보고 있는 데이터의 날짜 범위를 확인합니다. 어제/오늘 데이터라면 2~3일 후에 다시 확인하는 것만으로 해결되는 경우가 많습니다.

2. 3일 이상 지난 데이터에서도 (not set)이 많다면 원인을 좁힙니다. 탐색 보고서에서 (not set) 세션의 이벤트 이름을 확인합니다. 특정 이벤트에 집중되어 있다면 Measurement Protocol이나 잠재고객 트리거가 원인일 가능성이 높습니다.

3. 구조적 (not set)은 분석에서 분리합니다. Measurement Protocol이나 잠재고객 트리거에서 발생하는 (not set)은 없앨 수 없는 구조적 현상입니다. 이런 데이터는 트래픽 소스 분석에서 제외하고 별도로 관리하는 것이 데이터 품질을 높이는 방법입니다.

4. (not set) 비중을 모니터링합니다. 3일 이상 지난 데이터 기준으로 세션 소스/매체의 (not set) 비중이 5% 이하라면 정상 범위입니다. 이 수치가 갑자기 높아졌다면 추적 코드 누락이나 설정 변경이 있었는지 점검합니다.

정리

GA4에서 세션 소스/매체의 (not set)에 대해 기억해야 할 핵심은 세 가지입니다.

1. 가장 흔한 원인은 데이터 처리 지연입니다. 어제·당일 데이터에서 (not set)이 많이 보인다면, 2~3일 후에 다시 확인하면 대부분 해소됩니다.
2. 비활성 탭 복귀, Measurement Protocol, 잠재고객 트리거 이벤트는 구조적으로 (not set)이 발생합니다. 이들은 설정 오류가 아니며, 분석 시 분리해서 다루는 것이 맞습니다.
3. 3일 이상 지난 데이터에서도 (not set) 비중이 높다면 추적 코드 설치와 GTM 설정을 점검합니다. 전체 페이지에 추적 코드가 빠짐없이 설치되어 있는지가 가장 먼저 확인할 항목입니다.