작성자
Ira Holubovska
Facebook Pixel을 사용하면 사이트에서 사용자 활동을 추적하고, 리타겟팅 잠재고객을 수집하며, 유사 잠재고객을 생성할 수 있습니다. 올바르게 구현되면 Facebook Pixel은 관련 정보를 Facebook의 머신러닝 알고리즘(FB ML)에 제공하며, 이 알고리즘은 해당 데이터를 활용해 전환 가능성이 가장 높은 사람들에게 광고를 노출합니다.
수년 동안 저희는 JavaScript 코드, 앱 내 Facebook SDK, 또는 오프라인 이벤트 업로드를 통해 사이트에서 이벤트를 추적해 왔습니다. 하지만 광고 차단기를 사용하는 사용자를 어떻게 추적하고, 사이트 외부에서 발생하는 이벤트를 어떻게 모니터링하며, 쿠키 수명을 어떻게 연장할 수 있을까요? 이는 Facebook Conversions API 또는 Facebook Conversions API Gateway를 구현함으로써 가능합니다.
이 글에서는 Facebook 전환 트래킹에 초점을 맞추고, Google Tag Manager 서버 컨테이너를 통해 Facebook Conversions API를 설정하는 방법을 안내합니다. 또한 Stape의 Meta CAPI용 사전 구성 템플릿도 확인해 보세요. 설정이 이보다 더 쉬울 수 없습니다. 모든 것이 미리 구성되어 바로 사용할 준비가 되어 있습니다!
| 관련 글: Facebook 리드 광고. |
귀하의 Meta Pixel이 매출 데이터를 놓치고 있습니다
Stape로 Meta Conversions API를 설정하고 브라우저 이벤트와 서버 이벤트를 모두 활용하는 하이브리드 트래킹 환경을 구축하세요.
Facebook Conversions API가 무엇인지, 그리고 Facebook에서 이벤트 트래킹, 어트리뷰션, 데이터 수집을 개선하는 데 어떻게 활용할 수 있는지 살펴보겠습니다. Facebook Conversions API를 사용하면 귀하의 서버에서 Facebook의 서버로 이벤트를 직접 전송할 수 있습니다.
Facebook CAPI는 Facebook Pixel과 동일한 목적을 수행하지만, 다른 기술에 기반합니다. FB CAPI를 둘러싼 정책과 제한 사항은 현대 트래킹 환경의 요구 사항에 더 적합합니다. Facebook Pixel과 달리, Conversions API는 트래킹 정보를 전송하기 위해 사용자의 브라우저에 의존하지 않습니다. 모든 처리가 클라우드 서버를 통해 이루어지므로 데이터 보안성과 정확성이 향상됩니다.
Pixel과 달리, Facebook 서버 측 트래킹은 사용자의 브라우저에서 일어나는 일에 의존하지 않습니다. 즉, 광고 차단기, ITP, iOS 제한이 데이터 수집에 미치는 영향이 거의 없거나 전혀 없습니다. 이는 특히 브라우저의 개인정보 보호 제한이 계속 강화되는 상황에서, 전환 트래킹을 위한 더 안정적인 기반이 됩니다.
Facebook 광고의 URL을 살펴보면, FB가 거의 모든 URL 끝에 fbclid라는 추가 매개변수를 덧붙인다는 것을 알 수 있습니다. 랜딩 페이지의 픽셀 코드는 이 매개변수의 값을 쿠키에 저장하고, 모든 Facebook 이벤트와 함께 전송합니다. 클릭 ID(fbclid) 외에도, Facebook은 브라우저 ID(fbp)를 사용합니다. fbp와 fbc 쿠키는 Facebook이 귀하의 사이트에 방문한 사용자와 전환한 사용자의 유형을 식별하는 데 도움을 줍니다.
Facebook은 이메일, 전화번호, 이름/성과 같은 다른 매개변수를 통해서도 사용자를 매칭할 수 있습니다. Facebook Conversions API에 더 많은 사용자 데이터를 전송할수록 매칭률은 더 높아집니다.
Meta Conversions API 서버 측 트래킹은 전체 데이터 흐름을 브라우저에서 벗어나 귀하의 서버 인프라로 옮깁니다. 누군가의 탭 안에서 JavaScript 스니펫이 실행되기를 기다리는 대신 – 그 과정에서 느린 연결, 개인정보 보호에 중점을 둔 브라우저, 또는 타사 쿠키 제한으로 인해 이벤트가 소리 없이 누락될 수 있습니다 – 귀하의 서버가 히트 데이터를 Meta의 엔드포인트로 직접 전송합니다. 클라이언트 측에서 무슨 일이 일어나든 상관없이 이벤트는 전달됩니다. Meta Pixel과 병행하여 실행할 경우, Meta Conversions API 서버 측 트래킹은 2개의 채널로 구성된 설정을 만들어냅니다. Pixel은 Meta가 잠재고객 구축에 사용하는 브라우저 측 신호를 포착하고, 서버 계층은 그 공백을 메워 Pixel이 놓쳤을 수 있는 사용자 데이터를 전달합니다. 이러한 조합이야말로 전체적인 트래킹을 더욱 완전하고 신뢰할 수 있게 만드는 요소입니다.
대부분의 기업이 웹 이벤트에 집중하는 반면, Meta는 이제 오프라인 매장을 온라인 데이터와 동기화할 수 있도록 지원합니다. 온라인과 오프라인 전환을 결합하는 방법을 알아보려면 Meta 옴니채널 광고 가이드를 확인해 보세요.

Facebook 서버 측 태깅, 즉 Facebook Conversions API는 수년 전부터 이용 가능했습니다. 하지만 2021년부터 Facebook은 Conversions API를 더욱 적극적으로 홍보하기 시작했습니다. 귀하의 광고 계정을 관리하는 전담 Facebook 담당자가 있다면, 그들은 아마도 Facebook Conversions API 설정을 권장할 것입니다.
Facebook Conversions API 구현을 고려해야 할 가장 중요한 이유들은 다음과 같습니다. 자세한 내용은 아래를 참고하세요.

Facebook 서버 측 트래킹으로 전환한 기업들은 일반적으로 보고된 전환 수가 개선되는 것을 확인합니다. 이는 전환이 더 많이 발생해서가 아니라, 트래킹 제약으로 인해 손실되는 전환이 줄어들기 때문입니다. 이 차이는 Safari, Brave, 또는 광고 차단기를 많이 사용하는 잠재고객 사이에서 가장 두드러지게 나타납니다.
Ray-Ban은 Meta Pixel과 함께 Conversions API를 통합함으로써 광고 성과를 크게 개선할 수 있었습니다. 이 조합을 통해 Meta Pixel만 사용했을 때와 비교해 Facebook과 Instagram에서 도달률이 36% 증가했습니다.

또한, 이 브랜드는 1,000회 노출당 비용이 19% 감소하고, 전환당 비용이 7% 감소하는 효과를 확인했으며, 이는 Conversions API가 캠페인 최적화와 성과 향상에 효과적임을 보여줍니다.
Meta Conversions API Gateway는 Meta 서버 측 트래킹을 구현하는 가장 빠른 솔루션이며, 전문 지식이 전혀 필요하지 않습니다.
가장 접근하기 쉬운 방법 중 하나는 서버 Google Tag Manager(sGTM)를 사용하는 것입니다. sGTM을 사용하면 기업은 고객 데이터를 Facebook의 서버로 직접 전송할 수 있습니다. 이미 GA4를 사용하고 있다면, sGTM을 통한 Facebook 서버 측 트래킹은 최소한의 추가 구성만 필요합니다. GA4 이벤트를 Facebook 태그의 데이터 소스로 그대로 재사용할 수 있기 때문입니다. 이로 인해 sGTM은 대부분의 설정에서 가장 실용적인 출발점이 됩니다.
sGTM을 통해 Facebook CAPI를 설정할 때의 장점:
sGTM을 통해 Facebook CAPI를 설정할 때의 단점:
이 글에서는 서버 GTM을 통해 Facebook 서버 측 트래킹을 구성하는 방법에 초점을 맞춥니다.
서버 컨테이너를 사용하여 Google Tag Manager로 Facebook Conversion API를 설정하겠습니다. Facebook Conversions API를 구성하려면 다음이 필요합니다.
저희 블로그에는 Tag Manager 서버 컨테이너와 그 이점에 관한 글도 있습니다.
이 영상은 Google Analytics 4를 사용하여 Facebook Conversions API를 설정하는 방법을 보여줍니다.
2. 서버 GTM 컨테이너로 데이터를 전송합니다. sGTM으로 데이터를 전송하는 가장 널리 쓰이는 두 가지 방법은 Google Analytics 4와 Data Client Stape입니다.
3. Google Tag Manager 서버 컨테이너로 이동합니다. Template Gallery에서 Facebook Conversions API 태그를 추가합니다.

4. sGTM 내에 Facebook Conversions API 태그를 생성합니다. Tag를 선택 → New를 클릭 → 이전 단계에서 추가한 Facebook 태그를 선택합니다.
귀하의 Facebook Pixel ID와 Facebook API 액세스 토큰을 추가합니다(추적하려는 각 Facebook 이벤트마다 이 값들이 필요하므로 변수로 추가하는 것을 권장합니다). Facebook API 액세스 토큰을 모르는 경우, Meta의 문서를 참고하십시오.

5. Facebook Conversions API 태그를 구성하는 데는 2가지 옵션이 있습니다:
6. override(재정의) 옵션을 선택한 경우, Facebook 서버 이벤트를 트리거하기 위해 GA4 또는 Data Tag/Data Client 이벤트를 사용해야 합니다. Facebook의 pageview 이벤트는 특정 클라이언트가 가져온 맞춤 이벤트 page_view에서 트리거되어야 합니다(예를 들어, Server GTM의 데이터 소스로 GA4를 사용하기로 선택했다면, 클라이언트 이름이 GA4와 같을 때 page_view 이벤트를 사용해야 합니다).
다른 이벤트를 설정하려면 sGTM 미리보기 모드로 이동하여, Facebook에서 추적하고자 하는 작업을 사이트에서 수행한 다음, GA4 또는 Data Tag가 귀하의 서버 컨테이너로 전송하는 이벤트 이름을 확인하십시오.
아래 스크린샷에서는 누군가가 저희 사이트의 상품 페이지를 열었을 때 Facebook 이벤트 ViewContent를 설정하고자 합니다. 웹 컨테이너에서 GA4 이벤트/Data Tag와 함께, 서버 이벤트에 사용하고자 하는 추가 데이터도 반드시 함께 전송해야 합니다. 아래 예시에서는 표준 Facebook 전자상거래 매개변수와 사용자 데이터도 사용합니다.
이를 위해 저희는 서버 컨테이너 내에 새 태그를 생성하고, override로 설정하고, 표준 이벤트 ViewContent를 선택한 다음, API 액세스 토큰과 Facebook Pixel ID를 추가했습니다. 또한 User Data를 추가하고, 이벤트 이름이 view_item과 같고 Client Name이 GA4와 같은 새 트리거를 생성했습니다.


7. Server Event Data Override, User Data, Custom Data 필드를 사용하여 맞춤 매개변수를 전달할 수 있습니다. User Data 필드를 통해 사용자 데이터를 전송하여 Facebook에서의 매칭 점수를 높일 수 있습니다. Facebook Conversions API에 전송하고자 하는 사용자 정보는 해싱 처리되어야 한다는 점에 유의하십시오. 저희 Facebook 태그는 필요한 데이터를 자동으로 해싱합니다.
이벤트 데이터를 강화하기 위해 HTTP 전용 보안 쿠키(gtmeec)를 사용하는 Event Enhancement를 활성화할 수도 있습니다. 이 기능을 활성화하면, 태그는 사용자 데이터를 쿠키에 저장하고, 해당 데이터가 없을 때 사용자 데이터로 이벤트를 보강합니다. 이를 통해 이벤트 매치 품질을 높일 수 있으며, 이는 캠페인에 대한 전환 어트리뷰션을 개선할 수 있습니다.

8. 모든 Facebook 이벤트 설정을 완료했다면, Google Tag Manager 디버그 모드를 열고 Facebook 이벤트가 올바르게 작동하는지 테스트하십시오. 서버 컨테이너 내의 Facebook 태그로 이동하여 Facebook 테스트 ID를 추가할 수도 있습니다. 테스트 ID는 Meta Events Manager 내 Test Events 탭에서 확인할 수 있습니다.

9. Facebook Conversions API가 올바르게 작동하는지 설정하고 확인했다면, FB 브라우저 트래킹을 제거하거나 이벤트 중복 제거를 설정해야 합니다. 그렇지 않으면 이벤트가 중복될 것입니다.
Stape를 사용하면 서버 측 태깅을 통해 트래킹 정확도와 캠페인 성과를 높일 수 있습니다.
사용하시는 플랫폼에 따라, 저희의 맞춤 템플릿을 활용하여 빠르고 효과적으로 트래킹을 설정할 수 있습니다. 서버 GTM을 사용하여 다음 플랫폼에 대해 Meta CAPI를 설정하는 단계별 가이드를 따라해 보세요:
Wix, Shopware, PrestaShop 등을 위한 템플릿과 가이드도 곧 제공될 예정입니다. 다른 CMS용 템플릿이 필요하시면 알려주십시오.
Facebook은 이벤트를 추적하기 위해 Pixel과 Conversions API를 모두 사용할 것을 권장하지만, 이벤트 중복 제거가 없으면 브라우저와 서버에서 중복된 데이터가 결과를 왜곡할 수 있습니다. 중복 제거는 두 소스 간에 공유되는 고유한 이벤트 ID를 사용하여 오직 하나의 이벤트만 유지되도록 보장합니다. 올바른 설정을 위해서는 이러한 ID를 브라우저 이벤트와 서버 이벤트 간에 생성하고 동기화해야 하며, 이는 Facebook의 Events Manager에서 테스트할 수 있습니다.
Facebook 서버 측 트래킹에서 흔히 발생하는 실수는 서버에서만 이벤트를 전송하고 Pixel을 완전히 생략하는 것입니다. 이는 Facebook이 사용자 식별을 위해 fbp와 fbc 쿠키와 같은 브라우저 측 신호에 의존하기 때문에 잠재고객 매칭률을 떨어뜨립니다. 적절한 중복 제거와 함께 두 가지를 병행하여 실행하면 두 가지 장점을 모두 얻을 수 있습니다. 서버 측 데이터 수집의 신뢰성과, Facebook이 정확한 잠재고객을 구축하고 캠페인을 효과적으로 최적화하는 데 필요한 브라우저 신호를 모두 확보하게 됩니다.
또한, Conversions API를 통해 사용자 데이터를 전송하면 매칭 품질과 이벤트 매치 점수가 향상되어 광고 성과가 개선됩니다. 사용자 데이터는 이상적으로 데이터 레이어에서 가져와야 하며, 개인정보 보호정책을 준수해야 합니다. Stape 플러그인과 같은 도구는 더 나은 Facebook 캠페인 최적화를 위한 사용자 데이터 통합을 간소화해 줍니다.
귀하의 사이트를 방문하는 사용자를 자사 데이터베이스와 매칭하기 위해, Facebook은 Conversions API에 User Data를 사용합니다.
Facebook은 일부 매개변수를 전송하기 전에 해싱할 것을 요구하지만, 이에 대해 걱정할 필요는 없습니다. Facebook의 태그가 데이터를 전송하기 전에 자동으로 모든 데이터를 해싱합니다.
Facebook에 더 많은 사용자 매개변수를 전송할수록, 특정 사용자와 매칭될 가능성이 높아지고, 결과적으로 더 높은 이벤트 매치 점수를 얻게 됩니다.
귀하의 사이트에서 Facebook으로 사용자 매개변수를 전송하는 것은 민감한 주제입니다. 사용자 데이터를 타사 서비스와 공유하게 되기 때문입니다. 따라서 이 데이터를 Facebook에 전송하기 전에, 귀하의 개인정보 보호정책을 준수하는지 반드시 확인하십시오.
이상적으로는 사용자 데이터가 데이터 레이어에 추가되어 있어야 합니다. 이것이 불가능한 경우, 맞춤 JavaScript 코드를 사용하여 페이지에서 데이터를 수집하고, 관심 있는 전환이나 이벤트와 함께 전송하도록 시도해 보십시오.
예를 들어, CMS용 모든 Stape 플러그인(Shopify용 Facebook CAPI, WordPress 서버 측 트래킹, Magento 2 Google Tag Manager, BigCommerce용 GTM 앱)은 사용자 데이터도 포함하는 데이터 레이어를 추가합니다.
이를 데이터 레이어에서 쉽게 가져와 웹 컨테이너의 Facebook 이벤트에 추가할 수 있습니다.

그런 다음, 필요한 데이터를 서버 컨테이너로 전송합니다(사용 중인 것에 따라 페이로드의 GA4 또는 Data tag).

마지막으로, 이 데이터를 귀하의 서버 측 Facebook 이벤트에 추가합니다.

이러한 방식으로, 귀하의 Facebook 이벤트는 더 나은 매칭 품질을 달성하게 되며, Facebook이 귀하의 잠재고객을 더 잘 이해하고 광고 캠페인을 최적화함에 따라 광고 캠페인의 성과가 개선될 가능성이 있습니다.
기본적으로 태그는 GA 표준 이벤트를 Facebook 표준 이벤트로 매핑하려고 시도합니다. 매칭할 수 없는 경우, GA 클라이언트에서 전달된 원본 이벤트 이름이 사용됩니다. 예를 들어, gtag('event', 'UserLikedProduct')와 같은 이벤트 이름을 전송하면, Facebook 이벤트 관리자에서 UserLikedProduct라는 이벤트를 보게 됩니다.
아래는 저희가 이 태그에서 기본적으로 사용하는, GA 이벤트에서 Facebook 이벤트로의 매핑 체계입니다:
| page_view | PageView |
| add_payment_info | AddPaymentInfo |
| add_to_cart | AddToCart |
| add_to_wishlist | AddToWishlist |
| sign_up | CompleteRegistration |
| begin_checkout | InitiateCheckout |
| generate_lead | Lead |
| purchase | Purchase |
| search | Search |
| view_item | ViewContent |
| contact | Contact |
| customize_product | CustomizeProduct |
| donate | Donate |
| find_location | FindLocation |
| schedule | Schedule |
| start_trial | StartTrial |
| submit_application | SubmitApplication |
| subscribe | Subscribe |
1. 커뮤니티의 한 사용자는 Facebook 서버 측 트래킹으로 전환한 후, 리타겟팅 잠재고객이 GA4 트래픽보다 훨씬 작다(매칭률 약 15%)는 것을 발견했습니다. 문제는 트래킹이 고장 난 것이 아니라 비현실적인 기대치에 있었습니다. Facebook은 IP와 User Agent만으로는 사용자를 신뢰성 있게 매칭할 수 없습니다. 해결책은 Meta가 권장하는 하이브리드 설정(브라우저 + 서버, 중복 제거 포함)을 따르고, 가능한 경우 사용 가능한 모든 사용자 데이터(이메일이나 이름 등)를 전송하는 것이었습니다. 이 접근 방식은 매칭 품질과 잠재고객 규모를 개선하는 반면, 순수한 서버 측 트래킹만으로는 리타겟팅 잠재력이 제한됩니다.
2. 이 스레드에서 많은 사용자가 특히 타사 결제 페이지에서 Facebook 서버 측 트래킹 및 FBP/FBC 매핑 관련 문제를 겪고 있습니다. 퍼스트파티 서브도메인에서 Stape의 Facebook CAPI 템플릿을 사용하고, 메인 도메인에서 핵심 이벤트를 트리거하며, 중복 제거를 위한 하이브리드 브라우저+서버 이벤트를 구현하고, 선택적으로 webhook을 사용하면 대부분의 문제가 해결됩니다. Tag Assistant에만 의존하지 말고 항상 브라우저 네트워크 도구를 통해 데이터를 검증하십시오.
서버 측에서 시작하고 싶으신가요?
무료로 체험하기
댓글