동일한 이메일이 러시아의 사용자를 루블 가격의 랜딩 페이지로 안내할 수 있지만, 독일의 사용자는 404 오류 페이지로 안내될 수 있습니다. 다양한 지리적 위치에서 뉴스레터를 확인하지 않았다면, 눈을 감고 작업하는 것과 같습니다: 일부 데이터베이스는 전환율을 잃고 있으며, 여러분은 오픈 및 클릭 메트릭에서 이를 알지 못합니다. 이 기사에서는 프록시를 사용하여 다양한 국가의 이메일 링크의 정확성을 확인하는 방법과 대량 발송 전에 수행해야 할 6가지 체크를 설명합니다.
이메일의 링크가 잘못된 곳으로 안내되는 이유
대부분의 이메일 플랫폼 및 CRM(메일침프, 센드펄스, 겟리스폰스, 유니스엔더, 클라비요)은 수신자의 지리적 IP를 기반으로 동적 콘텐츠 및 리디렉션을 설정할 수 있도록 합니다. 이는 편리합니다: 하나의 이메일 템플릿으로 미국의 사용자는 달러 가격을 보고, 프랑스의 사용자는 유로와 현지화된 텍스트를 볼 수 있습니다. 그러나 이러한 유연성은 오류의 위험을 초래합니다.
문제는 마케팅 담당자가 사무실 내에서 뉴스레터를 테스트할 때 거의 항상 동일한 IP(자신의 집이나 직장의 IP)에서 이메일을 열기 때문에 발생합니다. 그는 올바른 랜딩 페이지 버전을 보고, 10개 국가의 50,000개 주소로 뉴스레터를 발송하지만, 일부 수신자는 관련 없는 콘텐츠, 잘못된 통화, 또는 호스팅 제공자나 CDN(클라우드플레어, 아카마이 등)이 해당 지역에 대해 차단된 페이지에 도달하게 됩니다.
이메일 뉴스레터를 통해 트래픽을 유도하는 중개인에게는 지리적 리디렉션의 오류가 예산 낭비를 의미합니다: 클릭은 있지만 전환이 없기 때문에 사용자가 자신의 지리적 버전이 아닌 랜딩 페이지에 도달했기 때문입니다. SMM 및 이메일 마케팅 에이전시의 경우, 이는 고객에 대한 평판 위험입니다 — 오픈 보고서는 좋지만 판매는 증가하지 않습니다. 따라서 규칙은 뉴스레터의 링크를 실제 구독자 데이터베이스가 있는 국가의 IP 주소에서 테스트해야 하며, 자신의 IP에서 테스트해서는 안 됩니다.
체크 1: IP 지리적 리디렉션
가장 먼저 확인해야 할 것은 지리적 리디렉션이 작동하는지 여부와 예상하는 페이지로 안내되는지입니다. 필요한 국가의 프록시가 연결된 브라우저를 통해 이메일의 링크를 열고 최종 URL을 확인합니다. 8개 국가에 대해 리디렉션을 설정했다면, 최소 8개의 서로 다른 IP를 통해 링크를 테스트해야 합니다 — 국가별로 하나씩, 가능하면 2-3개씩 테스트하여 우연성을 배제합니다(일부 서비스는 IP뿐만 아니라 제공자의 ASN에 따라 지리를 결정하며, 결과가 동일한 국가 내에서도 다를 수 있습니다).
자주 발생하는 오류는 리디렉션이 상위 5개 국가에 대해서만 설정되어 있고, 나머지 방문자는 로컬화되지 않은 기본 버전으로 떨어진다는 것입니다. 이는 항상 나쁜 것은 아니지만, 미리 알아야 하며 고객의 불만으로 알게 되어서는 안 됩니다.
체크 2: 랜딩 페이지의 통화 및 언어
리디렉션이 올바르게 작동하고 사용자가 필요한 도메인이나 필요한 언어 버전으로 안내되었더라도, 가격, 통화 및 측정 단위의 표시를 별도로 확인해야 합니다. 많은 전자상거래 플랫폼(쇼피파이, 우커머스와 같은 지리적 위치 플러그인 포함)은 IP에 따라 통화를 변경하지만, 테스트에 사용된 프록시가 "나쁜" 평판(데이터 센터 IP, 이미 봇에 의해 노출된 IP)일 경우, 시스템은 기본 통화(보통 미국 달러)로 롤백될 수 있습니다.
따라서 테스트의 정확성을 위해서는 일반 인터넷 사용자와 최대한 유사한 좋은 평판의 IP를 사용하는 것이 중요합니다. 여기에는 주거용 프록시가 적합합니다 — 이들은 실제 가정용 인터넷 제공업체에서 제공되며, 테스트 결과를 왜곡할 수 있는 안티프로드 시스템을 트리거할 가능성이 적습니다.
체크 3: UTM 태그 및 추적
이메일의 링크를 클릭한 후, UTM 태그가 유지되고 리디렉션 체인에서 추적 매개변수가 손실되지 않았는지 확인합니다. 이는 파트너 프로그램이나 CPA 네트워크에 연결된 뉴스레터에 특히 중요합니다: click_id 또는 sub_id가 손실되면, 사용자가 상품을 구매하더라도 전환이 기록되지 않습니다.
이를 각 지리적 위치에서 별도로 확인해야 합니다. 왜냐하면 일부 CDN 및 WAF(웹 애플리케이션 방화벽)는 "의심스러운" 지역에서 오는 트래픽에 대해 쿼리 매개변수를 공격적으로 정리하기 때문입니다 — 예를 들어, 제공자의 데이터에 따르면 사기 수준이 높은 국가입니다.
체크 4: 차단 및 도메인 접근성
이메일의 링크가 안내하는 도메인은 제공자의 차단, 지역 법률 또는 특정 지역에 대한 접근을 차단하는 CDN 설정으로 인해 특정 국가에서 접근할 수 없을 수 있습니다(지리적 제한). 이는 많은 스트리밍 서비스, 핀테크 제품 및 특정 관할권에 제한이 있는 SaaS의 표준 관행입니다.
국제 데이터베이스에 뉴스레터를 발송하는 경우, 반드시 청중의 주요 국가 중 최소 10-15개에서 목표 페이지의 접근성을 확인해야 합니다. 이러한 대량 검사를 위해서는 주거용 프록시보다 데이터 센터 프록시를 사용하는 것이 더 편리합니다 — 이들은 검사 속도가 빠르고 비용이 저렴하며, "도메인이 접근 가능한지"라는 작업에서는 IP의 평판이 속도만큼 중요하지 않습니다.
체크 5: 추적 픽셀 및 리디렉션 체인의 정확성
이메일에는 종종 하나의 직접 링크가 아닌 리디렉션 체인이 포함됩니다: 클릭 → 이메일 플랫폼의 트래커 → 링크 단축 서비스의 리디렉션 → UTM 프록시 → 최종 랜딩. 이 체인의 각 링크는 요청을 보낸 국가에 따라 다르게 작동할 수 있습니다. 예를 들어, 일부 링크 단축 서비스(비틀리, 클라우드플레어 워커 기반의 자체 리디렉터)는 이 중간 단계에서 지리적 로직을 적용하며, 최종 도메인에서는 적용하지 않을 수 있습니다.
이를 확인하기 위해서는 필요한 국가의 프록시를 통해 이메일을 열 때 브라우저의 개발자 도구(네트워크 탭)를 사용하세요 — 요청 체인의 전체 흐름을 볼 수 있으며, 지리적 로직이 발생하는 단계와 그곳에서의 중단(404, 500 오류, 무한 리디렉션)이 있는지 이해할 수 있습니다.
체크 6: 모바일 버전 및 딥 링크
오늘날 이메일의 절반 이상이 스마트폰에서 열리며, 일부 링크는 딥 링크로 설정되어 있습니다 — 모바일 애플리케이션을 직접 열도록 설정된 것이지 웹사이트의 브라우저 버전이 아닙니다. "앱이 설치되어 있으면 앱에서 열고, 그렇지 않으면 브라우저에서 열기"라는 로직도 지리에 따라 달라집니다: 일부 국가에서는 브랜드에 앱이 있지만, 다른 국가에서는 웹 버전만 있습니다.
이 시나리오를 확인하기 위해서는 단순히 필요한 지리적 프록시가 아니라 모바일 트래픽을 에뮬레이션해야 합니다 — 특정 국가의 이동통신 사업자로부터 실제 모바일 IP가 필요합니다. 이러한 테스트를 위해 중개인과 모바일 마케팅 담당자는 종종 모바일 프록시를 선택합니다. 많은 딥 링크 시스템과 애플리케이션의 안티프로드 메커니즘은 네트워크 유형(모바일/Wi-Fi/데이터 센터)을 확인하며, 단순히 국가만 확인하지 않기 때문입니다.
프록시 및 안티디텍트 브라우저를 통한 체크 설정 방법
다양한 국가의 테스트 간 쿠키와 세션이 혼동되지 않도록, 체크는 일반 브라우저가 아닌 안티디텍트 브라우저에서 수행하는 것이 좋습니다 — 돌핀 안티, 애드스파워, 멀티로그인, 고로그인 또는 옥토 브라우저와 같은 브라우저입니다. 이는 두 가지 장점을 제공합니다: 각 체크는 깨끗한 쿠키가 있는 격리된 프로필에서 진행되며, 매번 테스트 전에 프록시를 새로 설정하지 않고도 "국가별" 프로필을 수십 개 유지할 수 있습니다.
단계별로는 다음과 같이 진행됩니다:
- 체크해야 할 각 국가에 대해 안티디텍트 브라우저에서 별도의 프로필을 생성합니다(예: "DE" 프로필, "US" 프로필, "BR" 프로필).
- 프로필 설정에서 필요한 지리적 프록시를 지정합니다 — IP, 포트, 로그인 및 비밀번호를 입력하고, HTTP(S) 또는 SOCKS5 프로토콜을 선택합니다.
- 테스트 전에 안티디텍트 브라우저의 내장 체크기 또는 IP의 지리적 위치를 확인하는 외부 서비스를 통해 지리적 IP를 확인합니다.
- 테스트 이메일을 엽니다(이 프로필에 연결된 테스트 메일박스로 발송하거나 원본 뉴스레터에서 링크를 복사합니다).
- 이메일의 각 링크를 클릭하고, 어떤 페이지로, 어떤 언어와 통화로 안내되는지 기록합니다.
- 나머지 프로필-국가에 대해 반복하고 결과를 비교를 위해 표로 정리합니다.
이메일 링크 체크를 위한 프록시 유형 선택 방법
다양한 체크는 다양한 유형의 IP를 요구합니다. 프록시 유형 선택 오류는 테스트가 실제 사용자 행동을 "재현하지 못하는" 흔한 원인입니다.
| 체크 작업 | 추천 프록시 유형 | 이유 |
|---|---|---|
| 통화, 언어, 랜딩 페이지 개인화 | 주거용 프록시 | 높은 IP 신뢰성, 안티프로드로 인해 기본값으로 롤백되지 않음 |
| 국가별 도메인 접근성 (대량 검사) | 데이터 센터 프록시 | 높은 속도, 낮은 검사 비용, 지리가 평판보다 중요함 |
| 모바일 애플리케이션의 딥 링크 | 모바일 프록시 | 모바일 네트워크 에뮬레이션, "앱 vs 브라우저" 로직 검사 |
| UTM 및 CPA 오퍼를 위한 리디렉션 체인 | 주거용 프록시 | 실제 사용자 행동에 가까움, CPA 네트워크의 안티프로드에 걸릴 가능성이 적음 |
자동화 체크: 손으로 하지 않고 싶다면
링크를 정기적으로 확인하는 경우(예: 매주 15개 국가에 대한 뉴스레터 발송 전), 안티디텍트 브라우저에서 각 링크를 수동으로 클릭하는 것은 일상이 됩니다. 이 부분은 링크 및 프록시 목록을 순회하며 모든 리디렉션 후 최종 URL과 HTTP 응답 상태 코드를 기록하는 간단한 스크립트로 자동화할 수 있습니다.
import requests
links = [
"https://example.com/go?campaign=newsletter_jan",
]
proxies_by_country = {
"DE": "http://user:[email protected]:12321",
"US": "http://user:[email protected]:12321",
"BR": "http://user:[email protected]:12321",
}
for country, proxy in proxies_by_country.items():
try:
resp = requests.get(
links[0],
proxies={"http": proxy, "https": proxy},
allow_redirects=True,
timeout=15,
)
print(f"{country}: 상태 {resp.status_code}, 최종 URL: {resp.url}")
except Exception as e:
print(f"{country}: 오류 — {e}")
스크립트는 자동으로 리디렉션 체인을 순회하며(allow_redirects=True 매개변수) 각 국가의 사용자가 실제로 어디로 도달하는지를 보여줍니다. 결과는 CSV로 수집하고 주별로 비교할 수 있습니다 — 이렇게 하면 웹사이트 또는 CDN 규칙의 업데이트 이후 지리적 로직이 깨지지 않았는지 확인할 수 있습니다.
뉴스레터 발송 전 체크리스트
국제 데이터베이스에 대량 뉴스레터를 발송하기 전에 짧은 목록을 확인하세요:
- 각 지리적 세그먼트에 대해 최소 3개 국가에서 링크를 확인했습니다.
- 각 국가에 대해 랜딩 페이지의 통화 및 언어가 예상과 일치합니다.
- 리디렉션 후 최종 URL에서 UTM 태그 및 click_id가 유지됩니다.
- 도메인이 접근 가능하며, 어떤 목표 국가에서도 403/404 오류를 반환하지 않습니다.
- 딥 링크가 앱을 올바르게 열도록 설정되어 있습니다.
- 리디렉션 체인이 무한 루프에 빠지지 않으며 3-4단계를 초과하지 않습니다(그렇지 않으면 로딩 시간이 증가하고 전환율이 떨어집니다).
결론
이메일의 링크는 정적인 URL이 아니라, 수신자의 국가에 따라 다르게 작동하는 지리적 로직, 통화 설정 및 리디렉션의 전체 시스템입니다. 뉴스레터가 전체 데이터베이스에 대해 올바르게 작동하는지 확인하는 유일한 신뢰할 수 있는 방법은 이메일이 발송되는 국가의 실제 IP 주소에서 링크를 테스트하는 것이며, 자신의 작업 컴퓨터에서 한 번의 테스트에 의존해서는 안 됩니다.
국제 청중에게 정기적으로 뉴스레터를 발송하는 경우, 각 발송 전에 빠른 검사를 위한 다양한 국가의 프록시 세트를 준비하는 것이 좋습니다. 개인화 및 통화의 정확한 검사를 위해서는 주거용 프록시가 더 적합하며, 수십 개의 지리적 위치에 대한 도메인 접근성을 대량으로 검사하기 위해서는 더 빠르고 경제적인 데이터 센터 프록시가 적합합니다. 이러한 접근 방식은 뉴스레터 발송 예산을 절약하고, 클릭 후 "이해할 수 없는 랜딩 페이지"에 대한 고객의 불만을 줄입니다.