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

세션 소스/매체의 (not set)은 무엇인가요?

GA4(Google Analytics 4)는 웹사이트와 앱의 이용 현황을 분석하는 도구입니다. 세션은 일정 시간 이어지는 이용 활동의 묶음입니다. 소스는 유입 출처, 매체는 유입 방식으로, google / organic은 구글 자연 검색 유입을 뜻합니다.

세션 소스/매체의 (not set)은 GA4가 그 분류에 필요한 정보를 받지 못했다는 표시입니다. 단순히 처리를 기다리는 상태라고 단정할 수 없습니다. Google은 자동 수집 이벤트인 session_start가 빠진 세션을 원인으로 안내합니다. 이벤트는 페이지 조회나 구매처럼 기록하는 행동이고, session_start는 세션 시작을 나타냅니다. Google의 (not set) 원인 안내

보고서에서 측정기준은 소스처럼 데이터를 나누는 항목이고, 측정항목은 세션 수처럼 집계한 숫자입니다. 먼저 항목 이름을 정확히 확인합니다.

주요 이벤트는 사업에서 중요하게 보는 행동으로 지정한 이벤트입니다. 앞에 ‘세션’이 없는 이벤트 범위의 소스/매체는 주요 이벤트가 아닌 이벤트에서 (not set)으로 표시될 수 있습니다. 서로 다른 항목의 빈값을 같은 수집 오류로 판단하지 마세요. 트래픽 소스의 범위 설명

(direct) / (none)은 명확한 유입 출처를 확인하지 못해 직접 유입으로 분류된 값입니다. (not set)과 같지 않습니다. Unassigned는 기본 채널 분류 규칙에 맞지 않는 경우의 이름으로, 역시 별도 항목입니다. Direct가 궁금하다면 Direct 트래픽 가이드를 참고하세요.

먼저 세션 수와 조회 조건을 기록하세요

아직 GA4 접근 권한이 없다면 아래 가상 예제로 먼저 연습해도 됩니다. 실제 계정에서는 설정 변경 없이 조회부터 합니다.

1. Google Analytics에서 담당 사이트의 속성을 선택합니다. 속성은 데이터를 모아 관리하는 단위입니다.
2. 보고서 → 획득 → 트래픽 획득을 엽니다. 메뉴가 다르면 보고서 검색에서 ‘트래픽 획득’을 찾습니다.
3. 표의 첫 번째 열에서 세션 소스/매체를 선택합니다. 날짜와 현재 비교 조건, 필터를 기록합니다.
4. 같은 화면의 전체 세션 수, (not set) 행의 세션 수, 조회 시각을 적습니다. ‘이벤트 수’를 세션 수로 옮겨 적지 않습니다.

예를 들어 전체 200세션 중 (not set)이 20세션이라면 비중은 20 ÷ 200 × 100 = 10%입니다. 이 숫자는 원인이나 정상 여부를 알려주지 않습니다. 전체가 0이면 비율은 계산하지 않고 ‘세션 없음’으로 적습니다.

필요한 보고서나 속성이 보이지 않으면 담당자에게 조회 권한과 보고서 위치를 요청하세요. 확인하려고 새 속성을 만들거나 태그를 다시 설치할 필요는 없습니다.

1. 최근 데이터라면 같은 날짜를 다시 확인합니다

GA4 데이터 처리는 24~48시간 걸릴 수 있고 처리 중 보고서 값이 바뀔 수 있습니다. 그렇다고 모든 (not set)이 기다리면 사라진다는 뜻은 아닙니다. 데이터 처리 시간 안내

오늘 조회한 ‘어제’ 데이터를 나중에도 날짜를 직접 지정해 다시 조회하세요. 나중에 다시 ‘어제’를 선택하면 다른 날짜를 보게 됩니다. 속성, 측정기준, 필터와 비교 조건도 같아야 합니다.

다음은 재조회 방법을 설명하기 위한 가상 수치입니다.

이 예에서는 같은 날짜의 미분류 세션이 줄었습니다. 처리 과정의 영향을 의심할 근거는 생겼지만, 남은 4세션의 원인까지 밝혀진 것은 아닙니다. 실제로는 전체 세션 수도 바뀔 수 있으므로 매번 분자와 분모를 모두 기록합니다.

반대로 ‘어제는 10%, 일주일 전은 2%’라는 비교만으로는 처리 지연을 확인할 수 없습니다. 두 날짜의 방문 경로나 설정이 달랐을 수도 있습니다. 며칠 지난 같은 날짜에서도 값이 그대로이거나 문제가 남으면 다음 항목으로 넘어갑니다. 값이 줄지 않았다는 사실만으로 특정 설정 오류가 확정되는 것은 아닙니다.

2. session_start 수집과 동의 처리를 점검합니다

Google Tag Manager(GTM)는 사이트의 측정 태그를 관리하는 도구입니다. Google은 GA4 설정 태그의 실행 시점과 session_start 누락을 점검하도록 안내하며, Google 태그에 Initialization - All Pages 트리거를 사용하는 방법을 설명합니다. 트리거는 태그가 실행되는 조건입니다. Google의 세션 소스/매체 점검 절차

처음 다루는 분은 바로 트리거를 바꾸거나 게시하지 말고 담당자에게 다음 내용을 전달하세요.

해당 날짜의 세션 소스/매체에 (not set)이 남아 있습니다. 첨부한 조건으로 조회했으며, 첫 방문 페이지에서 Google 태그와 session_start가 정상적으로 수집되는지 확인을 부탁드립니다. 최근 태그 배포와 동의 배너 변경도 함께 확인해 주세요.

동의 모드는 사용자의 동의 상태에 맞춰 Google 태그의 동작을 조정하는 기능입니다. 동의 상태를 잘못 갱신하는 구현도 원인이 될 수 있습니다. 동의 배너를 제거하거나 사용자의 선택을 무시하는 방식으로 해결하지 않습니다.

개발 담당자는 GTM 미리보기 등의 점검 환경에서 태그 실행 순서, 첫 진입 페이지, 측정 ID와 동의 상태 변화를 확인할 수 있습니다. 측정 ID는 데이터를 받을 대상을 가리키는 식별자입니다. ID가 여러 개라는 이유만으로 중복 오류라고 단정하지 말고, 의도한 전송 대상과 비교해야 합니다.

한편 이벤트 목록 전체에 session_start가 보인다고 해서 문제가 된 각 세션에도 있다는 뜻은 아닙니다. 전체 이벤트 수 두 개만 비교해서 누락 세션 수를 계산하지 마세요.

3. 서버에서 보낸 이벤트는 연결 조건을 확인합니다

Measurement Protocol은 서버 등에서 GA4로 이벤트를 직접 보내는 방식입니다. 예를 들어 결제 서버가 결제 완료 이벤트를 전송할 수 있습니다. 기존 웹이나 앱 수집을 보완하는 용도이며, 이것만으로 모든 보고서가 완전하게 구성되는 것은 아닙니다. Measurement Protocol 소개

서버 이벤트라고 해서 세션 정보가 반드시 없는 것은 아닙니다. 개발 담당자가 웹의 client_id 또는 앱의 app_instance_id 등 해당 이용 기록과의 연결을 확인해야 합니다. 이들은 브라우저나 앱 설치를 구분하는 식별자이며, session_id는 세션을 구분하는 값입니다. 또한 온라인 세션과 같은 출처로 보고하려면 다음 조건을 점검합니다.

• 해당 세션의 session_id를 포함했는지 확인합니다.
• 온라인 세션 시작 후 24시간 이내에 요청을 보냈는지 확인합니다.
• 이벤트 시각이 그 온라인 세션의 시작과 종료 사이인지 확인합니다.

ID만 임의로 채워 넣는 것으로 해결할 수 없습니다. 실제로 나중에 발생한 일을 과거 세션에 넣으려고 발생 시각을 바꾸어서도 안 됩니다. Google의 세션 연결 조건

구매를 뜻하는 purchase나 환불을 뜻하는 refund 같은 이벤트에 (not set)이 집중된다면 서버 전송 여부를 물어볼 단서가 됩니다. 하지만 이벤트 이름만으로 서버에서 보냈다고 확정할 수는 없습니다. 먼저 ‘어디서 보내는 이벤트인지’를 확인합니다.

4. 잠재고객 트리거를 자동으로 제외하지 않습니다

잠재고객은 ‘일정 횟수 이상 방문한 이용자’처럼 조건으로 묶은 사용자 집단입니다. 잠재고객 트리거는 사용자가 그 조건을 만족할 때 이벤트를 만드는 기능입니다.

이 이벤트가 GA4 내부에서 생성된다고 해서 세션 정보가 전혀 없는 것은 아닙니다. 현재 공식 설명은 조건을 충족시킨 이벤트에서 세션 정보와 시각 같은 부가 정보인 메타데이터를 복사한다고 안내합니다. 여러 이벤트가 조건을 충족시키면 마지막 이벤트의 정보를 사용합니다. 페이지나 화면 정보는 복사 대상에 포함되지 않습니다. 잠재고객 트리거 설명

따라서 잠재고객 트리거라는 이유만으로 (not set)을 정상으로 처리하거나 트리거를 삭제하지 않습니다. 담당자에게 트리거 이벤트 이름을 받아, 실제로 어떤 항목이 비어 있는지 확인합니다. 페이지 정보 누락과 세션 소스 누락은 같은 문제가 아닙니다.

이벤트별로 살펴봐야 한다면 별도 탐색 보고서를 만들 수 있습니다. 탐색은 표의 항목을 직접 구성해 분석하는 기능입니다. 행에 ‘세션 소스/매체’와 ‘이벤트 이름’, 값에 ‘이벤트 수’를 넣으면 해당 조합의 이벤트 발생 횟수를 볼 수 있습니다. 이 표의 숫자는 세션 수가 아닙니다. 처음 기록한 세션 비중과 혼합하지 마세요.

탭을 오래 열어두면 무조건 (not set)이 되나요?

탭 복귀 사실만으로 원인을 확정할 수 없습니다. 일정 시간 활동이 없으면 세션이 끝날 수 있지만, ‘탭을 오래 열어두었다 → 외부 유입이 아니다 → 반드시 (not set)’이라는 설명은 성립하지 않습니다. 실제 새 세션의 시작 정보와 이벤트 수집을 확인해야 합니다.

(not set)을 줄이겠다는 이유만으로 세션 타임아웃부터 늘리지 마세요. 세션을 구분하는 기준 자체가 바뀌어 이전 기간과의 비교에도 영향을 줍니다. 이 글의 첫 점검은 시간 설정 변경이 아니라, 같은 조건의 보고서 재조회와 수집 상태 확인입니다.

담당자에게 전달할 메모를 완성해 보세요

아래는 앞의 가상 데이터를 옮긴 예입니다. 실제 요청에서는 사이트와 속성 이름도 적습니다. 계정 비밀번호나 API 비밀키는 필요하지 않습니다.

문제를 숨기기 위해 운영 데이터 필터를 새로 만들거나 기존 필터를 해제하지 않습니다. 보고서에 보이는 비교 조건을 바꿔 확인했다면 변경 전후 조건을 따로 기록하세요. 이벤트를 제외한 분석이 필요해도 원본 보고서와 분리하고, 제외한 범위와 분모를 표시해야 합니다.

혼자 다시 확인하기

10월 5일 데이터가 500세션 중 40세션이고, 일주일 전 데이터가 400세션 중 8세션입니다. 무엇을 말할 수 있을까요?

비중은 각각 8%와 2%입니다. 하지만 다른 날짜의 차이이므로 처리 지연이 원인이라고 확정할 수 없습니다. 10월 5일을 같은 조건으로 다시 조회할 시점을 정하고, 계속 남는 값은 수집 상태와 연결 조건을 확인합니다.

5% 이하면 정상으로 봐도 되나요?

모든 사이트에 적용할 수 있는 공통 정상 기준으로 사용하지 마세요. 비중이 작아도 중요한 결제 데이터에 집중되면 조사할 이유가 있습니다. 비율뿐 아니라 건수, 발생 시점, 영향을 받는 이벤트와 업무 중요도를 함께 봅니다.

3줄 요약

1. 세션 소스/매체의 (not set)은 해당 분류값을 받지 못했다는 뜻이며 원인이 모두 같지는 않습니다.

2. 최근 데이터는 같은 날짜와 조건으로 다시 확인하고, 계속 남는 값은 session_start 수집과 이벤트 연결을 점검합니다.

3. 서버 이벤트나 잠재고객 트리거라고 해서 세션 정보가 반드시 없는 것은 아니며 5%라는 공통 정상 기준도 없습니다.