GA4 데이터 스트림(Data Stream)의 이해: 웹과 앱(iOS/Android)의 데이터를 하나의 속성으로 통합 수집하는 메커니즘

GA4 속성(property)은 하나의 컨테이너이고, 그 안에 데이터가 실제로 들어오는 입구가 데이터 스트림입니다. 회사가 웹사이트 하나, iOS 앱 하나, Android 앱 하나를 운영한다면 세 개의 스트림을 같은 속성에 등록해서, 하나의 GA4 계정 안에서 세 채널의 데이터를 동시에 조회할 수 있습니다. 이전 UA 체계에서는 웹과 앱을 완전히 별도의 속성(웹은 UA, 앱은 Firebase Analytics)으로 분리해서 관리했기 때문에, 한 사용자가 앱에서 상품을 보고 웹에서 구매했는지를 이어서 확인하기가 구조적으로 불가능했습니다. GA4는 이 두 흐름을 같은 속성 아래 스트림으로 묶어서 관리하도록 설계됐습니다.

웹 데이터 스트림을 만들면 G-XXXXXXX 형태의 측정 ID가 발급되고, 이 ID를 gtag.js 스니펫이나 Google 태그 관리자의 GA4 구성 태그에 넣어야 데이터가 수집되기 시작합니다. iOS·Android 앱 스트림은 각각 앱 ID(번들 ID·패키지명) 기준으로 등록하고, Firebase SDK를 통해 이벤트를 전송합니다. 즉 웹은 브라우저에서 실행되는 자바스크립트 태그, 앱은 네이티브 SDK라는 서로 다른 기술로 데이터를 보내지만, 도착하는 곳은 같은 GA4 속성입니다. 스트림별로 별도의 스트림 ID가 있어서, 나중에 보고서에서 어느 스트림에서 온 데이터인지 구분해서 볼 수도 있습니다.

스트림이 여러 개라도 GA4는 기본적으로 모든 표준 보고서를 속성 전체 기준으로 합산해서 보여줍니다. 이때 데이터를 플랫폼별로 나눠보고 싶다면 '플랫폼(platform)'이라는 기본 제공 측정기준을 보고서에 추가하면, web·iOS·Android로 나뉜 값을 확인할 수 있습니다. 탐색 분석에서는 아예 플랫폼을 필터 조건으로 걸어서 "앱에서만 발생한 이벤트"나 "웹에서만 발생한 구매"처럼 특정 스트림 데이터만 골라볼 수도 있습니다. 다만 웹과 앱은 애초에 발생하는 이벤트 종류(예: 앱에는 app_update, os_update처럼 웹에 없는 자동 이벤트가 있음)가 다르므로, 통합 보고서를 볼 때는 이 차이를 먼저 알고 해석해야 오해가 없습니다.

플랫폼이 다른 두 스트림에서 같은 사람의 행동을 하나로 이어보려면 스트림을 같은 속성에 묶는 것만으로는 부족하고, 사용자를 식별할 공통 키가 필요합니다. 로그인 기능이 있는 서비스라면 로그인 시 발급하는 회원 고유 ID를 user_id 매개변수로 웹·앱 양쪽에 동일하게 전송해야, GA4가 "이 사람이 앱에서 로그인했다가 나중에 웹에서 다시 로그인했다"는 사실을 인식하고 두 스트림의 행동을 하나의 사용자 여정으로 이어 붙입니다. 이 사용자 식별(User-ID) 설정은 다음 레슨에서 세션·사용자 정의 구조와 함께 더 자세히 다룹니다.

가장 흔한 실수는 같은 웹사이트에 대해 실수로 스트림을 두 번 만들어 태그를 중복으로 심는 경우입니다. 이렇게 되면 페이지뷰 수가 두 배로 부풀려져 보이는데, 원인을 모르면 갑자기 트래픽이 폭증한 것으로 오인하기 쉽습니다. 또 다른 실수는 개발 서버(스테이징)에 운영 스트림의 측정 ID를 그대로 심어놓고 테스트 트래픽을 실제 데이터에 섞이게 방치하는 경우입니다. 스트림을 새로 만들 때는 운영·스테이징용을 처음부터 분리해서 발급받고, 반기에 한 번 정도 실제 심어진 태그의 측정 ID가 의도한 스트림과 일치하는지 페이지 소스에서 직접 확인하는 점검 루틴을 두는 편이 안전합니다.

브랜드가 여러 개거나 국가별로 별도 도메인을 운영하는 경우, 스트림(또는 아예 속성 자체)을 나눌지 하나로 합칠지 고민하게 됩니다. 일반적인 기준은 "같은 팀이 같은 KPI로 함께 보고 싶은 데이터인가"입니다. 같은 브랜드의 웹·앱처럼 한 사용자 여정으로 이어보고 싶다면 하나의 속성 아래 스트림만 나누는 편이 맞고, 완전히 다른 사업부·다른 의사결정권자가 쓰는 서비스라면 속성 자체를 분리해 접근 권한과 데이터를 물리적으로 나누는 편이 관리하기 쉽습니다. 스트림을 무작정 늘리면 관리자 화면에서 설정을 스트림마다 반복해야 하는 부담이 커지고, 반대로 무리하게 하나로 합치면 팀별로 봐야 할 데이터가 뒤섞여 권한 관리가 복잡해지므로, 조직 구조와 보고 체계를 먼저 확인하고 스트림 구성을 설계하는 순서가 안전합니다.