포스트백, 픽셀, 이미지 태그: 지급 근거가 되는 것은 하나뿐입니다

전환을 보고하는 방법은 세 가지입니다. 이미지 태그, 자바스크립트 픽셀, 그리고 서버 간 포스트백. 이 중 커미션을 지급할 근거로 쓸 만큼 견디는 것은 포스트백뿐입니다. 플레이어의 브라우저가 협조해 주지 않아도 되기 때문입니다. "트래킹이 안 된다"는 연동 대부분은 사실 포스트백이 깨진 것이 아니라, 플레이어 레코드에 클릭 식별자가 없는 것입니다.

전화는 늘 곤란한 시간에 옵니다. 제휴 매니저는 트래픽을 빼겠다는 파트너를 붙잡고 있고, 운영사는 연동이 살아 있다고 장담하며, 대시보드에는 0이 찍혀 있습니다. 누군가 입금 완료 페이지 푸터에 박힌 태그 스크린샷을 보내면서 왜 작동하지 않느냐고 묻습니다.

작동하지 않는 이유는, 그것이 페이지 푸터에 박힌 태그이기 때문입니다.

전환 보고는 작은 문제이지만 틀리는 방법은 많고, 그 방법들은 10년째 크게 달라지지 않았습니다. 달라진 것은 세 가지 중 둘이 조용히 신뢰를 잃는 동안에도 모두가 그것을 계속 배포해 왔다는 점입니다. 이 글은 연동이 끝난 뒤가 아니라 시작하기 전에 엔지니어에게 건네야 할 글입니다.

플레이어가 입금했다고 말하는 세 가지 방법

이미지 태그. 가장 오래된 방식입니다. 페이지에 1픽셀짜리 이미지를 넣고 그 소스를 트래킹 플랫폼의 URL로 지정합니다. 브라우저가 이미지를 불러오려 시도하면 그 요청이 플랫폼에 도달하고, 요청 자체가 곧 메시지입니다. 실제 이미지는 필요 없습니다. 요청이 목적입니다. HTML 말고는 아무것도 필요 없어서, 아무도 자바스크립트를 건드리고 싶어 하지 않는 템플릿 시스템에서 그토록 오래 살아남았습니다.

자바스크립트 픽셀. 같은 발상을 이미지 대신 스크립트로 합니다. 스니펫이 페이지에서 실행되어 약간의 맥락을 모아 호출을 보냅니다. 더 유연합니다. 페이지가 변수에 담아 둔 값을 읽을 수 있고, 확인 화면이 그려질 때까지 기다릴 수 있으며, 런타임에야 알 수 있는 입금 금액을 실어 보낼 수 있습니다. 동시에 더 취약합니다. 스크립트가 로드되어야 하고, 변수가 존재해야 하고, 그 위쪽에서 페이지가 에러를 던지지 않아야 하니까요.

서버 간 포스트백. 브라우저가 아예 없습니다. 백엔드가 문제의 이벤트를 기록하는 시점에, 플레이어가 처음 도착했을 때 넘겨받은 식별자를 실어 특정 URL로 HTTP 요청을 보냅니다. 결제 서비스가 입금을 확정하고, 시스템이 거래를 기록하며, 같은 경로 어딘가에서 요청 하나가 나갑니다. 이 플레이어, 이 이벤트, 이 금액, 이 통화라고.

그게 전부입니다. 앞의 둘보다 덜 영리하게 들리는데, 바로 그 이유로 견딥니다.

셋 중 둘이 믿을 수 없게 된 이유

원인은 하나가 아닙니다. 쌓여 있고, 각각만 놓고 보면 견딜 만한 것들입니다.

Safari와 Firefox는 서드파티 쿠키를 기본 차단하고, Firefox는 자체 트래커 목록에 있는 도메인으로의 요청도 차단합니다. Chrome은 여전히 서드파티 쿠키를 허용하므로, Chrome에서는 브라우저가 아니라 광고 차단기가 막습니다. Safari는 스크립트가 기록한 저장소의 수명에 추가로 상한을 두는데, 경우에 따라 며칠 수준까지 내려갑니다. 클릭 시점에 쓰고 입금 시점에 읽는 상태에 의존하는 모든 것이, 정상적인 고민 기간의 일부밖에 안 되는 유효 기간을 갖게 된다는 뜻입니다. 그 위에 광고 차단기가 얹히고, 하필 가입 전에 비교 콘텐츠를 읽는 바로 그 독자층에서 흔합니다. 어느 것도 자기가 막았다고 알려 주지 않습니다. 운영사는 페이지가 멀쩡히 그려지는 것을 보고 연동이 된다고 결론 내립니다.

그리고 어떤 브라우저 설정으로도 고칠 수 없는 부분이 있습니다. 플레이어가 회사 데스크톱에서 클릭하고, 고민하다가, 그날 저녁 휴대폰으로 입금합니다. 또는 웹에서 가입하고 네이티브 앱 안에서 입금합니다. 앱에는 브라우저도, 페이지도, 발사할 태그도 없습니다. 특히 스포츠북에서는 입금이 클릭이 아니라 경기 일정표를 따라가고, 그 일정표를 따라 앱 안으로 들어갑니다. 두 여정이 얼마나 다르게 움직이는지 보려면, 카지노와 스포츠북 트래픽이 정확히 이 지점에서 갈라집니다.

픽셀은 브라우저가 한 번도 가지 않은 곳에서 발사될 수 없습니다. 이것은 태그를 더 잘 배치한다고 해결되는 문제가 아닙니다.

알아 둘 만한 실패 유형

연동을 흥미로운 방식으로 깨뜨리는 사람은 없습니다. 거의 전부가 같은 여섯 가지 실수입니다.

이벤트가 아니라 페이지 로드 시점에 발사합니다. 태그가 입금 확인 페이지에 있으니 그 페이지가 열릴 때마다 발사됩니다. 플레이어가 새로고침하거나, 뒤로 가기로 돌아오거나, 실패한 시도 뒤에 그 페이지에 도착하면 그 하나하나가 리포트상 전환이 됩니다. 숫자를 보기 좋은 방향으로 부풀리기 때문에, 아무도 의심하지 않은 채 오래 살아남습니다.

정말 서버 사이드입니까? 백엔드 프레임워크가 템플릿을 렌더링해도 결국 브라우저가 실행해야 할 태그를 뱉는 것입니다. 요청이 플레이어의 기기에서 출발한다면, 어느 파일에 쓰였든 그것은 브라우저 사이드입니다. 확인은 1분이면 됩니다. 자기 브라우저에서 스크립트를 차단하고 이벤트가 여전히 도착하는지 보십시오.

그리고 플레이어 레코드에 없는 클릭 식별자가 있습니다. 압도적으로 가장 흔한 실패이고, 아래에 절을 따로 두었습니다.

입금이 정산되기 전에 보고됩니다. 결제가 승인되고 포스트백이 나간 뒤 결제가 실패하거나 취소됩니다. 이제 도착한 적 없는 돈에 커미션이 붙습니다. 결제 페이지가 보여 주는 상태가 아니라 재무팀이 인정할 상태에서 발사하십시오.

멱등성, 또는 그 부재. 네트워크는 타임아웃이 납니다. 잘 만든 발신 측은 재시도하고, 그것이 옳습니다. 수신 측이 두 번째 시도가 첫 번째와 같은 이벤트임을 구분하지 못하면, 그 재시도는 두 번째 전환이 됩니다. 모든 이벤트에는 발신 측이 부여한 안정적인 고유 참조값이 필요합니다. 재시도할 때마다 같은 값이어야 중복을 두 번 지급하는 대신 인식하고 버릴 수 있습니다.

이벤트는 순서가 어긋난 채 도착하기도 합니다. 두 서비스가 각자 발사했고 한쪽이 더 빨랐다는 이유로, 입금이 그것이 속한 가입보다 먼저 도착합니다. 서로 의존하는 이벤트는 순서를 보장하거나, 각 이벤트가 혼자서도 설 수 있을 만큼의 맥락을 싣게 하십시오.

모든 것을 결정하는 한 가지

위의 실패는 전부 한나절이면 고칩니다. 이것은 아닙니다.

플레이어가 트래킹 링크를 통해 도착하면, 그 링크에 실린 식별자는 가입 시점에 플레이어 레코드에 저장되어야 합니다. 세션에 두는 것이 아닙니다. 쿠키에 두는 것도 아닙니다. 그 계정을 나타내는 데이터베이스의 그 행에, 이메일 주소 옆에, 그 행을 만드는 같은 트랜잭션 안에 저장해야 합니다.

그렇게 되지 않으면 그 뒤의 어떤 것도 어트리뷰션될 수 없습니다. 플레이어가 3주 뒤에 입금하고, 백엔드는 기술적으로 완벽한 포스트백을 보내지만 거기에는 식별자가 없습니다. 실을 것이 없기 때문입니다. 포스트백을 아무리 손봐도 고쳐지지 않습니다. 지금 디버깅하는 것은 리포팅 문제가 아니라 가입 문제이고, 고칠 곳은 가입 플로우입니다.

관련된 습관 둘이 많은 논쟁을 줄여 줍니다. 값이 이상해 보여도 식별자를 그대로 보관하십시오. 여러분이 하는 일은 토큰을 검증하는 것이 아니라 저장하는 것입니다. 그리고 30일이 아니라 계정 수명 내내 보관하십시오. 적격 입금에 지급하는 CPA는 그 입금이 적격이 되는 시점까지 연결이 살아 있어야 하는데, 그 시점은 클릭으로부터 몇 달 뒤일 수 있습니다. 적격 입금과 최초 입금을 둘러싼 용어가 아직 흐릿하다면, 스키마를 쓰기 전에 FTD, NGR, CPA, CPL, CPR 용어집에 10분을 쓸 가치가 있습니다.

트래픽을 돌리기 전에 하는 테스트

제대로 된 연동 테스트는 지루하고 한 시간쯤 걸립니다.

1. 실제 트래킹 링크를 클릭하고 평범한 플레이어처럼 가입을 끝내십시오. 그런 다음 자사 데이터베이스에서 플레이어 레코드를 열어 식별자가 붙어 있는지 확인하십시오. 없다면 거기서 멈추십시오. 그 뒤는 전부 연극입니다.
2. 실제 돈으로 입금하십시오. 소액이면 됩니다. EUR 20이면 충분합니다. 테스트 모드 결제는 이벤트를 발사하는 바로 그 코드 경로를 건너뛰는 일이 잦고, 그래서 스테이징에서는 통과한 연동이 첫날에 무너집니다.
3. 입금 이벤트가 한 번만, 올바른 금액과 통화로, 결제가 제출된 시점이 아니라 정산된 뒤에 도착했는지 확인하십시오.
4. 같은 이벤트를 일부러 한 번 더 보내십시오. 중복으로 인식되어 두 번 집계되지 않아야 합니다.
5. 전체를 휴대폰에서 반복하고, 앱이 있다면 브라우저가 아니라 앱에서 입금해 한 번 더 반복하십시오.

엔지니어 한 시간과 입금 한 건이면 됩니다. 이미 자기 트래픽이 깎이고 있다고 확신하는 제휴사와 한 달간 대사를 벌이는 쪽과 비교해 보십시오. 트래킹 링크 QA 절차가 같은 테스트의 제휴사 쪽을 다루며, 양쪽 끝을 함께 돌리는 것이 분기 하나가 아니라 한나절 만에 불일치를 찾아내는 방법입니다.

AFFILIFY가 운영사에게 기대하는 것

연동 레퍼런스는 affilify.partners/docs에 있고, 엔드포인트와 파라미터 이름, 허용되는 이벤트 유형이 정리되어 있습니다. 블로그 글이 아니라 거기서 읽으십시오. 최신 상태로 유지하는 페이지는 그쪽입니다.

형태는 단출합니다. 이벤트 이름, 클릭 시점에 넘겨받은 식별자, 금액과 통화, 그리고 키. 가입, 최초 입금, 이후 입금, 매출 이벤트는 각각 별개의 메시지입니다. 딜에 붙은 커미션 모델이 그중 무엇이 중요한지 결정하고, 프로그램은 받은 적 없는 데이터로 RevShare를 지급할 수 없기 때문입니다. 아직 모델을 고르는 중이라면 CPA, RevShare, 하이브리드가 각 모델이 여러분 쪽에서 무엇을 필요로 하는지 정리해 둔 글입니다.

분명히 말해 둘 것이 둘 있습니다. 저희 쪽 어트리뷰션에는 여러 겹의 폴백이 있습니다. 그것은 보험이지 계획이 아닙니다. 가입 시점에 저장되는 식별자는 여러분이 통제하는 부분이니 보내 주십시오. 그리고 트래픽 품질은 상시 평가되므로, 일부 전환은 도착 즉시 적립되는 대신 확인되는 동안 보류됩니다. 이것은 거절이 아니며, 제휴사에게는 조용한 공백이 아니라 그 상태가 보입니다.

식별자를 되돌려 주고, 정산된 이벤트를 한 번만 보고하며, 실제 입금으로 한 시간 안에 테스트할 수 있는 운영사는 밤 열한 시의 그 통화를 겪을 일이 없습니다. 이 글의 목표는 그것뿐입니다.