简体繁体 English

SendGrid stats API 延迟定义

[英]SendGrid stats API deferred definition

原文 2022-09-09 16:37:49 0 1 twilio/ sendgrid/ sendgrid-api-v3

In the SendGrid stats API documentation, it states the response property stats.metrics.deferred refers to "The number of emails that temporarily could not be delivered".在 SendGrid stats API 文档中，它指出响应属性 stats.metrics.deferred 是指“暂时无法传递的电子邮件数量”。 I'm looking for a more precise definition, as I expect this is based on an interpretation or two.我正在寻找一个更精确的定义，因为我希望这是基于一两个解释。

For example, when I export the activity for a given time period, I can see activity where event=deferred in the export while the stats.metrics.deferred does not have a value for the same time period.例如，当我导出给定时间段的活动时，我可以在导出中看到 event=deferred 的活动，而 stats.metrics.deferred 在同一时间段内没有值。

One thing I noticed is that it appears "unable to get mx info" causes 4 deferrals before soft bouncing the message.我注意到的一件事是它似乎“无法获取 mx 信息”导致 4 次延迟，然后才软弹回消息。 I can understand why these deferrals would likely not want to be counted due to the reasoning behind them and that they ultimately were soft bounced.我可以理解为什么这些延期可能不想被计算在内，因为它们背后的原因是它们最终被软退回。

The second thing I noticed is that we do have a few instances where it appears minor throttling occurred, as I see a deferral for "450 4.5.9 Greylisted, please try again later" that ultimately was delivered after being deferred a 2nd time;我注意到的第二件事是，我们确实有一些似乎发生了轻微限制的情况，因为我看到“450 4.5.9 Greylisted，请稍后再试”的延迟，最终在第二次延迟后交付； causing a ~90 seconds delay.造成约 90 秒的延迟。

The second item mentioned not being counted in the deferred stats is making me think that "temporarily could not be delivered" has a more technical answer;提到的第二项未计入延迟统计数据使我认为“暂时无法交付”有一个更技术性的答案； hoping someone has already looked into this.希望有人已经对此进行了调查。

1 个解决方案

I am not 100% sure on this, so if you want to properly check why deferrals were not appearing in your stats, I would get in touch with SendGrid support .我对此不是 100% 确定的，所以如果你想正确检查为什么延期没有出现在你的统计数据中，我会联系SendGrid 支持。

My interpretation of why this happened is that the stats should ultimately add up to be 100% of the emails you sent.我对为什么会发生这种情况的解释是，统计数据最终应该占您发送的电子邮件的 100%。 In your explanation, you had several emails that were deferred and ultimately bounced or were delivered.在您的解释中，您有几封电子邮件被推迟并最终退回或送达。 Since those emails had reached a different termination state, they were described as that state in the stats.由于这些电子邮件已到达不同的终止 state，因此在统计信息中将它们描述为 state。 I would guess that if you ran your stats request before those emails entered their final state and were still being retried, they would show as deferrals in the report.我猜想，如果您在这些电子邮件进入最终 state 并且仍在重试之前运行您的统计请求，它们将在报告中显示为延期。

If you want to track emails as they go through the states, I recommend looking into the Event Webhook , which will be fired as emails enter different states.如果您想通过状态跟踪电子邮件 go，我建议查看Event Webhook ，它将在电子邮件进入不同状态时触发。