【第19回】 Journey Builder を使って「毎月の月初」に送信する方法
Salesforce Marketing Cloud の Journey Builder において、毎月の月初となる 1 日（ついたち）に送信したい場合は、どうすれば良いでしょうか？
Journey Builder には、待機アクティビティという「◯日間」待機するというアクティビティがあります。「分・時間・日・週・月」が選択が可能ですので「1 ヶ月」待機という設定自体は可能です。
まず、この待機アクティビティを用い、下記のようなジャーニーを作成してみました。ここでは、例として、8 月 1 日、9 月 1 日、10 月 1 日、11 月 1 日、12 月 1 日、1 月 1 日の 6 ヶ月間の送信で検討してみます。
上記の設定で、無事に成功するでしょうか？
実はこちらのシナリオだと、シナリオを開始する時間によって「成功」と「失敗」との明暗が分かれます。
どういうことかと言いますと、Salesforce Marketing Cloud を管理するサーバは、システム日付として CST（米国中部標準時）を採用しています。その関係で、日本のタイムゾーンである JST（日本標準時）との時差が、15時間あるわけですが、このことが、このシナリオに大きく影響してきます。
待機アクティビティの待機時間は、その計算に入る際に、一度 CST に戻り、CST で計算がされる習性があります。
うーんと・・・？ 何だかよく分かりませんね。。。何が言いたいかと言いますと、下記のようなイメージです。
ここで例として、配信時間を「14 時」とするシナリオで考えます。
まず最初のメールを、8 月 1 日の 14 時に送信します。この時は、まだ JST です。これを、まずは CST に変換します。ここで 15 時間前の計算をすることになりますので、CST では 7 月 31 日 23 時となります。そして、この状態から 1 ヶ月の計算が入ります。1 ヶ月後は CST で 8 月 31 日 23 時となりますね。そして、これを日本時間の JST にまた戻すことになりますので、JST では 9 月 1 日 14 時に送信となります。
JST 8月1日14 時 > CST 7月31日23時 > CST 8月31日23時 > JST 9月1日14時
カレンダー通り 1 ヶ月後に送信できましたね。それでは引き続き、翌月にどうなるか見てみましょう。9 月には 31 日がありませんので、CST への 1 ヶ月後の変換では、CST 9 月 30 日 23 時となります。この月も 10 月 月初の 1 日 14 時に送信となりますので、問題なさそうです。
JST 9月1日14 時 > CST 8月31日23時 > CST 9月30日23時 > JST 10月1日14時
さらに翌月分も同様に確認します。
JST 10月1日14時 > CST 9月30日23時 > CST 10月30日23時 > JST 10月31日14時
あれっ。。。？
送信が 10 月 31 日 14 時送信になってしまいました。では、この翌月は、どうでしょう。
JST 10月31日14時 > CST 10月30日23時 > CST 11月30日23時 > JST 12月1日14時
おっ！また、12 月 1 日 14 時送信に戻りました！では、翌月は！？
JST 12月1日 14時 > CST 11月30日 23時 > CST 12月30日 23時 > JST 12月31日 14時
ここでも月初ではなく、12 月 31 日 14 時となりました。このように、月初にならない月が発生します。これが「失敗」の例です。
では、待機アクティビティを使った場合で「成功」する例とは、どのような場合でしょうか？それは、日本の場合は 15 時以降（〜 24 時まで）の送信の場合です。
① JST 8月1日15時 > CST 8月1日0時 > CST 9月1日0時 > JST 9月1日15時
② JST 9月1日15時 > CST 9月1日0時 > CST 10月1日0時 > JST 10月1日15時
③ JST 10月1日15時 > CST 10月1日0時 > CST 11月1日0時 > JST 11月1日15時
④ JST 11月1日15時 > CST 11月1日0時 > CST 12月1日0時 > JST 12月1日15時
⑤ JST 12月1日15時 > CST 12月1日0時 > CST 1月1日0時 > JST 1月1日15時
このように成功します。①～⑤のすべてが、1 日（ついたち）の「15 時」送信となっていますね。
というわけで、待機アクティビティの待機時間「1 ヶ月」を使う場合は、15 時～ 24 時に使用する場合は成功しますが、0 時～ 14 時に送信する場合は、失敗します。
念の為、0 時～ 14 時の「失敗」の場合も、同じようにまとめておきますね。参考にしてください。
① JST 8月1日14時 > CST 7月31日23時 > CST 8月31日23時 > JST 9月1日14時
② JST 9月1日14時 > CST 8月31日23時 > CST 9月30日23時 > JST 10月1日14時
③ JST 10月1日14時 > CST 9月30日23時 > CST 10月30日23時 > JST 10月31日14時（←これが失敗している）
④ JST 10月31日14時 > CST 10月30日23時 > CST 11月30日23時 > JST 12月1日14時
⑤ JST 12月1日14時 > CST 11月30日23時 > CST 12月30日23時 > JST 12月31日14時（←これが失敗している）
🙆♂️ 解決策
では、根本的に、このようなトラブルを解決する B 案もご紹介します。
これを根本的に解決するには、シナリオの定期スケジュールを毎月 1 日に設定することです。下記のようなイメージです。
これで実行した場合は、そもそも「待機アクティビティ」を使用していませんので、前述した「待機アクティビティ上の計算」はありませんので、仮に14 時送信でも、以下のような形となり、問題なく成功となります。
① JST 8月1日14時
② JST 9月1日14時
③ JST 10月1日14時
④ JST 11月1日14時
⑤ JST 12月1日14時
⑥ JST 1月1日14時
それでは、月初のパターンは、このようになりましたが、月末のパターンはどうなりますかね？それは、また次回の記事で書いてみます。
今回は以上です。