포스트백

전환을 매체에 알리는 일은 오랫동안 사용자 브라우저가 맡았습니다. 사이트에 심어 둔 몇 줄짜리 코드가 결제 완료 화면에서 매체로 신호를 보내는 방식이었습니다. 이 방식은 기기와 브라우저가 협조해 주는 동안에만 작동합니다.

협조가 끊기기 시작했습니다. 브라우저가 다른 회사 쿠키를 기본으로 막고, 스마트폰이 앱마다 추적 동의를 따로 받게 하면서 신호의 절반 남짓이 사라졌습니다. 광고 관리 화면에는 전환 3건이 잡히는데 우리 데이터베이스에는 11건이 남아 있는 상황이 흔해졌습니다.

숫자가 적게 보이는 것보다 나쁜 일이 뒤따랐습니다. 매체는 전환 기록을 재료로 비슷한 사람을 더 찾아 주는데, 그 재료가 절반만 들어오면 엉뚱한 쪽으로 최적화합니다. 실제로 성과를 낸 광고가 낸 줄 모른 채 예산이 줄고, 성과 없는 광고가 그 자리를 채웁니다.

그래서 사용자 기기를 거치지 않는 경로가 자리를 잡았습니다. 우리 서버가 매체 서버에 직접 알리는 방식이고, 기기 설정이 무엇이든 이 길은 막히지 않습니다.

이 방식이 실제로 푸는 것은 넷입니다.

1. 끊긴 신호를 되살립니다. 광고를 클릭하면 매체가 주소에 클릭 식별자를 붙여 보내 주는데, 이것을 우리 쪽에 저장해 둡니다. 나중에 그 사람이 결제하면 저장해 둔 식별자와 전환 종류와 금액을 매체가 받는 창구로 보냅니다. 브라우저는 이 과정에 끼지 않습니다.
2. 진짜 전환만 보냅니다. 브라우저가 판단할 수 있는 것은 결제 완료 화면이 떴다는 사실까지입니다. 카드가 나중에 거절되거나 당일 취소되거나 같은 사람이 두 번 결제한 경우를 우리 서버는 알고 있고, 그래서 걸러서 보낼 수 있습니다.
3. 늦게 일어난 전환을 보냅니다. 무료 체험 14일이 끝난 뒤의 첫 결제가 대표적입니다. 그 시점에 그 사람의 브라우저는 2주 전에 어느 광고를 눌렀는지 기억하지 못하지만, 우리 서버는 식별자를 들고 있어서 이어 붙일 수 있습니다.
4. 매체의 자동 최적화에 재료를 줍니다. 전환 신호가 정확할수록 매체가 찾아 주는 사람이 실제 고객에 가까워집니다. 무료 가입이 아니라 첫 결제를 신호로 보내면 매체는 결제할 사람을 찾는 쪽으로 움직입니다.

한계도 분명합니다. 전환이 일어난 시점과 매체가 그것을 아는 시점 사이에 시차가 생겨서 어제 성과를 오늘 아침에 확정하지 못합니다. 그리고 보내는 쪽이 우리 서버라서, 우리 쪽 정의가 틀리면 틀린 숫자가 그대로 매체에 쌓입니다. 무엇을 전환으로 볼지 정해 두는 전환 추적 설정이 앞에 있어야 이 신호가 값을 합니다.

같은 문제를 다루는 방법이 넷 더 있습니다.

1. 사이트에 심는 코드입니다. 방문과 전환을 기록하려고 페이지에 심어 두는 픽셀이 그것인데, 붙이기 쉽고 결과가 즉시 보입니다. 대신 차단되면 그만큼 빠집니다. 실무에서는 둘을 함께 쓰고 같은 전환에 같은 열쇠를 붙여 매체 쪽에서 중복을 지우게 합니다.
2. 앱 쪽에서 쓰는 집계 방식입니다. 개인 한 사람을 따라가지 않고 며칠 단위로 묶은 요약 값만 받습니다. 개인 정보를 덜 쓰는 대신 누가 어느 광고에서 왔는지는 알 수 없고, 값이 며칠 뒤에 도착합니다.
3. 링크에 꼬리표만 붙이고 우리 안에서만 보는 방법입니다. 유입 경로를 구분하려고 링크에 붙이는 UTM 파라미터로 경로별 성과를 우리 분석 도구에서 읽습니다. 매체에 아무것도 보내지 않으니 자동 최적화는 받지 못합니다.
4. 개인 기록을 아예 쓰지 않는 방법입니다. 채널별 지출과 전체 매출을 몇 년치 모아 기여도를 추정하거나, 일부러 광고를 끈 집단을 만들어 순증분을 재는 방식입니다. 한 건 단위로는 알 수 없지만 어느 채널이 실제로 매출을 밀어 올렸는지는 이쪽이 더 정직하게 답합니다.

고르는 기준은 셋입니다. 매체의 자동 최적화가 필요한지, 광고비가 개발 공수를 들일 만큼 큰지, 전환 정의가 안정되어 있는지입니다. 월 광고비가 300만 원인 팀이 서버 연동에 2주를 쓰는 것은 대개 수지가 맞지 않습니다.

"광고 화면에는 3건인데 우리 쪽은 11건입니다. 포스트백 붙여야 합니다."

브라우저 신호가 끊겨 누락이 크다는 판단입니다.

"무료 가입 말고 첫 결제를 포스트백으로 보내죠."

매체가 찾는 사람을 실제 고객 쪽으로 옮기자는 제안입니다.

"픽셀도 그대로 두고 중복 제거 키만 맞춰 주세요."

둘을 병행하면서 같은 전환이 두 번 세지지 않게 하자는 요청입니다.

페이지덱이 이 작업을 한 분기에 했습니다. 현우가 광고 관리 화면과 내부 집계의 차이를 두 달 재 봤더니 누락이 평균 58퍼센트였습니다. 태오가 클릭 식별자를 저장하고 첫 결제 시점에 매체로 보내는 작업을 2주에 걸쳐 붙였습니다.

붙인 뒤에 두 숫자가 같아지지는 않았습니다. 누락은 58퍼센트에서 12퍼센트로 줄었지만 나머지 차이는 남았습니다. 매체가 클릭 후 7일 안의 전환만 자기 공으로 세고, 우리는 기간 제한 없이 세고 있었기 때문입니다. 현우는 두 숫자를 같게 맞추는 대신 어느 쪽을 어디에 쓸지 정했습니다. 예산 배분은 매체 숫자로, 전체 성과 보고는 내부 숫자로 합니다.

붙이면 숫자가 맞아진다고 보는 경우가 가장 많습니다. 누락이 줄어드니 맞아 가는 것처럼 보입니다. 하지만 매체 숫자와 내부 숫자는 같아질 수 없습니다. 공을 어느 접점에 돌릴지 정하는 어트리뷰션 규칙이 서로 다르고, 세는 기간도 다릅니다. 같게 만들려고 정의를 계속 고치면 지난달과 이번 달을 비교할 수 없게 됩니다. 두 숫자를 각자 무엇에 쓸지 정하는 편이 낫습니다.

붙였으니 픽셀을 떼도 된다고 보는 것도 흔합니다. 같은 일을 두 번 하는 것처럼 보이니 자연스러운 정리로 읽힙니다. 하지만 픽셀은 클릭 뒤의 페이지 이동처럼 서버가 모르는 행동을 알려 주고, 결과가 즉시 보이는 쪽도 이것입니다. 떼고 나면 광고를 바꾼 당일에 반응을 볼 방법이 없어져서, 소재를 빠르게 갈아 보는 운영이 어려워집니다.