픽셀과 서버 전송을 함께 쓸 때 중복을 제거하는 설계
📖 약 3분 읽기
서버 전송을 붙인 다음 날, 대시보드를 열어보니 전환수가 거의 두 배로 뛰어 있었습니다. 처음에는 반가운 숫자처럼 보이지만 곧 이상한 낌새를 느끼게 됩니다. 광고 성과가 갑자기 좋아질 이유가 없는데 숫자만 커졌다면, 같은 전환이 브라우저 픽셀과 서버 양쪽에서 각각 잡혀 두 번 계상되고 있을 가능성이 큽니다. 문제는 이 현상을 발견한 다음입니다. 어디를 어떻게 고쳐야 할지 막막해지고, 일단 서버 전송을 꺼두는 임시방편으로 넘어가는 경우가 많습니다.
왜 같은 전환이 두 번 잡히는가
구조를 뜯어보면 원인은 단순합니다. 사용자가 구매 버튼을 누르는 순간, 브라우저에 심어둔 픽셀이 전환 이벤트를 매체 서버로 한 번 보냅니다. 동시에 우리 쪽 서버도 같은 주문 정보를 받아 같은 전환 이벤트를 매체 서버로 또 한 번 보냅니다. 매체 입장에서는 이 둘이 같은 사람의 같은 행동이라는 사실을 모릅니다. 각각 독립된 신호로 도착하기 때문에, 매체가 두 신호를 하나로 묶어줄 근거가 없으면 그대로 두 건으로 집계됩니다. 결국 문제는 전송 경로가 두 개라는 데 있는 것이 아니라, 두 경로가 보낸 신호를 매체가 같은 사건으로 인식할 수 있는 장치가 없다는 데 있습니다.

매체마다 다른 중복 제거 조건
여기서 오해하기 쉬운 지점이 있습니다. 매체가 알아서 중복을 걸러줄 것이라는 기대입니다. 실제로는 매체마다 요구 조건이 다릅니다. 어떤 매체는 브라우저와 서버가 보낸 이벤트에 같은 식별자가 붙어 있어야만 하나로 묶어줍니다. 어떤 매체는 식별자와 함께 두 이벤트가 도착한 시간 간격까지 함께 봅니다. 그리고 일부 매체는 이런 중복 제거 처리 자체를 지원하지 않아서, 애초에 픽셀과 서버 전송을 동시에 켜두면 안 되는 경우도 있습니다. 이 차이를 모른 채 한 가지 설정 방식을 여러 매체에 그대로 복사해 적용하면, 어떤 매체에서는 정상 동작하고 다른 매체에서는 계속 중복이 발생하는 상황이 벌어집니다.
| 매체 유형 | 중복 제거 방식 | 필요 조건 |
|---|---|---|
| 공통 식별자 요구 매체 | 식별자 일치 시 병합 | 브라우저·서버 동일 식별자 |
| 시간 창 병행 확인 매체 | 식별자와 도착 시간차 함께 확인 | 식별자 일치 및 짧은 시간 간격 |
| 별도 처리 미지원 매체 | 자동 병합 없음 | 픽셀과 서버 중 하나만 운영 권장 |
식별자를 어떻게 설계해야 하는가
중복 제거 조건을 맞추는 실무의 핵심은 결국 식별자 하나로 모입니다. 원칙은 명확합니다. 같은 전환 이벤트라면 브라우저가 만드는 식별자와 서버가 만드는 식별자가 정확히 같은 값이어야 합니다. 값이 조금이라도 다르면 매체는 두 이벤트를 다른 사건으로 취급합니다. 또 하나 중요한 조건은 지속성입니다. 사용자가 페이지를 새로고침하거나 결제 단계로 넘어가는 과정에서 식별자가 바뀌면 안 됩니다. 이벤트가 발생한 그 순간에 식별자를 만들어 클라이언트와 서버가 같은 값을 나눠 갖고, 이후 어떤 페이지 전환이 있어도 그 값을 그대로 들고 가야 합니다. 이 원칙 하나만 지켜도 대부분의 중복 문제는 설계 단계에서 예방할 수 있습니다.
실무에서 자주 발생하는 실수
가장 흔한 실수는 식별자를 만드는 시점이 서로 다른 경우입니다. 브라우저는 페이지 로드 시점에 값을 만드는데, 서버는 주문 처리 시점에 별도로 새 값을 만들어버리면 두 값이 우연히 같아질 방법이 없습니다. 또 다른 실수는 서버 쪽에서 클라이언트가 만든 값을 그대로 넘겨받지 않고 자체적으로 값을 재생성하는 경우입니다. 개발 편의상 서버 로직 안에서 새 식별자를 만들어 쓰는 경우가 있는데, 이렇게 되면 겉보기에는 정상 작동하는 것 같아도 매체 쪽에서는 두 이벤트를 끝내 하나로 묶지 못합니다. 이 두 실수는 코드만 봐서는 잘 드러나지 않기 때문에, 실제 값이 일치하는지 눈으로 확인하는 절차가 반드시 필요합니다.

설계가 끝난 뒤 확인해야 할 것
식별자를 맞췄다고 해서 그대로 안심할 수는 없습니다. 매체마다 제공하는 이벤트 관리 도구에서 실제로 중복 처리가 일어나고 있는지 확인하는 절차가 뒤따라야 합니다. 브라우저 이벤트와 서버 이벤트가 각각 도착했는지, 그리고 그 둘이 하나의 전환으로 병합되어 표시되는지를 도구 화면에서 직접 확인하는 것이 가장 확실한 검증입니다. 이 확인 작업을 건너뛰고 설정만 마친 채 운영에 들어가면, 어딘가에서 값이 어긋나 있어도 한동안 발견하지 못한 채 지나갈 수 있습니다.
한편 중복 제거를 지원하지 않는 매체라면 접근 방식 자체를 바꿔야 합니다. 이런 매체에서는 픽셀과 서버 전송을 동시에 운영하는 대신 어느 한쪽만 전환 신호의 기준으로 삼고, 다른 한쪽은 보조 지표로만 참고하는 방식으로 운영 범위를 조정하는 것이 현실적입니다.
결국 구축과 함께 설계해야 하는 문제
중복 제거는 서버 전송을 켜둔 다음 나중에 손보는 부가 작업이 아닙니다. 어떤 식별자를 언제 만들고 어떻게 양쪽 경로에 나눠줄지는 서버 전송을 설계하는 단계에서부터 함께 정해야 하는 문제입니다. 이 부분을 구축 초기에 정리해두면 운영 중에 전환수를 다시 의심하고 되짚어보는 수고를 크게 줄일 수 있습니다.
픽셀과 서버 전송을 함께 쓰면서 중복 계상 없이 정확한 전환 데이터를 확보하고 싶다면, 매체별 조건에 맞춘 식별자 설계부터 점검해보세요.



