[김용한의 AI 마케팅 24/100] MS 광고의 전환 API, 더 많이 잡힌 구매를 어떻게 읽을 것인가

한 고객이 주문을 마치면 브라우저에는 구매 완료 화면이 열리고 판매자의 서버에는 주문 기록이 남는다. 같은 구매를 서로 다른 경로가 기록하는 것이다. 광고 플랫폼에 이 두 신호를 함께 보내는 기능이 늘면서, 얼마나 많이 측정했는가에 앞서 같은 거래를 어떻게 식별했는가가 경영의 질문이 된다.

마이크로소프트는 10월 28일 Microsoft Advertising의 Conversions API 정식 제공을 발표했다. 웹사이트와 앱, 고객관계관리 시스템, 판매시점정보관리 시스템의 전환 데이터를 서버 간 연결로 전달하는 기능이다. 고객의 탐색 이전에 메시지를 만드는 변화와 달리, 이번 변화의 초점은 구매나 상담 이후의 행동을 광고 성과에 연결하는 데 있다.

구매 이후의 신호가 광고 플랫폼으로 들어오는 길

회사의 발표는 Conversions API를 기존 Universal Event Tracking 태그와 함께 사용하는 기능으로 설명한다. 브라우저에서 놓칠 수 있는 활동이나 다른 접점의 신호를 보완한다는 취지다. 광고를 본 뒤 웹에서 구매한 사람뿐 아니라 고객관리 시스템의 진행 정보와 매장 거래처럼 별도 시스템에 남는 자료도 측정의 재료가 된다.

공식 구현 문서는 웹사이트와 고객관리, 오프라인, 모바일 이벤트를 같은 연결 안에서 다루는 시나리오를 제시한다. 이를 곧 모든 사업자의 데이터가 자동으로 통합된다는 뜻으로 읽을 수는 없다. 계정과 태그, 인증과 전환 목표, 식별자와 동의 처리 등 실제 연결의 조건을 갖추는 단계가 따로 있다.

이 기능이 마케팅에서 놓이는 위치는 비교적 명확하다. 고객의 행동이 일어난 뒤 그 기록을 광고 플랫폼에 보내 측정과 최적화에 활용하는 과정이다. 소비자가 보는 광고 문구를 만드는 기능과, 광고 이후에 어떤 행동이 생겼는지 기록하는 기능은 다른 역할이다.

발표에서 기대하는 것은 더 충실한 전환 신호와 측정 기반이다. 그러나 정식 제공됐다는 소식이 개별 광고주의 매출 개선을 확인해 준 것은 아니다. 플랫폼의 기능 출시와 사업자의 실적은 별도의 사실이다. API를 연결한 날짜와 실제 데이터를 검증한 날짜도 같다고 볼 수 없다.

서버를 통해 전환 데이터를 전한다는 말은 고객 행동의 실체를 바꾸지 않는다. 원래 발생한 주문과 상담의 기록을 어떤 경로로 플랫폼에 건넬지 바꾸는 일이다. 따라서 전환 건수가 달라졌을 때에는 고객이 더 많이 행동했는지, 원래 있던 행동을 새로 포착했는지를 먼저 나누어 읽어야 한다.

전환이 늘어난 화면과 더 많이 팔린 사업은 다르다

나는 이 변화를 광고와 영업이 같은 고객 행동을 어떻게 설명하는가의 문제로 읽는다. 브라우저의 구매 완료와 서버의 주문 생성이 같은 거래라면, 기록은 두 개여도 고객의 구매는 한 번이다. 화면에 숫자가 더 많이 잡혔다는 이유만으로 판매가 늘었다고 판단하면 집계 방식의 변화를 경영 성과로 오해할 수 있다.

구현 문서는 UET와 Conversions API가 같은 전환을 보낼 때 공통의 안정된 eventId를 사용하고 eventName을 호환되게 유지하도록 설명한다. 같은 사건임을 식별해 중복 집계를 피하기 위한 조건이다. 두 경로를 갖췄다는 사실에 더해 두 기록을 하나의 행동으로 알아볼 수 있어야 한다는 뜻이다.

이 문제는 단순한 기술 용어의 정확성에서 끝나지 않는다. 구매가 두 번 집계되면 광고가 기여한 거래의 모습도 달라진다. 반대로 서로 다른 행동을 같은 사건으로 묶으면 실제 고객의 다음 단계를 놓칠 수 있다. 고객여정의 의미와 시스템이 부여한 사건 이름이 맞는지가 성과 해석의 바탕이 된다.

클릭과 주문 사이의 연결도 자료의 조건을 갖는다. 문서는 광고 클릭 식별자인 MSCLKID와 시간 정보, 허용되는 고객 식별자를 다루며, 이벤트를 보냈다는 사실과 광고에 귀속될 조건을 구분한다. 어떤 사건을 플랫폼이 받아들였다고 해서 그 사건이 모두 같은 광고 성과로 인정되는 것은 아니다.

브랜드와 플랫폼의 관계는 이 지점에서 더 구체화된다. 브랜드가 가진 거래 기록이 플랫폼의 측정 체계에 들어가면, 양쪽의 기준과 기간이 맞아야 숫자를 비교할 수 있다. 판매자의 주문 장부와 광고 화면이 다른 경우에도 곧바로 어느 쪽이 틀렸다고 단정할 수는 없다. 무엇을 언제 어떤 조건으로 센 자료인지가 먼저다.

이 연결은 플랫폼이 더 많은 신호를 받는다는 의미와 브랜드가 자기 실적을 더 잘 이해한다는 의미를 구분하게 한다. 원천 거래의 내용과 광고에 전달된 사건이 설명되지 않으면 화면의 합계는 사업의 질문에 답하기 어렵다. 측정이 촘촘해지는 변화일수록 숫자를 만드는 정의가 경영 언어로 번역돼야 한다.

취소와 정정을 거친 뒤에도 성과의 뜻은 유지되는가

구현 문서는 기존 전환의 매출값을 수정하는 restate와 전환을 철회하는 retract도 설명한다. 거래 식별자인 transactionId가 있는 경우 지원되며, 값 수정과 건수 제거가 서로 다른 열에 영향을 준다고 밝힌다. 주문이 생성된 뒤 상황이 달라질 수 있다는 점이 측정 구조 안에도 들어 있는 것이다.

따라서 주문 직후의 전환만으로 실적을 확정하면 이후의 거래 상태를 놓칠 수 있다. 고객의 구매 행동과 회사가 최종적으로 받아들인 매출 사이에는 취소나 정정이라는 과정이 있다. 이번 API가 모든 사업자의 후속 처리를 자동으로 완성한다는 뜻은 아니지만, 성과를 어느 시점의 거래로 읽는지가 중요해진다.

데이터를 보내는 경로가 서버라는 이유로 개인정보와 동의 조건이 사라지는 것도 아니다. 공식 문서는 허용되는 범위와 고객 동의를 전제로 식별자를 사용하고, 원본 이메일이나 전화번호 등은 그대로 보내지 않도록 설명한다. 이는 회사가 안내한 구현 조건이며 특정 국내 사업자의 법적 적합성이 확보됐다는 판정은 아니다.

동일한 주문을 중복 없이 보냈는지, 어떤 전환 목표와 기간으로 귀속됐는지, 나중의 수정이 반영됐는지가 경영자가 물을 질문이다. 이 질문은 새 조직이나 임의의 실행 일정을 요구하지 않는다. 이미 제공된 연결 기능이 브랜드의 실제 거래를 어디까지 충실히 설명하는지 읽는 기준이다.

10월 발표에는 AI 캠페인 생성과 메시지 가이드라인, 여러 타기팅 기능도 함께 실려 있다. 이들 기능은 정식 제공과 공개 시험, 향후 배포로 단계가 나뉜다. 전환 API가 정식 제공됐다는 사실을 같은 발표의 모든 기능이 동일 범위로 풀렸다는 뜻으로 확대하면 안 된다. 국내 계정별 사용 조건 역시 개별적으로 살펴야 한다.

결과를 읽는 순서는 새로운 숫자가 생겼다는 사실에서 출발하되 거래의 내용으로 돌아가야 한다. 고객이 실제로 무엇을 했고 그 행동이 어느 기록과 연결됐는지가 설명될 때, 광고 측정은 브랜드가 책임질 수 있는 사업의 언어가 된다. API 도입 자체를 수익 개선의 증거로 삼기 어려운 이유다.

광고의 전환 신호가 더 충실해질수록 숫자 뒤의 한 고객을 놓치지 않는 일이 중요하다. 같은 구매를 한 번으로 읽고 바뀐 거래 상태까지 구분할 수 있어야 측정의 확대가 판단의 정밀함으로 이어진다. 이번 변화가 브랜드에 남기는 질문은 더 많은 전환을 보았는가에 더해, 그 전환을 어떤 실제 거래로 설명할 수 있는가다.

김용한의 AI 마케팅 연재 모아보기 →