랜딩 페이지에서 쓰는 Airtable
많은 리드 제너레이션 팀이 CRM이 아니라 베이스를 운영합니다. 리드 테이블 하나, 리드를 처리하는 칸반 하나, 어떤 캠페인이 돈이 되는지 알려 주는 롤업 몇 개. 약점은 리드를 들여오는 일입니다. 일일 내보내기는 점심이면 낡은 데이터가 되고, 중간의 Zap은 월 요금과 고장 날 곳 하나를 더합니다.
LanderLab은 커넥터 없이 그 공백을 메웁니다. 양식이 제출되는 순간 페이지의 웹훅이 리드를 Airtable API로 포스트하므로, 답변이 각자의 열에 들어갑니다. 페이지, A/B 변형, UTM도 함께 오고, 팀이 이미 믿는 베이스가 광고를 판단하는 곳이 됩니다.
고른 Airtable 열에 리드마다 레코드
베이스의 구조는 그대로입니다. 양식과 퀴즈 필드가 하나하나 팀이 이미 쓰는 이름의 지정한 열에 들어가므로, 유료 리드를 받기 시작한다고 뷰, 인터페이스, 자동화를 바꿀 필요가 없습니다.
Airtable의 typecast 옵션이 들어오는 길에 변환을 맡습니다. 퀴즈 답변은 single select 열의 옵션이, 날짜 문자열은 날짜가 됩니다. 데이터를 손으로 정리하지 않고도 베이스에 타입 필드를 유지하고, 예상하지 못한 새 답변은 그냥 새 옵션이 됩니다.
Airtable 칸반으로 보는 파이프라인
테이블에 상태 single select를 두면 새 레코드는 모두 기본값으로 정한 열에서 시작합니다. 칸반 뷰를 상태로 묶으면 오늘 아침 광고의 리드가 카드 한 열이 되고, 팀은 캠페인과 변형이 적힌 카드를 통화 완료, 예약, 성사로 끌어 옮깁니다.
거기서부터는 Airtable 자체 자동화가 이어받습니다. 카드가 예약에 닿으면 작업팀에 주소를 문자로 보내고, 리드가 성사로 표시되면 고객사에 이메일을 보냅니다.
캠페인과 변형별로 광고비 옆에 놓는 리드 품질
utm_campaign과 변형이 리드마다 함께 들어오므로, 롤업이나 연결된 캠페인 테이블이 캠페인별 리드, 예약, 성사를 보여 줍니다. 옆에 그날의 광고비를 붙여 넣으면, 양식 제출이 아니라 예약된 작업을 기준으로 어떤 광고 세트가 제값을 하는지 베이스가 알려 줍니다.
분할 테스트를 공정하게 읽는 방법이기도 합니다. 변형 B가 양식 제출로는 이기고 예약으로는 질 수 있는데, 레코드마다 LL Variant ID가 있으면 실제로 일정을 채우는 쪽이 어느 것인지 베이스가 보여 줍니다.
Airtable이 잠깐 말썽이어도 잃는 것은 없습니다
컴플라이언스 리드 전송을 켜지 않았다면, 모든 리드는 LanderLab 리드 탭에도 저장되고 날짜와 변형으로 필터링할 수 있으며 Grow 이상에서는 CSV로 내보낼 수 있습니다. Airtable이 요청을 거절해도 리드는 가져올 수 있게 남아 있습니다. Airtable은 베이스당 초당 요청 5건을 허용하며, 랜딩 페이지에는 충분합니다.
