IT기술사가 알려주는 마케터가 알아야 할 IT기술

🎬 익숙하신가요?

마케터: “리타겟팅이 갑자기 줄었어요. 사파리만 전환이 뚝 떨어졌네요.”
개발자: “쿠키 만료·제한 때문일 수 있어요. 브라우저마다 정책이 달라요.”
광고대행사: “크롬에선 잘 찍히는데요? 세션도 들쑥날쑥합니다.”
임원: “그럼 클릭은 이렇게 나오는데, 왜 매출은 안 맞아?”

👉 이런 대화, 낯설지 않다면 오늘 내용이 핵심입니다.
브라우저가 무엇을 허용/차단하는지, 쿠키가 어떻게 남고 지워지는지, 세션이 어떻게 계산되는지를 이해하면 리포트가 “왜 달라 보이는지” 설명할 수 있습니다.

---

📌 이번에 꼭 알아야 할 것은?

• 브라우저는 웹을 보여주는 프로그램이자, 추적·저장 정책을 결정하는 “심판”입니다.
• 쿠키는 웹이 사용자를 “기억”하는 작은 메모(로그인 유지·장바구니·어트리뷰션).
• 세션은 한 번의 방문·활동을 묶은 측정 단위로, 전환·이탈 등 핵심 지표의 바탕입니다.
• 최근 프라이버시 정책 강화로 서드파티 쿠키가 줄고, 퍼스트파티·서버사이드·컨센트 기반 측정이 표준이 되고 있습니다.

---

💬 IT기술사 코멘트 보러가기 ▼

브라우저 = 출입 통제되는 전시장

• 관람객(사용자)이 들어오면 전시장 규칙(보안·프라이버시 정책)에 따라 무엇을 기록할지 결정합니다.
• 크롬·사파리·파이어폭스 등 전시장마다 규정이 다릅니다.

쿠키 = 재입장 도장

• 퍼스트파티 쿠키: 전시장(현재 방문한 도메인)이 직접 찍는 도장 → 로그인·장바구니·기본 어트리뷰션에 사용.
• 서드파티 쿠키: 외부 업체(광고/측정사)가 찍는 도장 → 리타겟팅·크로스사이트 추적에 유리했으나 제한이 커지는 중.

세션 = 한 번의 관람

• 입장부터 퇴장까지의 연속된 활동 묶음. 중간에 긴 정지·다른 날 재방문이면 새 세션.
• 분석 도구마다 세션 정의·끊김 조건이 조금씩 달라 수치가 다르게 보일 수 있습니다.

핵심 정리

• “왜 사파리 전환이 낮죠?” → 브라우저 정책·쿠키 만료·서드파티 차단.
• “왜 툴마다 숫자가 달라요?” → 세션 정의·샘플링·차단 정책·태깅 품질 차이.
• 해결 방향: 퍼스트파티 데이터 전략 + 서버사이드 태깅 + 컨센트(동의) 기반 수집.

---

📝 주요 내용과 개념 설명

1) 브라우저란?

• 크롬(Blink/V8), 사파리(WebKit/JavaScriptCore), 파이어폭스(Gecko/SpiderMonkey), 엣지(Blink/V8)…
• 같은 페이지라도 엔진과 보안·쿠키 정책이 달라 추적·렌더링 결과가 다를 수 있습니다.
• 실무: 개발자 도구(F12) → Network(요청·응답·헤더), Application(쿠키/스토리지), Console(오류)로 태깅 점검.

2) 쿠키란? (구조·종류·속성)

• 작은 텍스트(보통 ≤4KB). Set-Cookie 헤더로 저장, 이후 요청마다 자동 전송(도메인·경로 일치 시).
• 핵심 속성
  • Expires/Max-Age: 유효기간(만료 시 자동 삭제)
  • Domain/Path: 쿠키가 유효한 범위
  • Secure: HTTPS에서만 전송
  • HttpOnly: JS로 접근 불가(보안↑)
  • SameSite: 교차 사이트 전송 허용 수준(Lax/Strict/None)
• 퍼스트파티 vs 서드파티
  • 퍼스트파티: 현재 사이트가 쓰고 읽음(기본 측정·로그인).
  • 서드파티: 다른 도메인(광고/위젯 등)이 발급·사용(리타겟팅·빈도 관리). → 브라우저 정책으로 점차 제한.

간단 예시(헤더):
Set-Cookie: sid=abc123; Max-Age=1800; Path=/; Secure; HttpOnly; SameSite=Lax

3) 세션이란? (측정 단위)

• 한 사용자의 연속 활동 묶음. 일반적으로 일정 시간 비활동(예: 수십 분) 또는 자정/캠페인 변경 등에서 새로 시작.
• 툴마다 정의가 달라 세션 수·이탈률이 차이 날 수 있음(예: “참여 세션” 개념 등).
• 마케터는 “우리 리포트에서 세션은 어떻게 정의되는가”를 문서로 합의해야 함.

4) 쿠키 대신/보완 저장소

• localStorage / sessionStorage: JS로 접근, 서버로 자동 전송 안 됨(어트리뷰션엔 직접 부적합, UI 상태 보관에 유용).
• IndexedDB: 구조화 데이터 저장, 오프라인 앱 등에 활용.
• 주의: 민감 정보(PII) 평문 저장 금지, 암호화·만료·삭제 정책 필요.

5) 프라이버시 정책 변화와 대응

• 브라우저 추적 제한 확대 → 서드파티 쿠키 축소, 쿠키 만료 단축, 크로스사이트 추적 제한.
• 대응 전략
  1. 퍼스트파티 측정 강화: 자사 도메인에서 이벤트·쿠키 발급, 퍼스트파티 UTM 표준화.
  2. 서버사이드 태깅/전송: 브라우저→자사 서버→플랫폼(Ads, Analytics) 프록시 전송로(데이터 품질·보안↑).
  3. 컨센트(동의) 모드: 동의 전송 제어·모델링 허용, 정책 준수.
  4. 플랫폼 전환 API(예: Conversions API 등): 해시 처리된 이메일/전화 등 퍼스트파티 시그널 연동.
  5. 모델링/보정: 관측 불가능 구간을 통계적으로 보정(보고서 커뮤니케이션 포함).

6) 마케팅 활용 시나리오

• 로그인 유지·장바구니·최근 본 상품(퍼스트파티 쿠키).
• 빈도 관리·리타겟팅(전통적으론 서드파티 → 대체 전략 필요).
• 어트리뷰션 윈도우 관리(유입 경로 보존), 크로스 도메인 추적(도메인 정렬·링크 데코레이션).

7) 운영 체크리스트

• 주요 브라우저(크롬/사파리/파폭/엣지)에서 동일 시나리오로 태깅 테스트
• SameSite=None; Secure 필요한 쿠키는 올바르게 설정
• 중복 태그/이중 발화 여부 점검(GTM Preview/Tag Assistant/Pixel Helper)
• 만료 정책(TTL)과 컨센트 로직 문서화
• 서버사이드 태깅·전환 API 도입 여부 검토 및 로드맵 확정

---

✅ 지금 바로 해 볼 수 있는 것은?

1. 크롬 개발자도구 Application → Cookies에서 우리 사이트 쿠키 목록 확인(도메인/만료/HttpOnly/SameSite)
2. 동일 흐름을 사파리/파이어폭스로 반복 테스트(로그인 유지, 전환 기록)
3. 주요 이벤트(뷰→클릭→전환) GTM 프리뷰/GA4 DebugView로 실시간 검증
4. 퍼스트파티 UTM 네이밍 규칙 재확인(소문자·하이픈, source/medium/campaign 필수)
5. 컨센트 배너 동작 점검(동의 전 전송 차단/허용 로직)
6. 서버사이드 태깅·전환 API 도입 타당성 간단 진단(유입 비중·사파리 트래픽·데이터 누락률)

---

📍 마무리 요약

• 브라우저는 정책의 차이로 측정 결과를 바꾼다.
• 쿠키는 기억 장치, 세션은 측정 단위 — 둘의 이해가 리포트 해석의 출발점.
• 대응의 핵심은 퍼스트파티·서버사이드·컨센트 기반으로의 전환이다.

---

🔜 다음 회차 예고

9회차에서는 HTTPS·SSL 인증서와 보안 마케팅을 다룹니다.
“왜 자물쇠(🔒)가 SEO·신뢰·전환율까지 바꿀까?” 실무 관점으로 풀어드립니다.