안녕하세요. 위어드섹터 래빗연구소입니다.

오늘은 서비스에서 숨은 이슈로 존재하고 있는 Amplitude 이벤트가 광고차단 필터에 의해 유실되는 문제를 해결하기 위해, Amplitude에서 공식적으로 소개하고 있는 Domain Proxy (도메인 프록시) 사용법을 소개드리려고 합니다.

도메인 프록시란?

Amplitude에서 말하는 도메인 프록시는 브라우저가 Amplitude 서버로 직접 이벤트를 보내지 않고, 우리 서비스의 도메인을 한 번 거쳐 우회하도록 만드는 중간 전달 지점(Proxy Layer) 입니다.

조금 더 쉽게 정리하면

• 원래는 브라우저 → api2.amplitude.com으로 이벤트를 직접 전송하지만
• 프록시 적용 시 브라우저 → 내부적으로 설정한 우리 도메인 주소로 먼저 요청을 보낸 뒤
• 서버(NGINX, CloudFront, API Gateway 등)가 다시 Amplitude로 전달하는 방식입니다.

왜 도메인 프록시가 필요한가?

광고차단 문제를 단순히 “이벤트 몇 개가 누락되는 수준”으로 보면 안됩니다. 실제로는 서비스 분석 전반, 특히 데이터 기반 의사결정, A/B 테스트 정확도, 전환 퍼널 분석, Session Replay 활용성에 큰 영향을 주는 구조적인 문제로 이어지기 때문입니다.

아래는 광고차단이 가져오는 문제 예시들입니다.

A/B 테스트 · 퍼널 분석 · Session Replay에 미치는 영향

1) A/B 테스트 결과 왜곡

• A안 사용자 중 광고차단기 사용 비율이 높다면 → 이벤트가 거의 수집되지 않고
• B안 사용자는 광고차단 비율이 낮다면 → 데이터가 정상적으로 들어옵니다.

이런 불균형은 실험군과 대조군의 샘플 자체가 다르게 수집되는 문제를 만든 뒤, 결국 실제 사용자 행동과 전혀 다른 방향의 왜곡된 실험 결과를 만들어냅니다.

2) 퍼널 분석 · 전환율 계산 오류

Amplitude 퍼널은 수집된 이벤트 기반으로 계산됩니다.

하지만 광고차단으로 특정 사용자군의 이벤트가 누락되면

• 실제보다 낮은 전환율로 보이거나
• 주요 CTA 클릭 데이터가 사라져 잘못된 UX 판단을 내리게 되고
• 실험군/대조군의 샘플이 뒤틀리며

전환·이탈 같은 핵심 지표가 현실과 다르게 계산되는 문제가 발생합니다.

3) Session Replay 중단

Session Replay 기능은 화면 이동·UI 흐름을 영상 형태로 업로드해야 하는데,

해당 기능이 사용하는 다음 도메인들이 광고차단 리스트에 포함되어 있습니다.

결과적으로 화면 이동, UI 사용 흐름, 오류 발생 시점 등

제품 개선에 필요한 핵심 행동 데이터가 전혀 기록되지 않게 됩니다.

즉 광고차단으로 발생하는 이벤트 유실은 테스트 결과 왜곡, 분석 정확도 하락, 행동 분석 불가능, 데이터 기반 의사결정 리스크 증가 등 서비스 운영 전반에 영향을 주는 심각한 문제입니다.

Domain Proxy 설치

Amplitude에서 설명하는 Domain Proxy를 적용하려면 Nginx 와 SDK 설정이 필요합니다.

Nginx

1) Analytics 이벤트 업로드 — /amp/2/httpapi

Amplitude Web/SDK가 이벤트를 업로드할 때 사용하는

Analytics 이벤트 수집 엔드포인트를 프록시합니다.

• 클라이언트 호출: https://our-domain.com/amp/2/httpapi
• 실제 Amplitude로 전달: https://api2.amplitude.com/2/httpapi

➡️ 광고차단 우회를 위한 가장 핵심적인 프록시 처리입니다.

2) Session Replay 세션 업로드 — /amp/sessions/v2/

Session Replay가 화면 기록·세션 데이터를 업로드할 때 사용하는 영상 및 세션 트래킹 서버를 프록시합니다.

• /amp/sessions/v2/... 요청을 https://api-sr.amplitude.com/sessions/v2/track 로 전달
• $is_args$args 는 쿼리 파라미터를 그대로 전달하기 위한 설정

➡️ Session Replay 기능이 광고차단에 걸리지 않고 정상 동작하도록 하는 블록입니다.

3) Session Replay 설정 조회 — /amp/config

Session Replay가 최초 초기화 시 불러오는 config 파일을 프록시합니다.

• 정확히 /amp/config 경로로 들어오는 요청만 매칭
• Amplitude의 config 서버로 요청을 그대로 전달

➡️ Session Replay 초기 설정 파일을 정상적으로 받아올 수 있게 하는 구성입니다.

4) Session Replay 하위 설정 경로 — /amp/config/…

/amp/config/ 이후 추가 경로가 붙는 요청 (예: /amp/config/v1/...)을 처리합니다.

➡️ Session Replay가 내부적으로 호출하는 다양한 config 관련 API를 모두 프록시합니다.

5) Experiment / Lab API — /amp/exp/

Amplitude Experiment · Feature Flag · Lab API 관련 요청을 프록시합니다.

• /amp/exp/... 요청을 https://api.lab.amplitude.com/... 로 전달

➡️ Feature Experiment / Remote Config 등을 도메인 프록시로 우회할 때 필요한 부분입니다.

이 server 블록 전체의 목적은 Amplitude의 모든 주요 API를 프록시 경로(/amp/...) 아래로 통일시키는 것이며, 이를 통해 광고차단기를 우회하여 안정적으로 이벤트를 수집·전송할 수 있는 구조가 완성됩니다.

Next.js에서 Amplitude SDK 설정 (Domain Proxy 적용)

앞에서 NGINX를 통해 /amp/... 경로를 Amplitude로 프록시하도록 구성했다면, 프론트엔드(Next.js)에서는 SDK가 이 프록시 엔드포인트를 바라보도록 설정해주면 됩니다.

1) API 키 및 프록시 Origin 설정

• NODE_ENV에 따라 프로덕션/개발용 Amplitude 프로젝트 키를 분리해서 사용합니다.
• NEXT_PUBLIC_AMP_PROXY_ORIGIN 환경변수에 https://analytics.your-domain.com 같은 프록시 도메인을 넣어두고, 없으면 로컬 개발용으로 http://localhost를 기본값으로 사용합니다.

2) 프록시 기반 엔드포인트 URL 만들기

• 뒤에 / 가 중복되지 않도록 replace(/\/$/, '') 로 마지막 슬래시를 제거합니다.
• 앞에서 NGINX에 정의한 프록시 경로와 1:1로 매칭됩니다.
  • trackServerUrl → /amp/sessions/v2/track
  • configServerUrl → /amp/config

➡️ Session Replay 업로드 및 설정 요청도 모두 우리 도메인을 거쳐 Amplitude로 우회 전송됩니다.

3) Session Replay 플러그인 설정

• trackServerUrl, configServerUrl 에 프록시 URL을 넣어서 Session Replay도 광고차단에 걸리지 않도록 우회시킵니다.

4) Analytics SDK 초기화 (Domain Proxy 적용)

여기서 중요한 부분은 두 가지입니다.

1. serverUrl
   • 원래는 SDK가 내부적으로 https://api2.amplitude.com/2/httpapi 를 직접 호출하지만,
   • 여기서는 https://our-domain.com/amp/2/httpapi 로 보내도록 바꿉니다.
   • 이 경로는 앞에서 설정한 NGINX 프록시에서 Amplitude로 전달해줍니다.
2. remoteConfig.serverUrl
   • Experiment / Remote Config / Feature Flag 등을 사용할 때 서버에서 설정을 가져오는 엔드포인트입니다.
   • 이 역시 /amp/config로 프록시를 통해 가져오도록 설정했습니다.

적용 전/후 비교

프록시 적용 전에는 광고차단 툴에서 *.amplitude.com 이 직접 차단되어, Amplitude Live View에서 이벤트가 거의 수집되지 않았습니다.

도메인 프록시를 적용한 이후에는 브라우저가 our-domain.com/amp/... 로만 통신하기 때문에, 광고차단에 걸리지 않고 Amplitude Live View에서 이벤트가 정상적으로 수집되는 것을 확인할 수 있습니다.

500에러 없이 200반환하면 Amplitude 수집이 정상 작동

마무리하며

도메인 프록시는 단순한 우회 설정이 아니라, 서비스의 데이터 신뢰도를 지키는 핵심적인 안전장치입니다.

광고차단 환경에서는 어떤 이벤트 설계나 실험 설계도 제대로 수집되지 않으면 결국 잘못된 판단으로 이어질 수밖에 없습니다.

이번 글에서 살펴본 것처럼 Nginx 프록시 설정과 SDK 서버 URL만 올바르게 구성해도,

Amplitude 이벤트·Session Replay·Experiment 트래픽을 모두 안정적으로 수집할 수 있습니다.

A/B 테스트, 퍼널 분석, 사용자 행동 기반의 제품 개선을 중요하게 생각하는 서비스라면

도메인 프록시는 선택이 아니라 필수 요소에 가깝습니다.

앞으로도 실제 운영 환경에서 겪는 데이터 수집 이슈와 해결 방법을 계속 공유드리겠습니다.

서비스 환경에 맞춘 적용 방식이 궁금하시다면 언제든 편하게 문의 주세요.