问题
我想建立报告，显示在我的每个支持地址收到的票的数量。我想根据收到票的支持地址来过滤我的报告。是否有一个指标或属性，我可以用来报告收到的支持电子邮件地址?
回答
是的。在支持-门票数据集，你可以使用购票邮件地址属性以报告此信息。该属性于2022年12月添加。
在此之前，不可能报告收到票的电子邮件地址，因为没有收到票的电子邮件地址的属性。前面提供了以下解决方案。
之前的解决方案
作为一种变通方法，创建一个触发器来设置自定义字段或添加标记。然后，您可以使用该字段或标记来识别报告中的收货地址。
设置跟踪接收地址的自定义字段
- 创建下拉票务栏。
- 创建一个触发
- 下满足以下所有条件，增加以下条件:
- 票| Is | Created
- 收到在|(支持地址)
- 下行动，添加以下动作:
- (自定义字段标题)|(值)
- 通过对每个地址和相关的下拉选项重复步骤2到4，为每个支持地址创建一个唯一的触发器。
如果你想用标签来跟踪你的收货地址，跳过步骤1，用标签跟踪步骤2到步骤5行动，添加标签|
(your_unique_tag)代替。
11日评论
我对此有些不满。这是一种借口，实际上是不正确的。
“不可能报告收到罚单的电子邮件地址，因为没有一个衡量罚单收到地址的指标。”
接收到的时间不是度量，接收到的时间是属性。度量是票的数量。是的，在zendesk中有一个关于票的属性。亚博出于某种疯狂的原因，您拒绝在要同步探索的票证数据中包含此属性。它在Gooddata中已经存在很多年了，但你一直固执地，似乎没有很好的理由，一直避免添加它来探索很长一段时间——有很多问题和产品建议，都有很多牵引力和用户请求，但什么都没有。
你的工作也不包括历史门票，这是非常有限的，令人沮丧的。
我建议你更新你的答案，因为它是不正确的，我还建议你尽快实施这个，因为对它的需求是巨大的，没有很好的理由提供为什么它不能做。
我完全同意上面的观点，收货时间是票证数据中的一个重要属性，所以在Explore中不包含这一点对我来说没有多大意义。如上所述，我想报告历史票，这根本不可能通过您建议的解决方案。
火上浇油——更糟糕的是，“收货地址”实际上是两个地址，而不是一个。一个地址是Zendesk作为收件人分配的地址，如果列出亚博了多个系统地址，则它实际上是TO行中的第一个系统地址，另一个地址是电子邮件通过Exchange发送到的Zendesk系统地址。这两个地址不相同，也不一致，因为请求者在TO行中以任何顺序放置的内容与Exchange决定如何发送的内容非常不同。如果您的请求者只发送到一个地址，那么没有问题，但是当他们发送到您的两个或更多地址时，就会出现这种不可能的情况。
该字段需要拆分，以便这两个值分开，并完全同意该值需要在Explore中。由于我上面描述的内容不一致，并且由于无法通过任何API获得此值，因此无法确定真正的“接收地址”电子邮件地址，因此在UI中通过API和Explore将这两个地址识别为变量的方法至关重要。我发现解决这种情况的唯一方法是为每个系统地址(即每个外部公司域名地址和每个zendesk系统地址)创建单个触发器。亚博在我们的例子中，这将涉及成百上千个触发器(最终是数千个)，以确定接收什么/如何接收电子邮件。
无法接受……修复这个Zende亚博sk!
我们已经实现了我们自己版本的“通过创建”，其中包括跟踪哪些“收到@电子邮件”，以及关于手动票务与真正由请求者在帮助中心提出的票务的更多细节。虽然这样可以工作，但这意味着每次我们向实例添加一个received@电子邮件时都要进行维护。如果在Explore中接收@作为属性，就像在View中一样，那将非常有帮助。
我正在努力把我们的不同实例结合起来。我需要这个是为了纪念历史，而不是为了新票。我很困惑为什么这个不能用。有人找到解决历史票的方法了吗?
你能提供更多关于你的商业案例和你想要实现的目标的细节吗?
@奥利弗·怀特(行政)
_____________________________________________
正确的!我们也在进行迁移，并且上述解决方法并不适用于所有旧票据。
解决方案是追溯的，我们希望这个属性很快可用。
@胡里奥·R。
我们最近收购了另一家公司，并将他们的团队版Zendesk迁移到我们的企业版。亚博他们有7个支持地址，有能力在收到的@上运行一个探索报告，将使我们知道每个地址的使用情况。目前有三个捕获所有地址，因为我们不能通过触发器搜索(因为它们不添加标签)，所以除了查看视图之外，没有其他方法可以给我们每个支持地址的流量水平。
对于未来的工作，我们希望跟踪每个支持地址的总流量，这是我们做不到的，我们有超过160个触发器，所以在每个中添加一个标签，然后跟踪每个标签是什么，这样我就可以逆向工程，这些标签等于这个地址似乎是一个巨大的提升，当你可以启用数据点时，这不是改变的东西，所以它只需要出现在一个数据集中。如果你需要更多的细节，请告诉我。
谢谢你！
我鼓励你投票支持以下功能请求:报告收到的电子邮件地址。
高参与度的对话会被标记出来供产品经理审查。
根据回溯性的解决方案，目前我建议使用 API并在外部创建报告。房地产收件人指定票务的原始收件人电子邮件地址(Zendesk支持地址)。亚博
谢谢!我会试试的。
这是一个噩梦般的解决方法，但我必须这样做…
请登录留下评论。