문자 미수신과 원인 미확인 이탈의 분리
해외 번호 문자 인증의 문의 손실은 확보 가능한 발송·수신 자료와 인증 완료·문의 제출 기록을 나누고, 미수신 확인 건과 원인 미확인 이탈을 따로 집계해 측정합니다. 인증 요청 이후 문의를 완료하지 않은 건을 모두 문자 미수신으로 단정하지 않습니다.
병원 마케팅 담당자는 먼저 인증 요청부터 문의 접수까지 어떤 기록을 확보할 수 있는지 개발 담당자와 정리합니다. 발송 요청 기록만 있는지, 실제 수신 여부를 뒷받침할 자료도 있는지에 따라 설명할 수 있는 범위가 달라집니다. 기록이 없는 구간은 추정값으로 채우지 않고 측정 불가 항목으로 남깁니다.
이때 측정 대상은 해외 번호로 인증을 요청한 문의 시도입니다. 해외 번호 사용 사실만으로 환자의 거주지나 국적까지 판단하지 않습니다. 집계 대상의 정의와 제외 조건은 보고서 첫머리에 기재합니다.
인증 단계별 기록의 증명 범위
| 인증 단계 | 확보 가능한 기록 | 확인 가능한 사실 | 확정할 수 없는 사실 |
|---|---|---|---|
| 인증 요청 | 요청 시각과 시도 식별값 | 인증 요청이 기록된 사실 | 발송 처리와 실제 문자 수신 |
| 문자 발송 처리 | 발송 요청 및 처리 응답 | 기록에 남은 처리 결과 | 상태 설명 없이 판단한 실제 수신 여부 |
| 문자 수신 여부 | 수신 여부를 뒷받침하는 자료 | 자료가 증명하는 범위의 수신 여부 | 자료가 없는 시도의 수신 여부 |
| 인증 완료 | 인증 성공 처리 기록 | 해당 시도의 인증 완료 | 문의 제출과 병원 접수 |
| 문의 제출 | 제출 성공 및 접수 기록 | 문의가 제출·접수된 사실 | 상담 진행과 진료 예약 |
표의 기록은 병원이 확보 가능 여부를 조사할 항목이며, 모든 서비스가 이를 제공한다는 뜻은 아닙니다. 개발 담당자는 각 기록이 생성되는 조건과 누락될 수 있는 상황을 문서화합니다. 문자 서비스의 상태 이름은 해당 설명 자료가 있을 때만 해석합니다.
사용자가 문자를 받지 못했다고 알린 내용과 서비스 처리 기록이 다르면 어느 한쪽을 삭제하지 않습니다. 상담 담당자는 진술 시점과 내용을 남기고, 개발 담당자는 같은 시도의 처리 기록을 연결합니다. 충돌을 해소하지 못한 건은 별도 표시해 확정 집계와 섞이지 않게 관리합니다.
문의 제출을 기준으로 한 성과 판단
구글 애널리틱스는 양식을 제출하거나 정보를 요청하는 활동에 generate_lead 이벤트를 권장합니다. 병원은 문의 제출 성공과 실제 접수가 어느 조건에서 성립하는지 정한 뒤 이벤트 발생 조건을 대응시킵니다. 인증 완료는 문의에 도달하기 전의 관찰 지표로 관리합니다.
구글 광고는 전환 액션을 기본과 보조로 적절히 설정해야 한다고 설명합니다. 광고 담당자는 인증 중간 단계가 문의 성과와 같은 의미로 사용되는지 검토합니다. 문의 제출을 성과로 삼는 운영에서는 인증 요청 증가만으로 광고 성과가 개선됐다고 판단하지 않습니다.
기록 확보부터 접수 연결까지의 순서
- 마케팅 담당자는 해외 번호 인증 요청의 집계 범위와 관찰 종료 기준을 정합니다. 개발 담당자는 요청·발송 처리·인증 완료·문의 제출 기록의 보유 여부를 정리합니다.
- 개발 담당자는 같은 문의 시도를 연결할 식별값과 재요청을 묶는 기준을 제시합니다. 상담 담당자는 미수신 신고를 해당 시도에 연결할 수 있는 자료를 준비합니다.
- 마케팅 담당자는 미수신 확인, 다른 실패 확인, 원인 미확인 이탈의 분류 조건을 문서화합니다. 자료가 충돌하거나 연결되지 않는 건의 처리 방식도 함께 정합니다.
- 개발 담당자는 문의 제출 기록을 병원 접수 기록과 연결합니다. 마케팅 담당자는 연결 누락과 중복을 처리한 뒤 단계별 미완료를 산출합니다.
실장은 담당자별 자료 목록과 판단이 필요한 항목을 모아 결정합니다. 준비 자료에는 기록 설명서, 식별값 연결 방식, 수신 관련 근거, 접수 성공 조건을 포함합니다. 자료를 확보하지 못한 항목에는 담당자와 확보 가능 여부를 기재합니다.
이탈 분류와 집계 단위의 설계
| 이탈 분류 | 분류에 필요한 확인 자료 | 집계 단위와 분모 | 문의 손실 해석의 한계 |
|---|---|---|---|
| 미수신 확인 후 미제출 | 해당 시도의 미수신 근거와 제출 기록 | 문의 시도 단위, 연결 가능한 인증 요청 시도 | 미수신이 유일한 포기 원인인지는 별도 판단 |
| 다른 실패 확인 후 미제출 | 미수신 외 실패를 증명하는 기록 | 문의 시도 단위, 연결 가능한 인증 요청 시도 | 문자 미수신 손실에 포함 불가 |
| 원인 미확인 이탈 | 인증 요청과 제출 미완료 기록 | 문의 시도 단위, 연결 가능한 인증 요청 시도 | 문자 수신 여부와 포기 이유 확정 불가 |
| 인증 완료 후 미제출 | 인증 성공과 제출 미완료 기록 | 문의 시도 단위, 인증 완료 시도 | 인증 이후 구간의 이탈로 해석 |
앞의 분류는 문의 시도의 상태를 설명하며 사람 수를 뜻하지 않습니다. 재요청이 발생해도 같은 시도로 묶는 조건을 충족하면 해당 시도 안에서 처리합니다. 발송 작업량을 조사할 때 필요한 요청 건수는 문의 시도 집계와 별도 항목으로 관리합니다.
원인별 분류와 인증 완료 후 이탈 표시는 서로 다른 질문에 답합니다. 같은 시도에 두 표시가 해당하면 이를 합산하지 않고 원인과 도달 단계로 나누어 기록합니다. 제출 기록과 연결할 수 없는 시도는 연결 불가 건으로 별도 보고해 미제출 확정 건에 포함하지 않습니다.
재요청과 미완료율 분모의 일치
단계별 미완료율은 해당 단계에 진입한 문의 시도 중 다음 단계에 도달하지 않은 시도의 비중으로 산출합니다. 인증 요청 이후 미완료를 계산할 때와 인증 완료 이후 미제출을 계산할 때는 분모가 다릅니다. 보고서에는 지표 이름 옆에 시작 단계와 종료 단계를 함께 기재합니다.
재요청마다 새 문의로 계산하면 요청 활동이 많은 시도가 전체 결과를 과도하게 좌우합니다. 반대로 서로 다른 문의를 무리하게 합치면 실제 미완료가 줄어들 수 있습니다. 개발 담당자는 화면을 다시 연 경우와 접속이 끊긴 경우에 기존 식별값이 유지되는지 조사하고, 묶을 수 없는 범위를 명시합니다.
관찰을 종료하는 기준도 집계 전에 정해야 합니다. 종료 시점에 아직 인증이나 제출을 진행 중인 시도는 완료된 관찰 대상과 분리합니다. 이후 문의 제출이 연결되면 기록을 갱신하고, 기존 보고서와 달라진 이유를 남깁니다.
미수신 사실과 포기 원인의 차이
미수신이 확인됐더라도 그 사실만으로 문의 포기 원인을 확정할 수는 없습니다. 사용자가 문의를 미룬 이유나 다른 접수 경로를 이용했는지는 별도 자료가 필요합니다. 보고서에서는 미수신이 확인된 미제출 건과 미수신 때문에 포기했다고 진술한 건을 같은 표현으로 기록하지 않습니다.
상담 담당자는 미수신 신고를 받을 때 인증을 시도한 시점과 이후 진행 여부를 함께 기록합니다. 사용자의 표현을 임의로 원인 코드에 대응시키지 않고, 진술 내용과 담당자의 분류 결과를 별도 항목으로 관리합니다. 재시도 후 제출한 건은 최종 상태를 갱신하되 이전 미수신 기록을 삭제하지 않습니다.
개선 전후를 평가할 때는 제출 증가와 원인 미확인 이탈 감소를 함께 읽어야 합니다. 기록 연결 방식이 변경되면 실제 이용 행태가 그대로여도 집계 결과가 달라질 수 있습니다. 마케팅 담당자는 변경 이력을 기준으로 직접 비교할 수 있는 기간을 가립니다.
오래된 시도의 소급 분류 제한
새로 확보한 기록을 과거의 모든 이탈에 소급 적용하지 않습니다. 과거에는 수집하지 않았던 수신 자료를 현재 확보한다고 해서 이전 시도의 원인이 밝혀지는 것은 아닙니다. 담당자는 자료별 수집 시작 시점과 조회 가능한 범위를 기록합니다.
과거 시도를 다시 분류하려면 해당 시도와 직접 연결되는 근거가 있어야 합니다. 최근 시도의 분류 비중으로 이전 미확인 건을 배분하면 실측과 추정이 섞입니다. 소급 연결이 가능한 건만 수정하고, 나머지는 당시의 원인 미확인 상태로 유지합니다. 보고서의 분류 기준이 변경된 경우에는 변경 시점과 적용 대상을 함께 기재해 과거 결과를 잘못 해석하지 않도록 합니다.
자주 묻는 질문
이미 누락된 인증 기록을 애널리틱스에서 복원할 수 있나요?
구글 애널리틱스의 추천 이벤트는 자동으로 전송되지 않으므로, 설정만으로 과거 인증 기록이 복원된다고 판단할 수 없습니다. 병원은 기존 서버나 문자 서비스에 남은 자료가 있는지 조사하고, 복원이 불가능한 구간을 보고서에 명시합니다. 새 수집을 시작한 시점과 과거 자료의 범위도 분리해 표시합니다.
새로 설정한 문의 이벤트는 어떻게 작동을 시험하나요?
구글 애널리틱스는 추천 이벤트 설정 후 디버그뷰로 이벤트를 관찰하고 실시간 보고서로 발생 여부를 확인하도록 안내합니다. 개발 담당자는 시험 제출의 발생 시점과 이벤트 기록을 대조합니다. 화면에서 제출 동작을 한 사실과 병원 접수 성공이 일치하는지도 함께 시험합니다.
문의 완료 화면 조회로 제출 성공을 판단해도 되나요?
완료 화면에 도달하는 조건을 조사한 뒤 사용 여부를 결정합니다. 구글 애널리틱스는 연락처 제출 후 확인 페이지 방문을 바탕으로 이벤트를 만드는 예를 제시합니다. 병원에서는 제출 없이 접근하거나 화면을 다시 여는 동작이 접수 성공으로 집계되지 않는지 시험해야 합니다.
문자 인증 자료를 대행사에 전부 전달해야 하나요?
대행사가 판단할 항목에 필요한 자료 범위를 먼저 정합니다. 병원 내부에서 연결 작업을 마친 집계 자료로 업무가 가능하면 원문 기록 전체를 전달할 필요가 있는지 별도로 판단합니다. 담당자는 접근 범위와 보관 방식을 정해야 하며, 이러한 측정 설계만으로 개인정보 처리의 적법성이 판정되지는 않습니다.
미수신 건수를 근거로 회복 가능한 문의를 계산해도 되나요?
미수신 건수만으로 회복 가능한 문의 규모를 산출하지 않습니다. 인증을 통과했더라도 제출하지 않았을 가능성을 현재 자료만으로 제거할 수 없기 때문입니다. 개선 뒤 실제로 접수된 문의를 별도 측정하고, 관찰된 변화와 아직 입증하지 못한 기대를 분리해 보고합니다.