メインコンテンツまでスキップ
バージョン: 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分に変更
  • 緊急待機列のリセット: 保持を無効化してすべての待機順をリセットして新しく開始
  • 条件付き有効化: 必要に応じてオン/オフしながら特定の時間のみ保持を有効化

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

関連する構成オプションについては、高度なタイミングおよび高度な設定 - 進入パスドキュメントを参照してください。

待機者メール通知

待機順維持機能を400秒以上有効化すると、待機者がメール待機通知を利用できます。この機能はコンソールで個別に設定する機能ではなく、待機順維持機能が有効化されているときに待機者が自動的に利用できる機能です。

機能概要:

  • 待機順維持機能が400秒以上有効化されている場合、待機時間が10分以上のときに待機者がメール通知を登録できます
  • 待機者がメールアドレスを入力して同意すると、予想進入時点の約5分前にメールで通知を受け取ることができます
  • 通知送信基準はシステムで自動的に最適化され、適切な時点に通知が提供されます

待機者メール通知の申請および受信

待機者が待合室でメール待機通知を申請して受信するプロセスです。

申請条件:

  • 待機順維持機能が400秒以上有効化されている必要があります
  • 待機時間が10分以上の場合にのみメール待機通知の申請が可能です
  • メール待機通知申請時に次の情報を入力します:
    • 本人が受信するメールアドレスを入力します
    • 「メール情報の収集および利用に同意します。」にチェックします

エンドユーザーフロー:

メール送信時点:

  • 登録完了案内メール: 待機者がメール待機通知を登録すると即座に送信されます
  • 待機進入5分前案内メール: 予定された進入時点の約5分前に送信されます

登録完了案内メールテンプレート:

件名: メール待機通知が登録されました。

メール待機通知登録

こんにちは。

お客様が申請してくださったメール待機通知が登録されました。

お客様の予想待機時間の約5分前に再度案内メールをお送りいたします。

該当メールを受け取られた後、案内されたリンクを通じてサービスにアクセスしていただけますが、
有効時間が経過すると待機順が自動的に無効処理され、再度待機列にアクセスしていただく必要があります。

※ 円滑な利用のためにメール受信後、できるだけ早くアクセスしていただくことをお勧めいたします。

利用時の注意事項
- 「待機通知メール」がスパムメールボックスに分類される可能性があるため、必ずご確認ください
- 最初の登録時に使用したブラウザーをそのままご利用ください。他のブラウザーまたは
「シークレットモード」でアクセスする場合、再入場が不可能な場合があります
- お客様のメール情報はSTCLABで管理され、通知申請日から30日後に削除されます

...

*本メールはシステムから自動送信された案内メールで返信はできません。

待機進入5分前案内メールテンプレート:

件名: 待機完了間近の案内をいたします。

待機完了間近の案内

こんにちは。

お客様が申請してくださったサービスの予想残り待機時間が約5分前後と予想されます。

以下のボタンを通じてサービスアクセスの準備をしていただくようお願いいたします。

※ 円滑な利用のためにメール受信後、できるだけ早くアクセスしていただくことをお勧めいたします。

[待合室へ]
https://...

利用時の注意事項
- 本メールは予想待機時間の約5分前の通知です
- 実際の進入可能時点はトラフィック流入状況および前のユーザーのサービス利用時間に応じて
変わる可能性があるため、残り待機時間を正確に保証することはできません
- 有効時間が経過すると待機順は自動的に無効処理され、再度待機列にアクセスしていただく必要があります
- 最初の登録時に使用したブラウザーからアクセスしていただく必要があり、他のブラウザーまたは
「シークレットモード」ではアクセスが制限される可能性があります
- アクセスが円滑でない場合、本メールに記載された[待合室へ]を通じて再度お試しください
- お客様のメール情報はSTCLABで管理され、通知申請日から30日後に削除されます

...

*本メールはシステムから自動送信された案内メールで返信はできません。

重複登録処理:

  • 既にメール通知を登録した待機者が同じメールで再登録をリクエストすると、重複登録案内メッセージが表示されます
  • 異なるメールアドレスで登録をリクエストすると、既存のアドレスを新しいアドレスに変更するか確認後、更新処理されます

進入有効性検証:

  • メール通知リンクでアクセスする場合、待機トークンの有効性を自動的に検証します
  • 有効時間が経過した後にアクセスする場合、「待機有効時間が超過して順番が無効処理されました。再度待機列にアクセスしてください。」案内メッセージが表示されます
重要: 待機時間超過案内

待機時間が超過すると待機列が新しく開始されます。ただし、待機維持機能を設定されている場合は、設定された時間だけ進入が保証されます。