SafariのITP対応は外部widgetのcookieに頼る前に通常の予約入口を残す

予約、地図、動画、計測などを外部serviceからpageへ入れると、短いcodeで機能を足せる。しかし、読者の操作に必要な情報まで外部のcookieへ任せると、そのcookieが使えない画面で連絡の入口が細くなる。外部widgetを置くときは、表示できるかだけでなく、使えないときにも予約、問い合わせ、必要な説明へ進めるかを決める。

WebKitは2月7日公開のSafari Technology Preview 49のrelease noteで、Intelligent Tracking Preventionが、利用者の操作がないprevalent resourceのcookieをblockする変更を案内した。これはTechnology Previewでの変更であり、全ての外部serviceがすぐ使えなくなるという話ではない。ただ、外部resourceのcookieを前提にpageを作る場合は、browserの処理だけに連絡や購入の入口を任せない方がよい。

外部widgetの表示と利用者の手続きを分ける

外部widgetには二つの役割が混ざりやすい。一つは、地図、空き時間、動画、評価のように、読者へ情報を見せる役割である。もう一つは、ログイン状態、入力途中の内容、紹介元の識別のように、読者の操作を続ける役割である。前者が表示されなくても、通常の本文で補えることがある。後者が続かなければ、読者は予約や問い合わせを終えられない。

たとえば、外部の予約serviceをiframeで表示するpageを考える。画面の中に空き時間が見えても、日を選んだ後に入力が消えたり、予約先へ進めなかったりすれば、読者には理由が分からない。予約を外部serviceへ委託すること自体は問題ではない。問題なのは、予約画面が使えないとき、読者が電話番号もmail addressも見つけられず、事業者側も連絡を受けられない状態である。

そこで、widgetの外に、予約の目的、受付時間、通常の予約先を置く。電話で受けるなら番号と時間を示す。mailで受けるなら、何を書けばよいかを短く示す。別pageへ移る方式なら、そのlinkを本文として読める形で置く。widgetが動く人はそのまま使える。動かない人も、同じ用件を伝えられる。この形なら、外部serviceの仕様が変わっても、事業者の連絡先まで消えない。

cookieを計測の数字と混同しない

外部のcodeを入れる理由には、予約だけでなく計測もある。どの広告や記事から来た人が問い合わせたかを知りたい場合、cookieを使って閲覧やクリックをつなげる仕組みを使うことがある。ここで大切なのは、計測できた数字と、実際に届いた問い合わせを別に扱うことだ。

計測の値が減ったとき、すぐに問い合わせが減ったと決めてはいけない。browserの設定、外部codeの読み込み、cookieの扱いが変われば、同じ行動でも記録のされ方が変わることがある。反対に、計測の数字が残っていても、問い合わせformの送信先が間違っていれば、受ける側には届かない。読者の行動を測る道具と、依頼を受け取る道具は、同じ画面にあっても別に確認する。

確認するときは、まず通常の問い合わせを一件通す。送信した内容が受信側に残り、担当者が読め、読者へ返す案内があるかを見る。次に、外部の計測画面で、必要な表示が出るかを見る。この順序なら、計測codeの調整をしている間も、受付の可否を見失わない。計測できない期間があっても、問い合わせを受ける経路を止める理由にはならない。

外部serviceへ渡す役割を一つずつ決める

外部serviceを使う場合、契約、設定、問い合わせ先がそのservice側にあることが多い。siteの所有者は、何を外部へ任せ、何を自分のpageへ残すかを分けておく。

地図なら、所在地を本文にも書く。動画なら、内容を文章でも説明する。予約なら、受付方法と連絡先を残す。計測なら、何を数えているかと、数えられない可能性があることを把握する。こうしておけば、iframeやscriptを外したときも、pageが何を伝える場所なのかが残る。

外部serviceの画面が便利でも、事業者が自分で更新できない案内まで預けると、修正に時間がかかる。臨時休業や受付停止のようにすぐ変える情報は、site側で直せる文章へも書いておく。外部の予約画面を閉じた後、古い案内がsiteに残れば、読者はどちらを信じるか迷う。正しい内容を一つに決め、外部serviceと自分のpageの両方でそろえる。

公開前に確認する順序

外部widgetを入れたpageは、制作者のbrowserで見えたかだけでは足りない。読者の入口、外部serviceへの移動、受付の結果を順に確かめる。特に、外部画面の内側で起きることと、自分のsiteで管理できることを区別する。

最初に、widgetを含むpageを開き、本文、連絡先、通常の予約先が読めるかを見る。次に、widgetから予約または問い合わせの操作を進め、入力後にどの画面へ移るかを確認する。その後、外部service側で受付が残るか、担当者へ届く通知があるかを見る。最後に、widgetを使わず、本文のlinkや電話番号から同じ用件を伝えられるかを試す。

この確認で、外部serviceの全ての仕様を把握する必要はない。読者が連絡できるか、受ける側が内容を確認できるか、使えない場合の入口があるかを確かめればよい。外部codeは便利な部品であって、siteの連絡先や受付責任そのものではない。

SafariのITPに限らず、browserと外部serviceの扱いは変わる。だから、cookieが使えることを前提に画面を一つに絞らない。本文で目的を伝え、通常の入口を残し、外部serviceはその上に加える。そうしておけば、計測や予約の仕組みを見直すときも、読者と事業者の連絡が途切れにくい。