기술나눔

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

원래 주소

매장지란 무엇입니까?

학명은 Event Tracking이며 주로 사용자 행동이나 비즈니스 프로세스에 대한 관련 기술 및 구현 프로세스를 캡처, 처리 및 전송하는 데 중점을 둡니다.
점매설은 데이터 분야의 전문용어이자, 인터넷 분야에서도 통용되는 명칭이다.

매장포인트는 상품 데이터 분석의 기초가 되며 일반적으로 추천 시스템의 피드백, 사용자 행동 모니터링 및 분석, 새로운 기능이나 운영 활동 효과에 대한 통계 분석 등에 사용됩니다.

임베딩 포인트에는 이벤트(event)와 속성(param)이라는 두 가지 중요한 개념이 포함됩니다.

• 이벤트: 사용자 작업, 시스템 이벤트, 시스템 오류 등 애플리케이션에서 발생하는 일입니다. 예를 들어 제품을 촬영하면 enter_page(페이지 입장), Leave_page(페이지 나가기) 이벤트가 포함됩니다.
• Param: 언어 기본 설정이나 지리적 위치와 같은 사용자 세그먼트를 설명하기 위해 정의된 속성입니다. "수업 후 운동 입장" 이벤트를 예로 들어 보겠습니다. 여기에는 enter_from(어느 페이지에서), class_id(강좌 ID) 등의 이벤트 속성이 포함되어 있습니다.
• 속성값(value) : 속성의 차원, 즉 행위가 트리거될 때의 특정 차원. 예: enter_from: home(홈페이지), system(시스템) 등

주류 계획

Traceless Buring(Full Buring)은 브라우저나 APP에 내장된 모니터링 방법을 사용하여 사용자의 탐색 페이지, 클릭 및 기타 행위를 모니터링하는 것으로 일반적으로 회사의 슬라다와 같은 대략적인 데이터 분석에 사용됩니다.
결점:

• 데이터는 시끄럽고 유용한지 여부에 관계없이 수집됩니다.
• 매장된 포인트를 맞춤 설정할 수 없으며, 특정 이벤트 및 비즈니스 속성을 수집할 수 없습니다.
• DA가 이용할 수 있는 정보가 적음
  이점:
• 간단한 접근, 침입이 거의 없으며, 추가 개발 비용이 필요하지 않습니다.
• 사용자 조작 행위의 수집은 매우 완전하며 누락이 거의 없습니다.

코드 매립 지점, 프런트 엔드 개발자는 코드에서 모니터링 및 수집을 사용자 정의합니다.
결점:

• 작업량이 많고 코드가 방해가 되며 나중에 유지 관리가 불편합니다.
  이점:
• 포인트를 정확하게 매립하고 이벤트를 명확하게 식별할 수 있습니다.
• 영업사원 속성이 매우 풍부합니다.
• 매립지 트리거 방식을 유연하게 정의할 수 있습니다.
• DA가 더 편리하고 정확해졌습니다

매몰포인트 SDK, SDK는 매몰포인트 보고를 위한 인터페이스를 노출하고 있으며, 개발자는 회사의 차 등 모니터링 및 수집 프로세스를 인지하지 못합니다.
단점: 없음
이점:

• 비즈니스 개발에서는 이벤트 식별, 비즈니스 속성 등에 주의하면 됩니다.
• 무추적 매장지와 코드 매장지의 장점을 고려

일반적인 숨겨진 속성

일반적으로 프런트엔드는 페이지 크기에 따라 매장된 포인트를 계산합니다. 일반적인 이벤트 속성은 다음과 같습니다.

일반적인 매장 사건

성능 데이터 수집 솔루션

현재 대부분의 성능 지표 데이터는 window.performance API에서 가져옵니다.

일반적인 성과 지표

FP

FP(FIrst Paint) 표시기는 일반적으로 페이지의 흰색 화면 시간을 반영합니다. 흰색 화면 시간은 사용자가 콘텐츠를 기다리는 시간이 짧을수록 웹 페이지의 로딩 성능이 저하됩니다. 아주 좋아요 하얀화면 시간이 짧을수록 사용자 이탈 확률이 낮아집니다.

이 표시기는 preformance.getEntriesByType('paint') 메소드를 통해 PerformancePaintTming API에서 제공하는 포인트 정보를 얻을 수 있으며 이름이 first-paint인 개체를 찾고 설명은 FP 표시기 데이터입니다.

에프씨피(에프씨피(FCP))

FCP(First Contentful Paint)는 콘텐츠가 처음으로 렌더링되는 시점입니다. 성능 통계 지표에서는 사용자가 웹 페이지에 접속하기 시작한 시점부터 FCP까지의 시간을 일반적으로 콘텐츠가 없는 시간으로 간주할 수 있습니다. , FCP >= FP

표시기는 다음 그림과 같이 FCP 표시기 데이터를 설명하는 first-contentful-paint라는 이름의 객체를 찾아 PerformancePaintTiming API에서 제공하는 포인트 정보를 얻을 수 있습니다.

FMP

FMP(First Meaningful Paint)는 의미 있는 콘텐츠가 처음으로 그려지는 시점으로 전체 페이지의 레이아웃과 텍스트 콘텐츠가 완전히 렌더링되면 의미 있는 콘텐츠의 첫 번째 의미 있는 그림이 완성된다고 볼 수 있습니다.따라서 FMP는 사용자가 웹페이지의 주요 콘텐츠를 보는 데 걸리는 시간을 측정하며, 사용자 경험 관점에서 중요한 측정 지표이다.

현재 프론트엔드 업계에서 인정하는 FMP 계산 방식은 '로딩 및 렌더링 시 페이지 레이아웃을 최대로 변경한 후 그리는 시간'이다. MutationObserver를 사용하면 페이지의 전체 DOM 변경 사항을 각각 모니터링하고 MutationObserver의 콜백을 트리거하며 콜백 중 현재 DOM 트리의 변경 점수를 계산할 수 있습니다. 점수가 가장 많이 변경되는 순간이 FMP 시점입니다.

티티티

TTI(Time To Interactive)는 페이지 로딩 시작부터 페이지가 완전히 대화형 상태가 될 때까지 걸리는 시간입니다. 페이지가 완전한 대화형 상태이면 다음 세 가지 조건이 충족됩니다.

페이지에 이미 유용한 콘텐츠가 표시되어 있습니다.
페이지에 표시되는 요소와 관련된 이벤트 응답 기능이 등록되었습니다.
이벤트 응답 기능은 이벤트 발생 후 50ms 이내에 실행을 시작할 수 있습니다.

리소스 로딩 표시기

window.performance.getEntriesByType('resource')는 현재 페이지에 로드된 모든 리소스(js, css, img...)에 대한 다양한 성능 지표를 반환하며, 이는 정적 리소스 성능 데이터 수집에 사용할 수 있습니다.

주요 유형은 script, link, img, css, xmlhttprequest, beacon, fetch 등입니다.
PerformanceResourceTiming - 웹 API | MDN

기타 지표 계산 방법

오류 데이터 수집 솔루션

세가지 종류가 있어요

• 리소스 로딩 오류, addEventListener('error', callback, true)를 통해 캡처 단계에서 리소스 로딩 실패 오류를 캡처합니다.
• js 실행 오류, window.onerror를 통해 js 오류를 캡처합니다.
  • 도메인 간 스크립트는 "스크립트 오류" 프롬프트를 표시하며 특정 오류 정보 및 스택 정보를 얻을 수 없습니다. 이때 스크립트 태그에 crossorigin="anonymous" 속성을 추가해야 하며, 리소스 서버에서는 Access-Control-Allow-Origin 등 CORS 관련 구성을 추가해야 합니다. *
• Promise 오류, addEventListener('unhandledrejection', callback)를 통해 Promise 오류를 캡쳐하지만, 오류가 발생한 행, 열 개수 등의 정보가 없어 수동으로 해당 오류 정보만 던질 수 있습니다.

// 在捕获阶段，捕获资源加载失败错误
Element.addEventListener('error', e => {
const target = e.target
    if (target != window) {
        monitor.errors.push({
            type: target.localName,
            url: target.src || target.href,
            msg: (target.src || target.href) + ' is load error',
            time: Date.now()
        })
    }
})

// 监听 js 错误
window.onerror = function(msg, url, row, col, error) {
    monitor.errors.push({
        type: 'javascript',
        row: row,
        col: col,
        msg: error && error.stack? error.stack : msg,
        url: url,
        time: Date.now()
    })
}
// 监听 promise 错误 缺点是获取不到行数数据
addEventListener('unhandledrejection', e => {
    monitor.errors.push({
        type: 'promise',
        msg: (e.reason && e.reason.msg) || e.reason || '',
        time: Date.now()
    })
})

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

데이터 보고 계획

이 시나리오에서는 고려해야 할 두 가지 문제가 있습니다.

데이터 리포팅 인터페이스와 비즈니스 시스템이 동일한 도메인 이름을 사용하는 경우 브라우저에서는 동시 요청 수에 제한이 있어 네트워크 자원을 놓고 경쟁할 가능성이 있습니다.
브라우저는 일반적으로 페이지가 언로드될 때 비동기 ajax 요청을 무시합니다. 데이터 요청이 필요한 경우 일반적으로 페이지 언로드를 지연하기 위해 unload 또는 beforeunload 이벤트에서 동기 ajax 요청이 생성됩니다. 사용자 관점에서 볼 때 페이지 이동 속도가 느려집니다.

네비게이터.sendBecon

이점:
페이지가 언로드될 때 페이지가 닫히는 것을 차단하지 않고 안정적으로 데이터를 보냅니다.
백그라운드에서 데이터 전송을 지원합니다.

결점:
POST 요청만 보낼 수 있으며, 응답 결과를 얻을 수 없습니다.

Internet Explorer 외에도 현재 주류를 이루는 최신 브라우저는 비콘에 대한 지원률이 매우 높습니다. 비콘 - MDN 문서

Beacon 인터페이스는 웹 서버에 대한 비동기 비차단 요청을 예약하는 데 사용됩니다.

• 비콘 요청은 HTTP POST 메서드를 사용하며 응답이 필요하지 않습니다.
• 비콘 요청은 페이지가 언로드를 트리거하기 전에 초기화가 완료되도록 합니다.

평신도의 관점에서 보면 Beacon은 데이터를 서버에 비동기식으로 보낼 수 있으며 페이지 언로드가 완료되기 전에 요청이 전송되도록 보장할 수 있습니다(Ajax 페이지 언로드로 인해 요청이 종료되는 문제를 해결함). 사용 방법:

navigator.sendBeacon(url, data);
1

data 매개변수는 선택사항이며 해당 유형은 ArrayBufferView, Blob, DOMString 또는 FormData일 수 있습니다. 브라우저가 전송할 큐에 비콘 요청을 성공적으로 추가하면 이 메서드는 true를 반환하고, 그렇지 않으면 false를 반환합니다.

Beacon을 사용할 때 백엔드는 매개변수를 수신하기 위해 post 메소드를 사용해야 하며, 크로스 도메인 문제를 고려하여 백엔드도 인터페이스를 수정하고 CORS를 구성해야 합니다. 동시에 요청 헤더는 CORS 허용 목록에 있는 요청 헤더를 충족해야 하며, 여기서 콘텐츠 유형은 application/x-www-form-urlencoded, multipart/form-data 또는 text/plain이어야 합니다.

type ContentType = 'application/x-www-form-urlencoded' | 'multipart/form-data' | 'text/plain';

const serilizeParams = (params: object) => {
    return window.btoa(JSON.stringify(params))
}

function sendBeacon(url: string, params: object) {
  const formData = new FormData()
  formData.append('params', serilizeParams(params))
  navigator.sendBeacon(url, formData)
}

1
2
3
4
5
6
7
8
9
10
11
12

영상

이점:
사용이 간편하고 호환성이 좋으며 여러 도메인에 걸쳐 보고할 수 있습니다.
페이지 로딩 및 닫기를 차단하지 않습니다.

결점:
GET 요청만 보낼 수 있으며, 응답 결과를 얻을 수 없습니다.
비동기 작업은 지원되지 않습니다.

sendBeacon의 호환성 문제는 피할 수 없지만 대부분의 브라우저는 페이지가 언로드되기 전에 이미지 로딩을 완료하고 페이지에 img를 추가하여 데이터를 보고하는 기능을 최대한 활용할 수 있습니다.

function sendImage(url: string, params: object) {
  const img = new Image()

  img.style.display = 'none'

  const removeImage = function() {
    img.parentNode.removeChild(img)
  }

  img.onload = removeImage
  img.onerror = removeImage

  img.src = `${url}?params=${serilizeParams(params)}`

  document.body.appendChild(img)
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

img 이미지는 get 요청이므로 서버마다 uri 길이에 제한이 있습니다. 길이가 한도를 초과하면 HTTP 414 오류가 발생하므로 보고 빈도에도 주의하여 속성을 너무 많이 줄여야 합니다. 한번에 업로드됩니다.

호환 가능한 솔루션

sendBeacon 메서드가 선호되며 Image 메서드가 대체 수단으로 사용됩니다.

function sendLog(url: string, params: object) {
    if（navigator.sendBeacon) {
        sendBeacon(url, params)
    } else {
        sendImage(url, params)
    }
}
1
2
3
4
5
6
7
8

사실 많은 분들이 요점을 묻기 위해 GIF를 사용하고 계시죠?
서버에 대한 데이터 보고는 인터페이스 요청, 일반 파일 요청, 이미지 리소스 요청을 통해 이루어질 수 있습니다. GIF 파일을 요청하든, js 파일을 요청하든, 페이지 인터페이스를 호출하든 데이터를 보고할 수 있는 한 서버는 실제로 특정 보고 방법에 관심을 두지 않습니다. 그렇다면 왜 모든 시스템이 데이터 보고를 위해 GIF 이미지를 요청하는 방식을 일률적으로 사용하는 걸까요?
●도메인 간 방지
일반적으로 점으로 구분된 도메인 이름은 현재 도메인 이름이 아니므로 모든 인터페이스 요청은 도메인 간 요청으로 구성됩니다. 부적절한 구성 및 보고 오류로 인해 교차 도메인 요청이 브라우저에서 쉽게 차단될 수 있으며, 이는 허용되지 않습니다. 그러나 이미지의 src 속성은 도메인을 넘지 않으며 요청도 시작될 수 있습니다. (인터페이스 보고 제외)
●페이지 로딩 차단 및 사용자 경험 영향 방지
일반적으로 리소스 노드를 생성한 후 브라우저는 개체가 브라우저 DOM 트리에 주입될 때까지 실제로 리소스 요청을 보내지 않습니다. DOM을 반복적으로 작동하면 성능 문제가 발생할 뿐만 아니라 js/css 리소스를 로드하면 페이지 렌더링이 차단되고 사용자 경험에도 영향을 미칩니다.
이미지 요청은 예외입니다. 이미지를 생성할 때 DOM에 삽입할 필요가 없을 뿐만 아니라, js에서 새로운 Image 객체가 생성된다면 요청을 시작할 수 있고, js가 없는 브라우저 환경에서는 차단 문제가 없습니다. 또 다른 리소스 요청인 img 태그를 통해서도 정상적으로 관리가 가능합니다. (파일 제외 방법)
●PNG/JPG에 비해 GIF의 크기가 가장 작습니다.
가장 작은 BMP 파일에는 74바이트가 필요하고, PNG에는 67바이트가 필요하며, 합법적인 GIF에는 43바이트만 필요합니다.
동일한 응답에 대해 GIF는 BMP보다 41%, PNG보다 35%의 트래픽을 절약할 수 있습니다.
그리고 대부분 1*1 픽셀의 투명 GIF를 사용하여 보고합니다.
1x1 픽셀은 가장 작은 법적 이미지입니다. 게다가 그림을 통해 이루어지므로 페이지 자체의 표시 효과에 영향을 주지 않도록 그림을 투명하게 만드는 것이 가장 좋습니다. 그림이 투명하다는 것을 나타내려면 바이너리 비트만 사용하여 표시하면 됩니다. 그림은 투명한 색상으로 표시되며 색 공간 데이터를 저장할 필요가 없어 볼륨을 절약할 수 있습니다.

XMLHttpRequest 또는 Fetch API

이점:

비동기식 요청을 보낼 수 있으며 GET 및 POST와 같은 여러 HTTP 메서드가 지원됩니다.
응답 결과를 얻고 추가 ​​처리가 가능합니다.
결점:

요청 및 응답 논리를 수동으로 처리해야 합니다.
도메인 간 요청 문제(예: CORS 설정)를 처리해야 합니다.

XMLHttpRequest 또는 Fetch API를 사용하여 보고서 데이터에 대한 비동기 요청을 보냅니다. GET 또는 POST 메서드를 사용하도록 선택하고 데이터를 요청 본문 또는 URL 매개변수로 보낼 수 있습니다.

웹소켓

이점:

실시간 성능이 좋고 양방향 통신을 지원합니다.
실시간 모니터링 및 대규모 데이터 보고에 적합합니다.
결점:

서버는 WebSocket 프로토콜을 지원해야 합니다.
더 복잡하고 단순한 매립점 요구 사항에는 적합하지 않습니다.

보고 플랫폼

일반적인 프런트엔드 데이터 저장 도구로는 Google Analytics, Baidu Statistics, Umeng Statistics 등이 있습니다. 물론 보고를 위해 회사의 내부 인터페이스나 플랫폼을 사용할 수도 있습니다.

Google Analytics를 예로 들어보겠습니다.
Google Analytics는 웹사이트 트래픽을 추적하고 보고하기 위해 Google이 개발한 웹사이트 분석 도구입니다. 이는 웹사이트 소유자가 방문자가 누구인지, 어디서 왔는지, 사이트에서 무엇을 하는지 등 방문자의 행동을 이해하는 데 도움이 됩니다. Google Analytics를 통해 웹사이트 소유자는 청중을 더 잘 이해하고 웹사이트 콘텐츠와 마케팅 전략을 최적화하여 웹사이트 성능과 사용자 경험을 향상시킬 수 있습니다. Google Analytics는 실시간 데이터, 사용자 행동 분석, 전환 추적, 트래픽 소스 분석 등 다양한 데이터 분석 기능을 제공합니다. 다양한 웹사이트와 온라인 마케팅 캠페인에서 널리 사용되는 강력한 도구입니다.

Google Analytics를 사용하는 방법

우리는 Google Analytics를 사용하고 있으므로 먼저 Google 계정이 있어야 하며 직접 만들어야 합니다. 둘째, Google Analytics의 입구를 알아야 합니다. 사용된 두 주소는 다음과 같습니다.

Google 태그 관리자：tagmanager.google.com/

분석：analytics.google.com/

구글 태그 관리자
Google 태그 관리자(GTM)는 Google에서 개발하고 제공하는 태그 관리 시스템입니다. 이를 통해 웹사이트 관리자는 웹사이트 코드를 수정하지 않고도 다양한 추적 코드, 분석 코드, 마케팅 태그를 관리하고 배포할 수 있습니다. GTM을 사용하면 사용자는 개발자에게 의존하지 않고도 태그를 쉽게 추가, 업데이트, 삭제할 수 있습니다.

GTM의 주요 기능은 다음과 같습니다.
일반 영어로 말하면, 이 플랫폼은 프런트 엔드에서 트리거된 숨겨진 이벤트를 수집하는 데 사용되며 트리거 조건 및 트리거 이벤트 콜백을 사용자 정의하여 데이터 보고를 실현할 수 있습니다. 여기서는 데이터를 수집하고 이를 Google Analytics에 보고하는 데 사용됩니다.

구글 애널리틱스
이름에서 알 수 있듯이 데이터를 수집하고, 보고, 표시하는 데 사용되는 웹사이트입니다.