ATT 이후 실제로 무엇이 끊겼나

애플의 앱 추적 투명성은 앱이 다른 앱·웹사이트에 걸쳐 사용자를 추적하기 전에 권한 요청 다이얼로그로 동의를 받도록 요구하고, 권한 상태는 허용, 거부, 제한, 미결정 네 가지입니다. 광고 식별자 접근은 상태가 허용일 때만 가능하며, 권한이 없으면 식별자는 모두 0으로 채워진 값을 반환합니다. 개별 사용자를 식별해 잇는 축 하나가 통째로 빠지는 구조입니다.

메타 쪽 대응이 집계 이벤트 측정입니다. 추적을 거부한 사용자에 대해서도 개별 사용자 단위가 아닌 도메인 단위 집계 데이터로 전환을 측정하고 보고하는 체계이고, 핑거프린팅 위험을 막기 위해 집계와 보고에 24~48시간의 지연을 의도적으로 둡니다. 오래 알려진 제약이 도메인당 8개 이벤트 우선순위 지정이었는데, 이 제한은 2025년 6월부터 웹 전환에 한해 제거돼 자격을 갖춘 표준·커스텀 이벤트가 별도 순위 지정 없이 처리되는 구조로 바뀌었습니다.

전환 API는 픽셀을 대체하는가

아닙니다. 전환 API는 광고주의 서버, 웹사이트 플랫폼, 앱, CRM에서 발생한 이벤트를 메타 시스템으로 직접 연결하는 공식 API이고, 픽셀과 동일한 표준 이벤트와 커스텀 이벤트를 지원하며 서버 이벤트는 픽셀과 동일하게 처리됩니다. 사용하려면 픽셀 ID와 비즈니스 관리자가 필요합니다. 즉 픽셀을 걷어내는 작업이 아니라 같은 행동을 두 경로로 보내 서로의 빈틈을 메우는 구성입니다.

두 경로를 함께 두는 이유는 각 경로가 막히는 지점이 다르기 때문입니다. 브라우저 경로는 서드파티 쿠키 제한, iOS 개인정보보호 설정, 광고차단기 때문에 손실이 생기고, 서버 경로만 남기면 브라우저에서만 잡히는 신호가 빠집니다.

중복 제거 키는 어디서 만들어 어떻게 싣나

두 경로로 같은 구매를 보내면 두 건이 되는 게 기본입니다. 이걸 하나로 합치는 열쇠가 event_id입니다. event_id는 픽셀에서 온 이벤트와 전환 API에서 온 이벤트가 같은 사용자 행동임을 메타가 알아보게 하는 공유 식별자이고, 같은 event_name과 같은 event_id를 짧은 시간 안에 받으면 중복으로 판단해 하나만 계산합니다.

구현에서 실수가 나는 지점은 값을 만드는 위치입니다. 브라우저와 서버가 각자 값을 생성하면 두 값이 다르므로 중복 제거가 되지 않습니다. 값은 한 곳에서 만들어 양쪽에 같은 값으로 전달해야 하고, 구매라면 주문 단위로 유일한 값을 쓰는 것이 자연스럽습니다. 이벤트 이름도 양쪽이 같아야 합니다. 잘 붙었는지는 이벤트 관리자 진단 탭의 중복 제거된 이벤트 지표로 비율을 확인하고, 비율이 낮거나 event_id 형식에 문제가 있으면 경고가 함께 표시됩니다.

무엇을 실어 보내야 매칭이 되나

전환 API 페이로드의 필수 코어 매개변수는 event_name과 event_time이고, 여기에 고객 정보를 담는 user_data와 거래 정보를 담는 custom_data를 추가합니다. 실제 성과를 가르는 것은 user_data 쪽입니다.

매칭 품질은 이벤트 일치 등급으로 표시되며 0~10점 또는 네 단계 등급으로 나타납니다. 점수를 결정하는 것은 주로 전송한 식별자의 종류와 품질입니다. 최고 등급 식별자는 해싱된 이메일, 해싱된 전화번호, 외부 ID이고 중간 등급은 브라우저 쿠키 값과 클릭 ID입니다.

개인식별정보를 다루는 대목이므로 순서를 지켜야 합니다. 이메일과 전화번호 같은 정보는 SHA-256 해싱으로 정규화한 뒤 전송해야 하고, 정규화와 해싱 방식이 메타의 처리 방식과 정확히 일치해야 매칭이 성립합니다. 소문자 변환과 공백 제거 같은 정규화가 어긋나면 해시값이 달라져 매칭이 실패합니다. 원본 값을 그대로 서버 밖으로 내보내는 구성은 권하지 않습니다. 매칭에 필요한 것은 원본이 아니라 양쪽이 같은 규칙으로 만든 해시값이고, 해싱은 원본을 보내지 않기 위한 장치이기 때문입니다.

목표 점수를 묻는 경우가 많은데, 6 이상이 양호하고 8 이상이 권장이라는 기준은 매체가 문서로 확정한 임계값이 아니라 커뮤니티와 업계 관행으로 통용되는 값입니다. 절대 점수를 목표로 삼기보다, 식별자를 하나씩 추가하면서 점수가 어떻게 움직이는지 자사 계정에서 확인하는 편이 실질적입니다.

어떤 구현 방식을 고를 것인가

크게 세 갈래입니다. 직접 API 호출은 개발팀이 필요하고, GTM 서버 컨테이너는 기술 요구사항이 중간이며, 쇼핑몰 솔루션이나 파트너 연동은 원클릭에 가깝습니다. 통제 가능성과 초기 리소스는 반비례합니다. 메타가 직접 붙여주는 설정은 비용 없이 끝나지만 픽셀이 보내는 이벤트와 파라미터를 그대로 복제할 뿐 개별 선택이 불가능하고 웹 이벤트만 지원합니다. 직접 코드 구현은 개발 리소스가 들고 통상 2~4주가 걸리지만 웹·앱·오프라인·CRM 이벤트까지 지원하며 전송 항목을 세밀하게 통제할 수 있습니다. 2026년 4월 15일에는 이벤트 관리자 안에서 원클릭으로 설정하는 기능이 출시돼, 메타가 서버 인프라를 직접 관리하는 선택지도 생겼습니다.

도입 효과는 무엇으로 판정하나

회복되는 전환 비율의 일반 수치는 공식 기준으로 공개된 바 없습니다. 메타가 발표한 값으로 확인되는 것은 전환 API를 쓰는 계정의 평균 목표달성비용이 개선됐다는 자체 보고이고, 이는 회복 전환 비율과 다른 지표입니다. 그러니 도입 전후를 자사 계정에서 대조하는 절차로 대신합니다.

최소 4주치 기준선을 확보하고, 한 번에 한 항목만 바꾸고, 같은 요일끼리 비교합니다. 판정 지표는 이벤트 일치 등급, 중복 제거된 이벤트 비율, 매체 전환수와 주문 데이터의 오차율 세 개면 충분합니다. 앞의 둘은 구현이 제대로 됐는지를, 마지막 하나는 그 구현이 리포트에 어떻게 반영됐는지를 보여줍니다.