전환 API 매칭률 높이는 방법 5가지

전환 API 매칭률, 왜 신경 써야 할까

전환 API(Conversion API, 이하 CAPI)의 매칭률을 높이려면 이메일·전화번호·클릭 ID 같은 식별 파라미터를 최대한 많이, 정확한 해시 규칙으로, 이벤트 ID를 붙여 중복 없이 광고 플랫폼에 전달하는 것이 핵심입니다. 매칭률이 낮으면 서버에서 전환 이벤트를 아무리 많이 보내도 광고 플랫폼이 실제 유저와 연결하지 못해 입찰 최적화에 반영되지 않고, 리포트 상 전환수도 실제보다 적게 집계됩니다.

전환 API는 브라우저 픽셀(예: 광고 플랫폼의 웹 태그)이 쿠키 차단·iOS ATT(App Tracking Transparency, 앱 추적 동의 절차)·광고 차단기 등으로 놓치는 전환 데이터를 웹서버·백엔드에서 광고 플랫폼으로 직접 전송하는 서버-사이드 연동 방식입니다. 이렇게 전달된 데이터를 광고 플랫폼이 자사 로그인 유저 데이터와 대조해 ‘이 이벤트가 어떤 유저의 행동인지’ 알아내는 비율을 매칭률, 또는 이벤트 매칭 품질(EMQ, Event Match Quality)이라고 부릅니다. 전환 API와 픽셀의 역할 차이가 궁금하다면 전환 API와 픽셀, 뭐가 다르고 언제 쓸까 글을 먼저 참고하면 이해가 빠릅니다.

매칭률이 낮으면 서버 전환 이벤트가 정상 전송되고 있어도 광고 플랫폼의 입찰 최적화·타겟팅에는 거의 반영되지 않습니다. 전송량보다 ‘얼마나 정확히 유저와 연결됐는가’가 광고 성과에 더 직접적으로 작용합니다.

매칭률을 결정하는 핵심 파라미터

개인식별 파라미터의 해시 처리

CAPI는 이메일·전화번호·이름 같은 개인정보를 원문 그대로 보내지 않고, 해시(Hash, 되돌릴 수 없는 형태로 변환한 문자열)로 암호화해 전송합니다. 이때 해시 전 정규화 규칙이 플랫폼 쪽 처리 방식과 정확히 일치해야 매칭이 성립합니다. 이메일은 소문자로 변환하고 앞뒤 공백을 제거한 뒤 SHA-256으로 해시하며, 전화번호는 국가번호를 포함한 숫자만 남기고 하이픈·공백을 제거해야 합니다.

import hashlib

def normalize_and_hash(value: str) -> str:
    # 이메일 예시: 소문자 변환 + 공백 제거 후 해시
    normalized = value.strip().lower()
    return hashlib.sha256(normalized.encode("utf-8")).hexdigest()

hashed_email = normalize_and_hash("User@Example.com ")
print(hashed_email)

실제 API 요청에서는 아래처럼 여러 식별 파라미터를 하나의 user_data 객체에 함께 담아 보내야 매칭 기회가 늘어납니다.

{
  "data": [
    {
      "event_name": "Purchase",
      "event_time": 1788490800,
      "event_id": "order_20260904_001",
      "user_data": {
        "em": ["<hashed_email>"],
        "ph": ["<hashed_phone>"],
        "client_ip_address": "203.0.113.1",
        "client_user_agent": "Mozilla/5.0 ...",
        "fbc": "fb.1.1788490800.abc123",
        "fbp": "fb.1.1788483600.xyz789"
      }
    }
  ]
}

해시 전 원문 개인정보(이메일 원문, 전화번호 원문)를 로그나 응답 본문에 그대로 남기면 개인정보보호법 위반 소지가 있습니다. 해시는 반드시 서버 내부에서 처리하고, 원문은 저장·전송 로그에서 즉시 제거하는 것이 원칙입니다.

이벤트 ID와 중복 제거

브라우저 픽셀과 서버 CAPI가 같은 전환을 각각 별도로 전송하면 광고 플랫폼은 이를 두 건으로 계산할 수 있습니다. 이를 막기 위해 픽셀 이벤트와 서버 이벤트에 동일한 event_id를 부여해 플랫폼이 자동으로 중복을 제거(deduplication)하도록 해야 합니다. event_id가 없거나 두 경로에서 다르게 생성되면 매칭률 계산 자체가 왜곡되고, 전환수도 부풀려질 수 있습니다.

• 주문번호, 결제 트랜잭션 ID 등 이미 시스템에 존재하는 고유값을 event_id로 재사용
• 픽셀 스크립트와 서버 이벤트 생성 시점에 같은 값을 참조하도록 코드 레벨에서 공유
• 재시도·재전송 시에도 동일 event_id를 유지해 중복 카운트 방지

전환 API 매칭률 높이는 단계별 방법

단계 1: 전송 가능한 파라미터를 최대한 수집한다

매칭률은 파라미터 ‘개수’에 비례해 개선되는 경향이 있으므로, 확보 가능한 식별값을 먼저 목록화합니다.

1. 이메일, 전화번호 등 회원가입·주문 시 수집되는 식별 정보 확인
2. 웹사이트 방문 시 생성되는 클릭 ID(광고 플랫폼별 파라미터)와 쿠키값 확인
3. IP 주소, User-Agent 등 브라우저 세션 정보 확인

단계 2: 해시·정규화 규칙을 플랫폼 문서와 통일한다

파라미터를 모아도 정규화 규칙이 틀리면 매칭이 실패합니다. 이메일 소문자 변환, 전화번호 국가코드 포함 숫자만 남기기 등 플랫폼별 가이드에 맞춰 해시 로직을 통일하고, 신규 배포 전 테스트 이벤트로 검증합니다.

단계 3: 픽셀과 서버 이벤트를 이벤트 ID로 묶는다

동일 전환에 대해 브라우저와 서버 양쪽에서 이벤트를 보내는 ‘이중 전송’ 구조를 유지하되, 반드시 같은 event_id를 부여합니다. 이렇게 하면 한쪽 경로가 유실돼도 다른 경로가 데이터를 보완하면서 매칭률과 데이터 완전성을 동시에 높일 수 있습니다.

단계 4: 테스트 도구로 파라미터별 매칭 기여도를 확인한다

대부분의 광고 플랫폼은 이벤트 관리자 화면에서 파라미터별 매칭 기여도(또는 EMQ 점수)를 제공합니다. 파라미터를 추가할 때마다 이 점수 변화를 확인하며 우선순위가 높은 파라미터부터 채워 넣는 것이 효율적입니다.

흔한 실수와 주의사항

실수 유형	원인	해결 방법
해시 규칙 불일치	대소문자·공백 처리 없이 그대로 해시	플랫폼 가이드대로 소문자 변환·트림 후 해시
이벤트 ID 미부여	서버·픽셀 이벤트를 독립적으로 생성	주문 ID 등 공통 고유값을 event_id로 공유
전송 지연	배치성 야간 일괄 전송	전환 발생 직후 실시간에 가깝게 전송
파라미터 누락	이메일 하나만 전송	전화번호·클릭 ID·IP 등 추가 파라미터 확보

매칭률 개선 효과, 어떻게 확인할까

이벤트 매칭 품질 점수 확인

광고 플랫폼의 이벤트 관리자(또는 전환 추적 대시보드)에서 이벤트별 매칭 품질 점수를 확인할 수 있습니다. 파라미터를 추가·수정한 뒤 이 점수가 상승했는지, 어떤 파라미터가 가장 큰 기여를 하는지 주기적으로 점검합니다.

전환수·어트리뷰션 변화 추적

매칭률이 개선되면 동일한 실제 전환량에서도 리포트상 잡히는 전환수가 늘어나고, 캠페인 최적화 정확도도 함께 좋아지는 경향이 있습니다. 다만 어트리뷰션 모델 자체의 한계로 인해 특정 채널의 기여가 과대·과소평가될 수 있으므로, 전환수 증가를 매칭률 개선 효과로만 해석하지 말고 어트리뷰션 모델의 한계도 함께 고려해서 판단해야 합니다.

자주 묻는 질문

Q. 전환 API 매칭률은 어느 정도가 적정 수준인가요?

플랫폼마다 점수 산정 방식이 달라 절대적인 기준을 제시하기는 어렵습니다. 절대값보다는 파라미터를 추가하기 전과 후의 변화 추이를 비교해 지속적으로 개선되고 있는지를 확인하는 방식이 더 실용적입니다.

Q. 이메일과 전화번호 중 하나만 보내도 매칭이 되나요?

하나만 보내도 매칭이 시도되지만, 여러 식별 파라미터를 함께 보낼수록 매칭 성공 확률이 높아지는 구조입니다. 가능하다면 이메일·전화번호·클릭 ID·IP·User-Agent를 함께 전송하는 것이 좋습니다.

Q. 개인정보를 해시하지 않고 그대로 보내도 되나요?

안 됩니다. 원문 개인정보를 그대로 전송하면 개인정보보호 관련 규정 위반 소지가 있고, 플랫폼 측에서도 원문 데이터 수신을 허용하지 않는 경우가 대부분입니다. 반드시 지정된 해시 알고리즘으로 변환한 뒤 전송해야 합니다.

Q. 서버 이벤트만 보내고 픽셀은 꺼도 되나요?

가능하지만 권장되지는 않습니다. 픽셀과 서버 이벤트를 함께 사용하면 한쪽에서 유실된 데이터를 다른 쪽이 보완할 수 있어 데이터 완전성이 높아집니다. 이 경우 반드시 동일한 이벤트 ID로 중복 제거를 설정해야 합니다.

Q. 매칭률 개선 작업은 개발자 없이도 가능한가요?

파라미터 정규화·해시 처리·이벤트 ID 연동은 서버 코드 수정이 필요한 영역이라 개발 리소스가 필요합니다. 다만 어떤 파라미터를 우선 확보할지, 어떤 이벤트부터 개선할지 우선순위를 정하는 기획 작업은 마케터가 주도할 수 있습니다.

참고자료

• Meta for Developers – Conversions API 고객 정보 파라미터(해시·정규화 규칙) 공식 문서
• Meta for Developers – 픽셀·서버 이벤트 중복 제거(event_id 기반 Deduplication) 공식 문서