디에스기획 자료실 / 2026-07-30 갱신

DB 운영 기록

DB 광고 허수·중복 신청,
무엇으로 걸러내는가

랜딩으로 들어온 신청서가 진짜 고객인지 같은 사람의 반복 제출인지 구분하지 못하면, 광고비가 새는 것처럼 보이는 착시가 생깁니다. 단일 랜딩 1개에서 9개월간 모인 신청 전체를 전수 집계하고, 판별 항목을 하나씩 실제로 심어 검증한 기록입니다.

먼저 중복이 얼마나 섞이는지

중복 대응을 설계하기 전에 규모를 알아야 합니다. 임플란트 상담 랜딩 1개를 단일 매체 전용으로 운영하면서 2025년 10월부터 2026년 7월까지 쌓인 신청을 스프레드시트 함수로 직접 재계산했습니다.

집계 결과, 같은 번호의 재제출분이 전체 신청에서 무시할 수 없는 비중을 차지했고, 한 번호가 수십 회 반복된 극단 사례도 있었습니다. 계산 자체는 간단합니다. 신청 총건수에서 고유 전화번호 수를 빼면 재제출 초과분이 나오고, 그것을 총건수로 나누면 자기 랜딩의 중복률입니다. 이 비율은 업종·매체·랜딩 구조에 따라 크게 달라지므로 남의 수치가 아니라 본인 데이터로 계산하는 것이 먼저입니다.

여기서 한 가지 주의할 점이 있습니다. 이 집계 과정에서 조회 도구가 전화번호 열을 숫자형으로 자동 인식해, 하이픈이 들어간 형태로 저장된 수백 건을 빈 값으로 반환한 적이 있습니다. 실제로는 전 행이 정상이었습니다. 텍스트와 숫자가 섞인 열은 스프레드시트 자체 함수로 교차검증하지 않으면 없는 문제를 만들어냅니다.

중복은 허수와 같은 말이 아니다

같은 번호가 두 번 들어왔다는 사실만으로 허수라고 부를 수는 없습니다. 다시 신청한 사람들은 며칠의 간격을 두고 관심 항목을 바꿔 제출한 경우가 많았습니다. 며칠쯤 고민한 뒤 조건을 바꿔 다시 문의하는 행동은 오히려 상담 의도가 강한 쪽입니다.

의심해야 하는 구간은 따로 있습니다. 몇 분 안에 다시 제출된 건들은 사람의 재검토로 설명되지 않는 구간입니다. 중복을 일괄 삭제하는 대신 간격으로 나누는 것이 실전에서 맞습니다.

판별 항목의 우선순위

수집할 수 있는 항목은 여러 개지만 판별력은 같지 않습니다. 하나씩 심어 테스트한 결과 아래 순서로 신뢰했습니다.

1 · 기기지문

이름과 번호를 바꿔도 같은 기기면 동일한 값이 남습니다. 판별력이 가장 높습니다.

2 · 접속 IP

같은 회선을 공유하는 다중 사용자가 있어 단독으로는 약하지만, 기기지문과 겹칠 때 확신을 줍니다.

3 · 번호 중복

재제출 간격과 함께 봐야 의미가 생깁니다. 그 자체로는 판정 근거가 아닙니다.

4 · 광고 클릭 ID

허수 판별보다 광고 유입 여부를 증명하는 데 씁니다.

기기지문은 실제로 구분이 되나요

화면 규격, 시간대, 언어, 플랫폼 값 등을 조합해 짧은 해시로 저장하는 방식입니다. 아이폰, 갤럭시, 화면 크기가 다른 아이폰, 윈도우 PC 네 종류로 시험했을 때 네 값이 모두 달랐습니다. 반대로 같은 기기에서 세 번 완주해 제출했을 때는 세 건 모두 같은 값이 기록됐습니다. 반복 제출 식별의 핵심 근거가 여기서 나옵니다.

광고를 끈 기간에도 DB가 들어온다는 의심은 어떻게 푸나요

광고 클릭 ID로 풉니다. 구글은 클릭 시 URL에 gclid, 상황에 따라 gbraid나 wbraid를 자동으로 붙이고, 틱톡은 ttclid를 붙입니다. 계정에서 자동 태그 설정이 켜져 있는지 먼저 확인한 뒤, 이 값을 신청 데이터에 같은 행으로 저장하면 됩니다.

실제 문의 사례에서는 광고 종료 다음 날부터 상당 기간 신청이 0건이었습니다. 광고비 누수는 없었다는 뜻입니다. 이후 재개된 유입은 전량 같은 기기 1대에서 직접 접속으로 반복 제출된 것이었고, 하루에 같은 경로로 수십 회 넘게 열람된 기록도 남아 있었습니다. 클릭 ID와 기기지문을 같이 저장해두지 않았다면 이 구분 자체가 불가능했습니다.

유입 경로만 저장하면 안 되나요

보조 지표로만 써야 합니다. 판별 코드가 정확하게 동작해도 iOS와 인앱 브라우저, 일부 광고 매체에서는 referrer 값 자체가 빈 값으로 도착합니다. 원본 값이 오지 않는 항목을 단독 근거로 쓰면 실제 광고 유입을 직접 접속으로 잘못 분류하게 됩니다.

신청 데이터에 빈칸이 많은 이유는 무엇인가요

대화형 랜딩은 단계별로 저장 시점이 다릅니다. 앞부분에서 행을 만들고 뒷부분에서 그 행을 갱신하는 구조라면, 마지막 단계까지 끝내지 않고 이탈한 사람은 뒤쪽 항목이 비어 있게 됩니다. 개인정보 동의나 통화 가능 시간대 같은 열이 유독 많이 비어 있다면 데이터 오류가 아니라 이탈 지점을 보여주는 지표입니다.

적용할 때 놓치기 쉬운 것

• 개인정보처리방침을 먼저 고칩니다. IP와 기기·브라우저 정보, 접속 기록을 수집한다면 동의 안내문에 항목을 명시해야 합니다.
• 원본을 건드리지 않고 복제본에서 검증합니다. 운영 중인 랜딩과 데이터 시트는 그대로 두고, 사본으로 실제 제출 테스트까지 통과한 다음 교체하는 순서가 안전합니다.
• 수집 도구의 흔적이 데이터에 남지 않게 합니다. 호스팅 도메인이 그대로 기록되면 광고주가 보는 시트에 내부 구성이 노출됩니다.
• 기존 캠페인의 URL을 일괄 수정하는 방식은 현실성이 낮습니다. 소재별 구분 파라미터는 신규 캠페인부터 적용하는 편이 낫습니다.

작성 · 김대한 (디에스기획 대표) — 보험·병의원·대출 등 규제 업종 DB 광고 컨설팅.
본문의 사례는 디에스기획이 직접 운영한 랜딩 1개의 운영 기록이며, 업종·매체·랜딩 구조에 따라 결과는 크게 달라집니다. 광고주 식별 정보와 구체 수치는 포함하지 않았습니다.
자료실 목록 · 디에스기획 홈