사용자가 실제로 쓰는 네트워크에서 광고 연동이 버티는지 알고 싶을 것이다. 먼 곳의 출구를 재현하는 가장 쉬운 방법은 VPN이다. 실수는 그 실험을 수익 실험으로 취급하는 것이다.

출구 국가를 바꾼다고 새 오디언스가 생기지 않고, 자기 자신의 탭이 적격 트래픽이 되지도 않는다. 바뀌는 것은 요청의 경로뿐이다.

그러니 문서화된 순서로 연결성 테스트로 실행하고, 라이브 재고는 완전히 분리해 두어라. 아래 단계는 어느 빌드에서든 반복할 가치가 있다.

테스트의 목적을 정하라

두 가지 질문이 뒤섞인다. 첫째는 특정 네트워크 경로에서 요청이 아예 서비스되는지이며, 이는 연동과 연결성의 문제다. 둘째는 그 나라의 실제 사용자가 얼마를 벌지이며, 이는 리포트와 비즈니스의 문제이고 SDK가 대신 답할 수 없다.

개발 기기에서 검증할 수 있는 것은 첫째뿐이다. 추정 수익은 리포팅 기간이 확정되기 전에도 바뀔 수 있으므로, 직접 만든 실험에서 관측한 숫자는 적격 수익의 증거도 아니고 다른 누군가를 위한 예측도 아니다.

연결하기 전에 질문을 적어라. 예를 들어 이 빌드에서 기기가 독일을 통해 나갈 때 배너 요청이 필을 반환하는지 확인하되, 원하는 답이 수익 숫자라면 어떤 VPN 구성도 그런 숫자를 만들지 않으니 여기서 멈춰라.

이륙 전 준비: 주소가 아니라 기기를 등록하라

Google의 테스트 광고 문서는 두 가지 지원 경로를 제공한다. 연동하는 형식의 데모 광고 단위를 쓰거나, 실제 기기를 테스트 기기로 등록하고 자체 단위를 써라. 둘 다 플랫폼별, SDK 세대별로 문서화되어 있고 Next-Gen과 Legacy 가이드는 서로 호환되지 않는다.

등록은 기기 식별자이며 네트워크 주소와는 아무 관계가 없다. 휴대폰 트래픽이 나가는 곳을 바꿔도 아무것도 등록되지 않는다. Android에서는 SDK가 식별자를 로그에 남기고, 코드에서 이를 적용한다:

RequestConfiguration.Builder().setTestDeviceIds(Arrays.asList("YOUR_TEST_DEVICE_ID"))

네트워크를 바꾸기 전에 등록을 확인하라. 그렇지 않으면 실패한 필과 한 번도 등록되지 않은 기기에 제공된 라이브 광고를 구별할 수 없으니, 광고에 Test Ad 라벨이 보이면 테스트 재고를 통과한 것이고 보이지 않으면 다른 것을 보고 있으므로 건드리지 마라.

순서를 고정된 순서로 실행하라

네트워크 외에는 모두 일정하게 유지하라. 같은 빌드, 같은 광고 단위, 같은 배치, 같은 앱 상태. 변수를 두 개 바꾸면 아무것도 배우지 못한다.

먼저 베이스라인. VPN을 끈 상태에서 배치를 로드하고 테스트 광고가 나타나는지 확인하라. logcat에서 adb logcat | grep -i ads 로 요청을 캡처하고 응답 코드를 기록하라. 베이스라인의 노필은 VPN 문제가 아니다.

그다음 연결해 반복하라. 같은 빌드, 같은 단위, 같은 배치, VPN 켬. 같은 로그 줄을 캡처하라. 찾는 것은 차이이며, 필이 타임아웃으로 바뀌는지, 요청이 아예 나가지 않는지, 오류 코드가 바뀌는지다. 필이 그대로 필이면 그 경로에서 연동은 정상이고 테스트는 끝난 것이다.

환경을 기록하라. SDK 버전, 어댑터 버전, 빌드 유형, 광고 형식, 출구 국가, 관측 결과. 이 기록이 없으면 다음 사람은 같은 실험을 처음부터 다시 하고 같은 증거에서 다른 결론에 이른다.

미디에이션은 별도 테스트다

미디에이션 광고에는 Google의 Test Ad 라벨이 붙지 않아, 건드리면 안 되는 것을 클릭하기 가장 쉬운 곳이 된다. 미디에이션 스택의 각 네트워크에는 자체 테스트 모드와 설정이 있고, Google의 테스트 구성은 그들에게 적용되지 않는다.

어댑터를 하나씩 확인하되 어댑터 자체의 테스트 모드를 켜 두고, 어느 네트워크가 광고를 제공했는지 로그로 확인하라. 어느 어댑터가 필을 했고 테스트 크리에이티브였는지 알 수 없다면 그 노출은 라이브 재고로 취급하고 건드리지 마라.

무효 트래픽 정책이 중요해지는 지점도 여기다. 자기 클릭, 반복 노출, 자동화된 상호작용, 기만적 트래픽이 모두 포함되며, 어떻게 되는지 보려는 불확실한 클릭은 바로 그 규칙이 서술하는 패턴이다.

롤백과 릴리스 게이트

테스트 구성을 출시해서는 안 된다—릴리스 빌드 전에 데모 광고 단위를 프로덕션 단위로 바꾸고, 테스트 기기 목록을 제거하고, 개발 전용 플래그를 모두 삭제하라. 기억에 의존하지 말고 릴리스 변형에서 테스트 식별자를 grep하라. 잘못 남은 항목은 조용한 실패이며, 수익 누락으로만 드러난다.

그다음 반대 방향을 확인하라. 릴리스 빌드를 등록된 테스트 기기에 설치하고 요청이 더 이상 테스트 트래픽으로 취급되지 않는지 확인하라—라벨이 여전히 보이면 구성에 무언가 남아 있다.

이후에도 문서화된 테스트 경로를 하나 남겨 두면, 다음 네트워크 질문에 라이브 재고를 건드리지 않고 답할 수 있다. 테스트 광고는 계정 리포트에 절대 나타나지 않으므로, 깔끔한 분리는 리포트 정확도를 전혀 해치지 않으면서 반복 가능한 진단을 준다.

관련 글