📖 약 4분 읽기

전환 API를 연동하기로 하면 가장 먼저 마주치는 질문이 있습니다. 어떤 값을 보내야 하는가입니다. 매체가 제공하는 개발 문서를 열어보면 이메일, 전화번호, 광고 식별자, 자체 발급 식별자까지 다양한 항목이 나열되어 있습니다. 그런데 문서에 적혀 있다고 해서 그 항목을 실제로 보내도 되는 것은 아닙니다. 기술적으로 전송 가능한 범위와 법적으로 전송해도 되는 범위는 서로 다른 기준에서 출발하기 때문입니다.

매체별로 받을 수 있는 식별자, 왜 다 다를까

매체가 전환 API로 받는 식별자는 크게 네 갈래로 나뉩니다. 이메일이나 전화번호 같은 연락처 계열, 모바일 기기에 부여된 광고 식별자, 매체 자체의 광고 클릭 식별자, 그리고 사이트가 직접 발급하는 자체 식별자입니다. 이 네 갈래를 매체마다 다르게 조합해서 요구하는데, 어떤 매체는 연락처 계열을 해시 처리해서 보내야만 매칭이 이뤄지고, 어떤 매체는 광고 클릭 식별자 하나만으로도 매칭률을 유지합니다. 그래서 한 매체 문서를 기준으로 설계한 전송 로직을 다른 매체에 그대로 옮기면 값이 비어 있거나 형식이 맞지 않아 매칭이 실패하는 경우가 생깁니다.

< 식별자 갈래별로 형식 요건과 확인할 근거가 다릅니다 >

형식 요건까지 맞춰야 진짜 전송이 완성된다

식별자의 종류를 맞췄다고 끝나는 것이 아닙니다. 같은 이메일 주소라도 소문자로 통일했는지, 공백을 제거했는지에 따라 해시 값이 완전히 달라집니다. 정규화 규칙이 매체마다 다르기 때문에, 한 매체에서 통했던 전처리 방식이 다른 매체에서는 매칭률을 떨어뜨리는 원인이 되기도 합니다. 이 지점에서 놓치기 쉬운 것은 보낼 수 있는가만 확인하고 어떻게 가공해서 보내야 하는가는 넘어가는 것입니다. 매체 문서의 정규화 규칙과 해시 방식을 항목별로 따로 정리해두지 않으면, 연동은 끝났는데 실제 매칭은 기대만큼 이뤄지지 않는 상황이 반복됩니다.

기술 기준과 법 기준, 왜 따로 봐야 하는가

여기까지는 기술 기준입니다. 매체가 무엇을 받을 수 있고 어떤 형식을 요구하는지의 문제입니다. 그런데 실제로 어떤 값을 보내도 되는지는 별도의 질문입니다. 광고 목적으로 이용자 정보를 처리하려면 이용자에게 알리고 동의를 받은 범위 안에서만 그 정보를 활용할 수 있다는 것이 국내 개인정보 처리 원칙의 기본 방향입니다. 매체 문서에 해시로 보내는 항목이라고 적혀 있어도, 그 항목을 수집하고 광고 목적으로 활용한다는 사실이 이용자에게 고지되고 동의를 받은 범위 안에 있지 않다면 전송 대상에서 제외해야 합니다. 해시 처리는 값을 읽을 수 없게 만드는 기술적 조치일 뿐, 그 자체로 수집·이용 근거를 대신해주지는 않습니다.

두 기준을 겹치면 실제 전송 범위가 남는다

결국 실제로 보낼 항목은 두 기준의 교집합입니다. 매체가 받을 수 있는 식별자 목록에서 시작해서, 그중 이용자 고지·동의 범위 안에 있는 항목만 남기는 방식입니다. 이 작업을 매체별로 표로 정리해두면, 새로운 매체를 추가할 때마다 같은 절차를 반복하지 않고 기존 판단 기준을 그대로 적용할 수 있습니다. 반대로 이 표 없이 매체 문서만 보고 연동을 진행하면, 연동 자체는 문제없이 동작하더라도 전송해서는 안 되는 항목이 섞여 들어갈 위험이 남습니다.

자체 발급 식별자로 균형을 잡는 방법

연락처 계열 정보의 활용 범위가 제한적일 때 대안으로 쓰이는 것이 자체 발급 식별자입니다. 사이트가 방문자에게 임의의 값을 부여하고, 그 값을 기준으로 전환 데이터를 매체에 전달하는 방식입니다. 이 값은 특정 개인을 직접 가리키지 않으면서도 같은 방문자를 반복적으로 식별할 수 있어, 연락처 계열 정보를 넓게 수집하지 않고도 매칭률을 어느 정도 유지하는 구성이 가능합니다. 다만 자체 발급 식별자 역시 어떻게 생성하고 어떤 목적으로 쓰는지에 대한 고지가 필요하다는 점은 동일하게 적용됩니다.

한 번 정하고 끝낼 수 없는 이유

전송 범위를 정하는 작업은 한 번으로 끝나지 않습니다. 매체는 주기적으로 받는 식별자 종류나 형식 요건을 바꾸고, 개인정보 처리에 대한 규제 해석도 시간이 지나며 조정됩니다. 그래서 전송 항목 표는 한 번 만들고 보관하는 문서가 아니라, 정기적으로 다시 열어 확인하는 문서로 다뤄야 합니다. 이 점검을 게을리하면 매체 쪽 요건 변경을 모른 채 예전 방식으로 계속 전송하거나, 반대로 이미 허용된 범위를 지나치게 보수적으로 좁혀 매칭률을 스스로 낮추는 결과로 이어질 수 있습니다.

전송 항목을 정하는 이 단계는 태깅 설계 전체의 앞 단계에 해당합니다. 여기서 정한 범위가 이후 이벤트 구조, 서버 사이드 연동, 매칭 로직까지 전부를 규정하기 때문에, 이 단계를 가볍게 넘기면 뒤에서 다시 손대야 할 일이 늘어납니다.

이 글은 태깅 설계 실무를 다루는 안내이며 법률 자문이 아닙니다. 개별 사안의 적법성은 소관 부서나 전문가의 확인을 받으시기 바랍니다.