门票解决了更新历史探索数据集的度量差异
我对我在探索中看到的东西有点困惑。
我试图验证在我的组织每组解决票的总数。
我所看到的文章建议我使用支持更新历史数据集来查看创建和解决的票据数量。
然而，由于我从来没有真正对探索中的数据有信心，所以我用Support Ticket data Set验证了这一点。
正如预期的那样，数据并不匹配。
有人会向我解释为什么当我看相同的信息，总票创建和总票解决我有4个完全不同的数字?
-
官方的评论
内森Cassella谢谢你与社区分享这个问题。我们会在你提到的配方中添加一些关于这种行为的注释。
CJ约翰逊格雷姆·卡迈克尔，感谢您的帮助和调查这个问题。
ticket和Updates历史数据集中的这些指标存在差异有两个原因。1日的原因
的票数据集不包括任何已删除的票据，除了更新历史记录所做的事。如果要从报表中删除已删除的票据，则需要在报表中使用一些票据级别的属性，例如机票状态或票组。由于与tickets表的连接，已删除的票据将被删除。如果您想更好地理解数据集的结构，请参考本文Zendesk支持的度量和属性亚博。
第二个原因
为了捕获唯一的创建和解析事件，我们使用字段更改数据。
- 捕获此事件对于票了度量，因为当票据状态从NULL设置为某些值时，只有一个事件。所以,票了公制通常是相当准确的。它可能不准确的唯一原因是，当通过API错误地创建帐户中的票证时，原始票证状态不是NULL。
- 的解析事件票解决度量更复杂，因为每个票证有多个解决事件。为了仅捕获最后一个分辨率事件，默认度量使用此条件"[Update - Timestamp]=[Ticket solved - Timestamp]"。问题是，在极少数情况下，这两个时间戳不相等。发生这种情况是因为这些时间戳不是同时记录在票证API中，而是一个接一个地记录。我们目前发现的最佳解决方案是创建一个使用此公式的自定义门票解决指标，并使用D_COUNT聚合器将其添加到报告中:
IF ([change - Field Name]="status")
和[更改-先前的值]!= "解决"
AND([更改-新值]="已解决"或[更改-新值]="已关闭")
AND([票状态-未排序]=“已解决”或[票状态-未排序]=“已关闭”)
AND [Update - Date]=[Ticket Solved - Date]
AND [Update - Minute]=[Ticket Solved - Minute])
然后[更新票证ID]
ENDIF我们将回顾用于默认值的公式更新历史记录2023年初的指标，如果有更好的配置，将更新它们。
结论
- 如果您想获得在您的帐户中创建和解决的现有票据数量的100%准确统计信息，请使用票数据集。创建两个独立的报告，一个由票证创建日期过滤，另一个由票证解决日期过滤。
- 如果要比较同一报表中的票据创建量和解析量，请使用更新历史记录数据集，但要注意这些统计是99%准确的。
-
内森
我可以重现这个。
支持更新历史数据集中Tickets_Solved的度量定义为:
IF([更改-字段名]="status")
AND[更改-先前的值]!= "解决"
AND([更改-新值]="已解决"或[更改-新值]="已关闭")
AND([票状态-未排序]=“已解决”或[票状态-未排序]=“已关闭”)
AND [Update - Timestamp]=[Ticket solved - Timestamp])
然后[更新ID]
ENDIF对于已知已解决的票据，不返回票据ID。它与条件的最后一行有关:
AND [Update - Timestamp]=[Ticket solved - Timestamp]
由于某种原因，这会导致计数失败。
您最好直接联系Zendesk支持人员。亚博
您可以创建自己的度量作为解决方法。用另一种检查日期匹配和返程机票ID(而不是更新ID)的方式替换最后一个条件。
IF([更改-字段名]="status")
AND[更改-先前的值]!= "解决"
AND([更改-新值]="已解决"或[更改-新值]="已关闭")
AND([票状态-未排序]=“已解决”或[票状态-未排序]=“已关闭”)
AND DATE_DIFF ([Update - Timestamp]，[Solved Timestamp]，"nb_of_seconds")=0
）
然后[机票ID]
ENDIF -
我也可以重现这个。这绝对是一个影响每个人的问题。
编辑:我做了一些挖掘，它似乎很挣扎，不计算不止一次解决的票，即使第二次解决是在指定的时间范围内。 -
我很感激你把事情弄清楚。
我有几点建议:
1.在定义门票创建和门票解决时，在所有数据集使用相同的逻辑:这些数字太重要了，甚至不能有1%的差异。
2.在所有数据集中为已删除的票据创建一个度量:这本身是一个有用的度量，但是构建一个自定义度量来从计数中提取它是大量不必要的工作。
-
这个答案不准确。请进一步调查这个问题。我也进行了调查，很明显问题不是我删除了票据，而是更新数据集不正确地不计算在所选时间段内解决的票据，如果它们以前已经解决了。我还能够编写一个自定义指标，该指标能够正确运行并返回该数据集上的正确数字。建议的度量并不能解决这个问题。
我不明白为什么Zendesk会故意留下一个糟糕亚博的指标，返回误导性、不正确的数据。我认为任何数据集的准确度低于100%都是完全不可接受的。这些指标直接影响代理商的雇佣和解雇。这里应该有一种强烈的责任感来确保准确性。
编辑:如果您需要进一步的证明，您可以使用更新历史数据集上的Ticket Solved过滤器重新创建此问题，“Ticket Created”不是调用此问题的必要组件。 -
作为后续，建议的解决方案是，如果票被多次解决，则重复计数解决。当我看到它返回比默认数据集更多的解决方案时，我很怀疑。
这不是“ticket Solved”指标应该返回的结果，因为该报告要求的是解决的ticket的数量，而不是发生的解决的数量。因此，不应该使用“update_id”作为返回值。 -
我同意你的看法;我主要担心的是，任何反映ticket Created或Solved的数据集都需要使用相同的计算，但事实并非如此。因此，如果我被告知使用默认票据数据集，因为它是准确的，那么我将使用它来获取下周向执行领导团队演示所需的数据。
根据回复，有两种方式进行:
1.使用Ticket默认设置和括号来查看更新。这是一个解决方法，至少可以看到第一次回复和第一次解决，但前提是用于计算这些括号的逻辑是可信的(我不相信)。当我们在使用它的时候，我们希望Zendesk能够真正解决这个问题，而不是让它亚博最终陷入开发的地狱(就像Round Robin票务进入测试版花了14年的时间)。
2.(更好的选择)使用一个真正的报告系统，比如PowerBI或它的竞争对手，从Zendesk的后端提取你想要的数据。亚博在接下来的几年里，我可能会把我的组织搬到这里。
-
由于尤金
希望这个默认度量可以被更新。
-
谢谢你对这个问题的跟进。
对不起，我忘记更新公式的THEN子句了。它需要计算票证id，而不是更新id，以避免重复计算。我已经更新了我上面建议的计算度量公式。公式应该以“THEN[更新票证ID] ENDIF”结束，而不是以“THEN[更新票证ID] ENDIF”结束。
而且，我想我找到了一个让公式更精确的方法。请尝试这个公式，让我知道它是否会返回更准确的数字在你的帐户:IF([更改-字段名]="status")
AND[更改-先前的值]!= "解决"
AND([更改-新值]="已解决"或[更改-新值]="已关闭")
AND([票状态-未排序]=“已解决”或[票状态-未排序]=“已关闭”)
AND DATE_TO_TIMESTAMP([Update - Timestamp])>=DATE_TO_TIMESTAMP([Ticket solved - Timestamp]))
然后[更新票证ID]
ENDIF -
同意上面的一些评论:即使数据准确性有1%的差异，当度量描述(即创建，解决)相同时，结果也不一致。另外，我注意到在不同的日期打开报表返回的数据结果是不同的。虽然在solved(票据可以设置为solved并重新打开)上可能会有一些可变性，但对于创建这样的度量，票据只有一个创建日期。当使用完全相同的过滤器打开带有此指标的报告时，创建的票证数量应该相同。但同样，这可能是由于混淆的本质相同的描述符可能意味着不同的东西取决于你所看的数据集。不管正确与否，我们实际上每周都会在另一个系统中导出我们的数据。这确保了我们报告的是一致的历史数据。
请登录留下评论。
10评论