ナレッジベース

送信したメールの開封を確認する

送ったメッセージが開封されたかどうか、いつ、何回開かれ、どのリンクがたどられたかが分かる。オフにするまで有効で、取得できない読み取りについても率直に示す。

詳細

スイッチは1つではなく2つあり、メールボックス側でオフにしない限りどちらも有効である。開封とクリックは、メールを受け取る人との間の別々の取り決めである。ピクセルはメッセージが表示されたことだけを報告するが、書き換えられたリンクは実際の訪問を当社経由にする。多くの送信者は前者を望み、後者を拒む。両方をオフにして送ったメッセージには、ピクセルも書き換えられたリンクも、トラッキングされたと主張する記録も付かない。API 経由の送信では tracking: { opens, clicks } を指定して、メールボックス単位ではなくそのメッセージ単位で決められる。これは両方向に働く。何も記録させたくないプログラムはメッセージごとにそう指定でき、メールボックスの設定がどうであれそのとおりになる。
どちらのスイッチも、次に送るメッセージに何が付くかを決めるだけである。すでに送信したメールは、送出時のピクセルと書き換えられたリンクをそのまま保持し、スイッチをオフにした後も報告を続ける。これを止める唯一の方法は、相手がすでに持っているメッセージの中のリンクを壊すことだが、それは集計を続けるよりも読み手にとって悪い仕打ちである。トラッキングをオフにすることは、これから出ていくものについての決定であり、送信済みのものを回収する手段はない。
開封にもクリックにも IP アドレスは保存されず、それを入れる列も存在しない。保持されるのは、リクエストが当社に届く前からエッジが把握していた情報(国、地域、都市、タイムゾーンで、いずれも取得のために照会したものではない)と、アドレスとユーザーエージェントの SHA-256 フィンガープリントである。後者には UTC の午前0時に更新される値でソルトが付く。このハッシュがあるおかげで、レポートは「開封2回」ではなく「デバイス2台」と言える。そして1日経てば、当社を含め誰もそれをアドレスに結び付けられない。位置情報は、人物についての事実ではなくネットワークについての事実として読むべきである。VPN や社内プロキシの背後にいる人は、行ったことのない場所として報告される。
数値の背後には2種類の記録がある。ヒットの行は、測定に同意したことのない人物についてのユーザーエージェント、都市、フィンガープリントを持つ。これは送信後の数日間に出てくる疑問、すなわちあれはスキャナーだったのか、どの端末か、本当に本人だったのかに答えるために存在する。もう1つは閲覧そのもの(メッセージごと、リンクごとの初回、最終、回数)であり、これは開封した人物ではなく自分のメールについての事実である。
自動的な取得は記録されたうえで集計から外される。これは破棄することとは別である。Apple の Mail Privacy Protection は、人が見るかどうかに関わらず、配信時にすべてのメッセージのすべてのリモート画像をダウンロードする。これは既定で有効であり、これを数えればどの送信者にも100%近い無意味な開封率が渡ってしまう。そのため、ユーザーエージェントとリクエストの発信元ネットワークから識別し、機械として印を付ける。企業のスキャナー、リンクチェッカー、ヘッドレスブラウザー、送信から10秒以内に届いたものも同様に印を付ける。人の操作がそこまで速く起きることはないからである。ユーザーエージェントは、そこから読み取った内容と並べて、届いたままの形で保持する。その文字列こそが呼び出しの出どころであり、入力と照合できない判定は誰にも訂正できない判定だからである。クライアントはそこに何でも書けるうえ、多くはほとんど何も書かないため、これは事実ではなく主張である。レポートは、ログと合計の間に説明のつかない差を残すのではなく、除外された件数を表示する。
Gmail は第三のケースであり、そのように報告される。Gmail の画像プロキシは誰かがメッセージを表示したから取得するので、開封自体は本物だが、端末、位置情報、クライアントはそもそも分からない。またプロキシはキャッシュするため、2回目、3回目の閲覧は当社に届かないことがある。Gmail 経由の開封数は合計ではなく下限である。
開封が記録されていないことは、メッセージが読まれなかった証拠にはならない。リモート画像の遮断はごく一般的で、既定で有効なクライアントも多く、そうでないクライアントも設定を用意している。遮断されると開封の記録は完全に失われるため、ここでの沈黙はどちらの方向の証拠にもならず、しかも最もよく得られる結果である。製品内で、トラッキングされていないメッセージや報告のないメッセージが「未開封」として表示されることはない。それは何もないことを拒否として読むことになるからである。
クリックは開封よりも強い証拠なので、両者が1つの数値にまとめられることはない。画像が遮断される頻度は、リンクがクリックされない頻度よりはるかに高い。そのため、クリックはあるが開封のないメッセージは、確実に読まれたメッセージである。書き換えられるのは1メッセージあたり最大100か所の遷移先で、同じ遷移先は1回だけ書き換えられる。ヘッダー画像、ボタン、フッターから同じキャンペーンページにリンクしている場合は、独自のカウントを持つ1行になる。それは同じ問いを3回尋ねているにすぎず、レポートは「どこかで何かがたどられた」ではなく「どのリンクがたどる価値があったか」を示せるからである。この上限を超えた分のリンクは、削除されるのではなく書いたままの形で残される。トラッキングされないリンクでも機能するが、200本のリンクを黙って失うメッセージは機能しないからである。
書き換えられたリンクは、当社自身がメッセージに入れた先以外には向けられない。遷移先はレコードとして保持され、URL にはその id しか含まれないため、改ざんできるクエリパラメーターは存在せず、ここがメールプロバイダーのドメイン上のオープンリダイレクトになることもない。オープンリダイレクトはフィッシングキャンペーンの原材料である。リダイレクトは 301 ではなく 302 を返す。恒久的なリダイレクトはブラウザーにも途中のすべてのプロキシにもキャッシュされ、カウントが1で止まってしまうからである。メッセージがすでに削除されたリンクは、素っ気ない 404 を返すのではなく、そのアドレスがもうどこも指していないことを伝える。
書き換えられるのは返信の新しい部分だけで、その下に引用された履歴は他人のメッセージであり、そのリンクは相手のものとして残る。Sent に保存される複製からはピクセルが取り除かれ、すべてのリンクが入力したとおりの形に戻される。そうしなければ、自分の送信済みメールを転送すると受信者のトークンを見知らぬ相手に転送することになり、自分の送信箱でリンクをクリックすると受信者がクリックしたものとして記録され、手元に残る複製も自分が書いたものとは違うものになってしまう。
宛先が1人のメッセージでは、常にその人の名前が示される。他の誰でもありえないからである。宛先が2人以上になると、誰が開封したかを特定するには、各人に本文の個別の複製を渡す必要がある。これは、人ごとに組み立て直しても負担にならない程度に小さいメッセージでのみ行われる。推定サイズに宛先の人数を掛けた値が 8MB 未満に収まる必要がある。この予算を超える場合、および1つの暗号文ブロックを人ごとに変えられない封をされたメッセージでは、全員に同じ本文が送られ、開封は一覧から選ばれた名前ではなく「このメッセージの誰か」として記録される。そこでは30秒以内に2人が開封しても1回の閲覧として数えられる。これは同じ制約を別の言い方で述べたものである。30秒という枠はどの場合にも適用される。プレビューペインの再描画や、スクロールで再び表示されたメッセージは画像を再取得するが、2回目の閲覧とは数えない。
OpenEmail のメールボックス間のメールは、閲覧側そのものが開封を報告する。ここでの閲覧側は、自社のものも含め、すべてのメッセージから 1×1 の画像を画面に届く前に除去するので、ピクセルが取得されることはない。リモート画像を表示した状態でメッセージが表示されると、閲覧側はそのメールボックスが受信した複製に対して開封を記録し、クライアント名を OpenEmail として記録する。画像を非表示のままにしている読み手は何も記録されない。これは画像を遮断する他のクライアントと同じである。リンクはどこでも除去されないため、OpenEmail のメールボックス間のクリックは通常どおり報告される。
レポート全体は、すでに送信済みメールを対象としている emails:read スコープのもとで REST API から取得できる。一覧、指定期間内のトラッキング対象メッセージの開封率とクリック率、そして要求すれば自動アクセスを含む個別のヒットが得られる。ヒットごとのログは複製1件あたり2,000行で止まる一方、カウンターは記録を続ける。そのため、ループで取得されたピクセルが、誰も見ていないテーブルを肥大化させることはない。
トラッキングをオフにして送ったメッセージは、開封0件と表示されるのではなく、何も表示されない。「誰も開封しなかった」と「記録していなかった」は別の答えであり、製品内でこの2つが同じように表示されることはない。