質問
Exploreでレポートを作成しました。レポートからチケットタグを除外しようとしているときに、フィルターパネルでタグ属性を追加すると、結果が予期せず増加または変化します。複数のタグでレポートをフィルターすると、メトリック値が変わるのはなぜですか？
回答
バックグラウンドでの計算に慣れていない場合、フィルターパネルで複数のタグに関するレポートを作成すると、予期しない動作が発生する可能性があります。
または、特定のタグを持つチケットをレポートから除外するには、それらのタグを持つチケットと持たないチケットを説明する標準ユーザー 定義メトリック を作成するか、フィルターとして使用する 標準ユーザー定義属性 を作成します。
詳細
前述のメトリック値の増加は、Exploreがメトリックの結果をスライスするために属性を使用する方法が原因で発生します。何が起こっているのかを理解するために、「行」パネルと「フィルター」パネルで属性を追加した場合の動作を見てみましょう。
Exploreは、行（または列）パネルで属性が追加されたときに、フィルターパネルで属性が追加された場合と同じ計算を実行します。ただし、前者はレポートに目に見える変化をもたらしますが、後者はそうではありません。これにより、舞台裏で何が起こっているのかを理解することが難しくなります。
以下のセクションでは、この問題の例について説明します。
COUNT集計方法を使用した場合の結果
タグ属性が行パネルに追加されると、結果は次のようになります。
上のレポートでは、「 チケットタグ 」属性が行パネルに追加され、2つの値（「apple」と「banana」）でフィルタリングされています。ご覧のように、2つのチケットがあり、それぞれに両方のタグが付いています。Exploreは結果を3つの列に分割します。最初の列には2つのチケット、2番目の列には2つのタグ（各チケットに繰り返し表示）、3番目の列には各タグが各（1）チケットに存在することが表示されます。
ただし、 チケットID 属性を削除し、 チケットタグ 属性をフィルターパネルに移動すると、結果は次のようになります。 
このレポートでは、「 チケットタグ 」属性が「apple」と「banana」の値でフィルタリングされています。ここで、Exploreは各タグが追加されるチケットの数を計算しています（2タグ x 2チケット = 4チケット）。つまり、レポートの最初のバージョンの3番目の列の値を合計しています。この結果は、Exploreの計算に不慣れなユーザーにとって直感的ではなく、混乱や誤ったデータレポートの原因となる可能性があります。
SUM集計方法を使用するとどうなるか
タグ属性が行パネルに追加されると、結果は次のようになります。
上のレポートでは、 チケットタグ 属性が行パネルに追加され、2つの値（「統合により終了」および「組織__is_信頼」）でフィルタリングされています。ご覧のように、2つのチケットがあり、それぞれに両方のタグが付いています。Exploreでは、結果を3つの列に分割します。最初の列には2つのチケット、2番目の列には2つのタグ（各チケットで繰り返し表示されるタグ）、3番目の列には各チケットの全体の解決時間を示します。
ただし、「 チケットタグ 」属性を「フィルター」パネルに移動すると、結果は次のようになります。
このレポートでは、「 チケットタグ 」属性は引き続き「closed_by_merge」および「org__is_trusted」の値でフィルタリングされています。しかし、Exploreは各タグのチケットの全体解決時間の値を合計しているため、誤って各チケットの全体解決時間を2倍にしています。
AVG集計方法を使用した場合の影響
タグ属性が行パネルに追加されると、結果は次のようになります。
上のレポートでは、 チケットタグ 属性が行パネルに追加され、2つの値（「統合により終了」および「組織__is_信頼」）でフィルタリングされています。この場合、3件のチケットがあり、1件には一方のタグのみが含まれ、2件には両方のタグが含まれています。繰り返しますが、Exploreは結果を3つの列に分割します。最初の列には3つのチケット、2番目の列には2つのタグ（最初のチケットには1つのみ存在するタグ）、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など）では機能しません。
- 一度に1つのタグでフィルターします。レポートのニーズに応じて、一度に1つのタグのみでレポートをフィルタリングできます。ただし、複数のタグが必要なチケットを見つけることにユースケースが依存している場合は、この方法は機能しません。
翻訳に関する免責事項：この記事は、お客様の利便性のために自動翻訳ソフ トウェアによって翻訳されたものです。Zendeskでは、翻訳の正確さを期すために相応の努力を払っておりますが、翻訳の正確性につ いては保証いたしません。
翻訳された記事の内容の正確性に関して疑問が生じた場合は、正式版である英語の記事 を参照してください。
0 コメント
サインインしてコメントを残してください。