멱등 Postback: 재무팀이 중복 집계를 신경 쓰는 이유
재시도해도 안전한 Postback이, 재무가 서명할 숫자와 재무가 다툴 숫자의 차이입니다. 멱등이 무엇인지, 운영사가 같은 이벤트를 두 번 보내는 이유, 그럴 때 제휴사 지갑에 보여야 할 것.
재무팀은 Postback을 싫어하지 않습니다. 다시 재생할 수 없는 합계를 싫어합니다. 요청이 타임아웃되어 다시 보내졌다는 이유로 같은 최초 입금이 두 번 나타날 수 있으면, 그 달은 닫히지 않습니다. 누군가는 금요일 오후를 CSV 둘과 형광펜과 보내게 됩니다. 멱등 Postback은 그 금요일을 취소하는 방법입니다.
이것은 능력에 관한 글입니다. AFFILIFY는 운영사가 두 번 보내도 전환을 한 번만 셉니다. 중복을 알아보는 방식은 공개 점검표가 아닙니다. 알아야 할 것은 문제의 모양, 선로에 무엇을 실을지, 재시도가 도착했을 때 제휴사 지갑이 해야 할 일입니다.
더 넓은 트래킹 그림이 필요하면 Postback 대 픽셀 대 이미지 태그가 비교입니다. 이것은 S2S의 재무 쪽 단면입니다.
여기서 멱등이 뜻하는 것
멱등이란 같은 이벤트를 두 번 적용해도 저장된 결과가 바뀌지 않는다는 뜻입니다. FTD #84102를 보냅니다. 큐가 200을 못 봐서 다시 보냅니다. 그래도 FTD는 하나입니다. 커미션도 하나입니다. 두 번째 요청은 에러가 아니고 두 번째 플레이어도 아닙니다.
반대는 HTTP 요청마다 올라가는 카운터입니다. 그 카운터는 재시도 로그와 맞을 것입니다. 운영사의 플레이어 데이터베이스와는, 한 사람만 보낸 제휴사와는 맞지 않습니다.
재시도는 버그가 아닙니다. 네트워크는 실패합니다. 로드 밸런서는 타임아웃합니다. 200이 사라집니다. 진지한 연동은 「확인될 때까지 보내기」를 정상 경로로 취급하고, 수신 측이 중복을 삼킬 수 있을 때만 안전합니다. 그것이 상품 요구의 전부입니다.
운영사가 보내야 할 것
클릭 ID는 이미 있습니다. 이벤트 유형도 이미 있습니다. 가입, FTD, 입금, 딜이 필요로 하는 그 외. 재시도가 새 객체가 아니라 같은 객체가 되도록 그 이벤트에 안정적인 식별자를 보내십시오. 정확한 필드 이름은 여기가 아니라 Postback 문서에 있습니다.
월말을 구하는 규칙이 세 가지입니다.
같은 페이로드를 재시도하십시오. nonce를 올리지 말고, 새 이벤트 ID를 만들지 말고, 타임아웃을 「고친다」며 FTD-2를 보내지 마십시오. 두 번째 전송은 첫 전송을 다시 한 것이어야 합니다.
HTTP 성공을 유일한 원장으로 쓰지 마십시오. 요청 전에 「FTD #84102를 보내려 했다」를 기록하고, 뒤에 「그들이 FTD #84102를 확인했다」를 기록해야 합니다. 요청만 기록하면 타임아웃이 구멍처럼 보이고, 그것을 메우려고 다른 이벤트를 보내게 됩니다.
NGR은 핑이 아니라 기간입니다. 입금 이벤트는 입금당 멱등일 수 있습니다. 월간 NGR 수치는 날짜 구간에 대한 진술입니다. 합쳐지기를 바라는 작은 증분의 흐름이 아니라, 그 구간에 대한 진술로 보내십시오. NGR과 네거티브 캐리오버가 그 차감이 안정적이어야 하는 이유의 제휴사 쪽 버전입니다.
픽셀은 이것을 잘하지 못합니다. 브라우저에서 두 번 발사되는 픽셀은 발사 둘입니다. 이미지 태그도 같습니다. S2S가 2026년의 기본값인 이유는, 셋 중 재무팀이 재생을 견딜 수 있는 유일한 것이기 때문입니다. 그것이 Postback 대 픽셀의 능력 주장입니다.
제휴사가 봐야 할 것
플레이어 하나, FTD 하나, CPA 행 하나. 전환을 열면 브랜드, 클릭, GEO, 서브 ID, 타임스탬프가 보여야 합니다. 쌍둥이는 보이지 않아야 합니다.
입금이 나중에 취소되면, 그것은 중복이 아니라 다른 이벤트입니다. 차지백, 보너스 남용, 취소된 결제. 그것들은 조정으로 도착하고, 돈을 보류에 넣을 수 있고, 대기 중 커미션을 되돌릴 수 있습니다. 재시도가 아닙니다. 지급이 돌아가는 방식이 대기 중, 사용 가능, 보류 중, 검토 중을 다룹니다. 나가는 지급 자체도, 들어오는 Postback이 한 번만 집계되는 것과 같은 이유로, 한 번만 집계됩니다.
무언가가 두 배로 보이면 지갑에서 시작하지 마십시오. 링크에서 시작하십시오. 깨진 클릭 ID는 여분이 아니라 빠진 전환을 만듭니다. 먼저 추적 링크를 QA하십시오. 그다음 랜딩 둘, 서브 ID 둘, 브랜드 둘이 실제 클릭 둘을 만들었는지 보십시오. 한 사람의 실제 클릭 둘은 이벤트 둘일 수 있습니다. 그것은 중복 집계가 아닙니다. 클릭 둘입니다.
이것이 운영사에게 판매 포인트인 이유
중복 집계하는 제휴 프로그램은 과지급하고, 회수하고, 관계를 소모합니다. 재시도를 떨어뜨리는 제휴 프로그램은 과소 집계하고, 다투고, 반대 방향으로 관계를 소모합니다. 멱등 S2S는 지루한 세 번째 선택입니다. 보내고, 필요하면 다시 보내고, 합계는 움직이지 않습니다.
AFFILIFY가 전환을 버킷이 아니라 행으로 보여 줄 수 있는 이유이기도 합니다. 행이 이벤트입니다. 재시도는 합계를 그 자리에 둡니다.
제휴사 쪽에서도 같은 규칙이 15일이 닫힐 수 있는 이유입니다. 대기 중이 사용 가능해지는 합계는, 큐가 14:58에 따라잡았다고 바뀌지 않습니다. KYC는 여전히 출금을 막습니다. 레벨은 여전히 적격 입금을 한 번만 셉니다. FTD 자체가 재시도 로그와의 동전 던지기라면 그중 아무것도 돌아가지 않습니다.
운영사로 이것을 연결한다면 문서에서 시작하고, 자체 클릭 파라미터를 쓰고, 「확인될 때까지 보내기」를 정상으로 취급하십시오. 제휴사라면 이것을 생각할 일이 없어야 하고, 그것이 요점입니다. 생각해야 한다면, 상류가 다른 이벤트 둘을 하나라고 부르며 보내고 있는 것입니다. 그것은 재시도가 아니라 연동 버그입니다.
자주 묻는 질문
Postback에서 멱등이란 무엇입니까?
같은 이벤트를 두 번 이상 보내도 한 번만 집계된다는 뜻입니다. 타임아웃과 재시도는 예상된 일입니다. 두 번째 HTTP 요청은 두 번째 FTD가 아니고 두 번째 커미션도 아닙니다. 페이로드가 바뀌고 새 이벤트 ID가 만들어졌다면, 그것은 재시도가 아니라 새 이벤트입니다.
운영사가 재시도하면 AFFILIFY 지갑에 FTD가 중복으로 보입니까?
안 보입니다. 같은 이벤트의 재시도는 두 번째 행을 더하지 않고 두 번째 CPA도 더하지 않습니다. 행이 둘 보인다면 이벤트가 둘이었습니다. 클릭 둘, 입금 둘, 또는 다른 이벤트 유형 둘. 플랫폼이 두 번 센 것으로 가정하지 말고, 브랜드와 풀어 볼 일입니다.
지급이 멱등인 것과 같은 이야기입니까?
같은 발상, 다른 방향입니다. 들어오는 전환은 재시도되어도 한 번만 집계됩니다. 나가는 지급은 지급 대행이 두 번 요청되어도 한 번만 적립됩니다. 둘 다 재무가 형광펜 없이 한 달을 닫을 수 있게 존재합니다. [지급이 돌아가는 방식](/blog/how-affilify-payouts-work)이 나가는 쪽입니다.
픽셀에도 이것이 필요합니까?
픽셀과 이미지 태그는 브라우저에서 발사되고, 페이지가 로드된 횟수만큼 발사됩니다. 서버 Postback처럼 재시도해도 안전하게 만들 수 없습니다. S2S가 기본값이고 픽셀이, 아직 서버 이벤트를 보낼 수 없는 사람을 위한 폴백인 이유 중 하나입니다. S2S를 택하십시오.
