태그 관리자 및 CDP

1. 두 계층, 하나의 개념

태그 관리자는 페이지에서 실행할 도구를 결정합니다. 고객 데이터 플랫폼은 이후 이벤트가 전달될 곳을 결정합니다. 둘 다 웹사이트와 기술 스택 사이에 있으며, 녹화가 있다는 정보를 전달할 만한 대상입니다.

브리지는 사용하는 쪽에 재생 링크를 기록합니다. 그러면 그 뒤에 연결된 분석, 웨어하우스, 마케팅 자동화 등의 도구가 각각 별도 연동 없이 링크를 전달받을 수 있습니다.

2. 각 도구가 실제로 받는 방식

이 여섯 도구는 같은 범주라는 인상보다 훨씬 다릅니다. 단순한 방식의 차이가 아닙니다. 각 도구는 다른 도구가 요구하는 형식을 거부합니다.

도구	값을 받는 방식
Tealium	utag.link 를 사용하며 utag_data는 사용하지 않음. 페이지 로드 시에만 읽기 때문
Adobe Launch	Client Data Layer를 통해 전달. _satellite 에는 공개 쓰기 API가 없음
Commanders Act	tc_vars 사용. 이 객체가 없으면 생성하지 않음 . 객체가 없다는 것은 TagCommander가 없다는 뜻이기 때문
Segment	analytics.identify 에 트레이트를 전달
RudderStack	같은 형태, 자체 전역 객체 사용
Snowplow	전역 컨텍스트 사용. 콜백으로 응답하므로 값을 버퍼에 보관
JENTIS	_jts.push 에 다음을 포함: track: "event". 맞춤 필드 이름을 사용할 수 있으며, track 및 type 만 예약됨

JENTIS는 로드 순서 규칙의 예외입니다. 설치 스니펫은 window._jts = window._jts || []를 생성합니다. 이로써 _jts 는 대기열이 되므로 push한 값은 라이브러리가 로드되어도 유지되며 사라지지 않습니다. 따라서 4절의 순서 설명은 이 도구에 적용되지 않습니다. 그래도 대기열이 없으면 생성하지 않습니다. Commanders Act와 같은 이유입니다. 없다는 것은 JENTIS가 설치되지 않았다는 뜻이며, 임의로 만든 _jts 는 아무도 이행하지 않을 약속이기 때문입니다.

짚고 넘어가야 할 Tealium의 실수

Tealium의 utag_data 에 값을 쓰면 올바르게 보이지만 아무 일도 일어나지 않습니다. Tealium은 페이지가 로드될 때 이 객체를 한 번만 읽고, 당사의 값은 그 뒤에 도착하기 때문입니다. utag.link 가 실행 중인 Tealium에 도달하는 호출이며, 당사가 사용하는 것도 이 호출입니다.

3. 하지 않는 일

데이터 레이어를 만들지 않습니다

페이지에 Commanders Act가 없다면 tc_vars 도 없습니다. 당사는 그대로 둡니다. 이를 만들면 페이지의 다른 모든 스크립트가 설정된 TagCommander로 오인하는 객체가 생깁니다. 아무것도 하지 않는 것보다 나쁜 결과입니다.

직접 아무것도 전송하지 않습니다

태그 관리자나 CDP는 자체 설정과 계약에 따라 값을 전달합니다. 당사 측에서는 로컬 객체에 값을 쓰는 것뿐입니다. 브라우저 밖으로 나가는지, 누구에게 전달되는지는 사용자의 도구에서 결정합니다. 이 수신자들이 당사의 처리 활동 기록에 포함되지 않는 이유도 여기에 있습니다.

무한히 재시도하지 않습니다

0.5초 간격으로 20번 시도한 뒤 멈춥니다. 10초 동안 나타나지 않은 태그 관리자는 이후에도 나타나지 않을 것입니다.

4. 순서에 관한 참고

태그 관리자는 설계상 일찍 로드되고, CDP는 보통 나중에 로드됩니다. MousePlayer는 삽입 방식에 따라 그 사이 어딘가에 놓입니다. 따라서 브리지는 한 번만 읽는 대신 반복 확인합니다.

로드 순서를 제어할 수 있다면 당사 스니펫보다 태그 관리자를 앞에 두어 대기 시간을 없앨 수 있습니다. 다만 반드시 필요한 조건은 아니며, 당사를 위해 페이지를 재배치하도록 요구하지 않습니다.