当状态为
unsubscribed
的联系人再次尝试使用同一邮件地址订阅时,我会发送状态为 pending
的 PUT 请求,以触发选择加入流程。
突然确认邮件停止发送。联系人从取消订阅切换为待处理,但没有机会确认其订阅。
这是代码的缩短版本:
<?php
$member_response = $MailChimp->get("lists/$list_id/members/$subscriber_hash"); // <-- Returns an array where status is `unsubscribed`
if($member_response['status'] == 'unsubscribed' || $member_response['status'] == 'pending') {
// User exists but is not active. Do a PUT request with new values to trigger re-opt-in
$update_response = $MailChimp->put("lists/$list_id/members/$subscriber_hash", $member_data); // <-- Returns an array where status is `pending`
}
?>
再次将现有订阅者设置为
pending
时,不应该发送确认邮件吗?为了跟进我之前的评论,这里总结了我本月初从 MailChimp 得到的答案。
和 [电子邮件受保护] 将被计为两个单独的地址,因为它们生成不同的订阅者哈希(如 API 端点中使用的那样)。 (在测试过程中,我经常使用我的一个地址,并更改它的末尾来表示日期,使用计数器等。)他们实际上告诉我,它们“不”被算作唯一地址:控制注册限制的算法将它们解析为同样的地址,这是我没想到的。 最后,他们的 API 帮助台(他们会发送及时且礼貌的回复 - 您也不需要有帐户即可给他们写信)能够临时为您手动检查个人地址的状态.
我的印象是 MailChimp 希望推动人们使用他们的第 3 方托管/可嵌入表单来处理注册,而不是使用 API。 从字里行间看出,考虑到免费套餐和他们现在拥有的客户数量,我想知道他们是否已经成为大量垃圾邮件投诉/黑名单的接收端。
虽然 v3 API 在架构上比之前的版本有了很大的改进,但更新代码(在我的例子中包括 WordPress 插件)来使用它是一项相当大的工作,并且存在多个未通知和/或临时通知的情况近年来 MailChimp 产品发生了颠覆性变化; Mandrill 的停产、API 服务器上过时的安全证书等。
实际上,我很难想到另一个 3 方服务,它反复需要这么多的开发时间,只是为了保持一小部分 API 功能的运行(订阅、取消订阅和兴趣小组,就我的客户而言)。这与其说是对产品质量的评论,不如说是对它为开发人员带来的工作量的评论。
这种情况很可能会持续下去,因此,如果您不想处理诸如无法检测是否存在的情况,我鼓励人们在选择批量电子邮件服务之前仔细考虑当有人收到选择加入确认信息时。
如果您发送 PATCH 请求,确认电子邮件会发送到电子邮件地址,而 PUT 则不会。