글을 읽다가 선택 기준을 확인하고, 다시 상담으로 넘어온 사람에게 처음부터 무엇을 보고 왔는지 묻게 만들고 싶지는 않았다. 그렇다고 마지막 화면 이름 하나로 그 사람의 관심과 방문 경로를 모두 설명할 수도 없다. 실제 광고·상담 사이트의 코드를 다시 읽으며 내가 중요하게 본 것은 이 서로 다른 정보를 한 칸에 덮어쓰지 않는 설계였다.
상담 담당자가 알고 싶은 것은 하나의 출처가 아니었다
문의가 일반 상담 양식에서 왔다는 사실은 어떤 글이 질문을 만들었는지 설명하지 않는다. 반대로 글 번호만 남기면 그 사이에 선택 기준이나 점검 화면을 확인했는지 구별하기 어렵다. 실제 구현은 landing_id, source_article_id, source_page를 별도 값으로 둔다. 서로 다른 질문에 답하는 값이어서 하나의 유입 경로 문자열로 합치지 않았다.
필드 이름의 뜻도 코드를 따라 읽어야 했다. 여기서 landing_id는 최초 방문 주소가 아니라 양식의 목적 분류에 가깝다. 일반 상담은 contact이고 지원 목적이 있는 양식은 그 목적을 쓴다. source_article_id는 전달된 글 식별자, source_page는 지원하는 중간 화면의 표시다. 세 값만으로 방문자가 실제 거친 전체 순서나 최초 유입을 알아냈다고 부르지 않는다.
다음 행동이 달라도 원래 글 번호는 이어가게 했다
모든 글의 버튼이 곧바로 상담으로 갈 필요는 없다. 대행사를 비교하는 글은 선택 기준으로, 페이지 구성을 설명하는 글은 점검 도구로 이어질 수 있다. 링크를 만드는 함수는 이런 목적지가 달라도 원래 글 번호와 분류를 함께 붙인다. 중간 화면은 현재 화면 표시를 추가하면서 글 번호를 버리지 않도록 되어 있다.
이렇게 나누면 일반 상담이라는 양식 목적, 가상의 글 번호 guide-a, 체크리스트를 거쳤다는 표시를 동시에 설명할 수 있다. 여기서 guide-a는 설명을 위한 합성 값이며 원래 서버가 허용하는 실제 ID가 아니다. 아래 표도 실제 문의 내역이 아니다. 독자가 필드의 역할을 구별하도록 만든 작은 사례이며 실제 고객의 글이나 이동 기록은 공개하지 않았다.
주소 전체를 복사하지 않고 필요한 표시만 넘겼다
글에서 상담으로 넘기는 값은 고정된 글 식별자와 분류, 필요한 경우 업종이다. 실제 코드에는 허용한 캠페인 표시를 따로 전달하는 부분도 있다. 이름이나 연락처, 상담 내용과 대화 원문을 이 링크의 문맥 값으로 넣지 않았다. 페이지 점검의 주소와 결과도 자동으로 상담 양식에 보내지 않는다고 화면과 운영 문서에 남겼다.
링크를 이어 주는 코드도 본문 안의 바로가기와 외부 링크를 그대로 두고 관리자·API 경로를 제외한다. 이미 목적지 링크에 있는 값은 무조건 덮어쓰지 않는다. 다만 이것이 모든 민감 정보의 자동 탐지나 모든 경로의 보안 검증을 뜻하지는 않는다. 내가 읽은 범위는 특정 표시값을 제한해서 전달하는 구조이며 사이트 전체의 개인정보 적합성을 인증한 것은 아니다.
화면의 친절한 안내와 서버의 검사는 다른 역할이었다
상담 화면은 전달된 업종을 선택지에 반영하고 읽던 글에 맞춰 안내 문장을 보여 준다. 하지만 브라우저에서 그럴듯한 글 번호를 만들 수 있다는 사실과 서버가 그것을 받아도 된다는 판단은 다르다. 서버는 글 번호가 실제 허용 목록에 있는지, 목적과 중간 화면 표시가 지원하는 값인지 다시 검사한다. 모르는 번호를 받은 경우에는 확인할 수 없다는 오류를 낸다.
여기에도 남는 한계가 있다. 허용 목록에 있는 번호라고 방문자가 그 글을 실제로 읽었다는 증거가 생기지는 않는다. 주소의 표시값은 바뀔 수 있고 링크만 전달받을 수도 있다. 나는 이 필드를 상담을 시작할 참고 문맥으로 설명한다. 읽기 완료 인증이나 광고가 문의를 만들었다는 인과관계로 이름을 바꾸지 않는다.
새 필드를 넣어도 지난 문의의 출처를 만들어 내지 않았다
출처 컬럼을 추가하는 마이그레이션은 기존 문의를 지우지 않고 새 값을 빈 문자열로 둔다. 과거 행에 글 번호가 없다는 이유로 현재 열려 있는 글이나 캠페인을 대신 채우지 않는다. 나중에 집계할 때도 빈 값은 알 수 없다는 상태로 읽어야지 직접 유입이었다고 단정하면 안 된다. 데이터가 없다는 것과 어떤 경로였다는 것은 다른 사실이다.
실제 저장과 조회 코드에는 출처 값과 캠페인 값이 별도로 남는다. 글을 읽고 온 경우에도 이미 있는 캠페인 표시를 무조건 지우는 방식으로 만들지 않았다. 상담 문맥을 보태기 위해 원래 있던 측정 문맥을 바꾸면 두 값의 해석이 함께 흔들릴 수 있다. 이 글에서 살핀 것은 그런 값의 보존이며 실제 광고 도구의 성과 보고서와 연동한 결과가 아니다.
글 분류를 업종으로 착각하지 않는 작은 예외도 필요했다
초기 글 분류는 상담 업종을 미리 고르는 데 쓸 수 있지만 모든 분류가 업종은 아니다. 실제 현재 링크 함수에는 특정 연구 글 분류를 업종 값으로 넘기지 않는 예외가 있다. 국가별 사례 묶음처럼 다른 축의 분류를 업종 선택에 그대로 넣지 않으려는 결정이다. 새 카테고리가 늘어날 때는 같은 함수가 어떤 의미의 값을 넘기는지 다시 봐야 한다.
이 점은 카피에도 이어진다. 어떤 글에서 왔다는 표시를 보여 주는 것과 고객의 실제 사업을 확정하는 것은 다르다. 자동 선택은 질문을 시작하기 위한 제안이고 고객은 자기 상황을 고칠 수 있어야 한다. 원래 구현의 특정 문구를 모든 고객에게 맞는 답변으로 확장하지 않고 전달된 분류와 실제 문의 내용을 따로 다루는 것이 중요했다.
확인한 것은 값의 연결이고, 문의 증가는 아니었다
선택한 원래 시험 소스는 중간 화면에서도 글 번호가 유지되는지, 본문 바로가기와 외부 링크를 바꾸지 않는지, 저장된 출처와 캠페인이 각각 남는지 확인한다. 알려지지 않은 글 번호의 거절과 기존 문의를 남기는 마이그레이션 항목도 있다. 이번 제작기에서는 그 코드를 읽었으며 원래 광고 사이트의 접수나 DB, 빌드와 시험을 실행하지 않았다.
새 출처 모듈을 비슷한 이름으로 하나 더 만들지는 않았다. 기존 공유 모듈의 계산 맥락 전달과 메모 보존 정책을 함께 연결했다. 그 모듈은 현재 공개 ZIP의 바이트와 해시를 대조하고 압축을 푼 뒤 17개 합성 검사를 다시 실행했다. 다만 글 번호 전달을 구현하는 모듈은 아니며, 이어서 상담 메모를 만들 때 적용할 별도의 참고 구현이다.
웹사이트의 좋은 연결은 방문자를 더 많이 추적한다는 문구보다 담당자가 무엇을 알고 무엇은 모르는지 설명할 수 있는 데서 시작한다고 본다. 이번 구조는 상담의 첫 질문을 준비하는 구현이다. 실제 접수 증가, 유효 문의나 계약 개선은 해당 운영 자료가 있어야 말할 수 있으며 이 글에는 그런 성과를 만들지 않았다.