あなたの組織において、過去 180 日間で一度もメールを開封しなかった購読者は、今後もメールを開封する可能性はありますか？そのような人達をどのように扱うかを真剣に考えたことがありますか？

2023 年 10 月、Google と 米 Yahoo の共同声明が発表されたことで、今、私たちマーケターはこのことを真剣に考える時が来ました。

このメールが開封されない理由を、受信者の側だけに押し付けるのは良くありません。なぜなら送信者の側が作成する「件名」や「プリヘッダー」に問題がある場合もあるからです。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 Marketing Cloud を利用しているほとんどの企業が、送信者認証パッケージ（SAP）を購入済みかと思いますが、購入済みであってもそれらが正しく設定されているかを確認してみて下さいという提案になっています。

■ ワンクリック購読解除

すべての商用およびプロモーションメッセージには、RFC 8058 要件を満たすワンクリック購読解除機能を実装する必要があります。

Google 側も RFC 8058 要件を満たすワンクリック購読解除を実装するにはどうするべきかの問いに対して、List-Unsubscribe ヘッダーを含めて下さいと明確な回答をしています。これについて Salesforce としては、すでに商用およびプロモーションメッセージにて提供済みですと回答しています。

トランザクションメールはこの要件から除外されます。トランザクションメールとは、パスワードリセットのメッセージ、予約確認、購入完了確認など、ある種機械的に送信しているもののことです。むしろこのようなメールには、配信停止リンクは設置しない方が良いとされています。受信者にとっても必要なものですし、混乱を招きますよね。

そして Google は、ワンクリック配信停止要件を満たしていないメッセージを自動的に拒否したり、メッセージをスパムとしてマークしたりすることは無いとも言っています。今のところは「迷惑メールとして報告される可能性が高くなるので気をつけて下さいね」というレベルになっているということですね。但し、受信者から迷惑メールとしてマークされるメッセージが増加すると、今後の配信において、メッセージが迷惑メールとして配信される可能性が高くなりますので気をつけておきましょう。

■ 迷惑メール率を 0.3% 以下に維持

1 日に 5,000 件以上のメッセージを送信する「大量送信者」は迷惑メール率を 0.3% 未満に維持してください。

Google は Postmaster Tools で報告される迷惑メール率が、通常 0.1% 未満に保たれ、迷惑メール率が多くても 0.3% 以上にならないようにと求めてきています。10,000 人に対して 10～29 人です。ハードルは結構高めですね。

さて、この迷惑メール率に関するルールを守らないとどうなるか？ですが、これには議論の余地があります。Google の言い方は下記のような形になっています。

ガイドラインに従う「必要がある」と言っていますが、拒否されるか、迷惑メール BOX に入れられる「可能性があります」とややぼかした表現をしています。これを単なる脅しと取るかは別としても、将来的には厳しく判定されると思いますし、やはり自分ごとに置き換えますと、迷惑メールは不要であり、Google のこのような態度は正しいと思います。もし、送信者である皆さんが受信者のためを思って行動するのであれば、何らかの改善の努力は必要かもしれませんね。

そこで・・・

やっと本題に入りますが、迷惑メール BOX に入れられるようなメール送信を削減するための改善策として「180 日間もメールを開封しない人は、将来的に迷惑メールにされるリスクが高いので、除外してから送信しませんか？」という内容になります。

ここで、なぜ 180 日としているかと言うと、これについては先ほどのヘルプドキュメントのリンクにあるガイドライン自体には記載されていませんが、Trailblazer Community 内で Salesforce のノックス・ヘンリー氏が提言していますので、それを参考にしています。

この 180 日間を長いと感じるか、短いと感じるかは企業ごとかと思いますので、そこは期間を調整すれば良いかと思います。

また、これを「個人の Google アカウントのみ」除外とするかについても企業ごとかと思います。但し、今回 Google や米 Yahoo が設けたこの基準は今後のメール送信における「事実上の標準（デファクト・スタンダード）」になると思います。この機会にすべてのドメインに対して実装するということで宜しいのではないでしょうか、というのは私の意見ですので参考までに。

それでは、以下で「180 日間で一度も開封していない購読者」を抽出してみたいと思います。この SQL では「Sent」と「Open」のデータビューを使用しますが、これらのデータは直近の 6 ヶ月分のデータしか保有していません。よって、これまでこれらのデータを蓄積できていない場合、180 日よりも過去のデータは取得できませんので、今回「180 日間で一度も開封していない購読者」を抽出しても、基本的には「0」若しくは「0」に近い値となりますので注意して下さい。対象の期間が同じだからですね。これをもしすぐにテストしてみたい場合は「90 日間で一度も開封していない購読者」などに変更してテストしてみて下さい。

1. 送信の履歴データの蓄積

以下の Sent のデータビューのヘルプページを参考にして、項目名やデータ型やデータの長さを取得して、格納用のデータエクステンションを作成します。

データエクステンション名を「Sent」とします。

プライマリーキーは、以下を設定してください。その他の項目は NULL 許容で大丈夫です。

一度、下記 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 許容で大丈夫です。

一度、下記 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 日間で一度も開封していない購読者を格納するためのデータエクステンションを用意しましょう。

あとは、以下の 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)

将来的に履歴データの蓄積が順調にいった場合は、以下のように該当の購読者が抽出できます。

最後に、これらの 3 つの SQL クエリアクティビティが準備できたら、後は、以下の形で Automation Studio の自動化の設定をして完成です。

あとは最終的にこの購読者データを配信マスタから除外するのか、自動連絡禁止リストにインポートするのかは、皆さんの会社の運用次第です。今回の一連の話は、あくまでメール送信に関するものになりますので、Salesforce Marketing Cloud を LINE 配信や SMS 配信なども併せてクロスチャネルで活用されている場合は、この購読者データの除外方法にも気を遣ってくださいね。メール送信以外のものまで除外してしまわないように注意して下さい。

最後に・・・

これは結構大事なことですが、Apple の標準 Mail アプリや Gmail アプリを利用している受信者の開封は正確には取れません。これについても、私の方で一度記事にしていますので、再度ご確認ください。

今回は以上です。

Click here for English version

次の記事はこちら

前回の記事はこちら

私の自己紹介はこちら