질문

Zendesk Explore 에서 보고서를 만들었습니다. 필터 창에서 티켓 태그를 제외하고 태그 속성을 추가하면 결과가 증가하거나 변경됩니다. 여러 태그로 보고서를 필터링할 때 메트릭 값이 변경되는 이유는 무엇인가요?

답변

내부 계산에 익숙하지 않은 경우 필터 창에 여러 태그가 포함된 보고서를 사용하면 예기치 않은 결과가 발생할 수 있습니다.

특정 태그가 있는 티켓을 제외하려면 그러한 태그를 포함하거나 제외하는표준 계산된 메트릭을만들거나 필터로 사용할표준 계산된 속성을만듭니다.

추가 설명

Explore가 속성을 사용하여 메트릭 결과를 세분화하기 때문에 메트릭 값이 증가합니다. 어떤 일이 일어나는지 이해하려면 로우 창과 필터 창에 속성을 추가할 때 어떤 일이 일어나는지 비교해 보세요.

로우(또는 컬럼) 창에 속성을 추가하든 필터 창에 속성을 추가하든 Explore는 동일한 계산을 수행합니다. 로우는 표시되는 보고서를 변경합니다. 필터는 그렇지 않습니다. 이러한 차이로 Explore가 결과를 계산하는 방식을 숨길 수 있습니다.

아래 섹션에서는 이 문제의 예를 보여주며 태그가 COUNT, SUM 및 AVG메트릭 집계 방식으로 작동하는 방식에 대해 설명합니다.

  • COUNT 집계 방식을 사용하면 어떻게 되나요?
  • SUM 집계 방식을 사용하면 어떻게 되나요?
  • AVG 집계 방식을 사용하면 어떻게 되나요?
  • 대신 수행할 작업

COUNT 집계 방식을 사용하면 어떻게 되나요?

로우 창에 태그 속성을 추가하면 다음과 같은 결과가 나타납니다.

위의 보고서에서티켓 태그속성은 로우 창에 있으며 두 개의 값(“사과” 및 “바나나”)으로 필터링됩니다. 두 개의 티켓이 있으며 각 티켓에 두 개의 태그가 있습니다. Explore는 결과를 3개의 열로 나눕니다. 첫 번째 열은 두 개의 티켓을 보여주고, 두 번째 열은 두 개의 태그를 보여주며(각 티켓에 대해 반복됨), 세 번째 열은 각 티켓에 각 태그가 있음을 보여줍니다(1).

티켓 ID속성을 제거하고티켓 태그속성을 필터 창으로 옮기면 다음과 같은 결과가 나타납니다.

이 보고서에서티켓 태그속성은 여전히 “apple” 및 “banana” 값으로 필터링됩니다. 여기에서 Explore는 태그당 티켓 수를 계산합니다(2 태그 x 2 티켓 = 4). 즉, 보고서의 첫 번째 버전에 있는 세 번째 열의 값을 합산합니다. 그러한 결과는 사용자를 혼동시키고 잘못된 데이터로 이어질 수 있습니다.

SUM 집계 방식을 사용하면 어떻게 되나요?

로우 창에 태그 속성을 추가하면 다음과 같은 결과가 나타납니다.

위의 보고서에서티켓 태그속성은 로우 창에 있으며 두 개의 값(“closed_by_merge” 및 “org__is_trusted”)으로 필터링됩니다. 두 개의 티켓이 있으며 각 티켓에 두 개의 태그가 있습니다. Explore는 결과를 3개의 열로 나눕니다. 첫 번째 열은 두 개의 티켓을 보여주고, 두 번째 열은 두 개의 태그(각 티켓에 대해 반복됨)를 보여주며, 세 번째 열은 각 티켓의 전체 해결 시간을 보여줍니다.

티켓 태그속성을 필터 창으로 옮기면 다음과 같은 결과가 나타납니다.

이 보고서에서티켓 태그속성은 여전히 “closed_by_merge” 및 “org__is_trusted” 값으로 필터링됩니다. 여기에서 Explore는 각 태그에 대한 티켓의 전체 해결 시간을 합산하므로 각 티켓의 전체 해결 시간을 잘못 두 배로 만듭니다.

AVG 집계 방식을 사용하면 어떻게 되나요?

로우 창에 태그 속성을 추가하면 다음과 같은 결과가 나타납니다.

위의 보고서에서티켓 태그속성은 로우 창에 있으며 두 개의 값(“closed_by_merge” 및 “org__is_trusted”)으로 필터링됩니다. 이제 3개의 티켓이 있습니다. 하나의 티켓에는 태그 중 하나만 있고, 두 개의 티켓에는 두 태그가 모두 있습니다. Explore는 다시 3개의 열로 결과를 나눕니다. 첫 번째 열은 3개의 티켓을 보여주고, 두 번째 열은 두 개의 태그를 보여주며(첫 번째 티켓에는 하나만 나타남), 세 번째 열은 각 티켓의 전체 해결 시간을 보여줍니다.

티켓 태그속성을 필터 창으로 옮기면 다음과 같은 결과가 나타납니다.

이 시점에서 결과는 정확합니다. 티켓 ID별로 결과가 세분화되므로 Explore에 각 티켓에 대한 올바른 전체 해결 시간이 표시됩니다.

티켓 ID속성을 제거하면 다음과 같은 결과가 나타납니다.

이 보고서에서는 3개의 티켓에 대한 평균 전체 해결 시간이 올바르지 않습니다. 이전 보고서의 값으로 올바른 계산은 다음과 같아야 합니다.

  • (36 + 54 + 23) / 3 = 38분

대신 Explore는 이 계산을 위해 각 태그 인스턴스에 대한 전체 해결 시간 값을 포함합니다.

  • (36 + 54 + 54 + 23 + 23) / 3 = 63분

대신 수행할 작업

잘못된 집계를 방지하려면 다음 옵션 중 하나를 선택하세요.

  • 계산된 속성을 만듭니다. 여러 태그가 있는 티켓을 리턴하는 수식을 사용합니다. 도움말은태그로 리포팅에서여러 태그가 있는 티켓 찾기를참조하세요.
  • D_COUNT 집계 방식을 사용하세요. 티켓 수와 같은 개수 기반 메트릭의 경우 매번 고유한 값을 리턴하는 D_COUNT 집계 방식을 사용합니다. 도움말은메트릭 집계 방식 선택하기를참조하세요. 이 옵션은 첫 번째 응답 시간 과 같은 시간 기반 메트릭이나 SUM, AVG 및 MED에는 작동하지 않습니다.
  • 한 번에 하나의 태그별로 필터링합니다. 필요에 따라 한 번에 하나의 태그별로 보고서를 필터링할 수 있습니다. 여러 태그가 있는 티켓이 필요한 사용 사례에는 이 옵션이 작동하지 않습니다.

번역 고지 사항: 본 문서는 콘텐츠에 대한 기본적인 이해를 제공하기 위해 자동 번역 소프트웨어를 사용하여 번역되었습니다. 정확한 번역을 제공하고자 합당한 노력을 기울였으나 Zendesk는 번역의 정확성을 보장하지 않습니다.

번역된 문서에 포함된 정보의 정확성과 관련하여 질문이 있으시면 문서의 공식 버전인 영문 버전을 참조하시기 바랍니다.

Zendesk 제공