모든 컬렉션 Show 자주 묻는 질문 누가 내 Event App 에 로그인했는지 어떻게 알 수 있습니까? 얼마나 많은 사람들이 웹 앱 또는 모바일 앱에 로그인했는지 확인하십시오.  작성자:Mahalia VanDeBerghe 이 기사는 기계 번역을 사용하여 영어에서 번역되었습니다. 웹 앱 또는 모바일 앱에 로그인한 사람은 사용자 및 그룹 페이지에 활성으로 표시됩니다.
질문? 채팅 또는 이메일 답변을 찾으셨나요? 이 도움말에서는 애널리틱스 앱에서 사용할 수 있는 보고서에 대해 설명합니다. 홈페이지에는 애널리틱스에서의 사용자 행동에 따라 사용자와 관련성 있는 정보가 표시됩니다. 이 페이지에서 트래픽을 모니터링하고, 애널리틱스를 살펴보고, 웹사이트 및 모바일 앱에 대한 통계를 확인할 수 있습니다. 애널리틱스를 계속 사용하면 홈페이지에서 더 맞춤화된 콘텐츠를 제공합니다. 홈페이지에서는 다음 정보를 확인할 수 있습니다. 홈페이지에 대해 자세히 알아보기 실시간 보고서를 사용하면 사용자의 활동을 실시간으로 모니터링할 수 있습니다. 이 보고서는 상호작용이 발생하고 나서 몇 초 뒤면 데이터를 보여줄 뿐 아니라 계속 업데이트되기 때문에 얼마나 많은 사용자가 어떻게 콘텐츠를 이용하고 있는지 실시간으로 파악할 수
있습니다. 실시간에 대해 자세히 알아보기 대시보드 보고서를 사용하면 소규모 맞춤 보고서를 만들 수 있습니다. 각 카드에서 측정항목, 측정기준, 차트 유형을 선택할 수 있습니다. 만들 수 있는 카드의 수에는 제한이 없습니다. 팁: 측정기준 및 측정항목을 선택할 때 측정기준 또는 측정항목에 대한 정보를 보려면 애널리틱스 계정에 로그인하면 모든 기기에서 저장된 대시보드에 액세스할 수 있습니다. 통계통계 보고서를 사용하면 애널리틱스에서 속성에 대해 생성하는 자동 통계 또는 맞춤 통계를 확인할 수 있습니다. 애널리틱스 통계에 대해 자세히 알아보기 보고서보고서 섹션에는 보고서 개요 보고서와 Google 애널리틱스 4 속성의 컬렉션 및 주제가 포함되어 있습니다. 상단의 탭을 사용하여 각 주제의 보고서를 볼 수 있습니다. 다음 예는 상단에 있는 참여도 보고서의 참여 개요 보고서(탭)를 보여줍니다. 유니버설 애널리틱스홈홈에는 다음과 같은 내용이 포함됩니다.
대시보드대시보드에서 소규모 맞춤 보고서를 만들 수 있습니다. 보고서에서 또는 대시보드 화면 오른쪽 상단의 +를 탭하여 대시보드에 카드를 저장합니다. 각 카드에서 측정항목, 측정기준, 세그먼트, 차트 유형을 선택할 수 있습니다. 만들 수 있는 보고서 수에는 제한이 없지만 다른 사용자나 다른 대시보드와 공유할 수는 없습니다. 특정 사용자가 설정한 대시보드는 애널리틱스 앱과 해당 기기에서만 사용할 수 있습니다. 통계애널리틱스에서 보고서 보기에 대해 생성한 자동 또는 맞춤 통계를 확인하세요. 실시간사용자의 활동을 실시간으로 모니터링할 수 있습니다. 실시간 보고서는 상호작용이 발생하고 나서 몇 초 뒤면 데이터를 보여줄 뿐 아니라 계속 업데이트되기 때문에 얼마나 많은 사용자가 어떻게 콘텐츠를 이용하고 있는지 실시간으로 파악할 수 있습니다. 실시간에 대해 자세히 알아보세요. 잠재고객사용자의 위치, 사용자가 콘텐츠를 이용하는 빈도 및 시간, 가장 많이 이용하는 기기 등 사용자에 대한 정보를 얻을 수 있습니다. 잠재고객 보고서는 콘텐츠를 이용하는 사용자에 대한 정보를 제공합니다. 웹 및 모바일 앱용 사용자 보고서에 대해 자세히 알아보세요. 획득이 보고서는 웹 속성에 대해서만 사용할 수 있습니다. 획득 보고서를 사용하면 사용자가 웹사이트를 방문하는 경로를 파악할 수 있습니다. 또한 이 보고서를 보면 사용자가 사이트를 직접 방문했는지 또는 검색엔진을 이용했는지 등 트래픽에 대한 세부정보를 얻을 수 있으며 특정 마케팅 캠페인이 사용자를 유치하는 데 얼마나 효과적인지 알 수 있습니다. 웹 획득에 대해 자세히 알아보세요. 행동행동 보고서는 사용자가 사이트나 앱에서 상호작용하는 방식을 보여줍니다. 이 보고서를 사용하여 세션당 화면 조회수, 일반적인 세션 지속 시간 또는 기타 측정항목을 파악할 수 있습니다. 웹 및 모바일 앱용 행동 보고서에 대해 자세히 알아보세요. 이벤트와 함께 동영상, 슬라이드쇼 등 특별한 콘텐츠를 추적하면 행동 보고서를 더 유용하게 사용할 수 있습니다. 이벤트에 대해 자세히 알아보세요. 목표목표 보고서를 보면 내가 정의한 사이트 관련 목표를 사용자가 얼마나 달성했는지, 그리고 각 채널, 소스, 매체 및 기기 카테고리가 목표 전환에 어떻게 기여하고 있는지를 알 수 있습니다. 목표에 대해 자세히 알아보세요. 전자상거래애널리틱스 계정에서 계정 가입, 제품 판매 등의 목표를 추적하도록 '전자상거래'를 설정한 경우 전자상거래 보고서를 사용하여 실적과 수익 목표를 추적할 수 있습니다. 웹 및 모바일 앱용 전자상거래 보고서에 대해 자세히 알아보세요. 도움이 되었나요? 어떻게 하면 개선할 수 있을까요?
작은 웹사이트일수록 더 빠르게 로드됩니다. 이는 놀라운 일이 아닙니다. 놀라운 것은, 이는 TCP가 무엇인가요?
브라우저가 웹사이트(또는 이미지, 스타일시트)를 요청할 때, 한편 웹사이트에서는 모든 데이터가 도착했다는 사실을 아는 것이 중요합니다. 그렇지 않으면 웹 페이지의 일부(chunk)가 누락될 수 있습니다. 다만 실시간 비디오 스트리밍과 같이, 이것이 그다지 중요하지 않은 경우도 존재합니다.
서버는 패킷의 일부를 송신한 다음, 패킷을 수신했다는 브라우저의 응답(이를 '확인 응답' - Acknowledgement, ACK 라고 합니다)을 기다립니다. 그런 다음 이전보다 더 많은 패킷을 송신하거나, TCP slow start는 무엇인가요?
브라우저가 처음으로 서버에 연결할 때에는, 상호 간의 대역폭bandwidth을 확인할 방법이 없습니다. 대역폭은 단위 시간 당 네트워크를 통해 전송할 수 있는 데이터의 양을 말합니다. 일반적으로 초당 비트 수(bits per seconds, bps)로 측정됩니다. 일반적으로 배관에 비유되기도 합니다. 초당 파이프에서 나오는 물의 양이라고 생각하면 됩니다. 서버는 해당 연결에서 얼마나 많은 데이터를 처리할 수 있을지 알 수 없기 때문에, 일반적으로 10개의 패킷만을 송신하여 작은 규모로 안전하게 프로세스를 시작하게 됩니다. 패킷이 사이트 방문자에게 성공적으로 도달하면, 방문자의 컴퓨터는 패킷을 수신했다는 응답(ACK)을 다시 보냅니다. 그런 다음 서버는 더 많은 데이터를 보내는데, 이때는 패킷의 양을 이전보다 두 배로 늘립니다. 이러한 프로세스는 패킷이 손실되고 서버가 더 이상 ACK 응답을 받지 않을 때까지 반복됩니다. (이 시점에서 서버는 패킷을 계속 송신하지만, 속도는 더 느립니다) 이것이 14kB는 어디서 온 건가요?대부분의 웹 서버에서, 이때 TCP 패킷의 최대 크기는 1500 bytes 입니다. 이 값은 TCP 스펙에서 결정된 것이 아니며, Ethernet frame에서 비롯된 것입니다. 각 TCP 패킷은 헤더에서 40bytes 만큼을 사용합니다. (IP에서 16bytes, TCP에서 24bytes) 그러면 이제 TCP 패킷 당 1,460bytes가 남습니다. 10개의 패킷을 보내므로, 따라서 웹사이트 또는 웹사이트의 중요한 부분의 데이터 사이즈를 14kB에 맞출 수 있다면, 방문자와 웹사이트의 서버 사이를 한 번 왕복(round trip)하는 데에 걸리는 시간을 절약할 수 있을 것입니다. 한 번의 왕복이 얼마나 나쁠 수 있을까요?사용자들은 매우 조급해합니다. 한 번의 왕복 시간은 경우에 따라 매우 길어질 수도 있는데, 이는 지연 시간(latency)이 얼마나 되느냐에 달려 있습니다. 지연 시간이란 데이터 패킷이 소스에서 대상(목적지)로 이동하는 데에 소요된 시간을 말합니다. 대역폭이 초당 파이프를 통과할 수 있는 물의 양이라면, 지연 시간은 한 방울의 물이 파이프에 들어갔다가 다른 쪽으로 나오는 데 소요된 시간입니다. 다음은 지연 시간이 얼마나 나쁜 것인지를 보여주는 재미있는 예입니다 : 위성 인터넷위성 인터넷은 지구 주위를 도는 인공위성에 의해 제공됩니다. 인구가 매우 적은 지역, 석유 굴착 장치(oil rigs), 유람선 및 항공사 기내 WiFi 등에서 사용됩니다. 지연 시간의 나쁜 예를 설명하기 위해, 석유 굴착 장치에서 실제 주사위가 아니라 14kB 미만의 missingdice.com 사이트를 통해서 Dungeons & Dragons* 게임을 플레이해야 한다고 가정해 보겠습니다.
스마트폰으로 웹 페이지 요청을 위성 안테나로 보내기 위해, WiFi 라우터로 데이터를 전송하는 데에 먼저 그런 다음 위성 안테나는 해당 데이터를 지구 궤도에 위치한 위성으로 보내야 합니다. 일반적으로 이는 지구 표면에서 이제 지상국에서는 웹사이트의 서버로 요청을 전송해야 합니다(이때 광케이블에서 광속은 200,000,000m/s 까지 느려질 수 있습니다). 지상국과 서버의 거리가 뉴욕과 런던 사이의 거리(5,569km)라면 서버에서 수신된 요청을 처리하고, 결과를 다시 전송하는 데에는 지상국으로, 우주로, 위성 안테나로, 그 다음 WiFi 라우터로, 그리고 다시 스마트폰으로 돌아갑니다.
합산해보면 이는 매 왕복마다 추가로 소요되는 시간입니다. 기다리는 시간이 그다지 길지는 않을 수도 있겠지만, 웹사이트에서는 첫 번째 리소스를 가져오기 위해 많은 왕복을 거쳐야 할 수 있습니다. 또한, HTTPS라면 첫 번째 왕복을 수행하기 전에 두 번의 추가 왕복이 필요하므로, 이 때는 지상에서의 지연 시간은 어떨까요?위성 인터넷은 의도적으로 나쁜 예를 든 것으로 보일 수 있습니다. 하지만 지상에서도 아래와 같은 이유들로 지연 시간이 나빠질 수 있습니다 :
또한 연결이 불안정한 경우에는 패킷이 손실될 수도 있으며, 이 때에는 패킷을 다시 가져오기 위해 왕복이 다시 발생합니다. 14kB 규칙에 대해서는 알았으니, 이제 무엇을 할 수 있을까요?물론 웹사이트를 가능한 가볍게 만들어야 합니다. 각 페이지를 14kB 미만으로 맞추는 것이 좋은 목표입니다. 이때 14kB는 압축을 포함하므로, 압축되지 않은 실제 데이터 기준으로는 50kB 정도라고 할 수 있겠습니다. 자동 재생 동영상, 팝업, 쿠키, 쿠키 수락 배너, 소셜 네트워크 버튼, 추적 스크립트, 자바스크립트 및 CSS 프레임워크, 그리고 기타 불필요한 정크 등을 줄인다면 이러한 목표에 도달할 수 있을 것입니다. 중요한 CSS나 JS, 앱 사용 방법을 설명하는 텍스트의 처음 몇 단락 등과 같이, 렌더링시 유용한 데이터를 가급적 처음 전송되는 14kB 내에 포함되도록 할 수도 있습니다. 참고 : 14kB 규칙에는 압축되지 않은 HTTP 헤더도 포함되어 있습니다(첫 번째 응답에서 HTTP/2를 사용하는 경우에도). 이는 이미지도 마찬가지이므로, 스크롤 없이 먼저 볼 수 있는 부분만 로드하면서 크기를 작게 유지하거나, placeholder를 사용하여 사용자가 기다려야 한다는 사실을 인지할 수 있도록 할 수 있습니다. 규칙에 대한 몇 가지 주의사항14kB 규칙은 컴퓨팅의 기본적인 규칙이라기보다는 일종의 경험적인 법칙에 더 가깝습니다 :
HTTP/2와 14kB 규칙 HTTP/3 및 QUIC 더 읽을거리
|
웹사이트 얼마나 이용 했는지 보여주는
저작권 © 2024 estudarpara Inc.
