etc

6. Event란 무엇인가?

6.1 이벤트는 페이지 외의 행동이다

페이지뷰가 “페이지를 열었다”는 기록이라면, 이벤트는 페이지 안에서 발생한 행동입니다.

예시:

예를 들어 사용자가 구매 버튼을 클릭하면:

이벤트 이름: purchase_button_clicked
페이지: /products/123
시간: 10:04

같은 기록을 보낼 수 있습니다.

6.2 이벤트는 페이지뷰와 다르다

사용자가 상품 페이지를 열고 구매 버튼을 클릭했다고 하겠습니다.

페이지뷰 1회
구매 버튼 클릭 이벤트 1회

버튼을 클릭했다고 해서 페이지뷰가 추가되는 것은 아닙니다.

반대로 페이지를 열었다고 해서 구매 이벤트가 발생한 것도 아닙니다.

각 행동을 따로 기록해야 합니다.

6.3 이벤트에는 이름이 필요하다

이벤트는 보통 이름을 가집니다.

signup_started
signup_completed
download_clicked
add_to_cart
purchase_completed

이름이 명확해야 나중에 분석할 수 있습니다.

좋은 이벤트 이름:

checkout_completed

나쁜 이벤트 이름:

button_clicked

button_clicked는 어떤 버튼인지 알 수 없기 때문입니다.

더 좋은 방식은:

pricing_button_clicked
download_resume_clicked
purchase_button_clicked

입니다.

6.4 이벤트에는 추가 정보가 붙을 수 있다

이벤트 이름만으로 부족할 때는 추가 정보를 함께 보냅니다.

예를 들어 상품 추가 이벤트는 다음과 같이 기록할 수 있습니다.

이벤트 이름: add_to_cart
상품 ID: product_123
상품 카테고리: shoes
가격: 59000
페이지: /products/123

이 추가 정보를 이벤트 속성이라고 부를 수 있습니다.

다만 개인정보를 넣으면 안 됩니다.

잘못된 예:

이메일: user@example.com
전화번호: 010-1234-5678
이름: 홍길동

분석 이벤트에는 개인을 직접 알아볼 수 있는 정보를 보내지 않는 것이 기본 원칙입니다.

6.5 이벤트는 중복될 수 있다

사용자가 버튼을 한 번 클릭했는데 네트워크 문제로 같은 이벤트가 두 번 전송될 수 있습니다.

실제 클릭: 1회
분석 기록: 2회

또는 사용자가 버튼을 빠르게 두 번 클릭할 수도 있습니다.

실제 클릭: 2회
주문: 1건

그래서 중요한 이벤트는 중복 처리가 필요합니다.

예를 들어 결제 완료 이벤트에는 주문 번호를 함께 보낼 수 있습니다.

주문 번호: order_123

분석 시스템이 같은 주문 번호를 다시 받으면 한 번만 처리하도록 만들 수 있습니다.

7. Conversion이란 무엇인가?

7.1 전환은 사업적으로 중요한 이벤트다

전환은 특별한 종류의 이벤트입니다.

모든 이벤트가 전환은 아닙니다.

예를 들어:

행동이벤트전환
메뉴 열기예보통 아니오
동영상 재생예경우에 따라
PDF 다운로드예경우에 따라
회원가입 완료예예
결제 완료예예
문의 제출예예

전환은 서비스의 목표에 따라 달라집니다.

7.2 전환은 제품마다 다르다

블로그

전환:

SaaS

전환:

쇼핑몰

전환:

포트폴리오 사이트

전환:

따라서 “전환”은 기술적으로 고정된 단어가 아니라, 사업 목표를 분석 데이터에 연결한 것입니다.

7.3 전환율이란 무엇인가?

전환율은 방문 중 얼마나 많은 방문이 목표를 달성했는지를 나타내는 비율입니다.

예를 들어:

방문: 1,000회
회원가입 완료: 50회

전환율은:

50 ÷ 1,000 × 100 = 5%

입니다.

즉:

전환율 = 전환 수 ÷ 기준이 되는 방문 수 × 100

다만 기준을 무엇으로 잡는지에 따라 결과가 달라집니다.

방문 기준 전환율

회원가입을 완료한 방문 ÷ 전체 방문

방문자 기준 전환율

회원가입을 완료한 방문자 ÷ 전체 방문자

페이지뷰 기준 전환율

구매 수 ÷ 상품 페이지뷰

어떤 기준을 사용하는지 반드시 명시해야 합니다.

7.4 한 사람이 여러 번 전환할 수 있다

한 사람이 한 번 방문해서 두 번 구매할 수도 있습니다.

방문자: 1명
방문: 1회
구매 전환: 2회

따라서 전환 수가 방문자 수보다 클 수 있습니다.

이때 다음을 구분해야 합니다.

예를 들어:

구매 전환 횟수: 10회
구매한 방문자 수: 7명

일 수 있습니다.

7.5 전환은 분석의 최종 목적에 가깝다

페이지뷰와 방문자는 상황을 보여줍니다.

전환은 사업 결과를 보여줍니다.

방문자가 늘었다
→ 좋은 현상일 수 있음

회원가입이 늘었다
→ 더 중요한 결과

결제가 늘었다
→ 사업적으로 가장 직접적인 결과

그래서 웹 분석 서비스를 만들 때는 단순히 방문자 숫자만 보여주는 것보다, 사용자가 원하는 목표를 직접 측정할 수 있게 하는 것이 중요합니다.

+++ # 8. 전체 개념을 하나의 흐름으로 보기

다음 사용자의 행동을 다시 살펴보겠습니다.

10:00 홈페이지 접속
10:01 상품 목록 접속
10:02 상품 상세 접속
10:03 상품 상세 새로고침
10:04 구매 버튼 클릭
10:05 결제 완료

분석 시스템에서는 다음과 같이 해석할 수 있습니다.

8.1 히트 관점

분석 서버에 기록된 데이터:

히트 1: 홈페이지 페이지뷰
히트 2: 상품 목록 페이지뷰
히트 3: 상품 상세 페이지뷰
히트 4: 상품 상세 페이지뷰
히트 5: 구매 버튼 클릭 이벤트
히트 6: 결제 완료 이벤트

총 6개의 분석 기록입니다.

8.2 페이지뷰 관점

페이지가 열린 횟수:

홈페이지: 1
상품 목록: 1
상품 상세: 2

총 4페이지뷰입니다.

8.3 방문 관점

사용자가 짧은 시간 안에 계속 활동했으므로:

방문: 1회

입니다.

8.4 방문자 관점

분석 기준상 이전에 보지 못한 익명 방문자라면:

방문자: 1명으로 추정

입니다.

8.5 이벤트 관점

페이지를 여는 것 외의 행동:

구매 버튼 클릭: 1회
결제 완료: 1회

입니다.

8.6 전환 관점

사업 목표가 “결제 완료”라면:

전환: 1회

입니다.

+++

+++ # 9. 자주 혼동하는 사례

사례 1. 한 사람이 페이지를 10번 새로고침했다

페이지뷰: 10
방문: 보통 1
방문자: 보통 1
이벤트: 별도 이벤트가 없다면 0
전환: 별도 목표를 달성하지 않았다면 0

페이지뷰가 10이라고 해서 사람 10명이 아닙니다.

사례 2. 한 사람이 휴대폰과 노트북으로 방문했다

실제 사람: 1명
분석상 방문자: 2명으로 보일 수 있음
방문: 2회일 수 있음

기기를 구분하는 방식에 따라 달라집니다.

사례 3. 한 사람이 한 달 동안 매일 방문했다

방문자: 1명으로 추정
방문: 약 30회
페이지뷰: 방문당 페이지 수에 따라 달라짐

재방문이 많은 서비스인지 판단할 수 있습니다.

사례 4. 네 명이 같은 컴퓨터를 사용했다

실제 사람: 4명
분석상 방문자: 1명처럼 보일 수 있음

익명 분석의 한계입니다.

사례 5. 사용자가 구매 버튼을 두 번 눌렀다

버튼 클릭 이벤트: 2회
결제 완료: 1회일 수 있음
실제 주문: 1건일 수 있음

클릭 이벤트와 사업 데이터는 구분해야 합니다.

사례 6. 페이지를 열었지만 광고 차단기가 작동했다

실제 페이지 방문: 발생
분석 페이지뷰: 기록되지 않을 수 있음

웹 분석 숫자는 실제 세상보다 작게 측정될 수 있습니다.

사례 7. 봇이 페이지를 열었다

검색엔진이나 자동 프로그램이 페이지를 열 수 있습니다.

실제 사람 방문: 0명
페이지 요청: 여러 건

그래서 분석 서비스는 봇을 제외할지 결정해야 합니다.

+++

10 .숫자를 말할 때의 규칙

다음처럼 말하면 안 됩니다.

어제 사용자가 1,000명이었어요.

“사용자”가 무엇인지 불분명하기 때문입니다.

대신 이렇게 말해야 합니다.

어제 익명 방문자 추정치는 1,000명이었습니다.

또는:

어제 방문은 1,200회였고, 페이지뷰는 3,500회였습니다.

또는:

어제 상품 페이지뷰는 3,500회였고, 구매 완료 전환은 70회였습니다.

분석 숫자를 말할 때는 항상 다음 네 가지를 함께 말하는 습관을 가져야 합니다.

무엇을 세었는가?
어느 기간인가?
어떤 조건으로 필터링했는가?
숫자의 한계는 무엇인가?

예를 들어:

2026년 8월 1일 하루 동안
봇을 제외하고
익명 방문 기준으로 계산한
방문자 추정치는 1,000명

11. 데이터는 브라우저에서 분석 서버로 전송된다

사용자가 웹사이트에서 행동하면, 그 행동이 분석 서버로 전달되어야 합니다.

전체 흐름은 다음과 같습니다.

사용자 행동
  → 분석 코드가 행동을 감지
  → 분석 서버로 데이터 전송
  → 데이터 검사
  → 데이터 형태 정리
  → 데이터 저장
  → 숫자로 집계
  → 대시보드에 표시

예를 들어 사용자가 상품 페이지를 열었다고 하겠습니다.

사용자가 /products/123 접속
  → 웹사이트의 분석 코드 실행
  → /products/123 정보를 분석 서버로 전송
  → 분석 서버가 데이터 검사
  → 상품 페이지 조회 수에 1 추가
  → 대시보드에 표시

11.1 사용자가 행동한다

가장 먼저 실제 행동이 발생합니다.

예를 들면:

분석 시스템은 사용자의 모든 행동을 수집하는 것이 아니라, 서비스가 기록하도록 정한 행동만 수집합니다.

11.2 분석 코드가 행동을 감지한다

웹사이트에는 분석 코드를 설치합니다.

가장 흔한 방식은 JavaScript입니다.

<script src="analytics.js"></script>

이 코드는 페이지가 열렸는지, 버튼이 클릭됐는지 등을 감지합니다.

버튼 클릭을 감지하는 예시는 다음과 같습니다.

<button data-event="signup_clicked">
  회원가입
</button>

분석 코드는 이 버튼이 클릭되면 다음과 같은 기록을 만들 수 있습니다.

이벤트 이름: signup_clicked
페이지: /pricing
발생 시간: 10:05

11.3 분석 서버로 데이터를 보낸다

분석 코드는 기록을 분석 서버의 주소로 보냅니다.

이 주소를 보통 Endpoint라고 부릅니다.

Endpoint는 어렵게 생각할 필요 없이:

분석 데이터를 받는 서버 주소

입니다.

예를 들면:

https://analytics.example.com/collect

분석 코드는 이 주소로 데이터를 보냅니다.

{
  "type": "pageview",
  "path": "/products/123",
  "timestamp": "2026-08-07T10:00:00Z"
}

11.4 데이터 검증

분석 서버는 받은 데이터를 바로 저장하지 않습니다.

먼저 데이터가 정상인지 확인합니다.

예를 들어 다음을 검사할 수 있습니다.

이 과정을 검증이라고 합니다.

쉽게 말하면:

분석 서버가 받은 데이터가 믿을 만한 형태인지 확인하는 단계

입니다.

11.5 데이터 정규화

같은 페이지가 여러 가지 형태로 들어올 수 있습니다.

/products/123
/products/123/
https://example.com/products/123

분석 서비스가 이것들을 모두 다른 페이지로 저장하면 통계가 나뉩니다.

그래서 저장하기 전에 형태를 통일할 수 있습니다.

예를 들면:

/products/123
/products/123/

를 모두 다음처럼 저장합니다.

/products/123

이 과정을 정규화라고 합니다.

정규화할 수 있는 항목은 다음과 같습니다.

11.6 데이터 저장

검증과 정규화가 끝난 데이터는 저장됩니다.

저장할 수 있는 정보는 다음과 같습니다.

사이트
페이지 경로
이벤트 이름
발생 시간
유입 경로
브라우저
운영체제
국가
화면 크기
익명 방문 식별자

여기서 중요한 점은 원본 데이터를 모두 저장할지 결정하는 것입니다.

원본 데이터를 저장하는 방식

장점:

단점:

집계된 숫자만 저장하는 방식

예를 들어 원본 방문 기록 대신 다음만 저장할 수 있습니다.

2026-08-07
/products/123
페이지뷰 1,200회

장점:

단점:

11.7 저장된 데이터를 집계한다

분석 서버는 저장된 기록을 숫자로 바꿉니다.

예를 들어 원본 기록이 다음과 같다고 하겠습니다.

10:00 /products/123
10:01 /products/123
10:03 /products/456
10:05 /products/123

이를 페이지별로 합치면:

/products/123: 3회
/products/456: 1회

이렇게 원본 기록을 의미 있는 숫자로 바꾸는 것을 집계라고 합니다.

11.8 대시보드에 표시한다

마지막으로 집계된 데이터를 사용자가 볼 수 있게 보여줍니다.

오늘 페이지뷰: 4,000
인기 페이지: /products/123
주요 유입 경로: Google
전환율: 4.2%

사용자가 보는 화면은 마지막 결과일 뿐입니다.

그 뒤에서는:

수집
→ 검증
→ 정규화
→ 저장
→ 집계
→ 조회

라는 과정이 일어납니다.

11.9 데이터를 받는 방법

웹 분석 서비스가 데이터를 받는 방법은 여러 가지입니다.

방식 1. JavaScript

웹페이지에 분석 스크립트를 설치합니다.

<script
  async
  src="https://analytics.example.com/script.js">
</script>

장점

단점

대부분의 웹사이트에서는 가장 먼저 JavaScript 방식을 사용합니다.

방식 2. Tracking Pixel

아주 작은 이미지 요청을 이용하는 방식입니다.

<img
  src="https://analytics.example.com/pixel.gif?page=/about"
  alt="">

이미지가 로드되면 분석 서버가 페이지뷰를 기록합니다.

장점

단점

방식 3. 서버 API

웹 브라우저가 아니라 웹사이트 서버가 직접 분석 서버에 데이터를 보냅니다.

사용자 결제 완료
  → 쇼핑몰 서버가 주문 확인
  → 분석 서버에 결제 완료 전송

장점

단점

결제나 회원가입 같은 중요한 전환은 서버 API로 기록하는 것이 더 안정적일 수 있습니다.

방식 4. 로그파일 가져오기

웹서버가 이미 기록해둔 로그파일을 분석 서비스로 가져오는 방식입니다.

예를 들어 웹서버 로그에 다음 기록이 있다고 하겠습니다.

2026-08-07 10:00 GET /products/123
2026-08-07 10:01 GET /products/123

이 로그를 읽어서 페이지뷰를 계산할 수 있습니다.

장점

단점

12. “무엇을 봤는가”와 “누가 보았는가”를 분리한다

분석 데이터를 볼 때 가장 중요한 구분 중 하나입니다.

12.1 측정값이란 무엇인가?

측정값은 숫자로 나타나는 결과입니다.

예를 들어:

방문 수: 1,000
페이지뷰 수: 3,500
이벤트 수: 700
전환 수: 50
전환율: 5%

측정값은 다음 질문에 답합니다.

얼마나 많이 발생했는가?

12.2 차원이란 무엇인가?

차원은 숫자를 나누어 보는 기준입니다.

예를 들어 전체 방문 수가 1,000회라고 하겠습니다.

이 숫자를 다음 기준으로 나눌 수 있습니다.

페이지별
국가별
캠페인별
브라우저별
날짜별

그러면 다음과 같은 결과가 나옵니다.

페이지별 방문 수
/products/123: 500
/products/456: 300
/about: 200

여기서:

입니다.

12.3 같은 숫자를 여러 방식으로 나눌 수 있다

전체 방문이 1,000회라고 하겠습니다.

페이지별로 나누면:

상품 페이지: 600
소개 페이지: 250
문의 페이지: 150

국가별로 나누면:

대한민국: 700
미국: 200
일본: 100

캠페인별로 나누면:

summer-sale: 500
newsletter: 300
직접 방문: 200

전체 방문 수는 같은 1,000회지만, 어떤 기준으로 나누느냐에 따라 화면에 보이는 결과가 달라집니다.

12.4 “페이지별 방문 수”는 무엇인가?

“페이지별 방문 수”는 새로운 종류의 숫자가 아닙니다.

다음 두 가지를 합친 표현입니다.

차원: 페이지
측정값: 방문 수

즉:

페이지별 방문 수

는 “페이지라는 기준으로 나눈 방문 수”입니다.

같은 방식으로:

국가별 페이지뷰
캠페인별 전환 수
브라우저별 방문자 수

도 만들 수 있습니다.

12.5 필터란 무엇인가?

필터는 분석할 대상을 좁히는 조건입니다.

예를 들어 전체 방문을 보지 않고:

대한민국 방문만 보기

를 선택하면 국가가 대한민국인 기록만 남깁니다.

또는:

/products로 시작하는 페이지 보기

를 선택하면 특정 경로의 데이터만 남깁니다.

차원과 필터의 차이는 다음과 같습니다.

12.6 측정값은 항상 설명이 필요하다

다음 문장은 애매합니다.

상품 페이지 성과가 좋아졌다.

무엇이 좋아졌는지 알 수 없기 때문입니다.

더 정확한 문장은 다음과 같습니다.

지난주보다 상품 페이지 방문은 20% 늘었지만, 구매 전환율은 3%에서 2%로 낮아졌습니다.

이 문장에는 두 가지 측정값이 있습니다.

12.7 평균값은 조심해서 봐야 한다

평균 체류 시간이 5분이라고 하겠습니다.

이것이 모든 방문자가 5분 동안 머물렀다는 뜻은 아닙니다.

실제로는:

1분 머문 방문자 9명
41분 머문 방문자 1명

일 수 있습니다.

평균은 편리하지만, 극단적인 값 하나 때문에 크게 바뀔 수 있습니다.

따라서 분석 화면에서는 필요에 따라:

을 구분해야 합니다.

다만 초기 서비스에서는 평균만 제공하고, 사용자가 충분히 늘었을 때 다른 값을 추가하는 것도 가능합니다.

13. 페이지 분석과 사용자 여정 분석은 다르다

웹 분석에는 서로 다른 두 가지 관점이 있습니다.

13.1 페이지 중심 분석

페이지 중심 분석은 각 페이지가 얼마나 많이 조회되고, 어떤 유입을 받는지 보는 방식입니다.

질문은 다음과 같습니다.

예를 들어 블로그라면:

/top-10-tools
/how-to-start
/about

중 어떤 글이 가장 많이 읽히는지 볼 수 있습니다.

13.2 페이지 중심 분석의 장점

블로그, 포트폴리오, 문서 사이트, 개인 웹사이트에 특히 잘 맞습니다.

13.3 페이지 중심 분석의 한계

페이지 중심 분석만으로는 다음을 알기 어렵습니다.

사용자가 어떤 순서로 페이지를 이동했는가?
회원가입 전에 무엇을 클릭했는가?
결제를 포기한 단계는 어디인가?

페이지별 숫자는 보여주지만, 사용자의 전체 이동 과정을 자세히 보여주지는 않습니다.

13.4 사용자 여정 분석

사용자 여정 분석은 사용자가 목표를 달성하기까지 어떤 순서로 움직였는지 보는 방식입니다.

예를 들어 쇼핑몰의 구매 과정을 다음처럼 정의할 수 있습니다.

상품 페이지
  → 장바구니
  → 주문서 작성
  → 결제 시작
  → 결제 완료

이 과정을 단계별로 분석합니다.

상품 페이지 방문: 1,000명
장바구니 추가: 300명
결제 시작: 150명
결제 완료: 80명

이제 어느 단계에서 사용자가 많이 빠져나가는지 볼 수 있습니다.

13.5 Funnel이란 무엇인가?

Funnel은 사용자가 목표에 도달하기까지 거치는 단계를 순서대로 보는 방식입니다.

한국어로는 보통 “깔때기 분석”이라고 하지만, 처음에는 다음처럼 이해하면 됩니다.

Funnel = 시작한 사람 중 다음 단계로 몇 명이 이동했는지 보는 표

예시:

방문
  1,000명
    ↓
상품 상세 보기
  600명
    ↓
장바구니 추가
  300명
    ↓
결제 시작
  150명
    ↓
결제 완료
  80명

이 자료에서 다음을 알 수 있습니다.

13.6 Cohort란 무엇인가?

Cohort는 비슷한 시점이나 조건으로 묶은 사용자 그룹입니다.

예를 들어:

8월 첫째 주에 가입한 사용자
8월 둘째 주에 가입한 사용자
8월 셋째 주에 가입한 사용자

이 그룹들이 이후에도 계속 돌아오는지 비교할 수 있습니다.

예시:

8월 첫째 주 가입자
1주 후 재방문: 40%
2주 후 재방문: 25%
3주 후 재방문: 18%

이렇게 보면 단순히 “이번 달 방문자가 많다”가 아니라:

새로 가입한 사람들이 계속 서비스를 사용하는가?

를 알 수 있습니다.

13.7 두 분석은 서로 대체하지 않는다

페이지 중심 분석과 사용자 여정 분석은 좋고 나쁜 관계가 아닙니다.

관점답하는 질문
페이지 중심어떤 페이지가 인기 있는가?
여정 중심사용자가 목표까지 어떻게 이동하는가?

같은 웹사이트에서도 둘 다 필요할 수 있습니다.

다만 처음부터 둘을 모두 깊게 만들면 복잡해집니다.

초기에는 다음 중 하나를 중심으로 정하는 것이 좋습니다.

콘텐츠 중심 서비스

페이지 중심
→ 인기 페이지
→ 검색 유입
→ 콘텐츠별 성과

SaaS·쇼핑몰 중심 서비스

사용자 여정 중심
→ 회원가입
→ 기능 사용
→ 결제
→ 재방문

14. 유입 분석은 “어디서 왔는가”를 이해하는 영역이다

웹사이트 방문자는 여러 경로로 들어옵니다.

Google 검색
SNS 링크
다른 웹사이트 링크
이메일
광고
직접 주소 입력
즐겨찾기

유입 분석은 다음 질문에 답합니다.

이 방문자는 웹사이트를 어떻게 발견했는가?

14.1 Referrer란 무엇인가?

Referrer는 방문자가 바로 전에 있던 페이지 또는 웹사이트입니다.

예를 들어 사용자가 Google 검색 결과를 클릭해 웹사이트에 들어왔다면:

이전 페이지: Google
현재 페이지: example.com

분석 시스템은 Google을 유입 경로로 기록할 수 있습니다.

다른 예시:

이전 사이트: news.example.com
현재 사이트: mysite.com

이면 뉴스 사이트에서 링크를 타고 들어온 것으로 볼 수 있습니다.

14.2 모든 유입 경로를 알 수 있는 것은 아니다

다음과 같은 경우에는 유입 경로를 알기 어렵습니다.

이런 방문은 다음처럼 표시될 수 있습니다.

Direct
Unknown
직접 방문
알 수 없음

직접 방문이 모두 사용자가 주소를 직접 입력했다는 뜻은 아닙니다.

정확한 이전 경로를 알 수 없다는 의미에 가깝습니다.

14.3 UTM 파라미터란 무엇인가?

UTM은 링크에 붙이는 추가 정보입니다.

예를 들어 Instagram 프로필에 다음 링크를 넣을 수 있습니다.

https://example.com/pricing
  ?utm_source=instagram
  &utm_medium=social
  &utm_campaign=summer-sale

여기서:

를 나타냅니다.

쉽게 말하면 링크에 이름표를 붙이는 것입니다.

14.4 UTM이 없을 때와 있을 때

UTM이 없는 링크:

https://example.com/pricing

분석 결과:

Instagram에서 온 것처럼 보임

정도만 알 수 있을 수 있습니다.

UTM이 있는 링크:

https://example.com/pricing
?utm_source=instagram
&utm_medium=social
&utm_campaign=summer-sale

분석 결과:

유입 출처: Instagram
채널 유형: Social
캠페인: summer-sale

처럼 더 구체적으로 분류할 수 있습니다.

14.5 같은 사이트에서 여러 캠페인을 비교할 수 있다

다음과 같은 링크를 각각 만들 수 있습니다.

뉴스레터:
?utm_source=email
&utm_medium=newsletter
&utm_campaign=august-news

Instagram:
?utm_source=instagram
&utm_medium=social
&utm_campaign=august-news

검색 광고:
?utm_source=google
&utm_medium=cpc
&utm_campaign=august-news

캠페인 이름은 같지만 유입 경로가 다릅니다.

이제 다음을 비교할 수 있습니다.

뉴스레터 방문: 1,000
Instagram 방문: 700
검색 광고 방문: 500

또는 방문 이후 전환까지 비교할 수 있습니다.

뉴스레터 전환율: 8%
Instagram 전환율: 3%
검색 광고 전환율: 5%

단순히 방문자를 많이 데려온 채널과, 실제 고객을 많이 만든 채널은 다를 수 있습니다.

14.6 유입과 전환을 연결하는 이유

방문자가 늘었다는 사실만으로 캠페인이 성공했다고 할 수 없습니다.

예를 들어:

캠페인 A: 방문 10,000명, 구매 10건
캠페인 B: 방문 1,000명, 구매 100건

방문자는 캠페인 A가 많지만, 구매는 캠페인 B가 더 많습니다.

따라서 유입 분석은 다음 단계까지 연결되어야 합니다.

어디에서 왔는가?
  → 어떤 페이지를 보았는가?
  → 어떤 행동을 했는가?
  → 전환했는가?

14.7 캠페인 분석에서 생기는 문제

UTM은 사람이 직접 붙이는 정보이므로 실수가 생길 수 있습니다.

예를 들어:

utm_source=Instagram
utm_source=instagram
utm_source=insta

는 사람이 보기에는 모두 Instagram이지만, 시스템에서는 서로 다른 값으로 저장될 수 있습니다.

그래서 다음 규칙이 필요합니다.

예시:

source: instagram
medium: social
campaign: 2026-08-summer-sale

15. 이벤트와 전환은 다르다

이벤트와 전환의 기본 뜻은 이전 문서에서 설명했으므로, 여기서는 실제 분석 서비스에서 어떻게 구분하는지만 보겠습니다.

15.1 이벤트는 행동 기록이다

이벤트는 사용자가 한 행동을 기록합니다.

가격표 버튼 클릭
회원가입 시작
상품 장바구니 추가
결제 페이지 진입

이벤트는 행동의 흐름을 이해하는 재료입니다.

15.2 전환은 목표 달성 기록이다

전환은 그중 서비스가 중요하게 정한 행동입니다.

예를 들어:

회원가입 완료
문의 제출
결제 완료

전환은 분석 화면에서 별도로 강조할 수 있습니다.

15.3 같은 이벤트가 상황에 따라 전환이 될 수 있다

어떤 서비스에서:

PDF 다운로드

는 일반 이벤트일 수 있습니다.

하지만 자료 판매 사이트에서는 PDF 다운로드가 결제 이후 발생하므로 중요한 전환일 수 있습니다.

따라서 이벤트 자체에 절대적인 의미가 있는 것이 아니라:

서비스 목표에 따라 이벤트를 전환으로 지정한다

고 이해하면 됩니다.

15.4 이벤트 흐름을 연결하면 사용자의 행동을 볼 수 있다

예를 들어 SaaS 서비스의 흐름은 다음과 같을 수 있습니다.

pricing_page_viewed
  → signup_started
  → signup_completed
  → workspace_created
  → subscription_started

각 이벤트의 사용자 수를 비교하면 어디에서 사용자가 줄어드는지 알 수 있습니다.

가격 페이지 방문: 1,000명
회원가입 시작: 400명
회원가입 완료: 250명
워크스페이스 생성: 180명
구독 시작: 50명

이 데이터는 단순한 페이지뷰보다 제품 개선에 더 직접적인 도움을 줍니다.

15.5 이벤트 이름은 나중에 바꾸기 어렵다

이벤트 이름이 이미 저장된 뒤에 이름을 바꾸면 과거 데이터와 현재 데이터가 나뉩니다.

예를 들어:

signup_done
signup_completed

를 서로 다른 이벤트로 사용하면 회원가입 완료 통계가 두 개로 쪼개집니다.

그래서 처음부터 이름 규칙을 정하는 것이 좋습니다.

예시:

페이지 조회: page_viewed
버튼 클릭: button_clicked
회원가입 시작: signup_started
회원가입 완료: signup_completed
결제 완료: purchase_completed

15.6 이벤트와 사업 데이터는 연결해야 한다

결제 완료를 브라우저 이벤트로만 기록하면 다음 문제가 생길 수 있습니다.

그래서 돈과 관련된 전환은 가능한 경우 서버의 실제 결제 결과와 연결하는 것이 좋습니다.

16. 분석 데이터는 실시간 숫자가 아닐 수 있다

대시보드에 숫자가 보인다고 해서 항상 방금 발생한 모든 데이터가 포함되어 있는 것은 아닙니다.

16.1 데이터가 처리되는 순서

일반적으로 다음 과정을 거칩니다.

1. 이벤트가 들어옴
2. 데이터가 정상인지 검사
3. 중복 여부 확인
4. 봇인지 확인
5. 시간대를 정리
6. 저장
7. 시간별·일별로 합산
8. 대시보드에 표시

각 단계에 시간이 걸릴 수 있습니다.

16.2 왜 데이터가 늦게 보이는가?

다음 이유로 지연될 수 있습니다.

따라서 사용자가 이벤트를 발생시킨 직후 대시보드를 열었는데도 숫자가 바로 변하지 않을 수 있습니다.

16.3 실시간과 최신 데이터는 다르다

실시간 데이터:

이벤트가 발생하자마자 화면에 표시되는 데이터

최신 데이터:

현재 처리까지 끝난 데이터

예를 들어:

실제 이벤트 발생: 10:00:00
서버 도착: 10:00:02
저장 완료: 10:00:03
집계 완료: 10:00:10
대시보드 표시: 10:00:12

사용자는 10:00:12부터 해당 이벤트를 볼 수 있습니다.

초기 분석 서비스에서는 완벽한 실시간보다:

보통 몇 초 이내에 반영됩니다

정도로 정의하는 것이 현실적입니다.

16.4 중복 데이터가 생기는 이유

같은 데이터가 여러 번 들어올 수 있습니다.

사용자가 버튼을 두 번 클릭한 경우

실제 클릭: 2회
기록: 2회

네트워크 재시도로 같은 요청을 다시 보낸 경우

실제 클릭: 1회
요청 전송: 2회
기록: 2회가 될 위험

결제 완료 페이지를 새로고침한 경우

결제 완료: 1건
결제 완료 화면 노출: 2회

분석 서비스는 어떤 데이터가 중복인지 판단해야 합니다.

중요한 이벤트에는 고유한 ID를 붙일 수 있습니다.

event_id: evt_123
order_id: order_456

같은 ID가 다시 들어오면 한 번만 처리하도록 합니다.

16.5 늦게 도착한 데이터

사용자가 지하철이나 비행기처럼 인터넷이 불안정한 곳에서 웹사이트를 이용했다고 하겠습니다.

10:00 페이지 방문
10:00 네트워크 끊김
10:20 네트워크 복구
10:20 분석 데이터 전송

이 경우 10시의 행동이 10시 20분에 도착합니다.

따라서 오늘 오전 통계가 오후에 변경될 수 있습니다.

16.6 어제 숫자가 바뀔 수 있다

다음과 같은 이유로 과거 데이터가 수정될 수 있습니다.

따라서 분석 데이터는 항상 완전히 고정되어 있다고 보기 어렵습니다.

특히 “오늘” 데이터는 아직 처리 중일 가능성이 높습니다.

16.7 봇 필터링

봇은 사람이 아닌 자동 프로그램입니다.

예를 들어:

이런 프로그램도 페이지를 열 수 있습니다.

봇을 포함하면:

실제 사람 방문: 1,000
봇 포함 페이지뷰: 1,800

처럼 보일 수 있습니다.

그래서 분석 서비스는 봇을 제외할 수 있습니다.

다만 봇 판별이 항상 완벽한 것은 아닙니다.

너무 강하게 제외하면 실제 사용자의 방문을 놓칠 수 있고, 너무 약하게 제외하면 자동 요청이 섞입니다.

16.8 광고 차단기

일부 사용자는 광고 차단기나 개인정보 보호 도구를 사용합니다.

이 도구는 분석 코드나 분석 서버 요청을 차단할 수 있습니다.

그 결과:

실제 방문: 1,000
분석에 기록된 방문: 850

일 수 있습니다.

따라서 분석 숫자는 “사이트에 실제로 온 모든 사람”이 아니라:

분석 시스템이 관측할 수 있었던 방문

이라고 이해해야 합니다.

16.9 시간대 변환

서버는 보통 세계 표준 시간인 UTC 기준으로 시간을 저장할 수 있습니다.

하지만 사용자는 한국 시간으로 보고 싶을 수 있습니다.

예를 들어:

서버 시간: 2026-08-06 15:30 UTC
한국 시간: 2026-08-07 00:30

같은 사건이 서로 다른 날짜로 보일 수 있습니다.

그래서 대시보드에서 날짜를 집계할 때는:

를 정해야 합니다.

시간대가 잘못되면 다음 문제가 생깁니다.

한국에서는 8월 7일 방문인데
미국 시간 기준으로는 8월 6일 방문으로 집계됨

16.10 사용자에게 상태를 설명해야 한다

분석 서비스는 숫자만 보여주면 안 됩니다.

다음과 같은 안내가 필요합니다.

최근 데이터는 처리 중일 수 있습니다.
최대 5분 지연될 수 있습니다.
오늘 데이터는 이후 변경될 수 있습니다.
봇 트래픽은 제외되었습니다.

오류가 발생한 경우도 숨기지 않아야 합니다.

최근 10분 동안 일부 이벤트 처리가 지연되고 있습니다.

이런 설명이 있어야 사용자가 숫자를 과도하게 신뢰하거나 잘못 해석하지 않습니다.

전체 흐름 정리

앞서 배운 개념을 모두 연결하면 다음과 같습니다.

사용자가 페이지를 엶
  ↓
JavaScript가 페이지뷰 기록을 만듦
  ↓
분석 서버로 전송
  ↓
데이터 검증
  ↓
URL과 이벤트 이름 정리
  ↓
중복·봇 여부 확인
  ↓
저장
  ↓
페이지별·국가별·캠페인별로 집계
  ↓
대시보드 표시

그리고 사용자가 버튼을 클릭하면:

버튼 클릭
  ↓
이벤트 기록 생성
  ↓
분석 서버 전송
  ↓
회원가입·결제 같은 목표 이벤트인지 확인
  ↓
전환 통계에 반영

**용어 정리

데이터 수집

브라우저나 서버가 사용자 행동을 분석 서버에 보낸다.

데이터 처리

분석 서버는 받은 데이터를 검사하고, 형태를 통일하고, 중복과 봇을 처리한다.

측정값

방문 수, 페이지뷰 수, 이벤트 수처럼 계산된 숫자다.

차원

페이지, 국가, 캠페인, 브라우저처럼 숫자를 나누어 보는 기준이다.

페이지 중심 분석

어떤 페이지가 인기 있고 얼마나 조회되는지 본다.

사용자 여정 분석

사용자가 목표를 달성하기까지 어떤 단계를 거쳤는지 본다.

유입 분석

방문자가 어느 경로와 캠페인을 통해 들어왔는지 본다.

데이터 지연

이벤트가 발생한 즉시 대시보드에 반영되지 않을 수 있다.

데이터의 한계

광고 차단기, 봇, 네트워크 문제, 시간대에 따라 실제 상황과 분석 숫자가 달라질 수 있다.