【第126回】 Automation Studio で過去 180 日間で一度もメールを開封していない購読者を定期的に抽出する方法
あなたの組織において、過去 180 日間で一度もメールを開封しなかった購読者は、今後もメールを開封する可能性はありますか？そのような人達をどのように扱うかを真剣に考えたことがありますか？
2023 年 10 月、Google と 米 Yahoo の共同声明が発表されたことで、今、私たちマーケターはこのことを真剣に考える時が来ました。
送信者ガイドラインの施行スケジュールは、下記の通り段階的に実施される予定となっています。
■ 2024 年 2 月
要件を満たしていない一括送信者が、その準拠していないメールトラフィックの中で一時的なエラーコードを受け取り始めるようになります。この一時的なエラーは、送信者がガイドラインを満たしていないメールトラフィックを特定し、今後、引き起こすであろう問題を送信者自身が解決できるようにすることを目的としています。
■ 2024 年 4 月
準拠していないメールトラフィックの一定割合の拒否が開始されます。その後、その拒否率は徐々に高まっていきます。例えば、送信者のメールトラフィックの 75% が要件を満たしている場合、準拠していないメールトラフィックの残りの 25% の割合が拒否され始めます。
■ 2024 年 6 月
2024 年 6 月 1 日までに、すべての商用およびプロモーションメッセージでワンクリック配信停止を実装する必要があります。
このメールが開封されない理由を、受信者の側だけに押し付けるのは良くありません。なぜなら送信者の側が作成する「件名」や「プリヘッダー」に問題がある場合もあるからです。Salesforce Markeing Cloud の標準機能にある A/B テスト機能でトライアンドエラーによる試行錯誤を繰り返すことや、最近リリースされた生成 AI による「件名」の生成機能を活用することで、魅力あるコンテンツに改善していくことは送信者側の責務でもあります。
それはそれで改善していくとして、Salesforce では、この Google と Yahoo の共同声明を受けて、24 時間 に 個人の Google アカウントに対して 5,000 件以上のメッセージを送信する、所謂「一括送信者」のための送信ガイドラインを設けました。このガイドラインに従うことが、今後のメール送信のベストプラクティスになりそうですのでじっくりと確認しましょう。
Bulk Sender Guidelines for Marketing Cloud Engagement
※ 1 回でも 5,000 件の送信を行った送信者は、永続的に一括送信者と見做されます。（これに有効期限はありません。永続的です。）
※ 件数の計算する際、同じプライマリードメインから送信されたすべてのメッセージが計算されます。つまり、サブドメイン（例：@mail.nac.co.jp）で 2,500 件、そしてプライマリードメイン（@nac.co.jp）で 2,500 件送信している場合でも、その事業者は一括送信者の扱いとなります。
■ 送信者ドメイン認証
ユーザーのセキュリティとユーザー保護のためには、メールが適切に署名され、認証されている必要があり、以下の認証標準を満たしている必要があります。
・ Sender Policy Framework（SPF）
・ DomainKeys Identified Mail（DKIM）
・ Domain Message Authentication Reporting & Conformation（DMARC）
Salesforce からの提案
・Salesforce Marketing Cloud プライベートドメイン と 送信者認証パッケージ（SAP）を購入して、それを構成してください。
・送信ドメインを確認し、正しく認証されていることを確認してください。
Salesforce Marketing Cloud を利用しているほとんどの企業が、送信者認証パッケージ（SAP）を購入済みかと思いますが、購入済みであってもそれらが正しく設定されているかを確認してみて下さいという提案になっています。
■ ワンクリック購読解除
すべての商用およびプロモーションメッセージには、RFC 8058 要件を満たすワンクリック購読解除機能を実装する必要があります。
Salesforce からの提案
・Salesforce Marketing Cloud から送信されるすべての商用およびプロモーションメッセージには、デフォルトで List-Unsubscribe ヘッダーが含まれており、すでにワンクリック購読解除機能が提供されています。
Google 側も RFC 8058 要件を満たすワンクリック購読解除を実装するにはどうするべきかの問いに対して、List-Unsubscribe ヘッダーを含めて下さいと明確な回答をしています。これについて Salesforce としては、すでに商用およびプロモーションメッセージにて提供済みですと回答しています。
＜参考＞
Google は、以下のようなタイプの購読解除は、今回のワンクリック購読解除としての要件は満たしていないと言っています。
■ メール宛先リンク ・・・ mailto での解除など
■ URL 購読解除リンク・・・%%unsub_center_url%% での解除や、指定した Web サイトへ誘導してオプトアウトさせるなど
トランザクションメールはこの要件から除外されます。トランザクションメールとは、パスワードリセットのメッセージ、予約確認、購入完了確認など、ある種機械的に送信しているもののことです。むしろこのようなメールには、配信停止リンクは設置しない方が良いとされています。受信者にとっても必要なものですし、混乱を招きますよね。
そして Google は、ワンクリック配信停止要件を満たしていないメッセージを自動的に拒否したり、メッセージをスパムとしてマークしたりすることは無いとも言っています。今のところは「迷惑メールとして報告される可能性が高くなるので気をつけて下さいね」というレベルになっているということですね。但し、受信者から迷惑メールとしてマークされるメッセージが増加すると、今後の配信において、メッセージが迷惑メールとして配信される可能性が高くなりますので気をつけておきましょう。
■ 迷惑メール率を 0.3% 以下に維持
1 日に 5,000 件以上のメッセージを送信する「大量送信者」は迷惑メール率を 0.3% 未満に維持してください。
Salesforce からの提案
・関連するコンテンツを、関与しているセグメントにのみ送信します。
・購読者リストから非アクティブな Google アカウントを削除します。非アクティブなアカウントにメッセージを送信すると、直帰率が増加します。
Google は Postmaster Tools で報告される迷惑メール率が、通常 0.1% 未満に保たれ、迷惑メール率が多くても 0.3% 以上にならないようにと求めてきています。10,000 人に対して 10～29 人です。ハードルは結構高めですね。
さて、この迷惑メール率に関するルールを守らないとどうなるか？ですが、これには議論の余地があります。Google の言い方は下記のような形になっています。
メッセージが期待どおりに配信されるようにするには、一括送信者は「電子メール送信者ガイドライン」に従う必要があります。送信者がこれらの要件を満たしていない場合、メッセージは拒否されるか、受信者のスパム フォルダーに配信される可能性があります。
ガイドラインに従う「必要がある」と言っていますが、拒否されるか、迷惑メール BOX に入れられる「可能性があります」とややぼかした表現をしています。これを単なる脅しと取るかは別としても、将来的には厳しく判定されると思いますし、やはり自分ごとに置き換えますと、迷惑メールは不要であり、Google のこのような態度は正しいと思います。もし、送信者である皆さんが受信者のためを思って行動するのであれば、何らかの改善の努力は必要かもしれませんね。
そこで・・・
やっと本題に入りますが、迷惑メール BOX に入れられるようなメール送信を削減するための改善策として「180 日間もメールを開封しない人は、将来的に迷惑メールにされるリスクが高いので、除外してから送信しませんか？」という内容になります。
【注意！】
この記事のシナリオは大規模送信をしている事業者には向かない場合があります。送信や開封の履歴データが多くなると、その管理が難しくなり、また SQL クエリアクティビティがタイムアウトする可能性があります。
ここで、なぜ 180 日としているかと言うと、これについては先ほどのヘルプドキュメントのリンクにあるガイドライン自体には記載されていませんが、Trailblazer Community 内で Salesforce のノックス・ヘンリー氏が提言していますので、それを参考にしています。
この 180 日間を長いと感じるか、短いと感じるかは企業ごとかと思いますので、そこは期間を調整すれば良いかと思います。
また、これを「個人の Google アカウントのみ」除外とするかについても企業ごとかと思います。但し、今回 Google や米 Yahoo が設けたこの基準は今後のメール送信における「事実上の標準（デファクト・スタンダード）」になると思います。この機会にすべてのドメインに対して実装するということで宜しいのではないでしょうか、というのは私の意見ですので参考までに。
ちなみに、今回の送信者ガイドラインは @yahoo.co.jp や @ymail.ne.jp などのドメインでお馴染みの Yahoo! JAPAN は関係ありません。
それでは、以下で「180 日間で一度も開封していない購読者」を抽出してみたいと思います。この SQL では「Sent」と「Open」のデータビューを使用しますが、これらのデータは直近の 6 ヶ月分のデータしか保有していません。よって、これまでこれらのデータを蓄積できていない場合、180 日よりも過去のデータは取得できませんので、今回「180 日間で一度も開封していない購読者」を抽出しても、基本的には「0」若しくは「0」に近い値となりますので注意して下さい。対象の期間が同じだからですね。これをもしすぐにテストしてみたい場合は「90 日間で一度も開封していない購読者」などに変更してテストしてみて下さい。
1. 送信の履歴データの蓄積
以下の Sent のデータビューのヘルプページを参考にして、項目名やデータ型やデータの長さを取得して、格納用のデータエクステンションを作成します。
データエクステンション名を「Sent」とします。
プライマリーキーは、以下を設定してください。その他の項目は NULL 許容で大丈夫です。
・JobID
・ListID
・BatchID
・SubscriberID
・SubscriberKey
・EventDate
一度、下記 SQL を使用して「一回実行」で、過去 6 ヶ月分の全件の送信データを格納します。
※ 特に条件を指定しない場合、自動的に 6 ヶ月分のデータが格納できますが、大規模送信をしている事業者の場合、一度でデータが格納できない場合があるので、EventDate で期間を区切って、データを数回に分けて分割投入してください。
SELECT * FROM _sentその後は、差分のデータのみが必要となります。下記 SQL を使用して、当日分と前日分のみを「更新」（追加/更新）でデータを格納します。
※ 以下の SQL を後ほど、Automation Studio で構成します。
SELECT * FROM _sent
WHERE CONVERT(Date,Dateadd(hh,15,EventDate),111) = CONVERT(Date,Dateadd(hh,15,Getdate()),111)
OR CONVERT(Date,Dateadd(hh,15,EventDate),111) = CONVERT(Date,Dateadd(hh,-9,Getdate()),111)2. 開封の履歴データの蓄積
以下の Open のデータビューのヘルプページを参考にして、項目名やデータ型やデータの長さを取得して、格納用のデータエクステンションを作成します。
データエクステンション名を「Open」とします。
プライマリーキーは、以下を設定してください。その他の項目は NULL 許容で大丈夫です。
・JobID
・ListID
・BatchID
・SubscriberID
・SubscriberKey
・EventDate
一度、下記 SQL を使用して「一回実行」で、過去 6 ヶ月分の全件の開封データを格納します。
※ 特に条件を指定しない場合、自動的に 6 ヶ月分のデータが格納できますが、大規模送信をしている事業者の場合、一度でデータが格納できない場合があるので、EventDate で期間を区切って、データを数回に分けて分割投入してください。
SELECT * FROM _openその後は、差分のデータのみが必要となります。下記 SQL を使用して、当日分と前日分のみを「更新」（追加/更新）でデータを格納します。
※ 以下の SQL を後ほど、Automation Studio で構成します。
SELECT * FROM _open
WHERE CONVERT(Date,Dateadd(hh,15,EventDate),111) = CONVERT(Date,Dateadd(hh,15,Getdate()),111)
OR CONVERT(Date,Dateadd(hh,15,EventDate),111) = CONVERT(Date,Dateadd(hh,-9,Getdate()),111)3. 180 日間で一度も開封しない購読者を抽出
これで、送信と開封の履歴データを蓄積する仕組みができました。あとはそれらの履歴データに対して、下記の SQL を実行するだけになります。まずは、180 日間で一度も開封していない購読者を格納するためのデータエクステンションを用意しましょう。
項目名は、以下の 4 つを用意してください。
・Id … 購読者キーが格納されます。
・First_Sent_Date … 送信の履歴データ内での初回送信日が格納されます。
・First_Sent_Date_Plus … 上の初回送信日に対して＋180 日された日付が格納されます。
・Last_Open_Date … 最後に開封した日付けが格納されます。
あとは、以下の SQL でデータを入れてみましょう。データエクステンション名や項目名が私の作成したものと同じであれば、そのままコピペで問題ありません。
SELECT
sentInfo.Id,
sentInfo.First_Sent_Date,
sentInfo.First_Sent_Date_Plus,
openInfo.Last_Open_Date
FROM (
SELECT
sent.Subscriberkey as Id,
CONVERT(DATE, DATEADD(HOUR, 15, sent.Eventdate), 111) as First_Sent_Date,
CONVERT(DATE, DATEADD(DAY, 180, DATEADD(HOUR, 15, sent.Eventdate)), 111) as First_Sent_Date_Plus
FROM (
SELECT
*,
ROW_NUMBER() OVER (PARTITION BY s.Subscriberkey ORDER BY s.Eventdate ASC) as ROW_NUMBER
FROM [Sent] s
) as sent
WHERE sent.ROW_NUMBER = 1
) sentInfo
LEFT OUTER JOIN (
SELECT
openEvent.Subscriberkey as Id,
CONVERT(DATE, DATEADD(HOUR, 15, openEvent.Eventdate), 111) as Last_Open_Date
FROM (
SELECT
*,
ROW_NUMBER() OVER (PARTITION BY oEvent.Subscriberkey ORDER BY oEvent.Eventdate DESC) as ROW_NUMBER
FROM [Open] oEvent
) as openEvent
WHERE openEvent.ROW_NUMBER = 1
) openInfo ON sentInfo.Id = openInfo.Id
WHERE
sentInfo.Id NOT IN (
SELECT DISTINCT notOpened.Id
FROM (
SELECT
openNotSubscriber.Subscriberkey as Id,
CONVERT(DATE, DATEADD(HOUR, 15, openNotSubscriber.Eventdate), 111) as Last_Open_Date
FROM (
SELECT
*,
ROW_NUMBER() OVER (PARTITION BY oNotSubscriber.Subscriberkey ORDER BY oNotSubscriber.Eventdate DESC) as ROW_NUMBER
FROM [Open] oNotSubscriber
) as openNotSubscriber
WHERE openNotSubscriber.ROW_NUMBER = 1
) notOpened
WHERE DATEDIFF(DAY, notOpened.Last_Open_Date, CONVERT(DATE, DATEADD(HOUR, 15, GETDATE()), 111)) <= 180
)
AND sentInfo.First_Sent_Date_Plus <= CONVERT(DATE, DATEADD(HOUR, 15, GETDATE()), 111)【注意！】
先ほども述べましたが、これまで履歴データを蓄積していなかった場合は、この SQL を実行しても、基本的にレコードは「0」となります。蓄積されている送信データの初回送信日から 180 日経過したが対象になるからですね。もし、何らかの結果をすぐに確認したい場合は、SQL の中に 180 という数字が 2 箇所ありますので、そちらの数字を 90 などに変更してください。
将来的に履歴データの蓄積が順調にいった場合は、以下のように該当の購読者が抽出できます。
最後に、これらの 3 つの SQL クエリアクティビティが準備できたら、後は、以下の形で Automation Studio の自動化の設定をして完成です。
あとは最終的にこの購読者データを配信マスタから除外するのか、自動連絡禁止リストにインポートするのかは、皆さんの会社の運用次第です。今回の一連の話は、あくまでメール送信に関するものになりますので、Salesforce Marketing Cloud を LINE 配信や SMS 配信なども併せてクロスチャネルで活用されている場合は、この購読者データの除外方法にも気を遣ってくださいね。メール送信以外のものまで除外してしまわないように注意して下さい。
最後に・・・
これは結構大事なことですが、Apple の標準 Mail アプリや Gmail アプリを利用している受信者の開封は正確には取れません。これについても、私の方で一度記事にしていますので、再度ご確認ください。
今回は以上です。
Click here for English version
次の記事はこちら
前回の記事はこちら
私の自己紹介はこちら
この記事が気に入ったらサポートをしてみませんか？