표준화는 컬럼명 통일에서 시작하지 않는다

스키마 표준화를 컬럼명 맞추기로 이해하면 절반만 하는 것입니다. 진짜 어려운 지점은 정의입니다. 영업팀의 "리드"와 마케팅팀의 "리드"가 같은 것인지, 전환 시점을 신청 시각으로 볼지 승인 시각으로 볼지, 취소·환불 건을 매출에서 언제 차감할지 같은 질문이 먼저입니다. 컬럼명은 이 정의가 합의된 뒤에 붙이는 이름표에 불과합니다.

그래서 첫 산출물은 테이블 설계서가 아니라 용어집입니다. 지표 이름, 한 문장 정의, 계산식, 집계 시점 기준, 담당 부서 다섯 칸짜리 표면 충분합니다. 이 표가 없으면 나중에 같은 이름의 컬럼 두 개가 서로 다른 숫자를 담게 되고, 그때부터는 어느 쪽이 맞는지 아무도 증명하지 못합니다.

원시 데이터를 왜 손대지 않고 남겨야 하나

표준화 작업을 적재 단계에서 곧바로 수행하려는 시도가 흔합니다. 적재하면서 컬럼명을 바꾸고 통화를 환산해 한 번에 깔끔한 테이블을 만드는 방식입니다. 이 방식의 문제는 되돌릴 수 없다는 것입니다. 나중에 정의가 바뀌면 과거 데이터를 다시 만들 원본이 없습니다.

BigQuery Data Transfer Service가 적재 도구이지 범용 ETL 변환 도구가 아니라는 점은 오히려 이 원칙과 맞습니다. 매체별로 컬럼명·통화·시간대가 제각각인 원시 테이블이 그대로 쌓이고, 표준화는 그 위에 예약 쿼리로 변환 레이어를 만들어 수행합니다. 정의가 바뀌면 변환 쿼리만 고쳐 과거분을 다시 만들면 됩니다. 원시 레이어는 보험이고, 이 보험료는 스토리지 비용뿐입니다.

이벤트·매개변수 명명 규칙은 어떤 제약 안에서 설계하나

행동 로그 쪽 표준화는 도구의 물리적 제약을 먼저 확인해야 합니다. GA4는 이벤트 이름 40자 이내, 이벤트당 매개변수 최대 25개, 매개변수 이름 40자 이내, 매개변수 값은 일반적으로 100자(특수 매개변수는 최대 1,000자)로 제한합니다. 또 표준 속성 기준으로 사용자당 일일 이벤트 수 제한 100,000개, 일일 전환 제한 10,000개가 적용됩니다.

주요 이벤트로 설정할 수 있는 개수도 제한이 있습니다. 표준 속성 30개, Google Analytics 360 속성 50개입니다. 명명 규칙을 만들 때 이 숫자들을 모르면 "모든 버튼 클릭을 개별 이벤트로"처럼 한도를 넘는 설계가 나옵니다. 이벤트는 행동의 종류로 좁히고 세부 구분은 매개변수로 내리는 방향이 제약 안에 들어옵니다. 추천 이벤트는 구글이 미리 정의한 이름과 매개변수 구조를 따라 내장 보고서에 자동 매핑되지만, 커스텀 이벤트는 보고서를 수동으로 구성해야 한다는 차이도 설계에 반영해야 합니다.

조인 키를 먼저 정하면 무엇이 달라지나

통합의 성패는 조인 키에서 갈립니다. GA4 원시 스키마에는 로그인 유저를 잇는 user_id와 브라우저·앱 단위 익명 식별자인 user_pseudo_id가 함께 있고, 매체 데이터 쪽에는 캠페인 식별자와 UTM 값이 있으며, 주문 데이터 쪽에는 주문번호와 회원번호가 있습니다. 이 값들이 각각 어느 테이블에서 어떤 형식으로 나오는지 표로 정리하는 것이 통합 설계의 실질입니다.

여기서 판단이 필요한 대목은 키가 없는 소스입니다. 오프라인 이벤트 참가자 명단이나 대행사가 엑셀로 주는 리포트처럼 조인 키가 없는 데이터는, 억지로 넣으면 웨어하우스 안에서 고립된 섬이 됩니다. 그럴 때는 통합 대상에서 잠시 빼두고, 다음 회차부터 키를 수집하도록 프로세스를 바꾸는 편이 낫습니다. 지금 붙이는 것보다 다음부터 제대로 들어오게 만드는 것이 결과적으로 빠릅니다.

표준을 유지하려면 무엇을 정해두어야 하나

스키마 표준의 수명은 문서 품질이 아니라 관리 주체가 결정합니다. 새 캠페인이 생길 때 캠페인 명명 규칙을 누가 적용하는지, 새 이벤트를 추가하려면 누구의 확인을 받는지, 규칙을 바꿀 때 어디에 기록하는지 세 가지가 정해져 있지 않으면 반년 안에 예외가 규칙보다 많아집니다.

가장 현실적인 형태는 변경 요청 창구를 한 곳으로 두고, 변경 이력을 날짜와 사유까지 남기는 것입니다. 데이터레이어는 사용자 행동 발생 시 값을 넣는 임시 저장소이므로, 개발팀이 코드에 넣는 키 이름과 마케팅팀이 리포트에서 쓰는 이름이 이 창구를 통해서만 연결되도록 해야 합니다. 그리고 배포 전에는 GTM 미리보기·디버그 모드로 실제 발동되는 태그와 전달되는 값을 확인하는 절차를 규칙에 포함해두면, 명명 규칙 위반이 운영에 반영되기 전에 걸러집니다.