웹사이트에서 Pixel이 작동하고 광고 계정에 이벤트가 쌓이고 있을 수 있습니다. 그렇다고 측정이 제대로 작동한다는 의미는 아닙니다. 구매 이벤트가 두 번 발생하거나, 잘못된 통화로 값이 전송되거나, 누군가 단순히 양식을 열었을 뿐인데 리드가 생성될 수 있습니다. 그러면 보고서는 정밀해 보입니다. 하지만 실제로는 비즈니스와 다른 무언가를 설명하고 있을 뿐입니다.
기존 2022 글에서는 당시의 인터페이스, 이벤트 목록, 잠재고객 및 설정을 살펴보았습니다. 인터페이스는 계속해서 바뀌며, Meta는 이제 웹 데이터를 데이터 세트로 묶어 관리합니다. 안정적인 프로세스는 다른 곳에서 시작합니다. 먼저 비즈니스 이벤트를 설계하고, 그다음 구현한 후, 마지막으로 실제 고객 여정에서 검증해야 합니다.
Meta Pixel은 브라우저에서 측정하고, Conversions API는 시스템에서 데이터를 전송합니다
Meta Pixel은 브라우저에서 방문과 행동을 기록할 수 있는 웹사이트 코드입니다. Conversions API는 웹 서버, 전자상거래 플랫폼 또는 CRM 등 회사의 데이터와 Meta 시스템을 직접 연결합니다.
웹 이벤트의 경우 Meta는 Pixel과 Conversions API를 함께 고려할 것을 권장합니다. 서버 연결은 페이지 로딩 오류, 연결 중단 또는 일부 브라우저 차단의 영향을 덜 받을 수 있습니다. 그렇다고 데이터가 완전해지는 것은 아니며, 사용자의 선택을 우회해도 된다는 뜻은 더더욱 아닙니다. Meta는 Conversions API가 개인정보 보호 규정을 우회하기 위한 도구가 아니라고 명시합니다. 현재 원칙은 공식 Conversions API 문서에 설명되어 있습니다.
회사가 실제로 사용하는 결과에서 시작합니다
먼저 광고 시스템이 무엇을 인식해야 하는지, 그리고 회사가 그 정보를 바탕으로 어떤 결정을 내릴지 적어 봅니다. 전자상거래 사이트라면 일반적으로 상품 조회, 장바구니 추가, 결제 시작 및 완료된 구매가 필요합니다. B2B 웹사이트라면 적격 리드, 미팅 예약 또는 이후 CRM 단계가 중요할 수 있습니다.
모든 클릭에 별도의 이벤트가 필요한 것은 아닙니다. 저는 명확한 목적을 가지고 데이터를 수집합니다.
- 캠페인의 실제 결과 측정;
- 상업적으로 중요한 행동을 기준으로 광고 최적화;
- 타당한 경우 관련 잠재고객 구축;
- 고객 여정에서 사람들이 이탈하는 지점 진단;
- 웹 행동과 쇼핑몰 또는 CRM의 결과 연결.
누군가 연락처 영역을 열었다는 이유만으로 Lead라는 이벤트를 생성해서는 안 됩니다. 유효한 주문 없이 감사 페이지 URL을 방문했다고 Purchase가 발생해서도 안 됩니다. 기술적 이름은 비즈니스의 실제 상황과 일치해야 합니다.
모든 중요한 이벤트에는 자체 데이터 계약이 필요합니다
구현을 위해 이벤트가 언제 발생하는지, 값의 출처는 어디인지, 어떤 통화를 사용하는지, 어떤 상품 또는 주문 ID를 전달하는지, 정확성에 대한 책임자는 누구인지 간략히 정리합니다.
구매 이벤트에서는 주로 다음을 확인합니다.
- 주문이 성공적으로 완료된 후에만 발생하는가;
- 값이 화면에 우연히 표시된 합계가 아니라 회사가 합의한 정의를 따르는가;
- 통화가 올바른 형식을 사용하는가;
- 주문 또는 이벤트 ID가 고유한가;
- 상품 광고를 사용하는 경우 상품 ID가 카탈로그와 일치하는가;
- 페이지를 새로 고침해도 이벤트가 반복해서 발생하지 않는가.
세금, 배송비 또는 할인 금액을 포함해 매출을 보고할지 여부는 Meta, 분석 도구 및 재무 보고 전반에서 일관되어야 합니다. 그렇지 않으면 두 플랫폼이 모두 정상적으로 작동하더라도 서로 다른 지침을 받았다는 이유만으로 서로 다른 값을 표시합니다.
Pixel 이벤트와 서버 이벤트는 중복 제거되어야 합니다
동일한 구매가 브라우저와 서버 양쪽에서 전송되면 Meta는 이것이 하나의 행동이라는 사실을 알아야 합니다. 따라서 구현 시 두 경로에서 동일한 이벤트 이름과 이벤트 식별자를 사용합니다. ID가 매번 다르게 생성되거나 누락되면 보고서에서 하나의 구매를 두 번 집계할 수 있습니다.
소스 코드를 살펴보는 것만으로 중복 제거를 테스트하지는 않습니다. 테스트 주문을 넣고 브라우저와 서버 버전이 모두 테스트 이벤트에 도착하는지, 시스템이 두 이벤트를 하나로 결합하는지 확인합니다. 필드 이름과 권장 사항은 바뀔 수 있으므로 기술적 매개변수는 최신 Meta Conversions API 문서와 대조합니다.
자존심이 아니라 운영을 기준으로 구현 방식을 선택합니다
Meta는 파트너 통합, 수동 설치 및 기타 연결 방식을 제공합니다. 현재 선택지는 Meta Pixel 설정 가이드에 설명되어 있습니다. 일반적인 전자상거래 플랫폼에서는 유지 관리가 되지 않는 맞춤 코드보다 테스트된 파트너 통합이 대체로 안전합니다. 복잡한 웹사이트나 CRM에서는 수동 솔루션이 더 정확할 수 있지만, 문서화와 테스트 및 책임 있는 담당자가 필요합니다.
“고급”이라는 이름이 붙었다는 이유만으로 플러그인을 추가하지는 않습니다. 두 통합이 동일한 이벤트를 전송하거나, 값을 서로 다르게 계산하거나, 동의 설정을 덮어쓸 수 있습니다. 먼저 웹사이트에서 이미 무엇이 실행되고 있는지 파악합니다.
동의와 데이터 최소화는 설계의 일부입니다
Pixel과 Conversions API는 마케팅 데이터를 처리합니다. 회사는 자신의 운영 방식과 시장에 적용되는 법적 의무 및 정보 제공 의무를 검토해야 합니다. 이 글은 법률 자문이 아닙니다. 다만 기술적으로는 측정 시스템이 동의 설정을 존중하고, 명시된 목적에 필요하지 않은 데이터를 전송하지 않도록 해야 합니다.
해싱은 익명화가 아니며 자동으로 법적 근거를 제공하지도 않습니다. 서버 측 전송은 같은 내용을 몰래 보내는 방법이 아닙니다. 기술은 회사의 결정과 법적 프레임워크를 구현해야 하며, 이를 회피해서는 안 됩니다.
기능 점검은 전체 고객 여정을 포괄해야 합니다
배포 후에는 초록색 표시만으로 충분하지 않습니다. 고객의 입장에서 웹사이트를 이용하며 각 단계에서 다음을 확인합니다.
- 올바른 데이터 세트 또는 Pixel이 필요한 곳에서만 로드되는가?
- 올바른 이벤트가 올바른 시점에 발생하는가?
- 합의된 값, 통화, ID 및 기타 매개변수가 포함되어 있는가?
- 동일한 이벤트가 두 번 생성되고 있는가?
- 서버 이벤트가 도착하고 브라우저 이벤트와 중복 제거되는가?
- 상품 ID가 카탈로그와 일치하는가?
- 동의를 거부한 후의 동작이 선택한 모드를 따르는가?
- 결과가 쇼핑몰 또는 CRM에도 나타나는가?
Events Manager의 테스트 이벤트, 진단 도구, Meta Pixel Helper 확장 프로그램과 실제 테스트 주문 또는 양식을 사용합니다. 그런 다음 내부 시스템의 집계와 비교합니다. 플랫폼 간 차이는 어트리뷰션과 기술적 한계로 인해 발생할 수 있지만, 큰 차이나 정확히 두 배로 늘어난 수치는 구현을 수정해야 한다는 신호입니다.
잠재고객은 양질의 이벤트가 만들어 내는 결과입니다
Pixel을 사용하면 웹사이트 방문과 행동을 기준으로 사람들에게 접근할 수 있습니다. 그러나 먼저 법적 허용 여부, 규모 및 비즈니스 관련성을 확인합니다. 장기간의 모든 방문자 잠재고객에는 고객, 구직자, 봇, 전혀 다른 주제를 찾는 사람이 섞일 수 있습니다.
더 나은 출처는 명확한 이벤트와 관계에서 나옵니다. 예를 들어 상품을 조회한 사람, 장바구니를 방치한 사람, 실제 고객 또는 관련 리드입니다. 그 경우에도 원하는 단계를 이미 완료한 사람을 제외했는지, 광고 빈도는 적절한지 확인합니다.
Meta 보고서는 회사의 회계 장부가 아닙니다
플랫폼은 자체 어트리뷰션 규칙을 사용합니다. Google Analytics 4는 고객 여정을 다른 방식으로 추적하는 반면, CRM은 영업 활동이 이루어진 후에야 리드의 품질을 파악합니다. 수치가 일치할 필요는 없습니다. 중요한 것은 그 이유와 각 시스템이 어떤 결정을 지원하는지 아는 것입니다.
캠페인에 UTM 매개변수를 붙이고 상업적 결과와 연결합니다. 광고 경제성과 타기팅에 대해서는 Facebook 광고에 관한 글에서 다룹니다. 모든 측정 시스템을 정기적으로 점검하려면 온라인 마케팅 체크리스트를 사용하세요.
정확한 측정은 가능한 한 많은 이벤트를 전송하는 것이 아닙니다. 명확한 이유에 따라 적절한 정보를 적절한 시점에 정확히 한 번 전송하는 것입니다.