공식 안내상 2025년 12월 17일부터 2026년 6월 15일까지 오프라인 전환이나 리드용 향상된 전환 업로드 요청이 없었던 개발자 토큰은 Google Ads API의 UploadClickConversions 요청이 제한된다. 제한 대상 요청에서는 권한 관련 오류가 발생할 수 있다. (developers.google.com ↗)

기존에 정상적으로 요청을 전송해 온 토큰은 조건이 다를 수 있으므로 전체 계정을 일괄 장애 대상으로 분류하면 안 된다. 다만 구글은 현재와 향후 오프라인 전환 데이터 업로드에 Data Manager API를 사용하도록 안내하고 있어, 신규 광고주 연동부터 새 방식으로 표준화하는 편이 운영 리스크를 줄인다. (support.google.com ↗)

자동차·교육·금융·부동산·B2B처럼 광고 클릭 후 상담과 계약을 거치는 광고주는 CRM에 저장된 최종 성과를 구글로 되돌려 보내는 경우가 많다. 주문이 전화, 영업 담당자, 매장 또는 별도 결제 시스템에서 완료되는 광고주도 같은 점검이 필요하다.

쇼핑몰 역시 전화 주문, 견적 구매, 정기 계약처럼 웹 구매 태그에 잡히지 않는 매출을 별도로 업로드한다면 대상이 된다. 광고대행사는 계정에 ‘오프라인 전환’이라는 이름이 있는지만 보지 말고 실제 데이터가 API, 파일, 제휴 솔루션 중 어느 경로로 들어오는지 확인해야 한다.

전환 업로드가 실패해도 광고 자체는 계속 노출될 수 있어 장애가 늦게 발견될 수 있다. 이 기간에는 실제 계약이 발생했는데도 보고서상 전환수와 전환가치가 줄고, 해당 데이터를 사용하는 자동 입찰의 판단 근거도 약해질 수 있다.

이전 비용은 CRM 구조, 서버 환경, 광고주 수, 보안 검토 범위에 따라 달라지므로 일률적인 금액을 제시하기 어렵다. 대행사는 개발 견적과 별도로 누락 전환 건수, 누락 매출, 목표 CPA·ROAS 변화를 기록해 ‘연동 비용’과 ‘미연동 손실 가능성’을 비교해야 한다.

Data Manager API는 Google Ads API와 달리 개발자 토큰을 요구하지 않으며, 운영 계정·로그인 계정·연결 계정 정보를 Destination 구조로 지정한다. 인증 범위도 달라 기존 자격 증명을 그대로 사용하는 방식이 아니라 새 API에 맞춘 접근 권한 점검이 필요하다. (developers.google.com ↗)

필드도 단순히 이름만 바꾸는 수준은 아니다. 기존 order_id는 transaction_id, conversion_date_time은 RFC 3339 형식의 event_timestamp로 대응하며, 일부 필드는 동일한 대체 항목이 없다. Data Manager API는 요청 내 필드 검증에 실패하면 전체 요청을 거부하는 빠른 실패 방식이므로 배치 설계와 사전 검증이 중요하다. (developers.google.com ↗)

웹 태그와 서버 API에서 같은 구매를 동시에 전송할 때는 동일한 전환 액션 안에서 일관된 transaction_id를 사용해야 중복 제거가 가능하다. 주문번호가 채널이나 시스템마다 달라지면 한 건의 매출이 여러 전환으로 집계될 수 있다. (developers.google.com ↗)

대행사는 광고주가 제공하는 주문번호를 그대로 받기 전에 취소 후 재주문, 부분 결제, 여러 상품의 묶음 주문에서 ID가 어떻게 생성되는지 확인해야 한다. 테스트 과정에서도 동일 사건에 서로 다른 임시 ID를 붙여 운영 전환 액션으로 보내지 않는 것이 안전하다.

API 이전 기간에는 전환 감소가 광고 효율 하락인지 데이터 수집 장애인지 구분하기 어렵다. 캠페인 변경 이력만 보고 판단하지 말고 CRM 원천 건수, 전송 건수, 처리 성공 건수, 구글 보고서 반영 건수를 단계별로 비교해야 한다.

Data Manager API에서는 반환된 request_id를 활용해 처리 상태와 진단 결과를 추적하는 운영 체계를 마련할 수 있다. 광고주가 여러 전환 액션을 사용하는 경우 액션별 성공률을 나누고, 장애 대응 책임이 대행사·개발사·CRM 업체 중 어디에 있는지도 계약서에 명확히 두는 것이 좋다. (developers.google.com ↗)