web-dev-qa-db-ja.com

mailchimpapiで今のところこれ以上のサインアップを許可していません

Mailchimp APIを使用して、リストのユーザーの登録を解除しました。次に、MailchimpAPIを使用して同じユーザーを再サブスクライブするための新しいリクエストをすぐに送信します。

私はこのメッセージで400エラーの悪いリクエストを受け取りました：

（...）ごく最近多くのリストにサインアップしたように;今のところ、これ以上の申し込みは許可されていません

新しいクエリをどのくらい待ちますか？これを修正する方法は？

mailchimp
18
Promo

tl; dr

5分後、1日後、2日後、7日後に再試行してください。

（あまりにも）長いバージョン

多数のサブスクライブでこの問題が発生し、次の（役に立たない）応答がありました。

HTTP 400 Bad Request
Server: openresty
Content-Type: application/problem+json; charset=utf-8
Content-Length: 301
X-Request-Id: {requestId}
Link: <https://us14.api.mailchimp.com/schema/3.0/ProblemDetailDocument.json>; rel="describedBy"
Date: {date}
Connection: close
Set-Cookie: _AVESTA_ENVIRONMENT=prod; path=/

{
    "type": "http://developer.mailchimp.com/documentation/mailchimp/guides/error-glossary/",
    "title": "Invalid Resource",
    "status": 400,
    "detail": "{email} has signed up to a lot of lists very recently; we're not allowing more signups for now",
    "instance": "{instance}"
}

リンクされたエラー用語集 もあまり役に立ちません：

400

要求の形式が正しくありません

リクエストを処理できませんでした。

これは一般的なエラーです。

実験を始めましょう！

MailChimp APIを直接呼び出すことから、すべてのサブスクライブ要求をデータベースに保存することに切り替えました（これは、ずっとやっていたはずです）。このテーブルは次のようになります。

CREATE TABLE `subscribes` (
  `id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
  `email` varchar(254) NOT NULL,
  `json` varchar(500) NOT NULL,
  `subscribed` datetime NOT NULL,
  `ip` int(10) unsigned NOT NULL,
  `retry` datetime DEFAULT NULL,
  `attempts` int(11) DEFAULT 0,
  `synced` datetime DEFAULT NULL,
  `failed` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `unsynced` (`synced`,`failed`,`retry`,`id`)
);

次に、次のようなクエリと同期する必要があるサブスクライブを定期的にチェックするcronジョブを設定します。

SELECT `id`
FROM `subscribes`
WHERE `synced` IS NULL
AND `failed` IS NULL
AND (`retry` IS NULL OR `retry` < UTC_TIMESTAMP())

サブスクライブごとに、attemptsがインクリメントされます。サブスクライブが機能する場合、syncedは現在のタイムスタンプで更新されます。それ以外の場合、retryはattemptsの値に基づいて将来の日付に設定されます。試行がなくなった場合は、failedが現在のタイムスタンプに設定されます。

（最新の試行後の）最初の遅延セットは次のとおりです。

  • 5分
  • 1時間
  • 6時間
  • 1日
  • 2日
  • 7日

サブスクライブがこれらの遅延で完全に再試行されるには、10日、7時間、および5分かかります。

現在、テストはまだ約3週間ですが、有益な結果が得られたので、今ここに投稿すると思いました。

after last | after first | % subscribed
-----------|-------------|-------------
-          | -           | 73.45%
5 minutes  | 5m          | 73.61%
1 hour     | 1h 5m       | 73.61%
6 hours    | 7h 5m       | 73.61%
1 day      | 1d 7h 5m    | 78.43%
2 days     | 3d 7h 5m    | 96.15%
7 days     | 10d 7h 5m   | 99.49%

遅延を短くすると、ネットワークエラーやMailChimp apiの一時的な問題（かなりまれです）を回避できます。遅延を長くすると（1日以上）、「今のところサインアップを許可しない」問題を回避できます。 MailChimpで「成功」して「クリーン」とマークされたサブスクライブはまだ少数でしたが、それは予想されることであり、大多数は正常にサブスクライブされました。

私の（非公式の）推薦

新しいクエリをどのくらい待ちますか？これを修正する方法は？

独自のテストを実行して、何が効果的かを確認することをお勧めします。しかし、他の人のために働いた何かをドアから出したいだけなら：

5分後、1日後、2日後、7日後に再試行することをお勧めします。おそらくその後も、サブスクライブの.51％を追加するためにキャッチしますが、それが機能することを確認するためのデータがありません。

5分の遅延により、登録者が.16％増加しました。これは、まもなく送信される電子メールに間に合うように誰かを購読するのに役立ち、「サインアップしたがニュースレターを受信しなかった」という苦情を回避します。これは私たちにとって多くのサブスクライバーを捕らえませんでしたが、MailChimp api（またはネットワーク上のどこか）の停止が短いときのために、これはありがたいことです。

1時間と6時間の遅延は私たちにとって何の役にも立たなかったので、おそらくそれは必要ではありません。ただし、結果は異なる場合があります。繰り返しになりますが、これは短期間の停止の場合に多くなるため、発生するまでの最善の遅延はわかりません。あなたのニーズに最も合うものを決定し、それに合わせてください。

1日の遅延により、サブスクライブする人が4.7％以上増えました（再試行の約11％が成功しました）。これにより、サブスクライブしようとした日にネットワークまたはMailChimp apiの問題が発生した場合、その人は翌日にサブスクライブされます。私がお勧めします。

2日間の遅延により、17.72％以上の登録者が発生しました（再試行の約80％が成功しました）。絶対にお勧めします。

7日間の遅延により、さらに3.34％がサブスクライブされました（再試行の約80％が成功しました）。推奨。

注：1、2、および7日間の遅延を単独でテストすることはまだできていません。それ自体ではそれほど有用ではないかもしれませんが、積み重ねられていることが成功する理由です（たとえば、2日間の遅延は失敗しますが、3日間の遅延は7時間5分で機能します）。

14
0b10011