식별자 값이 채워야 할 네 가지 조건
전환 중복 제거용 식별자는 예약 한 건마다 다른 값이어야 하고, 같은 예약에는 새로고침이나 다시 보내기, 나중의 업로드에서도 늘 같은 값이어야 하며, 환자를 알아볼 정보를 담지 않고, 매체가 정한 길이와 형식에 맞아야 합니다. 구글 광고 도움말은 같은 전환 액션에 같은 거래 ID로 전환이 두 번 들어오면 두 번째를 중복으로 알고 세지 않는다고 안내하므로, 식별자가 이 네 조건을 채울 때만 중복 제거가 제대로 작동합니다.
첫째 조건이 깨지면 전환이 크게 줄어듭니다. 도움말은 거래 ID를 거래마다 고유하게 백엔드에서 동적으로 만들어야 하며, 같은 ID를 고정해 넣거나 정적인 값을 쓰면 그 ID의 첫 번째만 처리되어 실제보다 훨씬 적게 집계된다고 경고합니다. 둘째 조건이 깨지면 반대로 중복이 걸러지지 않습니다. 새로고침할 때마다 새 값을 만드는 식별자는 같은 예약을 매번 다른 거래로 보이게 합니다.
셋째 조건은 식별자가 광고 매체로 넘어가는 값이기 때문에 생깁니다. 도움말은 거래 ID에 개별 고객을 식별할 수 있는 정보를 넣지 않아야 한다고 밝힙니다. 병원이 가진 값 가운데 예약마다 다르고 늘 같은 값이라는 두 조건을 채우는 것은 흔히 이름이나 연락처처럼 사람을 가리키는 값이어서, 편해 보이는 값일수록 셋째 조건에서 걸러야 합니다.
식별자의 네 가지 조건과 흔히 어기는 값
| 조건 | 흔히 어기는 값 | 어겼을 때 생기는 일 |
|---|---|---|
| 예약마다 다름 | 고정된 글자, 페이지 이름, 지점마다 처음부터 새로 매긴 번호 | 다른 예약이 같은 값으로 들어가 적게 셈 |
| 같은 예약에는 늘 같음 | 새로고침마다 새로 만드는 값, 시각을 쓴 값, 예약을 바꿀 때 새로 매기는 번호 | 같은 예약이 여러 번 셈 |
| 환자를 알아볼 정보가 없음 | 이름, 연락처, 생년월일, 진료명, 이들을 섞어 만든 값 | 환자 정보가 광고 매체로 넘어감 |
| 형식과 쓰는 곳마다 같음 | 매체의 길이를 넘는 값, 태그와 업로드에서 다른 값 | 값이 잘리거나 두 경로의 전환이 따로 셈 |
네 가지 조건 표의 첫째 줄에서 지점마다 새로 매긴 번호는 병원이 놓치기 쉬운 경우입니다. 두 지점이 각자 예약 번호를 처음부터 매기면 서로 다른 두 예약이 같은 번호를 갖게 되고, 두 지점이 한 광고 계정의 같은 전환 액션을 쓴다면 뒤에 들어온 예약이 중복으로 처리됩니다. 지점마다 앞에 다른 글자를 더해 번호가 겹치지 않게 하는 방식으로 풀 수 있습니다.
네 가지 조건 표의 넷째 줄인 형식에 대해 도움말은 거래 ID가 숫자와 문자, 특수 문자를 쓸 수 있고 예순네 자 이내여야 한다고 안내합니다. 태그와 서버 쪽 업로드를 함께 쓴다면 두 경로의 거래 ID가 일관되어야 한다고도 밝혀, 같은 예약을 두 경로로 보낼 때는 같은 값을 쓰는 것이 조건입니다.
쓰고 있는 식별자를 가리는 다섯 단계
- 광고 담당 실장이 홈페이지 업체에 지금 전환 태그가 식별자를 보내는지, 보낸다면 그 값이 어디서 만들어지는지를 받습니다.
- 광고 담당 실장이 받은 값을 네 가지 조건 표의 줄마다 대어, 채우는 조건과 어기는 조건을 표시합니다.
- 원장이 식별자로 쓸 값을 정합니다. 예약이 만들어질 때 예약 시스템이 매기는 번호처럼 사람을 가리키지 않는 값을 기본으로 합니다.
- 홈페이지 업체가 정한 값을 예약이 성공한 때 전환과 함께 보내도록 설정하고, 광고 담당 실장이 설정한 날을 기록합니다.
- 설정한 뒤 광고 담당 실장과 원무 담당이 같은 길이의 기간으로 전환 수와 접수 기록의 광고 경로 예약 수를 맞댑니다.
첫째 단계에서 값의 출처를 받는 까닭은, 화면에 보이는 값만으로는 그 값이 어떻게 만들어지는지 알 수 없기 때문입니다. 완료 화면에 번호가 보여도 그것이 예약 시스템이 매긴 번호인지, 화면이 열릴 때마다 새로 만드는 값인지에 따라 둘째 조건의 결과가 정반대가 됩니다.
다섯째 단계의 맞댐은 병원 쪽에서 예약을 넣어 보는 방식으로 하지 않습니다. 설정한 뒤 전환이 거의 없을 정도로 크게 줄었다면 첫째 조건이 깨져 같은 값이 들어가고 있을 가능성이 있고, 전환이 여전히 접수 기록보다 많다면 둘째 조건이 깨졌거나 다른 곳의 중복이 남은 것입니다. 두 모양 모두 값의 출처를 업체와 다시 맞댑니다.
넷째 단계에서 예약이 성공한 때 보내도록 하는 까닭은, 식별자가 있어도 실패한 신청에 전환이 걸려 있으면 실패한 신청마다 새 값이 만들어져 전환이 세어지기 때문입니다. 식별자는 보내는 때가 맞게 정해진 뒤에야 중복을 거르는 일을 합니다.
셋째 단계에서 원장이 값을 정하는 까닭은 셋째 조건이 병원의 개인정보 판단과 맞닿기 때문입니다. 예약 번호에 진료 날짜나 진료과를 뜻하는 글자가 섞여 있다면, 그 번호로 무엇을 알 수 있는지까지 따져 쓸지 정합니다.
식별자가 거르지 못하는 중복
| 중복의 모양 | 식별자로 걸러지는가 | 막는 곳 |
|---|---|---|
| 같은 예약이 새로고침으로 다시 보내짐 | 걸러짐, 같은 전환 액션이고 값이 같다면 | 식별자 |
| 같은 예약을 두 전환 액션이 함께 셈 | 걸러지지 않음, 도움말의 중복 제거는 같은 전환 액션 안에서만 | 주요 전환을 한 액션으로 정리 |
| 다시 신청해 예약이 두 건 생김 | 걸러지지 않음, 예약 번호가 둘로 매겨짐 | 신청 창의 다시 누르기 막기와 접수 기록 정리 |
식별자가 거르지 못하는 중복 표의 둘째 줄과 셋째 줄은 식별자를 넣은 뒤에도 전환이 접수 기록보다 많을 때 먼저 찾을 곳입니다. 식별자는 같은 값의 되풀이만 거르므로, 서로 다른 값으로 들어온 중복은 설정이나 예약 흐름에서 따로 막습니다. 식별자를 넣었다고 중복이 모두 사라졌다고 보고하지 않고, 이 표의 어느 줄까지 막았는지를 설정 기록에 함께 씁니다.
네이버 검색광고의 전환 스크립트에 이런 식별자를 넣어 중복을 거르는 방법이 있는지는 확인한 안내 범위에 나오지 않습니다. 네이버 쪽 중복은 전환을 보내는 조건을 고쳐 막는 것을 기본으로 하고, 매체마다의 성과를 함께 읽는 방법은 병원 광고 성과 분석에서 따로 다룹니다.
두 지점의 예약 번호가 겹친 치과 가상 사례
아래는 설명을 위해 만든 가상의 사례입니다. 두 지점을 둔 치과가 한 광고 계정에서 두 지점의 예약 전환을 같은 전환 액션으로 세고 있었습니다. 새로고침 중복을 막으려고 예약 번호를 거래 ID로 보내기 시작한 뒤, 광고 담당 실장은 전환 수가 접수 기록보다 눈에 띄게 적어진 것을 발견했습니다.
실장이 홈페이지 업체에 값의 출처를 묻자, 두 지점의 예약 시스템이 각자 번호를 처음부터 매기고 있다는 답이 왔습니다. 같은 날 두 지점에서 같은 번호의 예약이 생기면 뒤의 예약이 중복으로 처리되어 세어지지 않았던 것입니다. 네 가지 조건 표의 첫째 줄을 어긴 모양이었습니다.
지점을 가리는 글자를 더한 뒤
원장은 지점마다 번호 앞에 서로 다른 글자를 더해 식별자로 쓰기로 정했고, 그 글자는 지점의 이름이 아니라 병원 안에서만 뜻을 아는 짧은 기호로 하기로 했습니다. 업체가 설정을 고친 날 실장은 설정 기록에 그 날짜를 남기고, 원무 담당과 함께 다음 기간의 전환 수와 두 지점의 광고 경로 예약 수를 맞댔습니다.
두 숫자가 다시 가까워진 것을 확인한 뒤, 실장은 고치기 전 기간의 전환이 실제보다 적게 세어졌다는 사실을 기간과 함께 성과 기록에 밝혔습니다. 그 기간의 전환으로 캠페인을 판단했던 일이 있다면 그 판단도 다시 따지기로 했습니다. 새 지점을 열 때에는 그 지점의 기호를 정한 뒤에 광고를 시작하도록 설정 기록의 첫 줄에 쓴 규칙으로 남겼습니다.
전환 중복 제거 식별자 자주 묻는 질문
예약 번호가 없는 신청 창은 무엇을 식별자로 씁니까?
신청이 성공한 때 서버가 새로 매기는 접수 번호처럼, 신청마다 다르고 새로고침해도 바뀌지 않는 값을 만들어 쓰도록 홈페이지 업체에 요청합니다. 그런 값을 만들 수 없다면 식별자 대신 전환을 보내는 조건을 고쳐 중복을 막습니다.
연락처를 알아볼 수 없게 바꾼 값은 식별자로 써도 됩니까?
연락처를 바꾼 값도 같은 사람에게서 늘 같은 값이 나와 사람을 가리키는 값이 됩니다. 또 같은 사람의 두 번째 예약이 중복으로 처리될 수 있어, 첫째 조건과 셋째 조건을 함께 어깁니다.
예약 날짜를 바꾼 환자의 예약은 어떻게 셉니까?
예약 시스템이 날짜를 변경해도 같은 예약 번호를 유지한다면 식별자가 같아 한 건으로 셉니다. 날짜를 변경할 때 번호를 새로 매기는 시스템이라면 변경한 예약이 새 전환으로 세어질 수 있어, 변경 때에는 전환을 보내지 않도록 업체와 정합니다.
식별자를 넣은 뒤 전환이 크게 줄면 무엇부터 따집니까?
식별자가 예약마다 다른 값인지부터 가립니다. 도움말은 같은 값을 고정해 넣으면 첫 번째만 처리되어 크게 적게 집계된다고 경고하므로, 값의 출처를 업체에서 다시 받아 첫째 조건을 맞댑니다.
오프라인으로 전환을 올릴 때도 같은 식별자를 씁니까?
씁니다. 도움말은 태그와 서버 쪽 업로드를 함께 쓸 때 두 경로의 거래 ID가 일관되어야 한다고 안내하고, 오프라인 전환에서는 이 값을 주문 ID라고 부른다고 밝힙니다. 같은 예약을 두 경로로 보낸다면 같은 값을 씁니다.
이 조건을 그대로 쓰기 어려운 경우
외부 예약 서비스로 예약을 받는 병원은 식별자를 병원이 정할 수 없습니다. 그 서비스가 전환과 함께 보내는 값이 네 가지 조건을 채우는지를 서비스의 설치 안내에서 가리고, 알 수 없다면 식별자에 기대지 않고 접수 기록으로 판단합니다.
한 번의 신청으로 가족의 예약을 여러 건 받는 병원은 신청 하나에 예약 번호가 여럿 생길 수 있습니다. 이때는 예약마다 식별자를 따로 보내 여러 건을 모두 세고, 가족 예약을 한 건으로 셀지는 병원의 성과 기준으로 원장이 정합니다.