キューの逆行。ユーザーがキュー内で「後退」してしまう一般的な原因。

CrowdHandlerは公平性を重視しており、ほとんどの場合、先入れ先出し（FIFO）方式の待ち行列を運用することになります。このため、弊社では「待ち行列の逆行」（ユーザーが待ち行列での自分の順番が「後ろに下がった」と報告すること）に関する報告を非常に深刻に受け止めています。 キューの順位が正しい方向のみに進むことを保証するため、私たちは継続的に機能テストを実施しています。しかし、状況によっては、ユーザーが自分の番号が後退したと報告する場合があります。この記事では、その一般的な原因について説明します。トークンを添えて報告されたキューの逆行に関する個別の報告については調査を行いますが、これまでに調査したすべてのケースにおいて、原因は以下のいずれかでした：

トークンのローテーションについて

キュー内のユーザーは匿名です。ユーザーが初めて接続した際に、ランダムに生成されたトークンを送信することで、キュー内または貴サイト上でのユーザーのセッションを識別しています。ユーザーは、キュー内の順位更新をリクエストしたり、貴サイト上のURLにアクセスしたりするたびに、Cookieやローカルストレージを使用してそのトークンを保持します。この仕組みは、他のWebセッションとほぼ同様です。

キューがアクティブになると、優先度コードやIP優先順位付けなどの特別なケースを除き、トークンはキューの最後尾（つまり、番号が大きい位置）に割り当てられます。 もしユーザーのキュー順が低い番号から高い番号へと逆戻りしているのを目にした場合、それはほぼ間違いなく、そのユーザーに新しいトークンが発行されたことを意味し、つまり元のトークンを失ったことを示しています。したがって、ユーザーから「番号が逆戻りした」という報告があった場合、問題は「そのユーザーはどのようにして元のトークンを失ったのか」ということです。その原因としては、ほぼ間違いなく以下のいずれかの説明が当てはまるでしょう：

セッションのタイムアウト

トークンがその役割を果たすと、最終的には破棄されます。しかし、トークンが不要になったことをどのように判断すればよいのでしょうか？他のすべてのWebアプリケーションと同様に、ここでは「セッションタイムアウト」という概念を採用しています。つまり、ユーザーが接続するたびに、一定時間セッションを維持するということです。 デフォルトでは20分ですが、ドメイン設定でこの時間を変更できます。ユーザーが待合室での自分の順位を確認するたびに（これは1分ごとに自動的に行われます）、セッションの有効期間はその分だけ延長されます。ユーザーがウェブサイトにアクセスしてURLをリクエストした場合も、セッションの有効期間は延長されます。しかし、セッションタイムアウト後にユーザーが待合室やウェブサイトへの接続を停止した場合、そのトークンは破棄されます。

セッションがタイムアウトとなる正当なケースは以下の通りです：

待合室にて 待合室でのセッションの有効期限切れを許可するように設定している場合（これはドメインページにあるチェックボックスの設定です）、ユーザーがデバイスのスリープ状態にするか、ブラウザのタブを閉じている時間が、ドメインのタイムアウトとして指定された期間を超えると、トークンが失われる可能性があります。ユーザーがブラウザを再度開くと、新しいトークンが発行されることがあり、これにより番号が逆方向に進んでいるように見える場合があります。 デフォルトでは、待合室はこの動作についてユーザーに警告を表示し、このメッセージはドメイン設定に基づいて自動的に更新されます。

待合室でのセッションの有効期限を設定するかどうかは、管理者次第です。有効期限を設定しない場合、ユーザーはブラウザを閉じてから再度開いた後でも、最大24時間以内であればセッションに再接続できます。そもそも、なぜ待合室のセッションに有効期限を設けるのでしょうか？これにより待ち行列が短縮されるため、ご自身の待ち行列に適した動作を判断するのは管理者次第です。

サイト内について ユーザーが注意を払っていない場合、サイトへ転送されることはあっても、ドメインタイムアウトで指定された時間以上、実際にページをクリックしない可能性があります。その後、ユーザーがリンクをクリックすると新しいトークンが割り当てられ、キューに戻されることがあります。ユーザーは、サイトへ転送される前により低い順位を見ていたことを覚えているため、自分のキューの順位が下がったと報告する可能性があります。

レジでの不正行為

CrowdHandlerには、ユーザーがゴールページ（通常は決済確認画面など）に到達した時点でトークンを破棄する機能があります。これは、在庫が限られている商品へのアクセス待ち行列でよく利用されます。この機能は、ユーザーが待ち行列の順番を利用して複数回注文することを防ぐために設計されています。

想定される標準的なユーザー体験としては、確認ページが正常に読み込まれるものの、待機室への遷移をトリガーする他のリンクをクリックすると、ユーザーには新しいトークンが発行され、その結果、キューの最後尾に回されることになります。

しかし、ユーザーからは、この意図された動作について、単に「キューが逆方向に進む」と報告されている事例が見受けられます。

統合に関する課題

独自のカスタム統合を実装する場合は、Cookie を発行するか、セッションストレージを使用することで、サイトにアクセスしたユーザーのトークンを追跡するのは開発者の責任となります。特に最初の引き渡し時点では、この点に細心の注意を払う必要があります。 Cookieの設定が不正確であった場合、またはユーザーが最初にアクセスしたページでCookieの設定に失敗した場合、ユーザーは以降のクリックでトークンを提示できなくなり、その結果、新しいトークンが発行されてしまいます。ユーザーは、最初のページの読み込みを目にする間もなく待機室に戻されてしまう可能性があり、その結果、この問題をキューの退行として報告する可能性が高いです。この問題の一般的な原因は以下の通りです：

  1. CrowdHandlerの統合コードが実行されていないページへユーザーを誘導する。
  2. クッキーの設定および取得に関する一般的な問題
  3. ランディングページにおける一般的なエラーにより、CrowdHandlerの統合コードが実行されない。
  4. パスワード再設定メールなど、予期せぬ、かつセキュリティ対策が施されていないユーザー経路を通じてサイトにアクセスするユーザー。

詳細については、カスタム統合のトラブルシューティングのヒントをご覧ください。