랜딩 페이지에서 쓰는 웹훅
대부분의 리드 제너레이션 스택에는 중간에 세금이 붙습니다. 리드를 직접 받을 수 있었던 엔드포인트로 페이지의 리드를 옮기는 게 유일한 일인 Zap이나 시나리오 말입니다. 모든 리드가 그 중간 단계의 값을 작업이나 크레딧으로 치르고, 중간 단계 하나하나가 구매자가 기다리는 동안 리드가 멈출 수 있는 곳이 됩니다.
LanderLab의 웹훅 연동은 그 세금을 없앱니다. 각 페이지가 리드를 원하는 HTTPS 엔드포인트로 바로 보냅니다. 구매자의 포스팅 URL, 자체 리드 API, CRM의 엔드포인트, 트래커의 포스트백까지. 메서드, 형식, 헤더, 정확한 본문을 직접 정하므로, 상대는 자기 문서에 적힌 그대로 리드를 받습니다.
이 사이트에서 자체 항목이 없는 도구 대부분이 이 연동을 쓰며, 구매자가 사양서를 보내오면 꺼내 들 연동이 바로 이것입니다.
미들웨어에 돈을 내는 것보다 직접 웹훅이 나은 이유
페이지에서 Zap을 거쳐 구매자로 가는 리드는 두 시스템에 의존하고, 그중 하나에서 요금이 나갑니다. 물량이 많은 오퍼에서는 중간에서 하는 일이라곤 Zap이 리드를 받아 다른 곳에 포스트하는 것뿐인데도, 리드 수에 따라 자동화 요금제가 커집니다.
직접 웹훅은 중간 단계 없이 같은 포스트를 합니다. 리드는 제출 시 페이지에서 엔드포인트로 바로 가고, 모든 것이 내 통제 아래 있으며, 멈추거나 작업이 바닥나거나 가격을 바꿀 중간 단계가 없습니다. 여러 단계가 필요한 작업은 미들웨어에 맡기고, 그렇지 않은 작업은 웹훅이 나르게 하세요.
상대가 기대하는 형식으로 리드 보내기
구매자와 API는 까다롭습니다. 어떤 곳은 사양서에 적힌 이름 그대로의 필드로 된 평면 폼 포스트를 원하고, 어떤 곳은 연락처를 리드 객체 안에, 트래킹을 또 다른 객체 안에 중첩하고 그 옆에 고정 소스 태그와 캠페인 ID를 둔 JSON을 원합니다. 웹훅은 둘 다 합니다. 필드를 체크하고 키 이름을 하나씩 바꾸는 간단한 필드 목록, 또는 중첩 객체, 배열, 고정 값을 넣어 직접 작성하는 JSON 본문입니다.
메서드는 GET, POST, PUT을 지원하고, 본문은 JSON이나 URL 인코딩 폼 데이터로 보내며, 커스텀 헤더에 API 키나 토큰을 실으므로 자격 증명이 URL에 남지 않습니다.
모든 리드에 컴플라이언스·어트리뷰션 필드
LanderLab은 모든 리드에 자체 필드를 더합니다. 전체 페이지 URL, 방문자의 IP와 사용자 에이전트, UTC 기준 제출 시각, 노출된 A/B 변형입니다. 리드에 이의가 제기될 때 구매자가 확인하는 필드이자, 리드의 출처를 증명할 때 필요한 필드입니다.
utm_campaign, gclid, 트래커의 클릭 ID처럼 URL 파라미터와 같은 이름으로 숨김 필드를 추가하면, 리드와 함께 저장되고 함께 전송됩니다. 구매자는 어트리뷰션을 받고, 나는 단순 양식 제출이 아니라 승인된 리드를 기준으로 각 변형을 판단할 수 있습니다.
GET으로 포스트백과 핑
모든 목적지가 본문을 원하지는 않습니다. 트래커 포스트백, 제휴 네트워크의 전환 URL, 간단한 핑은 쿼리 문자열로 데이터를 받으며, GET 웹훅은 매핑한 필드를 정확히 그렇게 보냅니다. 트래커가 기대하는 파라미터 이름에 클릭 ID를, 그 옆에 고정 지급액이나 상태를 담아서요. 전환은 제출 시 그 클릭을 산 캠페인으로 돌아갑니다.
워크플로를 대신 써야 할 때
웹훅은 그 페이지의 모든 리드를 보냅니다. 미국 리드는 한 구매자에게, 나머지는 다른 구매자에게, 또는 지연 후 후속 조치처럼 일부 리드만 보내야 한다면, LanderLab의 워크플로(베타)에 같은 종류의 요청이 HTTP 요청 노드로 있습니다. 필터, 조건 분기, 케이스 분기 노드 뒤에 둘 수 있고, 실행 화면에서 각 리드의 경로와 실패한 단계를 볼 수 있습니다.
어느 쪽이든 리드는 LanderLab의 리드 탭에도 저장되므로, 엔드포인트가 다운됐다고 리드를 잃지 않습니다. 단, 설계상 저장을 건너뛰는 ‘컴플라이언스 리드 전송’이 켜져 있으면 예외입니다.
