질문
Explore에서 보고서를 만들었습니다. 보고서에서 티켓 태그를 제외하려고 할 때 필터 창에서 태그 속성을 추가하면 결과가 예기치 않게 증가하거나 변경됩니다. 여러 태그를 기준으로 보고서를 필터링할 때 메트릭 값이 변경되는 이유는 무엇인가요?
답변
백그라운드 계산에 익숙하지 않은 경우에는 필터 창에서 여러 태그에 대한 리포팅을 하면 예기치 않은 동작이 발생할 수 있습니다.
다른 방법으로는 특정 태그가 있는 티켓을 보고서에서 제외하려면 그러한 태그가 있거나 없는 티켓을 설명하는표준 계산된 메트릭을 만들거나 필터로 사용할표준 계산된 속성을 만들 수 있습니다.
추가 설명
위에 설명된 메트릭 값의 증가는 Explore가 속성을 사용하여 메트릭 결과를 세분화하는 방식으로 인해 발생합니다. 어떤 일이 진행되는지 이해하기 위해 로우 창에 속성이 추가된 다음 필터 창에 속성이 추가되면 어떻게 되는지 살펴보겠습니다.
Explore는 행 또는 컬럼 창에 속성이 추가될 때 필터 창에서 속성이 추가될 때와 동일한 계산을 수행합니다. 단, 전자를 사용하면 보고서에 눈에 띄는 변화가 생기는 반면 후자는 그렇지 않습니다. 이로 인해 백그라운드에서 어떤 일이 일어나고 있는지 이해하기가 어렵습니다.
아래 섹션에서 이 문제의 예를 자세히 안내합니다.
COUNT 집계 방식을 사용할 때 일어나는 일
태그 속성이 로우 창에 추가되면 결과는 다음과 같습니다.
위의 보고서에서는티켓 태그속성이 로우 창에 추가되었고 두 가지 값(“사과” 및 “banana”)으로 필터링되었습니다. 각각에 두 태그가 있는 두 개의 티켓이 있는 것을 볼 수 있습니다. Explore는 결과를 3개 열로 나눕니다. 첫 번째 열은 두 개의 티켓을, 두 번째 열은 두 개의 태그(각 티켓에 대해 반복)를 보여주며, 세 번째는 각 티켓에 각 태그가 있는 것으로 보여줍니다.
하지만티켓 ID속성을 제거하고티켓 태그속성을 필터 창으로 옮기면 다음과 같은 결과가 나타납니다. 
이 보고서에서티켓 태그속성은 “apple” 및 “banana” 값으로 계속 필터링됩니다. 여기에서 Explore는 각 태그가 추가되는 티켓의 수를 계산합니다(2개의 태그 x 2개의 티켓 = 4개의 티켓). 즉, 보고서의 첫 번째 버전에 있는 세 번째 컬럼의 값을 합산합니다. Explore의 계산에 익숙하지 않은 사용자에게는 이 결과가 직관적이지 않으므로 혼동을 야기하거나 잘못 보고된 데이터가 발생할 수 있습니다.
SUM 집계 방식을 사용할 때 일어나는 일
태그 속성이 로우 창에 추가되면 결과는 다음과 같습니다.
위의 보고서에서는티켓 태그속성이 로우 창에 추가되었고 두 가지 값(“closed_by_merge” 및 “org__is_trusted”)으로 필터링되었습니다. 각각에 두 태그가 있는 두 개의 티켓이 있는 것을 볼 수 있습니다. Explore는 3개의 열로 결과를 보여주며, 첫 번째는 두 개의 티켓, 두 번째는 두 개의 태그(각 티켓에 대해 반복), 세 번째는 각 티켓의 전체 해결 시간을 보여줍니다.
하지만티켓 태그속성을 필터 창으로 이동하면 다음과 같은 결과가 나타납니다.
이 보고서에서티켓 태그속성은 “closed_by_merge” 및 “org__is_trusted” 값으로 필터링됩니다. 하지만 이 경우 각 태그에 대한 티켓의 전체 해결 시간 값을 합산하기 때문에 Explore가 각 티켓의 전체 해결 시간이 두 배로 늘어나는 잘못이 있습니다.
AVG 집계 방식을 사용할 때 일어나는 일
태그 속성이 로우 창에 추가되면 결과는 다음과 같습니다.
위의 보고서에서는티켓 태그속성이 로우 창에 추가되었고 두 가지 값(“closed_by_merge” 및 “org__is_trusted”)으로 필터링되었습니다. 이 경우 티켓 3개가 나오는데 그 중 1개에는 둘 다 태그가 있는 티켓이 2개 있습니다. 역시 Explore는 3개의 컬럼으로 결과를 보여줍니다. 첫 번째 컬럼은 3개의 티켓, 두 번째 컬럼은 두 개의 태그(그 중 하나만 첫 번째 티켓에 있음), 그리고 세 번째 컬럼은 각 티켓의 전체 해결 시간을 보여줍니다.
티켓 태그속성을 필터 창으로 이동하면 다음과 같은 결과가 나타납니다.
이 시점에서도 결과는 여전히 정확합니다. 티켓 ID를 기준으로 결과가 세분화되므로 Explore는 각 티켓에 대한 올바른 전체 해결 시간을 표시합니다. 하지만티켓 ID속성을 제거하는 경우에는 다음과 같이 나타납니다.
이 보고서에서 3개의 티켓의 평균 전체 해결 시간이 올바르게 계산되지 않고 있습니다. 이전 보고서의 전체 해결 시간 값을 계산할 때 올바른 계산은 다음과 같습니다.
- (36 + 54 + 23) / 3 = 38분
대신 Explore는 SUM 집계 방식과 유사한 각 태그 인스턴스의 전체 해결 시간 값을 포함하여 다음과 같이 계산합니다.
- (36 + 54 + 54 + 23 + 23) / 3 = 63분
대신 수행할 작업
결과가 잘못 집계되는 것을 방지하려면 대신 다음 방법 중 하나를 사용하면 됩니다.
- 계산된 속성을 만듭니다. 여러 태그를 찾도록 특별히 디자인된 수식으로 계산된 속성을 만들 수 있습니다. 도움말은 태그로리포팅문서에서여러 태그가 있는 티켓 찾기섹션을 참조하세요.
- D_COUNT 집계 방식을 사용하세요. 티켓 수와 같은 개수 기반 메트릭의 경우에는 항상 고유 값을 반영하는 D_COUNT 집계 방식을 사용할 수 있습니다. 도움말은메트릭 집계 방식 선택하기문서를 참조하세요. 하지만 시간 기반 메트릭(예: 첫 번째 응답 시간)이나 기타 집계 방식(예: SUM, AVG 및 MED)에는 이러한 방법이 적용되지 않습니다.
- 한 번에 하나의 태그를 기준으로 필터링합니다. 리포팅 필요에 따라 한 번에 하나의 태그만 기준으로 보고서를 필터링할 수 있습니다. 하지만 여러 태그가 있어야 하는 티켓을 찾는 사용 사례에 의존하는 경우에는 그렇지 않습니다.
번역 고지 사항: 본 문서는 콘텐츠에 대한 기본적인 이해를 제공하기 위해 자동 번역 소프트웨어를 사용하여 번역되었습니다. 정확한 번역을 제공하고자 합당한 노력을 기울였으나 Zendesk는 번역의 정확성을 보장하지 않습니다.
번역된 문서에 포함된 정보의 정확성과 관련하여 질문이 있으시면 문서의 공식 버전인 영문 버전을 참조하시기 바랍니다.