ユースケース

参加者ごとに正しい時刻を表示するウェビナーのスケジュール設定

「木曜日の東部時間午後2時にご参加ください」という案内は、もともと東部時間で考えている参加者にとっては正確ですが、それ以外の人にとっては推測するしかありません。海外のオーディエンス向けに定期的にウェビナーを開催しているB2Bソフトウェア企業は、欠席や遅刻のかなりの割合が、参加者がタイムゾーンの計算を間違えたこと、あるいはまったく計算せずに招待状の時刻を自分の現地時間の午後2時だと思い込んだことに起因していると気づきました。

同社の登録フォームでは、すでにメールアドレスと、スケジュール調整のためのおおよその位置情報を収集していました。位置情報は直接入力されるか、登録時の登録者のIPアドレスから推定され、/v1/ipによって国や都市とともに座標に変換されていました。その座標を/v1/timezoneに渡すと、登録者の位置のIANAタイムゾーン名が返されます。これにより同社は、参加者自身に換算してもらうのではなく、その参加者にとってのウェビナーの正しい現地時刻を確実に計算できるようになりました。

それ以降、すべての確認メールにはウェビナーの時刻が2回表示されるようになりました。1回は統一のために発表者自身のタイムゾーンで、もう1回はその参加者について判定したタイムゾーンで個別に計算したものです。後者は、読み手がさらに計算しなければならないオフセットではなく、平易な言葉で書き表されています。同じ二重表示は確認メールに添付されたカレンダー招待にも引き継がれたため、参加者が自分のカレンダーにイベントを追加すると、手作業の換算を信用する必要なく、自動的に正しい現地時刻に登録されました。

ウェビナーは数週間前にスケジュールされることが多く、ある地域では夏時間の切り替えをまたぎ、別の地域ではまたがないこともありました。そのため同社は、招待状を送信した日に有効なオフセットではなく、ウェビナーが開催される特定の将来の日付について正しいオフセットを計算できるタイムゾーン検索の機能を活用しました。固定のオフセットではなくIANA名を保存しておくことで、どの地域がまもなく時計を切り替えるかを社内の誰かが追跡し、招待状を手作業で調整しなくても、正しい状態が保たれました。

測定可能な成果として、今後のセッションの実際の現地時刻を確認するサポートや営業へのメールの数が大きく減りました。これはスタッフの時間を少しずつ、しかし繰り返し奪うコストで、以前は国際的なウェビナーを運営するうえで避けられないものとして扱われていました。参加率もわずかに向上しましたが、同社は、参加率の向上はおそらく複数の要因が組み合わさった結果であり、タイムゾーン表示がわかりやすくなったことは唯一の説明ではなく、いくつかある要因の一つにすぎないと慎重に述べています。

リクエスト量は少なく予測可能で、登録時に登録者1人あたり1回の検索を行うだけでした。個々のイベントの登録数が、リクエストのコストが重要な検討事項になる規模に達することはほとんどないため、頻繁にウェビナーを開催する企業であっても、この負荷が1日あたりの無料枠に近づくことはありませんでした。

一人ひとりに自分で換算してもらうのではなく、参加者全員について個別に会議の時刻を正しく示すことで、予定された通話に参加するという単純なことから、小さいながらも確かな手間を取り除けます。両方のエンドポイントのドキュメントは、/docs/ipv4-lookup/と/docs/timezone-lookup/にあります。