한 예약에 한 키, 두 경로에 같은 글자
서버 측 전환과 브라우저 전환을 함께 보낼 때의 중복키는 예약이 확정될 때 병원의 예약 시스템이 매긴 번호 하나를 거래 ID로 삼아, 두 경로가 같은 전환 액션에 글자 하나까지 같은 값으로 보내는 것입니다. 그리고 두 경로 모두 다시 보낼 때 새 값을 만들지 않고 처음 값을 그대로 쓰도록 재시도 규칙을 정합니다. 키가 같아도 전환 액션이 다르면 중복은 걸러지지 않으므로, 두 경로가 어느 액션으로 들어가는지부터 따집니다.
구글 애즈 도움말은 같은 전환 액션에 같은 거래 ID로 전환이 두 번 들어오면 두 번째를 중복으로 알고 세지 않는다고 안내합니다. 또 구글 태그 외에 데이터 관리 도구로 백엔드에 저장한 온라인 전환을 올리는 경우 태그와 서버 간 업로드에서 거래 ID가 일관되어야 하고, 새 데이터 소스의 ID가 태그가 받은 transaction_id와 정확히 일치해야 한다고 밝힙니다. 앞이나 뒤에 붙은 글자가 다르거나 공백이 하나 더 있어도 중복을 지우지 못합니다.
한 태그 안의 새로고침 중복은 태그가 같은 값을 다시 보내는 문제이지만, 두 경로의 중복은 서로 다른 시스템이 같은 예약을 각자 표현하는 문제입니다. 그래서 값이 어디서 나오는지와 두 경로 로그에서 그 값이 같은 모양인지를 함께 따져야 합니다.
중복키 판정표
| 순서 | 묻는 것 | 답하는 사람 | 그렇다면 | 아니라면 |
|---|---|---|---|---|
| 첫째 | 서버 경로가 태그의 전환 액션을 보완하는 데이터 소스로 연결되어 같은 전환 액션으로 들어가는가 | 광고 담당 | 둘째 물음으로 | 한 액션을 보조로 설정 |
| 둘째 | 두 경로가 보내는 키가 예약 시스템이 예약 확정 때 매긴 같은 번호에서 나오는가 | 홈페이지 담당 | 셋째 물음으로 | 키의 출처를 하나로 맞춤 |
| 셋째 | 두 경로 로그에서 같은 예약의 키가 앞뒤 글자와 공백까지 같은가 | 홈페이지 담당 | 넷째 물음으로 | 형식을 맞춤 |
| 넷째 | 두 경로가 다시 보낼 때 새 키를 만들지 않고 처음 키를 쓰는가 | 홈페이지 담당 | 병행 사용 | 재시도 규칙 고침 |
중복키 판정표는 위에서부터 묻고 판정이 나오면 멈춥니다. 어느 병행 설정이든 한 액션을 보조로 설정, 키의 출처를 하나로 맞춤, 형식을 맞춤, 재시도 규칙 고침, 병행 사용의 다섯 판정 가운데 하나로 끝나고, 맞춤과 고침으로 끝났다면 고친 뒤 그 물음부터 다시 묻습니다.
첫째 물음이 맨 앞인 까닭은 중복 제거가 같은 전환 액션 안에서만 일어나기 때문입니다. 서버 경로가 가져오기용으로 따로 만든 전환 액션으로 들어간다면 두 액션이 같은 예약을 각각 세고, 둘 다 기본 액션이라면 도움말대로 두 액션이 모두 전환수 열에 보고됩니다. 이때는 원장이 어느 쪽을 기본으로 남길지 승인하고, 광고 담당이 다른 쪽을 보조 액션으로 설정해 모든 전환수 열에서만 보고되게 합니다.
두 경로 로그 대조표
| 맞댈 것 | 브라우저 경로 | 서버 경로 |
|---|---|---|
| 키가 드러나는 곳 | 개발자 도구 네트워크 탭의 전환 요청에 붙은 oid 매개변수 | 업로드 파일이나 요청의 주문 ID 열 |
| 보내는 때 | 예약 완료 화면이 열린 때, 다시 열린 때 포함 | 병원이 정한 업로드 주기 |
| 다시 보내게 되는 일 | 방문자의 새로고침과 돌아오기 | 업로드 실패 뒤의 재시도 |
| 보고서에 드러나는 때 | 출처 문서에 따로 밝힌 안내 없음 | 원본 클릭의 노출 날짜로 반영되고 마지막 클릭 기준 최대 세 시간 뒤 표시 |
| 처리 결과를 가리는 곳 | 태그 어시스턴트의 거래 ID 필드 | 업로드 도구의 처리 결과, API라면 오프라인 데이터 진단 |
두 경로 로그 대조표가 필요한 까닭은 도움말대로 거래 ID가 구글 애즈 보고서에 나오지 않기 때문입니다. 보고서의 전환 수만으로는 두 경로가 같은 예약을 한 번으로 셌는지 알 수 없어, 같은 예약 몇 건을 골라 두 경로 로그에서 키를 나란히 놓고 셋째 물음에 답합니다. 도움말은 방문자가 전환 페이지로 돌아가거나 새로고침하면 같은 태그가 다시 실행된다고 설명하므로, 브라우저 경로 로그에 같은 키가 여러 번 나오는 것은 그 자체로 오류가 아닙니다.
보고서에 드러나는 때가 다르다는 점도 로그로 맞댈 까닭입니다. API 문서는 가져온 전환이 가져오기 요청 날짜가 아니라 원본 클릭의 노출 날짜 보고서에 반영되고, 마지막 클릭 기여 분석에서 최대 세 시간, 다른 기여 분석 모델에서는 더 걸릴 수 있다고 안내합니다. 업로드 직후 전환 수가 늘지 않았다고 서버 경로가 빠졌다고 판단하지 않습니다.
병행을 설정하는 차례
- 광고 담당이 두 경로가 들어가는 전환 액션을 계정에서 찾아 첫째 물음에 답하고, 액션이 둘이라면 원장에게 어느 쪽을 기본으로 남길지 승인을 받습니다.
- 홈페이지 담당이 예약 완료 화면의 태그와 서버 업로드가 각각 키를 어디서 받는지 두 경로의 코드와 설정에서 찾아 둘째 물음에 답합니다.
- 홈페이지 담당이 같은 예약 몇 건의 키를 두 경로 로그 대조표의 첫째 줄에서 나란히 놓고 셋째 물음에 답합니다.
- 홈페이지 담당이 두 경로의 재시도 동작을 코드에서 따라가 넷째 물음에 답하고, 병행 사용으로 끝나면 설정한 날을 광고 담당에게 넘깁니다.
- 광고 담당이 설정한 날 뒤의 전환 수를 같은 기간 접수 기록의 광고 경로 예약 수와 맞대 원장에게 올립니다.
넷째 단계에서 재시도를 코드에서 따라가는 까닭은 서버 경로의 실패가 드러나는 방식 때문입니다. API 문서는 가져온 이벤트에 주문 ID가 같은 전환이 여러 개 들어 있으면 DUPLICATE_ORDER_ID 오류로 그 전환들이 처리되지 않으니, 주문 ID가 고유한지 확인한 뒤 다시 시도하라고 안내합니다. 재시도가 실패한 묶음을 그대로 다시 올리면 같은 오류가 되풀이되고, 실패를 피하려고 키 뒤에 시각을 덧붙이면 넷째 물음을 어기게 됩니다.
가상 한의원의 병행 첫 주
아래는 설명을 위해 만든 가상의 사례입니다. 한 한의원이 예약 완료 화면의 구글 태그에 더해, 밤마다 예약 시스템의 확정 예약을 데이터 관리 도구로 올리는 서버 경로를 붙였습니다. 광고 담당은 두 경로가 같은 전환 액션으로 들어가는 것을 계정에서 찾아 첫째 물음을 지났고, 홈페이지 담당은 두 경로 모두 예약 시스템의 예약 번호를 쓴다는 것으로 둘째 물음을 지났습니다.
셋째 물음에서 걸렸습니다. 브라우저 경로의 oid 값에는 예약 번호 앞에 한의원을 뜻하는 영문 약자와 줄표가 있었고, 서버 경로의 주문 ID 열에는 번호만 있었습니다. 같은 예약이 두 값으로 들어가 두 번 세어지고 있었고, 홈페이지 담당은 서버 경로도 같은 약자와 줄표를 쓰도록 형식을 맞춘 뒤 셋째 물음부터 다시 물었습니다.
넷째 물음에서도 한 번 걸렸습니다. 어느 밤 업로드가 실패하자 서버 경로가 다음 날 이른 아침에 다시 올리면서, 겹침을 피한다며 키 뒤에 재시도 시각을 덧붙이고 있었습니다. 홈페이지 담당은 재시도 때 처음 키를 그대로 쓰고, 올리기 전에 묶음 안의 같은 키를 하나로 줄이도록 재시도 규칙을 고쳤습니다. 그 뒤 두 경로 로그에서 같은 예약이 같은 키로 들어간 것을 몇 건 맞대고 병행 사용으로 판정했습니다.
영상 광고가 같은 전환을 셀 때
같은 계정의 영상 광고도 이 전환 액션으로 성과를 센다면, 두 경로의 중복은 같은 키로 걸러집니다. 다만 도움말은 거래 ID를 넣어도 중복되는 조회 후 전환은 해결되지 않는다고 밝히므로, 광고를 보고 나중에 예약한 전환이 겹치는지는 거래 ID로 따질 수 없습니다. 영상 성과를 무엇으로 볼지는 병원 영상 성과에서 다룹니다.
서버와 브라우저 전환 중복키 자주 묻는 질문
집계 설정을 클릭당 한 번으로 바꾸면 중복키가 없어도 됩니까?
도움말은 거래 ID를 넣는 것과 집계 설정을 광고 클릭당 전환 한 번으로 바꾸는 것이 서로 다른 작업이라고 설명합니다. 집계 설정은 한 클릭 뒤의 서로 다른 여러 전환을 한 번으로 줄이는 것이고, 같은 예약이 두 경로로 들어오는 일은 거래 ID로 거릅니다.
오프라인 전환 가져오기에도 주문 ID를 꼭 넣어야 하나요?
도움말은 오프라인 전환 가져오기에서 거래 ID가 선택사항이지만, 추가 데이터 소스의 거래 ID를 설정하는 경우에는 필요하다고 안내합니다. API 문서는 가져올 때 주문 ID를 설정했다면 그 뒤의 모든 조정에도 그 값을 써야 한다고 밝힙니다.
두 경로가 다른 전환 액션으로 들어가면 입찰에는 어떤 영향이 있습니까?
도움말은 기본 액션이 전환수 열에 보고되고 기본 액션이 든 목표가 입찰에 쓰이면 함께 입찰에 쓰인다고 설명합니다. 보조 액션은 모니터링 전용으로 모든 전환수 열에서만 보고되고, 맞춤 목표에 든 경우를 빼면 입찰에 쓰이지 않습니다.
서버 경로가 며칠 늦게 올리면 전환이 그날로 잡히나요?
API 문서는 가져온 전환이 요청한 날이 아닌 원본 클릭의 노출 날짜로 보고서에 반영된다고 안내합니다. 늦게 올린 만큼 지난 날짜의 전환 수가 뒤늦게 달라지므로, 광고 담당은 업로드가 늦은 기간을 보고서 옆에 씁니다.
키로 쓸 값에 환자 연락처를 섞어도 됩니까?
도움말은 거래 ID에 개별 고객을 식별할 수 있는 정보를 넣지 않아야 한다고 하고, 거래 ID로 쓰면 안 되는 값의 예로 이메일 주소를 듭니다. 예약 번호처럼 사람을 가리키지 않는 값을 두 경로가 함께 씁니다.
판정표를 그대로 쓰기 어려운 경우
외부 예약 서비스가 예약 완료 화면을 맡는다면 브라우저 경로의 키를 병원이 정할 수 없습니다. 이때는 홈페이지 담당이 그 서비스가 태그에 넘기는 값을 로그에서 찾아, 서버 경로가 같은 값을 받을 수 있을 때만 병행하고, 받을 수 없다면 한 경로만 기본 액션으로 씁니다.
서버 경로로 이메일이나 전화번호 같은 사용자 제공 데이터를 함께 올리려 한다면 중복키와 별개로 고객 데이터 정책의 건강·의료정보 제한을 먼저 따져야 합니다. 이 판단은 중복키 판정표가 다루지 않으며 원장이 정합니다. 두 경로를 정리한 뒤의 전환으로 광고 성과를 무엇으로 판단할지는 병원 광고 성과 분석에서 다룹니다.