イベントサイトにチケット購入画面を埋め込み、購入経路を確認する方法

1. コードをコピーする前にイベントとページを確認する

埋め込みと購入経路の試験シートをダウンロード（Markdown、英語）

販売するイベント、その公開URL、表示すべき券種、購入入口を置くページを記録します。対象のチケットが提供元の管理画面で実際に販売中か確認してください。イベントや券種が下書きのままだと、見た目の整ったウィジェットでも空欄や利用不可になる場合があります。チケット設定の担当者とサイト編集の担当者を決めます。

設置前に提供元とサイト編集ツールの前提条件を確認します。EventbriteのEmbedded Checkoutには、対象となる公開済みまたは公開予定のイベント、販売中のチケット、HTTPS、カスタムコードを追加する権限が必要です。通常の文章は編集できても、スクリプトやHTMLを禁止するホスト型サイトもあります。サイト担当者に承認済みの挿入位置を確認し、検索結果にある未確認のコードを貼り付けないでください。[1]

2. 購入の入口を選ぶ

ページ内に券種の一覧を見せるのか、小さなボタンを置くのか、提供元のイベントページへ直接リンクするのかを決めます。見た目だけでなく、利用可能な設定と購入者の目的で選びます。重ねて表示される購入画面を開くボタンと、ページ内の一覧では、必要な場所やフォーカスの動きが違います。日付、会場、価格の説明の近くに入口を置き、対象イベントを分かるようにします。[1][2]

名称と動作は提供元によって異なります。EventbriteのEmbedded Checkoutにはボタン型とチケット一覧型があり、一度に扱えるのは一つのイベントです。Ticket Tailorではイベントまたはストアのウィジェットを設定し、コードをコピーする前にプレビューできます。同社は、ブラウザーのCookie制限によって購入が別タブで開く場合もあると説明しています。実際の移動先を記録し、「埋め込み」なら決済の全工程が自サイト内に残ると決めつけないでください。[1][2]

3. 発行されたコードを設置して公開する

選んだイベントから、チケット提供元のコードを発行します。例えばEventcubeはイベント概要からサイト埋め込みコードをコピーするよう案内し、Ticket Tailorはウィジェット設定後にHTML用またはWordPress用のコードを用意します。承認されたカスタムコード・埋め込み欄にだけ貼り付けてください。代替経路として提供元のイベントURLを控え、ボタンや欄に実際の販売イベント名を示します。[1][2][3]

編集ツールに実際のプレビューがあれば使い、その後に公開URLを開きます。コンテナーがウィジェットを切り取ったり、大切なイベント情報を隠したりしないか確認してください。Eventbriteでは、コピー後に埋め込みの外観を変えた場合、新しく発行されたコードに置き換えるよう案内しています。どの提供元でも、管理画面の変更が貼り付け済みコードに反映されたと思い込まず、公開ページと保存設定を比較します。[1]

4. 購入経路を最後までたどる

ログアウト状態のブラウザーで公開ページを開きます。イベント名、日付、表示された券種、価格、販売状態を提供元のイベントと照合します。対象チケットを選び、許可された試験経路がある場合は枚数、質問、購入、確認まで進みます。同じページに残るか、重ね合わせ画面が開くか、転送や別タブになるかを観察します。最初のボタンが動くだけでは、購入完了を証明できません。

提供元が認める試験方法か、意図的に管理されたチケットを使います。Eventbriteは、プレビューから購入を完了すると実際の登録が作成されると注意しています。送信前にその処理方法か承認された試験経路を決めてください。成功画面だけでなく、提供元の登録・注文記録を確認します。安全に完了試験を行えない場合は、確認を未検証と記し、最終確認の担当者を決めます。[1]

画面幅の狭いスマートフォンとキーボード操作でも、重ね合わせ画面の開閉を含めて入口を試します。経路が変わるか失敗する場合は別のブラウザーでも確認します。観察した移動先とエラーをワークシートに記録します。代替となる提供元のイベントURLも別途テストし、一般的なストアではなく、同じイベントと購入可能なチケットに到達することを確かめます。

5. コードだけでなく画面上の不具合を調べる

入口が空欄または利用不可なら、公開状態、チケットの販売状態、イベントの選択、サイトで必要なコードを使えるかを先に確認します。別のイベントが出る場合は、発行したコードと選択したイベントを照合します。Eventbriteは誤ったイベントIDを原因の一例に挙げています。購入がページ外へ移る場合は、故障と決める前に想定動作を確認します。Ticket TailorはCookie制限により一部のブラウザーで別タブが開くと説明しています。[1][2]

表示はされても操作できない場合は、公開ページでコンテナーの幅、スクロール、ボタンの見え方を調べます。Eventbriteは自社の購入画面について、サイズ、スクロール、Safari、HTTPSに関する問題を説明していますが、どの提供元にも共通する解決策ではありません。サイト担当者と提供元サポートには、正確なページURL、ブラウザー、端末、表示文、失敗した段階を伝えます。解決まで検証済みの直接リンクを用意します。[1]

修正後は失敗したケースと基本のチケット経路を再試験します。見た目が直っただけで購入可能とは言えず、状態の表示だけで注文完了とも言えません。許可された完了試験が可能なら、提供元の記録と購入者への確認を照合します。例外対応の担当者と検証済み代替経路を運営チームに共有します。

6. 購入経路を最新に保つ

チケット設定とサイトのコードにそれぞれ責任者を割り当てます。イベントの日付、券種、販売期間、ページのテンプレート、ドメインが変わったら公開経路を再確認します。ウィジェットを交換したら古い入口を削除し、購入者が異なるイベントへの二つの経路を見ないようにします。最後に成功した公開ページ試験と直接URLをページ担当者と記録します。

ページを広める前に、設置に関わっていない人に購入経路を進んでもらい、到達したイベント名を答えてもらいます。別イベントや見落としたウィンドウを見つける助けになります。提供元への直接リンクを意図的な代替手段として保ち、販売終了時には両方の経路を更新または削除します。