メインコンテンツまでスキップ
バージョン: 4.6.1

高度な設定 - 待機順維持

「待機順維持」は、ブラウザの偶発的な閉じるまたは一時的な接続切断後にも既存の待機順番を復元する高度な構成で、再待機を防止し、重複待機列を減らします。このガイドでは、待機順維持の構成、実装、およびベストプラクティスについて説明します。

Queue Position Retention Console

概要

待機順維持を使用すると、クライアント(ブラウザまたはネイティブアプリ)が接続を失った後でも、訪問者が待機順番を復元できます。これは、ユーザーが再待機する必要がないようにし、重複待機列を減らします。

この機能の役割

有効化されると、待合室で接続が切断された訪問者が再接続して新しい位置を割り当てられる代わりに、待機列の席を再開できます。これは、以下を通じてユーザー体験を向上させます:

  • 再待機防止: ユーザーがブラウザやアプリを閉じても席を失わない
  • 重複待機列の減少: 不必要に新しい位置を作るユーザーを減らす
  • 公平性の維持: ユーザーが元の待機時間と位置を維持

動作方法

待機順維持メカニズムは、クライアントが接続が切断されても待機順番を保存するために、多段階プロセスを通じて動作します:

待機順維持タイマーの開始

待機順維持タイマーは待機中の訪問者がNetFUNNELサーバーへの再リクエスト呼び出しを停止する即座にカウントを開始します。技術的には、これは訪問者の最後の進入確認リクエスト後に発生します。

訪問者が待機列で活発に待機中、まだ進入できるかどうかを尋ねる再リクエスト呼び出しを定期的に送信します。これらの呼び出しが停止されると - ブラウザを閉じる、アプリを終了、ネットワーク中断、または他の場所に移動 - 待機順維持タイマーが開始されます。

再接続期間

待機順維持期間内に訪問者は再接続して待合室保護サービスにアクセスできます。再進入しようとするとき:

待機順維持期間内の場合:

  • システムが保存された識別子を使用して訪問者を認識
  • 元の待機順番に復元される
  • 再待機不要 - 中断したポイントから継続

待機順維持期間が満了した場合:

  • 再進入のために新しいキーが発行される
  • 新しい待機順番を受け取る(現在の待機列の最後)
  • 順番が保存されていない新しい訪問者として処理される

保存メカニズム

ブラウザクライアント:

  • HTTPクッキーを使用して待機順番識別子を保存
  • クッキーの持続性はブラウザ設定に従う:
    • クッキーはブラウザを閉じた後も維持される(セッションクッキーは満了するが永続クッキーは維持される)
    • クッキーはブラウザ別(Chromeクッキー ≠ Firefoxクッキー)
    • クッキーはドメイン別(他のウェブサイト = 他のクッキー)

ネイティブアプリクライアント:

  • アプリデータストアを使用(プラットフォームに応じてローカルストレージ、キーチェーンなど)
  • クッキーよりも安定 - データがアプリセッション間で持続する
  • ブラウザ別制限なし

タイムライン例

タイムライン: 待機順維持が動作中

午前10:00:00 訪問者が待合室に進入、待機順番 #47 割り当て
午前10:00:30 訪問者のブラウザ/アプリがアクティブで数秒ごとに再リクエストを実行
午前10:01:15 訪問者がブラウザ/アプリを閉じる(または接続切断)

│ 待機順維持タイマーがここで開始

午前10:05:45 [4分30秒後]
│ 訪問者がサービスに再度アクセスしようとする

├─ 待機順維持期間(例: 5分)がまだアクティブな場合:
│ → 待機順番 #47 に復元
│ → 元の順番から待機継続

└─ 待機順維持期間が満了した場合:
→ 新しいキー発行
→ 新しい待機順番 #150 割り当て(現在の待機列の最後)

構成

基本動作

無効化された場合(デフォルトOFF):

  • 待機順番は1秒間のみ維持される
  • 最小再接続期間を提供

有効化された場合:

  • デフォルトの待機順維持期間は60秒
  • 待機順維持期間をカスタマイズできる(最大7,200秒 / 2時間)
  • システムが構成された期間中待機順番を維持

構成ステップ

区間制御セグメントを作成または編集するときに待機順維持を構成できます:

  1. セグメント設定に移動(作成または編集モード)
  2. 高度な設定セクションに移動
  3. 待機順維持を有効化: 待機順維持機能をオンにする
  4. 待機順維持期間設定: 秒単位で時間を指定(デフォルトは60秒)
  5. 構成保存: 設定を適用
重要な要件

待機順維持期間はセグメントの「再リクエスト周期最大値」よりも大きくなければなりません。これは重要です!

例えば、デフォルトの再リクエスト周期設定(1-10秒)を使用する場合、待機順維持期間は10秒よりも大きくなければなりません。これは、待機順維持期間が最も長い再リクエスト周期よりも長く、訪問者が順番が満了する前に再接続する十分な時間を提供します。

ベストプラクティス

推奨保存設定

基本推奨事項: 60秒

  • 偶発的な接続切断のためのバランスの取れた期間を提供
  • 合法的な再接続機会を提供しながら、悪用を防止できるほど短い
  • ほとんどの一般的なイベントおよびトラフィックパターンにうまく動作

ほとんどのイベント(10-30分 / 600-1,800秒):

  • 短いイベント(1時間未満): 10分(600秒)を使用
    • 不必要なセキュリティ露出なしで再接続期間を提供
    • ほとんどのユーザーが偶発的に接続が切断されると、この期間内に再接続
  • 中間イベント(1-3時間): 15-20分(900-1,200秒)を使用
    • ユーザー利便性とイベント期間のバランス
    • しばらく席を空ける必要があるかもしれないユーザーを考慮
  • 長いイベント(3時間以上): 30分(1,800秒)を使用
    • ユーザーが合理的な再接続機会を持つように保証
    • 延長された待機期間中のフラストレーションを防止

30分より長くない理由:

  • セキュリティリスク: キー重複および悪用の可能性を開く
  • システム負荷: 延長された待機順維持期間はサーバー負荷を増加させる可能性がある
  • ユーザー期待: ほとんどの偶発的な接続切断は数分以内に発生
  • クッキー制約: ブラウザクッキーは非常に長い待機順維持を信頼できないようにする制限がある

最大期間(2時間 / 7,200秒)を使用する場合:

  • 高価値取引: 重要な購入をするユーザーは技術的な問題で席を失ってはならない
  • 重要なイベント: 一生に一度のセールや登録で位置を失うことが致命的な場合
  • エンタープライズサービス: 再接続が予想され、モニタリングされるB2Bシナリオ

保存制限事項

ブラウザクライアント(クッキーベース):

  • 待機順維持は同じブラウザおよびデバイス内でのみ動作
  • ブラウザまたはデバイス切り替え時に順番損失
  • プライベート/シークレットモードはクッキーを保存しない
  • クッキーを削除するユーザーは順番を失う

ネイティブアプリクライアント(アプリデータストア):

  • 同じデバイス内でアプリセッション間で待機順番が維持される
  • ブラウザクッキーよりも安定
  • デバイス切り替え時に再認証が必要

FAQ

リアルタイムで設定を変更できますか?

はい!待機順維持設定はリアルタイムで適用されます - 変更内容はセグメント再起動やサービス中断なしで即座に適用されます。

リアルタイム更新例:

  • 一時的に待機順維持を無効化: トラフィックが多い中で待機順維持をオフにしてすべてのユーザーが待機列を再度通過するように強制
  • 待機順維持期間を調整: 現在待機中の訪問者に影響を与えずに待機順維持期間を60秒から10分に変更
  • 緊急待機列リセット: 待機順維持を無効化してすべての待機順番をリセットして新しく開始
  • 条件付き有効化: 必要に応じてオン/オフしながら特定の時間中のみ待機順維持を有効化

この柔軟性により、ダウンタイムなしでリアルタイム条件に基づいて待機列管理戦略を調整できます。

関連構成オプションについては、高度なタイミングおよび進入キー無効化ドキュメントを参照してください。