클라이언트 측 태그 대신 서버 측 태그를 사용해야 하는 9가지 이유

서버 측 태깅과 클라이언트 측 태깅의 차이점 및 서버 측 태깅을 선호하는 이유

온라인 마케팅 및 웹 분석 분야에서는 서버 측 태깅과 클라이언트 측 태깅이라는 두 가지 주요 태깅 방식이 존재합니다. 최근 추세는 클라이언트 측 태깅보다 서버 측 태깅을 더 선호하는 쪽으로 기울고 있는데, 그 이유는 무엇일까요?

마케팅은 소비자의 행동을 이해하는 데서 시작됩니다. 하지만 이는 효과적인 데이터 수집과 추적 기술을 통해서만 실현될 수 있습니다.

본 문서에서는 태깅의 개념, 데이터 수집 및 추적에서 태깅이 갖는 중요성, 서버 측 태깅과 클라이언트 측 태깅의 차이점, 그리고 클라이언트 측 태깅 대신 서버 측 태깅을 선택해야 하는 이유에 대해 심층적으로 분석합니다.

태깅이란 무엇인가?

태깅은 웹사이트에 '태그'라고 불리는 작은 코드 조각을 삽입하는 과정을 말합니다. 이러한 태그는 사용자 상호 작용에 대한 데이터를 수집하고, 수집된 정보를 외부 분석 도구로 전송하거나, 특정 이벤트를 추적하는 데 사용됩니다.

태그를 활용하여 다음과 같은 작업을 수행할 수 있습니다.

• 웹 분석: 웹사이트 내 사용자 행동을 페이지 조회, 클릭, 양식 제출 등의 지표를 통해 추적합니다.
• 개인화: 사용자 행동이나 선호도에 기반하여 맞춤형 경험을 제공하기 위한 정보를 수집합니다.
• 리마케팅: 리마케팅 캠페인 대상을 설정하기 위한 데이터를 수집합니다.
• 전환 추적: 리드 양식 제출이나 구매 성공과 같은 전환 이벤트를 모니터링합니다.

이러한 태그는 서버 또는 클라이언트 측에 추가될 수 있습니다.

클라이언트 측 태깅

클라이언트 측 태깅은 태그가 클라이언트 측에서 처리되는 방식입니다. 웹사이트 또는 애플리케이션은 하나의 컨테이너를 가지며, 이 컨테이너에는 사용자 상호 작용을 측정하는 데 필요한 모든 태그, 변수, 트리거, 코드가 포함되어 있습니다.

사용자가 웹페이지에 접속하면 컨테이너가 활성화되고 관련 태그가 로드됩니다. 사용자의 활동은 브라우저에서 하나 이상의 HTTP 요청을 통해 이벤트 데이터를 전송하는 태그를 트리거합니다.

이미지 출처: developers.google.com

서버 측 태깅

서버 측 태깅은 태그가 서버에서 처리되는 방식입니다. 이 방식은 두 개의 컨테이너를 사용합니다.

• 클라우드 환경에 위치한 서버 컨테이너
• 애플리케이션/웹사이트에 위치한 웹 컨테이너

웹 컨테이너는 사용자 상호 작용 정보를 모니터링하고 전달하는 태그를 포함합니다. 이 컨테이너는 이벤트 정보를 HTTP 요청으로 생성합니다. 반면에 서버 컨테이너는 웹 컨테이너에서 보낸 요청을 받습니다.

최근 들어 많은 마케터들이 서버 측 태깅으로 전환하고 있습니다. 그렇다면 클라이언트 측 태깅은 더 이상 유효하지 않은 것일까요?

서버 측 태깅으로 전환하는 주요 이유는 다음과 같습니다.

성능 향상

서버 측 태깅은 실행되는 코드의 양을 줄여 속도와 성능을 개선합니다. 클라이언트 측 태깅에서는 각 이벤트가 브라우저에서 여러 개의 HTTP 요청으로 매핑됩니다. 이로 인해 클라이언트가 불필요하게 많은 요청을 보내 클라이언트 리소스에 과부하가 걸릴 수 있습니다.

반면, 서버 측 태깅은 클라이언트가 이벤트당 하나의 HTTP 요청만 생성합니다. 이 요청은 서버 컨테이너로 전송되고, 서버 컨테이너는 개별 요청을 생성하여 전달합니다. 결과적으로 HTTP 요청 수가 줄어들고 실행되는 코드 양이 감소하여 속도가 향상됩니다.

개인 정보 보호, 안전 및 보안

클라이언트 측 태깅은 브라우저와 제3자 간에 어떤 데이터가 공유되는지 제어하기 어렵게 만듭니다. 개인 식별 정보가 HTTP 요청을 통해 공유될 위험이 존재합니다.

반면, 서버 측 태깅은 제3자와 공유할 데이터를 더 세밀하게 제어할 수 있게 해줍니다. 서버 컨테이너를 통해 개인 식별 정보를 마케팅 플랫폼에 전달하기 전에 삭제할 수 있습니다. 따라서 관련 데이터와 현행 데이터 규정을 준수하는 데이터만 공유할 수 있습니다.

서버 컨테이너에서 퍼스트 파티 컨텍스트를 설정할 수도 있습니다. 모든 웹사이트 데이터와 쿠키를 자신의 도메인에 유지함으로써 제3자 쿠키에 대한 접근을 어렵게 만들 수 있습니다.

정확성

모든 서버 측 프로세스는 브라우저 외부에서 처리됩니다. 따라서 외부 공급업체로 전송되는 데이터의 유효성과 일관성을 확보하기가 용이합니다. 클라이언트 측 처리 과정에서 장치나 브라우저 문제로 인해 이벤트 데이터에 불일치가 발생할 수 있지만, 서버 측 태깅은 이를 완벽하게 보정하여 일관성을 유지합니다.

또한, 서버 측 태깅은 데이터 손실 위험을 줄이는 데도 효과적입니다. 서버에서 태깅을 처리하는 과정에서 데이터의 유효성을 검증하고, 외부 공급업체가 설정한 기준을 충족하는지 확인할 수 있습니다. 서버 측 태깅은 브라우저나 애플리케이션이 삽입했을 수 있는 불필요하거나 중복된 데이터를 제거하는 역할도 합니다.

광고 차단 저항

기업은 사용자 선호도와 개인 정보를 존중해야 합니다. 하지만 일부 광고 차단기는 마케팅과 무관한 도구까지 차단하는 경우가 있습니다. 사용자 경험을 개선하기 위한 쿠키나 사용자 행동을 분석하기 위한 웹 분석 등이 그 예입니다.

사용자 지정 도메인과 서버 측 구현을 활용하면 광고 차단기의 영향을 받지 않고 데이터를 전송할 수 있습니다. 서버 측 태깅은 퍼스트 파티 데이터로 간주되므로 더 이상 제3자 도메인에 의존할 필요가 없습니다.

더 나은 캠페인 관리

서버 측 태깅은 안정적인 데이터 수집 환경을 제공하여 데이터 불일치를 줄여줍니다. 그 결과, 마케터는 정확한 데이터 수집, 전환 추적 및 마케팅 활동에 대한 더 깊은 통찰력을 얻을 수 있습니다.

모든 픽셀과 태그를 중앙 위치에서 통합 관리할 수 있어, 분석 및 마케팅 태그를 보다 쉽게 관리, 구현 및 업데이트할 수 있습니다.

사용자 입력 제어

서버 측 태깅은 애플리케이션이 사용자 입력을 더욱 효과적으로 제어할 수 있게 해줍니다. 사용자 입력을 처리하기 전에 유효성을 검사하고 불필요한 부분을 삭제할 수 있습니다. 이는 XSS 공격(교차 사이트 스크립팅) 또는 SQL 삽입과 같이 악의적인 코드가 처리될 가능성이 있는 상황에 유용합니다.

단계적으로 폐지되는 제3자 쿠키를 통한 미래 대비

기술 환경은 끊임없이 변화하고 있습니다. 과거에 널리 사용되었던 제3자 쿠키는 점차 사라지고 있습니다. 제3자 쿠키는 사용자가 방문하는 웹사이트가 아닌 다른 웹사이트나 애플리케이션에 의해 생성되고 사용자의 장치에 저장됩니다. 개인 정보 보호 문제가 중요하게 부각되면서 제3자 쿠키를 단계적으로 폐지하는 것이 한 가지 해결책으로 제시되었습니다.

간편한 업데이트 및 패치

서버 측 태그 코드를 업데이트하는 것은 개발자에게 매우 쉽습니다. 서버 측 태그를 쉽게 업데이트할 수 있어, 추적 도구가 항상 최신 상태로 유지됩니다. 업데이트를 자동화하여 서버 측 태그를 항상 최신 상태로 유지할 수도 있습니다.

반면, 클라이언트 측 태그는 브라우저나 기기를 수동으로 업데이트해야 합니다. 또한 클라이언트 측 태그 업데이트는 브라우저 확장 프로그램이나 광고 차단기에 의해 차단될 수도 있습니다.

확장성

클라이언트 측 태깅은 서버 측 태깅에 비해 확장성이 떨어집니다. 클라이언트 측 태깅은 사용자 브라우저를 통해 실행되기 때문에 페이지 로드 시간이 과부하되거나 느려질 수 있습니다. 반면, 서버 측 태깅은 대량의 데이터를 보다 효율적으로 처리할 수 있습니다. 또한 애플리케이션/웹사이트의 성장에 따라 태그를 조정할 수 있습니다. 서버 측 태그는 광고 차단 프로그램의 영향을 받지 않아 데이터 수집의 정확성도 보장합니다.

서버 측 태깅의 제한 사항

서버 측 태깅에는 여러 가지 장점이 있지만 다음과 같은 제한 사항도 존재합니다.

• 복잡한 구현: 서버 측 태깅을 구현하려면 기술 지식이 필요할 수 있습니다. 따라서 개발자 및 IT 팀과의 협력을 통해 서버 구성을 수정해야 할 수도 있습니다.
• 사용자 행동 추적 감소: 서버 측 태깅은 클라이언트 측 태깅만큼 개별 행동에 대한 자세한 정보를 제공하지 못할 수 있습니다.
• 개발자에 대한 의존성: 서버 측 태그 코드를 추가하는 작업은 개발자에게 의존해야 할 수 있습니다. 반면에 클라이언트 측 태깅은 플러그인을 사용하여 기술 지식이 없는 사람도 쉽게 구현할 수 있습니다.

서버 측 및 클라이언트 측 태깅 비교

서버 측 구현 모범 사례

• 일관된 데이터 레이어 설계: 분석 플랫폼으로 전송해야 하는 정보를 정의하는 명확하고 구조화된 데이터 레이어를 만듭니다. 데이터 레이어 내의 명명 규칙 또한 일관되게 유지해야 합니다.
• 데이터 유효성 검사: 유효한 데이터만 분석 서버로 전송되도록 유효성 검사 프로세스를 설정합니다.
• 보안 통신 구현: HTTPS와 같은 프로토콜을 사용하여 서버와 분석 플랫폼 간에 데이터를 안전하게 전송합니다. 이는 데이터가 외부로 유출되어 악의적인 목적으로 사용되는 것을 방지합니다.
• 개인 정보 보호 규정 준수: 데이터 개인 정보 보호는 중요한 문제입니다. GDPR 및 CCPA와 같은 데이터 규정을 준수해야 합니다. 또한 사용자 활동을 추적하기 전에 사용자 동의를 얻고 데이터 처리 방법을 투명하게 알려주어야 합니다.
• 모니터링 및 로깅: 서버 측 태그의 성능을 추적하기 위한 도구를 설정합니다. 감사 목적으로 중요한 정보와 이벤트를 기록하는 로깅 도구를 사용하는 것도 좋습니다.

결론

이제 마케팅 및 분석 분야에서 서버 측 태깅이 클라이언트 측 태깅을 대체하는 이유를 이해하게 되었습니다. 클라이언트 측 태깅이 구현하기 쉽다는 장점은 있지만, 미래 대비, 경제성, 광고 차단 저항 등 다양한 장점으로 인해 대부분의 마케터는 서버 측 태깅을 선호합니다. 또한 서버 측 태깅은 데이터 제어 능력을 향상시켜 분석 알고리즘에 제공할 정보를 직접 결정할 수 있도록 해줍니다.

다음 단계로 자체 호스팅 오픈 소스 웹 분석 플랫폼을 살펴보는 것도 좋은 방법입니다.