전환 추적 서버 전송의 안전성, 브라우저 태그와 같은 검토 항목

전송 위치가 바뀌어도 남는 다섯 가지 검토

브라우저 태그는 방문자의 화면에 있는 값만 읽을 수 있지만, 서버는 예약 시스템과 접수 기록처럼 병원 안의 자료에 닿아 있습니다. 예약 완료를 서버에서 보내기로 하면 진료 항목, 예약 날짜, 환자 연락처가 같은 곳에 있어, 설계하는 사람이 편의를 위해 한두 칸을 더 붙이기 쉽습니다. 서버라는 이름이 주는 안심은 이 늘어남을 가리지 않고, 늘어난 칸은 방문자의 화면에 보이지 않아 병원 밖에서는 알아채기도 어렵습니다.

매체의 정책도 전송 위치를 가리지 않습니다. 구글 고객 데이터 정책은 향상된 전환, 리드 확보용 향상된 전환, 오프라인 매장 판매 업로드, 구글 추천 잠재고객을 쓰는 광고주에게 적용되며, 고객 정보를 올릴 때는 구글이 승인한 API나 인터페이스만 쓰고 민감한 카테고리와 관련된 전환 정보는 올릴 수 없다고 정합니다. 민감한 카테고리에는 의료 서비스 구매 내역 같은 건강 또는 의료 정보가 들어 있습니다.

다섯 검토 항목표

다섯 검토 항목표의 첫째 줄과 넷째 줄이 서버 전송에서 새로 무거워지는 곳입니다. 브라우저 태그로는 애초에 닿지 않던 값이 서버에서는 한 줄의 코드로 붙고, 서버 로그는 기본값으로 요청의 원문을 남기는 경우가 있어 보낸 값이 병원 서버에 한 번 더 남습니다. 서버로 옮기는 날이 오히려 보내는 값과 남기는 값을 줄일 기회여야 하는 까닭입니다.

같은 표 둘째 줄과 셋째 줄은 서버로 옮겨도 가벼워지지 않습니다. 인증 정보를 가진 사람이 곧 병원 이름으로 전환을 넣을 수 있는 사람이 되고, 매체의 정책은 어느 경로로 보내든 같은 문장으로 걸립니다.

같은 표 다섯째 줄은 옮기는 동안 생깁니다. 브라우저 태그를 그대로 둔 채 서버 전송을 더하면 같은 예약이 두 경로로 들어가므로, 두 경로가 같은 전환 액션에 같은 거래 ID를 보내야 한 번으로 세어집니다.

서버 전송 판정표

서버 전송 판정표는 전환 액션마다 위에서부터 묻고 판정이 나오면 멈춥니다. 좁힘과 정함으로 끝나는 세 판정은 그 일을 마친 뒤 같은 물음부터 다시 묻고, 그 기능으로는 보내지 않음은 다른 기능으로 옮겨 보내려 할 때 그 기능의 이름으로 셋째 물음을 새로 묻습니다.

첫째 물음의 보내도 되는 값은 브라우저 태그 때 정한 목록에서 시작합니다. 서버로 옮기며 목록에 없던 값을 더하려면 그 값마다 왜 필요한지를 광고 담당이 한 줄로 쓰고, 원장이 승인한 값만 목록에 올립니다. 목록은 전송 위치가 아니라 전환 액션에 붙는 것이어서, 같은 액션을 두 경로로 보낸다면 두 경로가 같은 목록을 씁니다.

셋째 물음은 전송 방식까지 묻습니다. 구글 고객 데이터 정책은 고객 정보를 올릴 때 구글이 승인한 API나 인터페이스만 쓰라고 정하므로, 서버에서 보내는 길이 매체가 안내하는 방식인지를 광고 담당이 기능의 도움말과 맞댑니다. 병원이 만든 서버 코드가 매체의 승인된 방식을 거치지 않고 다른 경로로 값을 넘긴다면, 보낸 값이 몇 개 안 되더라도 이 물음을 지나지 못합니다.

둘째 물음의 명단이 중요한 까닭은 서버 전송의 인증 정보가 곧 병원 이름으로 매체에 전환을 넣을 수 있는 열쇠이기 때문입니다. 브라우저 태그는 누리집을 고칠 권한이 있어야 바꿀 수 있지만, 서버 전송은 인증 정보를 가진 사람이면 누리집과 관계없이 보낼 수 있습니다. 인증 정보는 개인의 기기가 아니라 병원이 정한 보관 방식에 두고, 쓸 수 있는 사람이 바뀌면 그날 새로 정합니다.

서버로 옮기기 전의 차례

1. 광고 담당이 지금 브라우저 태그가 보내는 값의 목록을 전환 액션마다 뽑고, 서버로 옮기며 더하려는 값이 있다면 까닭을 한 줄씩 씁니다.
2. 원장이 더하려는 값의 승인 여부와 서버 전송을 쓸 수 있는 사람의 명단을 정합니다.
3. 광고 담당이 보내려는 기능의 공식 정책에서 적용 범위와 민감한 카테고리 제한과 전송 방식을 문장 그대로 옮겨 셋째 물음에 답합니다.
4. 홈페이지 담당이 서버 로그에 남는 값과 보관 기간을 정하고, 브라우저 태그와 함께 쓰는 동안의 거래 ID 규칙을 두 경로에 똑같이 겁니다.

한 예약이 두 길로 나가는 모습

브라우저 태그의 길에서 예약 한 건은 방문자가 완료 화면에 도착하는 순간 그 화면의 태그가 매체로 신호를 보내며 끝납니다. 보내는 값은 그 화면에 있는 것에 한정되고, 방문자가 화면을 닫거나 동의를 거부하면 신호가 나가지 않을 수 있습니다. 병원 쪽에는 따로 남는 것이 거의 없습니다.

서버의 길에서 같은 예약은 예약 시스템에 확정으로 들어온 뒤 병원 서버가 매체로 신호를 보냅니다. 방문자가 화면을 닫아도 신호는 나갈 수 있어 빠지는 전환은 줄지만, 서버는 예약 시스템의 모든 칸에 닿아 있고 보낸 요청은 서버 로그에 남습니다. 빠짐이 줄어드는 대신 보내는 값과 남는 기록을 병원이 직접 관리해야 하는 일이 늘어납니다.

두 길의 차이는 안전의 크기가 아니라 관리하는 곳의 차이입니다. 브라우저의 길에서는 매체의 태그가 정한 범위 안에서 값이 나가고, 서버의 길에서는 병원이 짠 코드가 정한 범위 안에서 값이 나갑니다. 병원이 그 범위를 좁게 짜고 지키면 서버의 길이 더 단정할 수 있지만, 넓게 짜면 브라우저의 길보다 많은 값이 나갑니다.

두 길을 함께 쓰는 동안에는 같은 예약이 두 번 나갑니다. 두 길이 같은 거래 ID로 같은 전환 액션에 보내면 매체가 두 번째를 중복으로 알고 세지 않지만, 한 길이라도 다른 값을 보내면 한 예약이 두 전환으로 세어집니다. 서버의 길이 더 많은 전환을 잡았다는 보고를 받으면, 그 차이가 빠짐이 줄어서인지 겹쳐 세서인지를 먼저 가립니다. 광고 성과를 병원의 접수 기록과 함께 읽어 이 차이를 가리는 방법은 병원 광고 성과 분석에서 다룹니다.

판정표를 그대로 쓰기 어려운 경우