온라인 광고의 지속적인 발전과 함께 새로운 어려움이 등장합니다. 그 중 하나가 서버 측 추적으로, 사용자 브라우저 대신 클라우드 서버를 사용하여 웹사이트에서 사용자 행동을 모니터링하는 도구입니다. 이 도구는 2020년에 등장하여 상대적으로 새롭고, 아직 많은 사람들이 정확히 다루지 않았습니다.
따라서 새로운 마케팅 활동을 시작하고 소셜 미디어에서 광고를 집행하기로 결정했다면, 이 새로운 추적 방법에 대해 알아야 합니다. 서버 측 세계의 초보자를 위해 이 블로그를 만들기로 결정했습니다. 여기에서 서버 측 추적의 이점, 서버 측 태깅을 지원하는 가장 인기 있는 플랫폼에 대한 간략한 개요, 다양한 사용 사례에 대한 논의 및 sGTM을 위한 Stape 서버의 장점을 배울 수 있습니다.
오늘날 많은 조직들처럼 일관성 없는 분석 데이터에 불만이거나 데이터 소유권 및 개인정보 보호에 대해 걱정한다면, 서버 측 추적은 몇 가지 문제를 해결하는 데 도움이 될 수 있습니다. 그러니 그 작동 방식에 대해 자세히 알아보겠습니다.
서버 측 태깅을 통해, 데이터는 클라우드 서버를 통해 추적 플랫폼과 타사 벤더 간에 공유됩니다. 사용자의 브라우저 사용을 제거합니다. 서버 컨테이너는 당신의 통제 하에 클라우드 서버에서 운영됩니다.
서버 Google Tag Manager 컨테이너의 도입은 서버 측 태깅의 인기에 상당한 영향을 미쳤습니다. sGTM 인터페이스를 사용하여 가장 인기 있는 플랫폼에 대한 서버 간 추적을 구현할 수 있습니다. 또한 웹 GTM을 서버 GTM 컨테이너의 데이터 소스로 사용할 수 있습니다. 웹과 서버 Google Tag Manager를 연결할 수 있습니다. 서버 GTM에 데이터를 제공하기 위해 Google Analytics 4 또는 Data Tag/Data Client를 사용할 수 있습니다.
웹(클라이언트 측 태깅)과 유사해 보이지만, 서버 GTM 컨테이너는 완전히 다른 논리로 운영되는 서버 측 추적을 사용합니다.
클라이언트 측 추적은 전통적인 추적 형태로, 분석 제공업체가 사용자의 브라우저와 직접 소통합니다. 추적 태그가 활성화되고, 컨테이너가 페이지 로드와 동시에 로드되며, 모든 상호작용 데이터가 분석 제공업체에 전달됩니다. 이는 페이지가 과부하되고, 페이지 속도가 급격히 감소하며, 보안 및 타사 쿠키와 관련된 문제가 발생한다는 것을 의미합니다.
이때 서버 측 태깅이 구원자로 나섭니다! 서버 측 추적은 ITP, iOS 제한, AdBlocker로 인한 데이터 손실을 관리하고, 웹사이트를 가속화하며, 데이터를 보호할 수 있습니다. 서버 측 추적을 위한 사용자 정의 하위 도메인 사용은 퍼스트 파티 쿠키와 서버 측 데이터 스트림을 생성하는데, 이는 차단되거나 발견될 수 없습니다. 이 모든 것의 근본적인 이유입니다.
추적 상호작용은 브라우저와 타사 서비스 간에 발생합니다. 하지만 서버 측 추적에서는 중간 지점이 추가됩니다. 즉, 클라이언트 브라우저 대신 클라우드 서버가 요청을 처리합니다. 이 경우, Google Tag Manager 클라우드 서버입니다. 요청은 먼저 클라우드 서버로 가고, 그 다음 서버가 처리하여 타사 시스템에 보냅니다.
우리는 다른 플랫폼보다 서버 Google Tag Manager를 선호합니다. GTM으로 전환하는 주요 이점은 우리의 의견으로는 다음과 같습니다:
웹사이트에서 서버 측 Google Tag Manager 태깅을 설정하려면 이 블로그를 방문하세요.
Stape를 사용하면 1분 이내에 서버 GTM을 설정할 수 있으며, 시장에서 가장 저렴한 솔루션입니다. Stape는 대량으로 서버를 구입하고 장기간 사용하기 때문에 저렴합니다. 또한, Google Tag Manager만을 위해 서버를 최적화합니다.
또한, 다음과 같은 다른 이점이 있습니다:
1. Custom gtm.js and gtag.js loader. 이는 Google Tag Manager 및/또는 Analytics 4 스크립트를 차단기에 더 저항력 있게 만들어줍니다.
2. Global CDN. 사이트 방문자에게 더 가까운 서버를 사용하여 더 빠른 js 파일 제공을 가능하게 합니다. 이는 페이지 속도 개선으로 인해 유기적 순위에 긍정적인 영향을 미칠 수 있습니다.
3. Logs. 서버 측 태깅 설정이나 문제 해결 시 유용한 기능입니다. 서버로 보낸 데이터와 그 처리 방법을 파악하는 데 도움이 됩니다. 예를 들어, 모든 구매 이벤트가 200 상태(정확하게 처리됨)인지 확인하거나 500 응답 코드를 가진 모든 요청을 확인할 수 있습니다.
4. Preview header. 웹 GTM에서 요청이 보내지지 않았을 때 sGTM 디버거에서 모든 들어오는 요청을 볼 수 있도록 도와줍니다.
이 블로그 게시물에서 모든 것에 대해 자세히 알아볼 수 있습니다.
고용량 웹사이트의 경우, 맞춤형 요금제를 제공합니다. 가격 계산기를 사용하여 사이트에 가장 적합한 요금제를 추정할 수 있습니다.
모든 구성 사이에서 길을 잃은 새로운 사용자라면, 아래에서 서버 측 태깅을 시작하는 방법에 대한 필수 목록을 찾을 수 있습니다.
서버 측 태깅을 시작할 때 첫 번째 단계는 sGTM 컨테이너를 구성하는 것입니다. Stape를 사용하면 한 번의 클릭으로 sGTM 컨테이너를 위한 태깅 서버를 설정할 수 있습니다. 필요한 것은 다음과 같습니다:
1. https://tagmanager.google.com/ 에 로그인하세요.
2. 새 컨테이너를 생성하세요.
3. 컨테이너 이름을 추가하고 대상 플랫폼으로 서버를 선택한 다음 생성을 클릭하세요.
4. 태깅 서버 수동 프로비저닝을 선택하세요.
5. C컨테이너 구성을 복사하세요.
6. app.stape.io 계정에 로그인하세요.
7. 컨테이너 생성을 클릭하세요.
8. 컨테이너 이름을 추가하고, Google Tag Manager에서 복사한 컨테이너 구성을 붙여넣고, 서버 위치를 선택하세요. 웹사이트 방문자에게 더 가까운 서버 위치를 선택하는 것이 좋습니다.
9. 이 단계는 선택 사항이지만 매우 권장됩니다. 태깅 서버에 대한 사용자 정의 도메인을 설정하고 CDN을 활성화할 수 있습니다. 사용자 정의 도메인은 퍼스트 파티 쿠키를 설정하는 데 도움이 되며, 글로벌 CDN은 사용자 위치에 더 가까운 서버에서 js 파일을 제공합니다. 글로벌 CDN을 활성화하기 전에 국가 추적 정책을 확인하세요.
10. 이 두 가지(또는 그 중 하나)를 활성화한 후에는 DNS 설정을 업데이트해야 합니다. Stape 계정에서 컨테이너의 DNS 설정을 찾을 수 있습니다.
11. 생성을 클릭하세요. 컨테이너를 배포하는 데 약 10분이 걸릴 수 있습니다. 컨테이너 상태가 실행 중이면 서버 측 태깅 설정을 계속할 수 있습니다.
12. 서버 Google Tag Manager 컨테이너 설정을 열고 서버 컨테이너 URL을 추가하세요. 9단계에서 사용자 정의 도메인을 설정했다면 서버 컨테이너 URL을 구성할 때 사용합니다. 9단계에서 사용자 정의 도메인을 구성하지 않았다면, 우리가 app.stape.io에서 생성한 태깅 서버 URL을 복사할 수 있습니다.
13. 9단계에서 사용자 정의 도메인을 설정했다면, 사이트의 GTM 스크립트를 업데이트하는 것이 매우 권장됩니다. tag manager.google.com을 대체하기 위해 사용자 정의 도메인을 사용하세요.
서버 Google Analytics 4 설정은 UA 설정과 유사합니다:
1. Google Tag Manager 서버 컨테이너로 이동하세요. 클라이언트를 클릭하고 Google Analytics 4 클라이언트를 추가하세요.
2. 서버 컨테이너 내에서 GA4 태그를 생성하세요. 태그 -> 새로 추가 -> GA4를 선택하세요.
3. 이전 단계에서 생성한 태그에 대한 트리거를 생성하세요. GA4 트리거는 클라이언트 이름이 GA4와 같아야 합니다.
4. Google Tag Manager 서버 컨테이너의 디버그 모드를 열고 서버에서 GA4가 작동하는지 확인하세요. 서버 디버거가 웹보다 업데이트하는 데 더 오래 걸린다는 점에 유의하세요. 설정을 두 번 확인하기 위해 콘솔을 열고 Google 분석 요청을 확인하세요. 모든 설정이 완료되면 변경 사항을 게시하는 것을 잊지 마세요.
광고 캠페인의 성능을 검토하고 Google의 머신 러닝 알고리즘에 회사 목표에 대한 추가 정보를 제공하기 위해서는 Google Ads 전환 추적이 필요합니다. Adwords 태그를 서버로 이동하면 웹페이지에서 실행되어야 하는 코드 양이 줄어들고, 느린 인터넷 연결에 대한 성능 문제도 해결할 수 있습니다!
서버 측 Google Ads 추적은 서버 측 Google Analytics 4 요청을 사용하여만 작동합니다. 이는 서버-서버 Google Ads로 진행하기 전에 서버 측 Google Analytics 4를 설정해야 함을 의미합니다.
서버 Google Ads 설정 방법은 다음과 같습니다:
1. 서버 측 Google Analytics 4가 올바르게 설정되었는지 확인하세요.
2. 서버 컨테이너에서 Conversion Linker 태그를 설정하세요. 이 태그는 모든 페이지뷰에서 트리거되어야 합니다.
3. 서버 GTM에서 Google Ads 리마케팅 태그를 설정하세요. 웹 리마케팅 태그 설정과 유사합니다. Conversion ID를 추가하고 GA4 요청을 사용해야 하는 트리거를 선택해야 합니다. 동적 리마케팅 이벤트 데이터를 보내고 사용자 지정 매개변수를 제공하기로 결정할 수도 있습니다.
4. 서버 컨테이너에서 새로운 Google Ads 전환 추적 태그를 생성하세요 -> 웹 Adwords 태그 설정과 유사하게 Conversion ID와 Conversion Label을 추가하세요. 그런 다음 제품 및 사용자 데이터를 추가할 수 있는 옵션이 있습니다. (Facebook 전환 API 작동 방식과 매우 유사합니다). 웹에서 서버로 사용자 및 제품 데이터를 보내는 경우, 이 체크박스를 활성화하고 데이터 소스로 이벤트 데이터를 선택할 수 있습니다. 제 Adwords 서버 전환은 구매 이벤트에서 트리거됩니다.
Google 플랫폼과 달리, Facebook은 웹 및 서버 추적을 모두 사용할 것을 권장합니다. 웹+서버 방법의 주요 장점은 가능할 때마다 서드 파티 쿠키를 계속 사용한다는 것입니다. 서버 전용 접근 방식의 주요 이점은 사이트에서 서드 파티 자바 스크립트의 수를 줄이고 FB에 전송된 데이터를 엄격히 제어할 수 있다는 것입니다. 따라서 웹+서버 FB 추적을 사용할지 서버 전용을 사용할지는 당신의 결정에 달려 있습니다.
FB CAPI 설정은 이벤트 중복 제거(웹+서버 방법 사용 시), 이메일, 전화번호, 이름 등과 같은 사용자 매개변수 전송이 필요하기 때문에 더 복잡합니다.
Facebook 전환 API 설정 방법에 대한 자세한 내용은 블로그 게시물을 방문하거나 Google Analytics 4를 사용한 Facebook 전환 API에 대한 비디오를 시청하세요.
이 시점까지 서버 측 추적이 귀하의 마케팅 캠페인에 필수적이라는 데 동의하시길 바랍니다. 하지만 여전히 상대적으로 새로운 기술이며 모든 플랫폼이 제공하지 않는 경우도 있습니다(예: Twitter). 따라서 서버 GTM을 지원하는 모든 벤더의 목록을 만들고 그들의 요구 사항, 지침 및 문서를 통합했습니다.
클라이언트가 사용하는 서버 측 추적에 대해 가장 인기 있는 플랫폼은 다음과 같습니다:
이 블로그 게시물에서 앞서 설명한 서버 측 추적의 직접 구현 외에도, 서버 측 추적은 웹 추적에서 사용할 수 없거나 구현하기 어려웠던 몇 가지 고급 기능을 제공합니다. 여기에서 가장 인기 있는 몇 가지 기능을 다룰 것입니다.
CRM에서 sGTM으로 웹훅을 제공하는 것이 가능합니다. sGTM 내에서 웹훅 데이터를 검색하고 어떤 플랫폼에든 추가할 수 있습니다. 예를 들어, 사용자 매개변수 또는 오프라인 이벤트로 Facebook Conversion API 데이터를 풍부하게 만들거나 POS에서 Google Analytics로 매장 주문을 보내거나 환불을 추적할 수 있습니다.
Firestore는 문서의 컬렉션을 저장하는 데이터베이스입니다. sGTM을 사용하면 Firestore에서 데이터를 읽고 쓸 수 있습니다. sGTM과 Firestore는 데이터 풍부화 측면에서 무한한 기회를 제공합니다. Firestore에 데이터를 읽고/쓰는 방법에 대한 자세한 가이드가 있습니다.
Stape는 sGTM과 Google 시트를 통합할 수 있는 사용자 정의 태그를 만듭니다. 사이트의 데이터를 Google 시트로 추적하기 위해 Zapier와 유사한 도구를 사용하는 사람들에게 훌륭한 기회입니다. Zapier와 같은 도구는 비용이 많이 들 수 있지만, sGTM을 사용하면 거의 0원에 가까운 가격으로 동일한 통합을 얻을 수 있습니다. sGTM용 Google 시트 태그에 대한 이 기사를 확인하세요.
이것들은 가장 인기 있는 비표준 sGTM 사용 사례의 상위 3가지이지만, 블로그 게시물에 더 많은 기사가 있습니다.
여기에서는 서버 측 태깅의 가장 일반적인 사용 사례를 개요로 설명하겠지만, 여기에서 찾을 수 있는 많은 다른 가능성들이 있다는 것을 잊지 마세요. 서버 측 추적의 영향과 구현 방식에 따라 데이터를 보는 방식이 어떻게 달라질 수 있는지 유의하세요. 부실한 통합으로 결과가 더 나빠질 수도 있습니다.
서버 측 추적은 새로운 기술에 의존하기 때문에 복잡한 주제이므로, 그것을 구현하는 사람이 모든 힌트를 올바르게 수행하는지 확인하세요.
서버 측 추적 설정에 도움이 필요하다면 Stape가 해결할 수 있습니다! 몇 가지 질문을 남겨주시면 다음 영업일 내에 연락 드리겠습니다.
사용자 정의 로더는 Stape가 고객에게 제공하는 가장 뛰어나고 인기 있는 기능 중 하나입니다. 사용자 정의 로더를 사용하면 추적을 Ad Blocker에 저항력 있게 만들 수 있습니다.
연구에 따르면, 인터넷 사용자의 약 25%가 광고 차단기를 설치했으며, 이는 사용자 데이터의 약 25%를 잃을 수 있음을 의미합니다. 물론, 이는 사용자 인물과 국가에 따라 달라질 수 있습니다.
사용자 정의 로더 파워 업을 설정하고 서버 측 GA4를 사용하여 FB CAPI를 설정한다고 가정해 보겠습니다. Stape 사용자 정의 로더 파워업은 gtag.js 및 gtm.js를 광고 차단기에 보이지 않게 만듭니다. 광고 차단기가 활성화된 사용자가 사이트에 접속하는 경우, GTM 및 GA4뿐만 아니라 FB도 데이터를 추적할 수 있습니다.
서버 측 추적과 사용자 정의 로더를 활성화하면 웹사이트 방문자에 대한 데이터를 최대 30% 더 추적할 수 있습니다.
Facebook은 광고주가 CAPI를 구현하도록 권장하며, 이는 획득 비용을 줄이고 측정을 개선하는 데 도움이 될 것입니다.
Facebook 전환 API의 캠페인 결과에 미치는 영향은 구현의 정확도와 정밀도에 크게 의존합니다. Facebook은 최대 결과를 얻기 위해 다음과 같은 모범 사례를 사용할 것을 권장합니다:
이는 FB가 사용자 지정 및 유사한 관객을 위한 품질 데이터를 가질 수 있음을 의미합니다. 또한 FB 광고 관리자에서의 전환 속성을 더 정확하게 만듭니다. 이 모든 모범 사례가 구현되면, 고객은 FB 이벤트 관리자에서 최대 98%의 전환을 볼 수 있습니다.
Klaviyo 서버 측 통합은 표준 Klaviyo 구현과 동일한 기능을 제공하지만, 주요 이점은 ss Klaviyo가 사이트 속도를 늦추지 않는다는 것입니다.
일부 클라이언트의 경우, Klaviyo 자바스크립트를 사이트에서 제거하면 페이지 속도 점수가 7점 향상되었습니다.
서버 측 추적을 구현하는 이상적인 스키마는 sGTM에 대한 하나의 주요 데이터 소스를 가지고 있고, 그것을 사용하여 모든 플랫폼에 대한 ss 추적을 설정하는 것입니다.
이 시나리오에서는 사이트에서 모든 불필요한 타사 추적 스크립트를 제거할 수 있습니다. 서버 측 추적이 페이지 속도에 미치는 영향에 대한 사례 연구가 있는 기사가 있습니다.
서버 측 추적을 설정하는 것은 웹사이트의 성능을 향상시키고 더 정확한 데이터를 얻는 데 도움이 됩니다. 처음에는 다소 어려울 수 있지만, 이 가이드를 통해 어려움 없이 시작할 수 있어야 합니다.
이 블로그 게시물에서는 서버 측 추적을 시작하는 데 필요한 일반적인 정보를 모았습니다. 여기에서 가능한 모든 가이드와 사용 사례를 다루었습니다. 태그의 세계로 뛰어들 수 있도록 도와드릴 수 있으니 support@stape.io로 문의 주시기 바랍니다. 귀하의 필요를 이해하고 있으며 도움을 드릴 수 있습니다.
몇 가지 간단한 질문만 있으면 됩니다. 견적 받기를 클릭하여 양식을 작성하시면, 견적을 보내드리겠습니다.
