サイト上の実際のエラーまたは想像上のエラーは、驚くべき鐘です。 特に、トラベラータが詐欺ではないことを確認したい新規クライアントの場合。 この記事では、技術的な側面、サイトで起こりうるバグ、およびTravelata.ruウェブサイトインターフェースの明らかな機能とは限らないものを分析します 。
じょうごを見てみましょう。
メインページ
ユーザーが偶然に私たちのところに来て、以前は地下鉄の近くの旅行代理店でのみツアーを購入したと想像してください。 彼が最初に行うことは、植物の形を見つけることです。 そして、私たちはそれを持っていません。「ツアーを選んでください」というボタンしかありません。これはあまり目立たず、サイトのすべてのページに表示されません。
これは否定的な顧客を引き起こしますが、間違いではありません。 アプリケーションフォームを追加すると、ユーザーの注意を検索バーから削除します。 そして、自分でツアーを検索して価格を比較する代わりに、マネージャーの助けを待っています。 ユーザーは、私たちが標準的な旅行代理店とは異なることを理解する必要があります。
検索結果（SERP）
観光客が検索プロセスを開始しました。 ホテルの発行が読み込まれています。
一般的にどのように技術的な側面からツアーを検索しますか？ 選択した観光基準のリクエストをツアーオペレーター（以下TOと呼びます）に送信します。 一度に2つのアクションがあります。1つのリクエストがキャッシュに送信され、2番目のリクエストがメンテナンスデータベースに直接送信されます。 キャッシュに既にツアーがある場合は、すぐに表示されるため、ユーザーは検索結果を長時間待つことはありません。 要求に応答すると、新しいツアーが引き渡しにロードされます。
ほとんどの場合、問題はありません。 しかし、一部の顧客には論理的な不満があります。 特定の例を分析します。
状況1：「検索は愚かで、ホテルの読み込みが遅い」
リクエストがまれであり、キャッシュに何もない（たとえば、まだウィンドウの外にある新年のモスクワからジャマイカへのリクエスト）か、サーバーの負荷のために長時間応答します。 ユーザーはこの問題を非常に長く待つことになります。 クライアントが失われないように、結果にダブルタイムアウト機能を使用します。最初の30秒で、到着したすべてのものを表示します。 さらに30秒後-問題に範囲を追加します。 制限に何も達していない場合、ツアーがないことを示し、日付または方向を変更することをお勧めします。
この段階のクライアントにとって、最も関連性の高いオファーを選択することが最も重要です。 そして、ツアーがたくさんある場合、誰もが追いつくわけではありません。 各MOTには、リクエストでサーバーが過負荷にならないように選択できる固定数のツアーがあります。 同時に、ツアーオペレーターはホテルではなく、ツアーの数のデータを送信します。 サンプルがまれに空にならないようにするために、製品部門は新しいTOを接続して「配達を拡大」しようとします。これにより、リクエストごとに少なくとも10〜20のホテルとツアーがあります。
最も関連性の高い問題を取得するには？
特定の出発日には、より狭いリクエストを作成することをお勧めします。 フィルターを使用します。 最低価格に興味がある場合は、 価格カレンダーをご覧ください。
価格カレンダーは、どこに行き、特定の予算があるのかわからない場合に便利なサービスです。 これは、異なる国の異なる月の夜の月全体の最低価格を示しています。
また、検索の下の鎌では、グラフ形式の低価格のカレンダーが開きます。 飛行するのに最も安い日を確認できます。 日付をクリックすると、新しい検索が作成されます。 休暇が特定の日付に関連付けられていない場合、最も安い出発日を選択できます。
これらのアプリケーションは両方とも、価格統計サービスで実行されます。 お客様が見たすべてのツアーの価格履歴を保持しています。 これらは、アプリケーションを要求するときにプルアップされるテラバイトのデータです。
Turkunterサービスも機能し、指定されたトルコの基準に従って価格を追跡します。 鎌でツアーが見つからなかった場合は、WebサイトまたはモバイルアプリケーションでTourhunterからの通知をサブスクライブします。 指定された基準によるツアーの価格が下がった（または上がった）場合、電子メールまたはプッシュ通知を受け取ります。 そして、ツアーを購入する時間です（または今のところ、少し待つ方が良いです）。
状況2：「ホテルが見つかりませんでした」
独立した観光客が最初にフライトを選択し、次にこれらの日付に合わせて手頃な価格のホテルをカスタマイズします。 また、パッケージツアーの検索は、休日が多少スムーズなホテルを選択することから始まります。 したがって、私たちの観光客がホテルの大規模な品揃えをすぐに受け取ることが重要です。 しかし、その国が人気があり、出発日が広範囲に選択されている場合、すべてのホテルが鎌に負荷をかけることができません。
ホテルをすばやく見つける方法は？
検索ボックスにホテル名を入力します。 その後、メンテナンスのリクエストは特定のホテルにのみ送信されます。 そして出口で、あなたのturkriteriaに適した可能なツアーの最大数とそれらの現在の価格を受け取ります。 細心の注意を払っている旅行者には、他のサイトのホテルを選択し、短いリストでTravelataに来ることをお勧めします。 そして、価格を比較します。
状況3：「特定のMOTからのオファーが見つかりませんでした」
統計によると、ツアーオペレーターのツアーを探している人はほとんどいません。 したがって、このようなフィルターはありません。 しかし、クライアントは別の場所でツアーの面倒を見ることができ、私たちと一緒にチェックするようになります。 すべての有名なツアーオペレーターが、常にTravelatに参加しているわけではありません。 特定の領域で無効にするか、サイトから完全に削除する必要がある場合があります。 これは、メンテナンス側で技術的な問題が発生したときに発生します。 この場合、リクエストの送信を停止し、すぐに担当者に連絡します。 バグが修正されるとすぐに、問題をテストし、メンテナンスを再度オンにします。
特定のツアーオペレーターが今日見つからなかった場合は、明日検索してみてください。
状況4：「リゾートへのツアーはありません」
人気のないリゾートへのツアー、特に地域からの出発があるツアーへのツアーはほとんどありません。 特に夏にスキーツアーを探す場合は、一部の日付ではまったく存在しない場合があります。 MOTはまだこれらのツアーを形成し、価格を設定することができていません。 そのような場合-「Pick me a tour」ボタン。
リゾートが観光客で人気がないか、在庫が少ない場合、より大きな「仮想」リゾートに追加します。 たとえば、1つのホテルが販売されているKalikratiaは、ハルキディキ半島の引き渡しに添付されました。 したがって、より有名なリゾートをリクエストした場合でも、このホテルを見たり購入したりできます。
当社のウェブサイトでツアーのセットを拡大しようとしています。 しかし、すべての可能なツアーオペレーターを追加することはできません。 私たちのサイトにたどり着くには、メディアにスキャンダラスなストーリーがなく、信頼できるものでなければなりません。 ツアーオペレーターの現在の仕組みについては、 Habréに関する最後の出版物の1つにすでに書いています。
状況5：「ツアーは関係ない」
彼らはバグを起こし、間違った価格を送信することが起こります。 ほとんどの場合、このような場合、非現実的に低い価格が転送されます-つまり、ツアーの一部です。 たとえば、宿泊料金のみまたは燃油サーチャージのみ。 または、購入済みのツアーを引き続き提供します。 その方向のメンテナンスをオフにし、それが修正されるのを待って、接続し直します。
状況6：「異なる年齢の5人と3人の子供の会社のツアーが見つかりません」
このような組み合わせをサイトで自分で見つけることは困難です。 そのような組成物の製品はありません。
どうする
ホテルを選択し、ウェブサイトまたはモバイルアプリケーションでチャットを介して便利なメッセンジャーで質問します。 フライトごとに無料のファミリールームが2室、チケットが8枚あるかどうかを尋ねます。 ある場合は、ホテルを選択し、注文を残して、支払いはしません。 マネージャーが折り返し電話し、予約の完了をお手伝いします。
状況7：「競合他社の価格は低い！」
主観的な意見。これは多くの要因で発展する可能性があります。 価格で並べ替えるのではなく、人気で並べ替えを開始し、フィルターを5つ星に設定して忘れました...価格は競合他社とほぼ同じです。 客観的には、特定の1つのツアーのみの価格を比較できます。つまり、出発日、ホテル、宿泊日数、食事の種類、部屋の種類、およびツアーオペレーターが一致する場合です。 そして、最終価格を確認するには、チェックアウトの前に必ず「失敗」してください。 競合他社の中には、特に鎌の価格を下げるものがあります。 そして、彼とのツアーが200ルーブル安くなるとしても、多くの観光客は彼らに行く準備ができています。
状況8：「サイトはダウンしています！」
サイトへのトラフィックは、日中の午前10時から午後7時まで広がります。訪問の付着は検出できません。 また、3〜4時間でバッチで郵送します。 したがって、原則として、サイトをリロードする可能性は除外します。 しかし、私たちの側のいくつかのサーバーが対処できないことが起こります。 一部のクライアントは504エラーを受け取ります。 プログラマーはすぐにこれに気づきます。 そして、サーバーをオフにして、稼働中のサーバーの負荷を再分散します。 通常、サイトは5以下、場合によっては15分までです。 しかし、これは誰にとっても起こりうる例外です。
これらはすべてのバグではありません。 第二部は明日です :)