GA4·Google Tag Manager 권한 감사 체크리스트 2026, 광고 전환 추적을 대행사와 연결하기 전 기준
GA4·Google Tag Manager 권한 감사 체크리스트 2026, 광고 전환 추적을 대행사와 연결하기 전 기준
광고 전환 추적이 맞지 않으면 가장 먼저 열어 보는 곳이 Google Analytics 4와 Google Tag Manager입니다. Google Ads 전환이 안 잡히고, 구매 완료 이벤트가 중복되고, 랜딩페이지별 전환율이 다르게 보이고, Consent Mode 설정을 바꿔야 할 때도 결국 GA4 property와 GTM container 권한을 만지게 됩니다.
문제는 이 권한이 생각보다 큽니다. 대행사, 프리랜서, 개발자, 마케터에게 "잠깐만 권한을 열어 주세요"라고 했다가 publish 권한까지 넘어가면 태그, 전환 이벤트, Google Ads 연결, Consent Mode, 외부 스크립트가 바뀔 수 있습니다. 광고 계정 자체보다 덜 위험해 보이지만, 실제로는 매출 측정과 개인정보 동의 흐름, 애드센스·광고 로딩, 사이트 속도까지 건드릴 수 있는 운영 권한입니다.
이 글은 법률 자문이나 개인정보보호 컨설팅이 아닙니다. 광고 성과, 전환율, 수익 개선을 보장하지도 않습니다. 작은 팀이 GA4와 Google Tag Manager 권한을 외부 파트너와 연결하기 전 실수를 줄이기 위한 운영 체크리스트입니다. 실제 적용 전에는 회사 정책과 Google 공식 문서, 지역별 규정, 내부 개인정보 처리 기준을 다시 확인해야 합니다.
공식 문서 확인 기준은 2026년 6월 24일입니다.
먼저 결론부터 보면
GA4와 Google Tag Manager 권한을 열기 전에는 아래 12개 질문에 답해야 합니다.
| 항목 | 확인 질문 |
|---|---|
| 권한 목적 | 전환 태그 수정, GA4 이벤트 확인, Google Ads 연결 중 무엇이 목적인가 |
| GA4 property | property 단위 권한인지 account 단위 권한인지 구분했는가 |
| GTM container | container 읽기, 편집, 승인, 게시 권한을 나눴는가 |
| publish 권한 | 외부 파트너에게 바로 게시 권한이 필요한가 |
| Google Ads 연결 | 연결된 광고 계정과 전환 가져오기 범위를 확인했는가 |
| Consent Mode | 동의 설정 변경은 별도 승인 절차를 두었는가 |
| 변경 로그 | 누가 언제 어떤 태그와 trigger를 바꿨는지 볼 수 있는가 |
| 외부 스크립트 | 새 script, iframe, pixel, custom HTML 태그를 검토하는가 |
| 테스트 절차 | preview, debug, staging 확인 없이 publish하지 않는가 |
| 회수 기준 | 작업 종료일과 권한 회수 담당자가 정해져 있는가 |
| 내부 문서 | 전환 이벤트 이름, owner, 광고 연결 목적을 남기는가 |
| 재점검 | 월 1회 이상 외부 사용자와 publish 권한을 다시 보는가 |
고객 목록 업로드나 맞춤 타깃 운영 기준은 AI 광고 오디언스 동기화 보안 체크리스트에서 다뤘습니다. 이번 글은 고객 목록이 아니라 GA4 property, GTM container, 전환 태그, Consent Mode, 대행사 권한에 집중합니다.
마케팅 자동화 도구와 CRM을 함께 연결한다면 AI 마케팅 자동화 보안 체크리스트도 같이 봐야 합니다. 새 SaaS 도구를 도입하는 절차 자체는 SaaS 구매 승인 체크리스트와 이어집니다.
GA4 권한은 account와 property를 구분해야 함
Google Analytics 도움말은 사용자를 Analytics account 또는 property 단위로 추가하고, 역할과 데이터 제한을 관리할 수 있다고 안내합니다. 작은 팀은 여기서 account와 property를 자주 혼동합니다. 특정 사이트의 GA4 property만 봐야 하는 사람에게 account 전체 권한을 주면 다른 property까지 보거나 설정을 바꿀 수 있습니다.
참고: Google Analytics Help – Access management
GA4 권한을 줄 때는 아래 표부터 봅니다.
| 권한 항목 | 실무 기준 |
|---|---|
| account 권한 | 여러 property를 관리하는 내부 관리자에게만 부여 |
| property 권한 | 특정 사이트나 앱 작업자에게 우선 적용 |
| viewer | 리포트 확인만 필요한 대행사, 콘텐츠 담당자 |
| analyst | 탐색 분석과 리포트 분석이 필요한 담당자 |
| editor | 이벤트, conversion, 설정 변경이 필요한 실무자 |
| administrator | 내부 owner 또는 장기 관리 책임자 중심으로 제한 |
| 데이터 제한 | 비용, 수익, 사용자 데이터 제한 필요 여부 확인 |
GA4 권한은 "보고서만 볼 사람"과 "설정을 바꿀 사람"을 분리해야 합니다. 전환 추적 오류를 고치는 작업이라도 처음부터 administrator를 줄 필요는 없습니다. 작업 목적이 전환 이벤트 확인인지, Google Ads 연결인지, property 설정 변경인지 먼저 나누는 편이 안전합니다.
Google Tag Manager 권한은 publish를 따로 봐야 함
Google Tag Manager 도움말은 account와 container의 사용자 권한을 관리할 수 있고, container 권한에는 읽기, 편집, 승인, 게시 같은 단계가 있다는 점을 안내합니다.
참고: Google Tag Manager Help – User permissions
GTM에서 가장 조심해야 할 권한은 publish입니다. 편집 권한은 태그를 만들 수 있지만, publish 권한은 실제 사이트에 반영할 수 있습니다. 외부 script, 광고 tag, 전환 tag, A/B 테스트 script, consent 관련 tag가 바로 live로 나갈 수 있으므로 publish는 내부 owner가 잡는 편이 좋습니다.
| GTM 권한 | 허용 기준 |
|---|---|
| Read | 현재 태그와 trigger 확인만 필요한 경우 |
| Edit | 수정안을 만들지만 live 반영은 내부 승인을 거치는 경우 |
| Approve | 내부 검토자가 변경안을 승인하는 경우 |
| Publish | 실제 사이트 반영 권한, 최소 인원으로 제한 |
| Account admin | 여러 container 전체를 관리하는 내부 책임자에게만 부여 |
대행사나 프리랜서에게는 보통 edit까지 열고, publish는 내부 담당자가 preview와 변경 내역을 확인한 뒤 수행하는 구조가 안전합니다. 급한 장애 수정이라면 예외를 둘 수 있지만, 예외도 작업 종료 시간과 회수 기준을 남겨야 합니다.
Google Ads 연결은 전환 데이터 흐름을 바꾼다
GA4와 Google Ads를 연결하면 Analytics 전환과 audience를 Google Ads에서 활용할 수 있습니다. Google 공식 문서는 GA4 property와 Google Ads 계정을 연결하는 절차와 필요한 권한을 안내합니다.
참고: Google Analytics Help – Link Google Ads and Analytics
Google Ads 쪽 사용자 권한도 별도로 봐야 합니다. Google Ads 도움말은 account access level을 설명하고, 관리자 권한과 표준 권한 등 접근 수준을 나눕니다.
참고: Google Ads Help – Access levels
Google Ads 연결 전에는 아래를 확인합니다.
| 항목 | 확인 질문 |
|---|---|
| 연결 목적 | 전환 가져오기, remarketing, audience, 보고서 중 무엇이 목적인가 |
| 계정 범위 | 어떤 Google Ads 계정 또는 manager account와 연결되는가 |
| 전환 소스 | GA4 conversion을 Ads로 가져올 것인지 Ads tag를 따로 둘 것인지 정했는가 |
| 중복 측정 | Google Ads tag와 GA4 conversion이 같은 전환을 중복 집계하지 않는가 |
| 권한 owner | GA4 owner와 Ads owner가 둘 다 승인했는가 |
| 해제 절차 | 대행사 변경 시 연결과 권한을 누가 회수하는가 |
전환 추적은 광고비와 연결되기 때문에 "잘 잡히면 좋다" 수준으로 넘기면 안 됩니다. 어떤 전환이 입찰 전략에 쓰이는지, 어떤 이벤트가 보고서용인지, 어떤 태그가 실제 광고 최적화에 영향을 주는지 구분해야 합니다.
Consent Mode 변경은 별도 승인으로 다루기
Google Tag Manager의 Consent Mode 도움말은 사용자 동의 상태에 따라 Google tag가 동작하는 방식을 조정할 수 있다고 안내합니다. 이는 단순 태그 수정이 아니라 동의 상태, 광고·분석 측정, 지역별 요구사항과 연결됩니다.
참고: Google Tag Manager Help – Consent mode
GTM에는 consent settings를 확인하고 태그별 동의 요구사항을 조정하는 기능도 있습니다.
참고: Google Tag Manager Help – Manage consent settings
Consent Mode와 관련된 작업은 아래 기준으로 제한합니다.
| 항목 | 기준 |
|---|---|
| 변경 권한 | 일반 tag 편집과 분리해 내부 owner 승인 필요 |
| 문서화 | 변경 전후 consent state, 적용 지역, 적용 tag 기록 |
| 테스트 | preview/debug에서 동의 전·후 tag 동작 확인 |
| 배포 | 캠페인 시작 직전 급한 publish 금지 |
| 회수 | 외부 작업자 권한은 배포 후 바로 낮추거나 제거 |
Consent Mode는 법률 자문으로 접근할 영역이 아닙니다. 다만 운영 관점에서는 "누가 어떤 설정을 바꿨고, 어떤 tag 동작이 달라졌는가"를 추적할 수 있어야 합니다.
외부 스크립트와 Custom HTML 태그는 따로 검토하기
GTM은 Custom HTML 태그를 통해 외부 script를 쉽게 넣을 수 있습니다. 이 편의성 때문에 광고, heatmap, chat widget, A/B 테스트, affiliate, popup, tracking script가 계속 쌓이기 쉽습니다. Google Tag Manager 문서는 태그와 trigger를 만들고 테스트하는 기본 절차를 제공합니다.
참고: Google Tag Manager Help – Set up and install Tag Manager
참고: Google Tag Manager Help – Preview and debug containers
Custom HTML이나 외부 script를 넣을 때는 아래 표를 확인합니다.
| 항목 | 확인 질문 |
|---|---|
| 출처 | script 도메인이 공식 도메인인가 |
| 목적 | 광고, 분석, 채팅, heatmap, 전환 중 무엇인가 |
| 로딩 방식 | async, defer, trigger 조건, 모든 페이지 적용 여부를 확인했는가 |
| 성능 | Core Web Vitals, CLS, INP에 영향을 줄 수 있는가 |
| 개인정보 | form 입력, URL parameter, user id를 읽는가 |
| owner | 누가 관리하고 언제 제거할 script인가 |
| 테스트 | preview와 실제 public 페이지에서 동작을 확인했는가 |
애드센스나 광고 위치와 함께 사이트 속도를 보고 있다면 워드프레스 속도 개선 애드센스 체크리스트와 애드센스 광고 위치 점검을 같이 열어 두는 편이 좋습니다.
대행사와 프리랜서 권한은 기간을 정해 열기
GA4와 GTM 권한은 외부 파트너에게 한 번 열어 두면 오래 남기 쉽습니다. 캠페인 하나를 고치려고 초대한 계정이 몇 달 뒤에도 editor나 publish 권한을 갖고 있는 경우가 많습니다.
권한 부여 표는 아래처럼 남깁니다.
| 항목 | 예 |
|---|---|
| 외부 사용자 | agency@example.com |
| 소속 | 광고 대행사, 개발 외주, 분석 컨설턴트 |
| 작업 목적 | 구매 완료 이벤트 중복 수정 |
| GA4 권한 | property viewer 또는 editor |
| GTM 권한 | container edit, publish 없음 |
| 연결 계정 | Google Ads 123-456-7890 |
| 시작일 | 2026-06-24 |
| 종료일 | 2026-07-08 |
| 내부 owner | 마케팅 담당자 또는 개발 담당자 |
| 회수 확인 | 작업 종료 후 권한 제거 여부 |
팀 전체 SaaS 권한 관리는 팀 SaaS 계정 권한 감사 체크리스트와 같은 원칙을 쓰면 됩니다. 외부 파트너 권한은 "필요한 만큼, 필요한 기간만" 열고 회수 기록을 남겨야 합니다.
전환 태그 변경 전 2주 파일럿 절차
전환 태그는 바로 전체 사이트에 반영하지 말고 작은 절차를 둡니다.
| 단계 | 할 일 |
|---|---|
| 1 | 현재 GA4 conversion, Google Ads conversion, GTM tag 목록을 export 또는 캡처 |
| 2 | 변경 목적을 한 문장으로 기록 |
| 3 | staging 또는 preview에서 trigger 조건 확인 |
| 4 | test purchase, lead form, button click 같은 핵심 이벤트를 직접 실행 |
| 5 | GA4 DebugView와 Google Ads 전환 진단을 확인 |
| 6 | publish 전 변경자와 승인자를 분리 |
| 7 | publish 후 24~48시간 동안 중복·누락·급증 여부 확인 |
| 8 | 2주 뒤 전환 수, 광고비, landing page, consent 상태를 다시 점검 |
Google Ads에는 전환 추적을 설정하고 확인하는 공식 문서가 있습니다. 실제 전환 추적 방식은 웹사이트, 앱, 전화, 오프라인 전환 등 유형에 따라 달라질 수 있으므로 계정 상황에 맞게 확인해야 합니다.
참고: Google Ads Help – Set up conversion tracking
전환 데이터가 맞지 않는다고 바로 tag를 여러 개 추가하면 중복 측정이 더 심해질 수 있습니다. 먼저 현재 tag와 event 구조를 기록하고, 어떤 문제를 고칠지 좁혀야 합니다.
월간 GA4·GTM 권한 감사표
월 1회 아래 표만 채워도 권한 방치가 줄어듭니다.
| 점검 항목 | 확인 결과 |
|---|---|
| GA4 account administrator가 내부 인원 중심인가 | |
| GA4 property editor 중 외부 계정이 필요한 상태인가 | |
| GTM publish 권한자가 최소 인원인가 | |
| GTM edit 권한 외부 계정의 종료일이 정해져 있는가 | |
| Google Ads 연결 계정이 현재 운영 계정과 일치하는가 | |
| Consent Mode 설정 변경 로그가 남아 있는가 | |
| Custom HTML 태그의 script 도메인을 확인했는가 | |
| 최근 30일 publish 변경 내역을 검토했는가 | |
| 대행사 변경 후 권한 회수가 끝났는가 | |
| 전환 이벤트 owner와 문서 위치가 명확한가 |
이 표는 복잡한 보안 감사 문서가 아니라 운영용 점검표입니다. 담당자가 바뀌어도 "누가 GA4를 관리하고, 누가 GTM을 publish할 수 있고, 어떤 광고 계정과 연결되어 있는가"를 바로 볼 수 있어야 합니다.
공개 전 마지막 체크리스트
GA4와 GTM 권한을 열기 전에는 아래 10개를 마지막으로 확인합니다.
| 번호 | 체크 항목 |
|---|---|
| 1 | GA4 account와 property 권한을 구분했다 |
| 2 | GTM container edit와 publish 권한을 분리했다 |
| 3 | 외부 파트너 권한에 작업 목적과 종료일을 붙였다 |
| 4 | Google Ads 연결 계정과 전환 사용 범위를 확인했다 |
| 5 | Consent Mode 변경은 별도 승인 절차로 다룬다 |
| 6 | Custom HTML과 외부 script 도메인을 검토한다 |
| 7 | preview/debug 없이 publish하지 않는다 |
| 8 | publish 후 24~48시간 전환 누락·중복을 본다 |
| 9 | 작업 종료 후 외부 권한을 회수한다 |
| 10 | 월 1회 GA4·GTM 권한 감사표를 업데이트한다 |
GA4와 Google Tag Manager는 마케팅 도구이지만, 실제로는 사이트의 측정·광고·동의·스크립트 운영 권한을 묶고 있습니다. 전환 추적을 빨리 고치는 것도 중요하지만, 누구에게 어떤 권한을 얼마나 오래 열었는지 모르면 다음 장애의 원인을 찾기 어렵습니다. 권한을 열기 전 기준을 정하고, publish를 분리하고, 작업 종료 후 회수하는 것만으로도 대부분의 운영 사고를 줄일 수 있습니다.
About The Author
