광고주 전환 테스트의 시작과 성공을 분리하다

광고주는 광고를 집행하기 전에 자신의 행동이 전환으로 들어오는지 확인해야 합니다. 제가 만든 도구는 연동 값을 입력하고 테스트 링크를 만든 다음, 실제 행동에 해당하는 서버 기록을 확인하는 흐름이었습니다. 그런데 출시 뒤 고객 피드백에서 첫 기록을 만들기 위해 들어온 광고주에게 이미 과거 기록이 있어야 다음 단계로 갈 수 있는 모순이 드러났습니다.

저는 Vue 단계 화면·ViewModel·API client와 Node.js BFF의 조회·권한·요청 조건 전달을 맡았습니다. 전환의 실제 수집과 성공 판정은 서버가 담당했습니다. 이 사례에서 제가 구분한 것은 테스트를 시작할 자격과 이번 전환이 성공했다는 증거입니다.

먼저 행동부터 결과 확인까지 연결하다

기존에는 절차를 문서로 설명했습니다. 저는 API의 입력·응답 조건부터 제품 담당자와 논의해 진행과 성공의 기준을 확인했고, 운영 대시보드에서 연동 대상 조회→유형별 입력→테스트 링크 생성→광고주의 실제 행동→서버 기록 재조회로 이어지는 작업으로 만들었습니다. 링크를 만들었다는 사실은 테스트 준비가 끝났다는 뜻일 뿐, 전환이 성공했다는 뜻은 아니었습니다.

WEB·SDK·MMP 연동은 필요한 값이 달랐습니다. WEB은 URL과 추적 식별자, SDK는 광고 식별자, 모바일 측정 파트너인 MMP는 tracker·플랫폼·이벤트 이름과 발생 시각을 다뤘습니다. ViewModel에 유형별 표시와 값 변환을 모으고, QA 뒤에는 이전 단계의 숨은 입력이 다음 유형의 조회에 섞이지 않도록 조건을 정리했습니다.

화면 입력이 실제 판정까지 도착하는지도 확인했습니다. BFF에서 빠진 query 전달을 수정하고 구·신 권한 이름 호환을 보완했습니다. 필드 표시와 기본값뿐 아니라, store가 조회 요청에 넘기는 인자도 테스트했습니다. 화면에 값이 보이는 것과 서버가 그 값으로 전환을 찾는 것은 서로 다른 확인 조건이었습니다.

첫 테스트에 과거 기록을 요구하지 않다

2022년 12월에는 제품 담당자가 이 도구로 실제 고객의 전환을 확인했습니다. 운영 담당자는 그 결과를 근거로 추가 테스트 없이 예정된 집행을 진행할 수 있다고 판단했습니다. 그러나 이후 다른 고객은 연동 대상이 올바른데도 과거 포스트백이 없어 첫 단계에서 막혔습니다. 고객에게는 식별자를 잘못 입력한 것처럼 보였습니다.

제품 담당자가 이 피드백을 전달했고 팀은 과거 기록이 없어도 첫 테스트를 진행할 수 있도록 정했습니다. 저는 이벤트 소스 조회의 빈 배열을 실패로 취급하던 조건을 바꿨습니다. 다음 화면에서도 목록이 없다는 이유로 로그 조회 영역을 숨기지 않도록 수정했습니다. 첫 화면만 통과하고 결과를 다시 조회할 수 없다면 고객의 작업은 끝나지 않기 때문입니다.

과거 이벤트가 없어도 테스트 링크 생성
→ 광고주가 첫 행동 수행
→ 이번 전환 기록 재조회
→ 서버 판정이 있을 때만 성공 표시

응답 형태와 연동 유형 확인은 유지했습니다. 시작 조건은 완화했지만 성공 기준은 완화하지 않은 것입니다. 2023년 1월 변경으로 과거 기록이 없는 대상도 첫 테스트를 시작하고 결과를 재조회할 수 있게 했습니다. 이후 고객이 몇 명 다시 사용했는지나 전환 조회의 실패율은 확인된 결과로 제시할 수 없습니다.