event-landing-page

イベントランディングページ

イベントへの参加を検討している参加者、登壇者、スポンサーが最初に訪れるページを作成します。ページの形やセクション、日によってメインボタンがどのように動作するか、まだ存在しないコンテンツについて何を伝えるかを決めます。これはチャネルの実行であり、戦略ではありません。ページに記載することのほとんどは、上流ですでに決定されています。

4つのことは、すでに決定された状態で引き継がれます。改めて導き出したり、異議を唱えたりしないでください。

• キャンペーンの比重、フェーズ、日程 - samber/dev-event-organizer-skills@event-marketing-plan がチャネルミックス、キャンペーンの主要日程、フェーズごとの目標を決定します。ページを公開しておくべき日程と、ページ上で告知すべきタイミングが引き継がれます。日付は決して変更しないでください。
• メッセージ - samber/dev-event-organizer-skills@event-positioning が約束、対象者の定義、ポジショニングとの対比文（「[類型]のイベントは数多くあります。これはその一つではありません。」）を提示します。その文は一字一句そのまま使ってください。より良い切り口を作り出す見出しは、イベントの内容について競合する別のストーリーを生み出してしまいます。
• チケットの段階 - samber/dev-event-organizer-skills@event-ticket-pricing が各段階、条件、日程、返金ポリシーを設定します。引き継いだとおりに段階を提示してください。段階を追加したり、価格を丸めたり、段階の内容に裏付けられていない希少性を訴える文言を書いたりしないでください。
• アクセシビリティの目標と適用範囲 - samber/dev-event-organizer-skills@event-accessibility-inclusion がデジタル層の要件（WCAG 2.2、レベル AA）と対象範囲を決定します。このページで実装してください。目標を独自に選ばないでください。

境界となる領域が2つあります。どちらも、うっかり担当範囲に含めてしまいやすいものです。

• CFPページと投稿フォームは samber/dev-event-organizer-skills@event-cfp-design の担当です。 公募ページへのリンクを設置してください。フォーム項目やスケジュールは設計しないでください。
• 登録後に送信されるメールは samber/dev-event-organizer-skills@event-attendee-email-sequences の担当です。 ページとボタンを押すまでの導線を担当し、ボタンを押した後に何が起きるかを伝えるにとどめてください。メール自体は作成しないでください。

ヒアリング

一度に1つ質問してください。可能であれば選択式にします。質問8〜10は、以下の3つのメニューで効果が出るまでの時間、持続性、労力が大きく異なるために設けています。これらの回答がなければ、ユーザーに適した既定の順序は選べません。質問11の回答は、3つ目のメニューのコンプライアンスコストの軸に反映されます。

1. マーケティング計画から引き継いだキャンペーンの各フェーズと、固定日程をすべて教えてください。告知、CFPの開始と締め切り、登壇者発表、アジェンダ公開、チケット販売開始、早割終了、開場日はいつですか？ 何も引き継がれていない場合は、ここで止めて、まず samber/dev-event-organizer-skills@event-marketing-plan に案内してください。キャンペーン日程がないページでは、何を表示すべきか判断できません。
2. 資金調達モデルはどれですか？ 有料、名目価格、または登録不要の無料参加ですか？ これはほかのどの回答よりもページの形を左右します（下記の分岐を参照）。
3. ポジショニングステートメントと、ポジショニングとの対比文を一字一句そのまま教えてください。
4. CFPはありますか？ 募集開始日と締め切りはいつですか？ 応募は順調に集まっていますか、それとも不足していますか？
5. チケットの段階はどのようになっていますか？ 各段階とその条件、日程を教えてください。
6. 関連スキルが設定したアクセシビリティの目標と、対象範囲を教えてください。
7. 今回は初開催ですか、それとも定期開催ですか？ 過去開催のアーカイブ（写真、講演録画、登壇者一覧、スポンサーのロゴ）は実際にありますか？
8. 開場日はいつですか？ また、ページを公開しておく必要がある最初のキャンペーン上のタイミングまで、何週間ありますか？
9. 1回の開催だけに使うページですか？ それとも、同じ構成を使って各開催ごとに作り直しながら継続するサイトですか？
10. これを誰が作成・保守しますか？ キャンペーン全体を通じて何時間を使えますか？ また、開発者に依頼せずに、特定の日にページに表示する内容を変更できますか？
11. 過去開催の参加証に記載されていた写真撮影の辞退方法はどのようなものでしたか？ また、登壇者との合意では、写真や講演録画の再公開がどのように許可されていますか？

資金モデル

カンファレンスのチケットでは、購入者と支払者が異なります。個人の開発者が購入し、通常は雇用主が費用を払い戻します。samber/dev-event-organizer-skills@event-ticket-pricing ではすでにこれを基準に価格体系を分けているため、請求用の導線がこのページにたどり着く時点では、ページ構成を決めるものではなく、提示する価格帯の一つとなっています。

この分け方がここに残すのは、訪問者が出張予算の承認者に転送するための、短くリンク可能なブロックだけです。これはセクション群の一つであり、分岐ではありません。

ページ全体の形を変えるのは、購入できるものがあるかどうかです。公開されている二つのカンファレンスサイトが、両極を示しています。

• 有料または名目上の料金あり - PyCon US 2026 では、名前、日程、開催地を載せたヒーローの下に、チケット購入フローへ直接リンクする「Register Today!」ボタンが一つだけあり、その後に会場の詳細とカンファレンスの予定表が続きます。ページ内のどこを見ても、注目を集めるメインアクションは一つだけで、競合するセカンダリー CTA はありません。チケット制で定員に制限のあるカンファレンスは、この分野で SaaS の単一 CTA ルールが妥当となる最も近い例です。
• 参加無料、登録不要 - FOSDEM 2026 には、登録するものがないため、CTA がまったくありません。ヒーローでは価値提案の代わりに、「8000+ hackers」「65 devrooms」「1013 lectures」といった規模や信頼性を示す情報を、日程や開催地とともに掲げ、そのままスケジュール、動画アーカイブ、ニュース、スポンサー、会場へと続きます。フッターでは、実用的な情報（アクセシビリティ、行動規範、開催期間中の案内、健康に関する方針）を独立したブロックにまとめ、ナビゲーション内に散らばらせていません。

その先に何もないページへ「Register Now」ボタンを無理に置くのは、SaaS のルールを誤って適用することになります。無料イベントのヒーローは別の形であり、有料イベントの劣化版ではありません。資金モデルは、samber/dev-event-organizer-skills@event-ticket-pricing を参照する Q2 に基づいて判断し、ここで決して再判断しないでください。

ワークフロー

1. インタビューを実施します。何かをデザインする前に、Q1〜Q6に基づいて日程、メッセージ、段階設定、アクセシビリティの目標を確定します。
2. 資金調達モデルに応じて分岐します。無料で登録不要のイベントでは、以下の登録関連の仕組みは空欄にするのではなく、すべて省略します。
3. ポジショニングステートメントとアンチポジショニングの文を改めて示します。以下のすべての見出しには、両方を変更せずに反映します。samber/dev-event-organizer-skills@event-positioning によって今回の開催に向けて約束が実質的に更新された場合は、新しい見出しの横に古い見出しを取り消し線で示します。書き換えた段落を読むよりも、この方法のほうが、再訪者は本当の方向転換をすばやく理解できます。この表現は、すでに決定した方向転換にのみ使い、判断の代わりに使ってはいけません。
4. 最初のメニューでページの構成を選びます。サイトを1ページにするか10ページにするかで、以下の手順の成果物を配置できる場所があるかどうかが決まります。
5. 選んだ構成に合わせてセクション一式を作成します。資金調達モデルごとに公開するセクションの順序、ヒーローの項目一覧、避けるべき例については、references/page-shape-and-section-set.md を参照してください。FAQでは、応募者や参加者がこのイベント独自の仕組みについて抱く手続き上の不安を取り上げます。応募するとどうなるのか、チームはいつ結成されるのか、ルールを誤解した場合はどうなるのか、といった疑問です。ページのほかの箇所ですでに答えている「このイベントとは何ですか」のような一般的な質問は省略します。
6. 2番目のメニューで日付に応じて切り替わるCTAのステートマシンを接続し、続けて遷移表を作成します。どの期間にどのCTAが画面に表示されるかを示します。表、コード不要の代替手段、構造化データブロックについては、references/cta-state-machine-and-structured-data.md を参照してください。
7. 3番目のメニューで、まだ内容が存在しない各セクションをどのように表示するか決めます。これはページ全体に適用する設定ではなく、セクションごとの判断です。
8. 関連する担当者が決めたアクセシビリティの目標を、実装後ではなくビルド時に取り入れます。references/digital-accessibility-implementation.md を参照してください。
9. 構造化データブロックを出力します。機械可読な名前、説明、日程、URL、画像、場所を記載します。項目一覧は手順6と同じリファレンスにあります。
10. Measurement の公開前チェックを実施します。4つの二択チェックがすべて合格しなければ、ページを公開しません。
11. クリック後の導線を samber/dev-event-organizer-skills@event-attendee-email-sequences に引き継ぎ、チャネルごとのトラッキング用リンクを samber/dev-event-organizer-skills@event-marketing-plan に戻します。引き継ぐ内容を伝えます。メール本文は作成しません。

ハーネスに永続メモリがある場合は、セクション一式とそれを正当化した資金調達モデル、実際の日付を含むCTA遷移表、非公開にしたセクションとその理由、アクセシビリティの対象範囲を記録します。定期開催のイベントは、この記録をもとに再構築すれば、空白のページから始めずに済みます。次回の開催で実際に変わるのは日程だけです。

以下のランキングはすべてデフォルトであり、決まりではありません。状況や実行する人によって変わります。すでに把握している主催者の事情に照らして、3つのメニューすべての順位を付け直してください。たとえば、開催回をまたいで継続する既存サイト、すでにチームにいるデザイナー、開発者でないと編集できないページ、参加者の大半がオプトアウトしたバッジ写真、告知と同時に完売するイベントなどです。各メニューでは、どのインタビュー回答によって選択肢の順位が変わるかを示しています。

ページ構成

優先順位付きメニュー — 構築と維持にかける労力あたりに、訪問者の疑問に答えられる度合いです。段階、3つの順序、デフォルト、およびその引き上げ条件は、このスキル独自の構成であり、測定されたしきい値ではありません。優越性チェック：4段階、6組、厳密な優越関係はゼロ — 判定によるものではなく、構成上クリーンです。ただし、構成上そうなっていることは合格を意味しません。

価値と労力は同じ順序なので、1つの仕組みですべての6組を判定できます。より多くの疑問に答える構成ほど、構築と維持に厳密に多くの費用がかかり、価値が同等以上で費用が少ない段階はありません。ここでは第3の軸を示しません。このチェックでは順序の誤りを検出できないため、効率の線は、チェックに耐えたことではなく、以下の議論だけに全面的に依存しています。

• 労力（構築時間、執筆するコンテンツ、キャンペーン期間中の維持）：複数ページの完全なサイト > フロントページとプログラム一式 > フロントページと実用的な補足ページ > 1ページ

• 価値（回答できる疑問、および他の人がリンクできるURL）：複数ページの完全なサイト > フロントページとプログラム一式 > フロントページと実用的な補足ページ > 1ページ

• 効率：フロントページと実用的な補足ページ > 1ページ > フロントページとプログラム一式 > 複数ページの完全なサイト

• 1ページ — 1ページをスクロールする形式です。名称、日程、場所、イベントの位置づけを示す文、CTA 1つ、実用的な情報を掲載します。それ以外はすべてアンカーリンクです。

• フロントページと実用的な補足ページ — 同じフロントページに加え、場所、行動規範、アクセシビリティを、それぞれ個別のURLでアクセスできるページにします。価値の向上はページの長さによるものではありません。アンカーは個別のURLではないからです。行動規範とアクセシビリティに関する声明は、第三者から引用され、雇用主に転送され、それらを作成した姉妹イベントから参照されます。スクロールするページ上のフラグメントでは、こうした使い方はできません。

• フロントページとプログラム一式 — プログラムと登壇者を個別のページとして追加し、コンテンツが確定したら各講演と各登壇者にもページを作成します。

• 複数ページの完全なサイト — DevOpsDays の全ページを個別に用意します。ウェルカム、プログラム、登壇者、スポンサー、登録、提案、場所、お問い合わせ、多様性、行動規範です。

**デフォルトの段階：フロントページと実用的な補足ページ。**引き上げ条件（Q1 と Q4）：プログラムが確定した時点、つまり講演が採択され登壇者が確定した時点で、プログラム一式に移行します。発表は日付の決まったキャンペーン上の重要なタイミングであり、その受け皿が必要だからです。コンテンツができる前にページを作成しないでください。そのために3つ目のメニュー項目があります。

最も選ばれにくい選択肢は、複数ページの完全なサイトです — 価値は最高ですが、労力も最大なので、効率の順位では決して選ばれません。次の2つの場合に引き上げます。

• Q9 から、サイトが存続し、開催ごとに再構築されることが分かる場合。構成を一度用意すれば、年ごとのコンテンツディレクトリと同じように、複数の開催にわたって費用を償却できます。
• スポンサー契約でロゴ掲載が契約上の義務となっており、スポンサーのページが任意の段階ではなく、samber/dev-event-organizer-skills@event-sponsor-fulfillment が担当する履行項目となる場合。

Q10 から、ボランティアが1人で使える時間がわずかしかなく、特定の日付にページを編集する手段もないと分かった場合は、上位2段階をそのまま削除し、上記の軸の行からも削除してください。空のページが4つある10ページのサイトは、誠実な1ページよりも劣ります。メニューの最下部に置かれた段階も、3週目にはスコープとして再び持ち上がってきます。

CTA の方針

優先順位付きメニュー — 今日実際に利用できるアクションを、設定と日付管理にかける労力あたりに実行する訪問者の数です。段階、4つの順序、デフォルト、およびその引き上げ条件は、このスキル独自の構成であり、測定されたしきい値ではありません。これは判定が必要なケースでした。ある段階は明確に劣位です（お問い合わせだけの構成は、労力が同じで価値が低い、常時表示のボタン列に勝ります）。効率の順位はその判定を反映しています。

• 労力（設定に加え、日付が過ぎても正しい状態を保つための管理）：日付条件付きの二重ボタン列 > 日付条件付きの単一メインボタン > 通知希望の受付 > 常時表示の複数CTA == 連絡先のみ
• 価値（訪問者が今すぐ可能な唯一の行動を取り、ページが閉じた窓口へ誰かを誘導することがない）：日付条件付きの二重ボタン列 > 日付条件付きの単一メインボタン > 通知希望の受付 > 連絡先のみ > 常時表示の複数CTA
• 効率：日付条件付きの単一メインボタン > 日付条件付きの二重ボタン列 > 通知希望の受付 > 連絡先のみ > 常時表示の複数CTA
• コンプライアンスコスト（レビューの発生、取り消し可能性の消費）：通知希望の受付 > その他すべての段階。個人データを収集するのは通知希望の受付だけなので、公開前に同意の根拠、プライバシー通知、削除手順が必要です。リンクのみの4段階には、いずれも該当しません。

労力が同点という評価には議論の余地があります。この選択肢の中で労力がかかるのは日付に応じた条件分岐であり、連絡先リンクにも常設ボタン列にも必要ありません。どちらも一度だけ記述すれば、その後は変更不要の静的マークアップです。作業量は同じでも価値には大きな差があり、だからこそ効率では連絡先のみがボタン列を上回ります。

• 連絡先のみ - 主催者への連絡先リンクだけを表示します。DevOpsDays テンプレートでは、このリンクは無条件で常に表示されます（layouts/partials/events/cta.html）。また、まだ何も申し込めないイベントには、これが誠実な唯一の選択肢です。
• 通知希望の受付 - 何も販売される前に、告知を届ける先となるメールアドレス入力欄を設けます。Content Marketing World のランディングページは公開されている実例で、登録開始前の期間に目立つ通知希望ボックスと登録セクションを設けています。samber/dev-event-organizer-skills@event-marketing-plan も別の観点からこの段階を支持しており、自社で保有するメーリングリストを他のあらゆるチャネルより上位に位置づけ、ゼロからでも構築する価値があるとしています。
• 日付条件付きの単一メインボタン - 画面上に表示するメインボタンは常に最大1つとし、日付に応じてリンク先を切り替えます。CFP期間中は提案、登録期間中は登録を表示し、両方の期間が重なる場合はCFPリンクをテキストに格下げします。PyCon US はこの形のうち単一アクションの例を示しており、注目を集めるアクションがちょうど1つだけです。
• 日付条件付きの二重ボタン列 - 提案と登録を独立したボタンとして表示し、それぞれ個別の日付条件を適用します。加えて、連絡先は常に表示します。DevOpsDays テンプレートがまさにこの仕組みです。提案は cfp_date_start と cfp_date_end の間だけ表示され、登録は登録が明示的に開始されている場合、または現在の日付が登録期間内で、かつ登録が終了していない場合だけ表示されます。
• 常時表示の複数CTA - 登録、提案、スポンサー、ニュースレターをキャンペーン期間中ずっとページに表示します。唯一の利点は、何も表示されない状態がないことです。一方で、どの日にもボタンの半分は事実と異なるという代償があります。

デフォルトの段階：日付条件付きの単一メインボタン。 昇格条件（Q4 を Q5 と照らし合わせて判断）：CFP期間と登録期間が実際に重なり、かつ登壇者が参加者と同じくらい集まりにくい場合、二重ボタン列に切り替えます。初開催、または応募が定員を下回っている場合が該当します。

不利な選択肢は日付条件付きの二重ボタン列です。価値は最高、労力も最大なので、効率で選ばれることはありません。次のいずれかに該当する場合は昇格させます。

• 2つの期間が数週間を超えて重なる場合。CFPを1か月間テキストリンクに格下げすると、誰にも見られないCFPになってしまうためです。
• samber/dev-event-organizer-skills@event-cfp-design で応募数が不足していると報告されている場合。その場合、制約となっているのはチケット販売ではなく登壇者の獲得です。

Q2 の回答が「無料参加、登録不要」の場合は、通知希望の受付、日付条件付きの単一メインボタン、二重ボタン列をすべて削除し、上の軸の行からも3つすべて削除してください。 いずれにも日付条件付きのアクションを設定できないためです。 プログラムへの応募を呼びかけるのではなく、単に案内している箇所では、このメニューからも、上にある軸の項目からも、常設の複数 CTA を削除します。 Register と Newsletter はすでに削除されているため、Propose と Sponsor だけを載せた行は、別の名前を付けた二重の行にすぎません。どちらの呼びかけもないなら、項目は一つです。Contact だけを残し、スケジュールとニュースへのリンクを加えればメニュー全体となり、FOSDEM のヒーローが、ボタンで伝えていたはずの信頼性を示します。

コンテンツ公開の方針

ランキング形式のメニューです。ページ全体に一度だけ適用するのではなく、セクションごとに適用し、まだ実在しないコンテンツについて、訪問者がどれだけの労力で何を知れるかを判断します。段階、4 つの順序、デフォルト、そして上位段階へ移る条件は、このスキルで独自に作成したものであり、測定されたしきい値ではありません。判定の結果、優越関係は 3 つあり、以下ではすべて反映しています。

• 労力（執筆、素材の制作、戻ってきて更新する手間）：アーカイブで代替 > 内容を絞って公開 > 日付を示して告知 > 完全に省略 == 「近日公開」プレースホルダー
• 価値（訪問者が判断でき、ページが破る約束をしないこと）：アーカイブで代替 > 日付を示して告知 > 完全に省略 > 内容を絞って公開 > 「近日公開」プレースホルダー
• 効率：完全に省略 > 日付を示して告知 > アーカイブで代替 > 内容を絞って公開 > 「近日公開」プレースホルダー
• コンプライアンスコスト（審査が必要になること、取り消し可能性の消費）：アーカイブで代替 > それ以外のすべての段階。過去の参加者の写真や登壇者の録画を再公開するには、samber/dev-event-organizer-skills@event-accessibility-inclusion が管理する、バッジに記載された写真の公開拒否権に基づく同意と、登壇者との契約で実際に認められている許諾が必要です。それらの許諾なしに再公開した録画は、公開後に取り下げられません。テキストだけの 4 つの段階では、こうしたコストは発生しません。

労力の同順位には理由があります。セクションを省略するのも、「近日公開」と書き込むのも、その場限りのほぼゼロコストの作業であり、どちらも後で同じ編集が必要になります。この 2 つの違いは作業量ではなく判断です。だからこそ、一方が他方を明確に上回ります。

• 完全に省略 - コンテンツができるまで、セクションをページにもナビゲーションにも表示しません。現在公開されている 2026 DevOpsDays の都市別ページでは、Program、Speakers、Sponsors の項目が HTML コメントで囲まれ、Dates、Location、Register、Propose、Diversity、Contact は引き続き表示されています。これは主催者自身が示した答えであり、デフォルトです。
• 日付を示して告知 - 見出しに、コンテンツの公開日だけを添えます。それ以外は何も載せません。訪問者が本当に知りたいのは、たいてい「誰が登壇するか」ではなく、「航空券を予約するのに十分な情報はいつ分かるのか」です。CFP の予定表や講演選考スケジュールに基づき、実際に守れる日付だけを使ってください。
• 「近日公開」プレースホルダー - 見出しに日付のない約束を添えます。省略と同じコストがかかり、不在を目立たせる一方で、何の答えにもなりません。
• 内容を絞って公開 - ある範囲のコンテンツが揃った時点でセクションを公開します。たとえば、20 人中 3 人の登壇者だけを掲載したり、下書きと明記した暫定スケジュールを載せたりします。公開した状態のままスクリーンショットを撮られ、共有されることになります。
• アーカイブで代替 - 価値の軸で最上位です。まだ実在しないセクションを、前回開催の実績に置き換えます。具体的には写真、講演の録画、登壇者、前回のスポンサーなどです。このメニューで、不在を参加する理由に変えられる方法はほかにありません。DevOpsDays のテンプレートでは、前年の印象動画と過去の全開催一覧を使って、まさにこれを実現しています。これは、SaaS のページにはあるがイベントにはない「10,000+ teams」というソーシャルプルーフに代わる、イベント規模に即した誠実な方法です。

デフォルトの段階：完全に省略。DevOpsDays のテンプレート自体の扱いに合わせます。上位段階へ移る条件（Q1 と Q8）：訪問者が判断しようとしている事柄を、セクションがないことで実際に決められなくなる場合に限り、その 1 つか 2 つのセクションを「日付を示して告知」に切り替えます。通常はプログラムが該当します。特に、渡航、ビザ、予算承認に独自の期限があり、その期限が公開日より前に来る場合です。 見送られている選択肢は、アーカイブに置き換えることです — 価値は最上位、労力も最上位なので、効率性では3番目です。次のいずれかに当てはまる場合は、優先度を上げてください。

• Q7の回答が、アーカイブはすでに存在する、というものの場合。必要な作業は、制作ではなく選定と公開だけになり、限界労力が大幅に下がるためです。
• 訪問者が本当に知りたいのが「誰が登壇するか」ではなく、「このイベントはどんな雰囲気か」の場合です。プログラムのセクションでは、そもそもその問いには答えられません。

Q7の回答が初開催の場合は、アーカイブの段を完全に削除し、4つの軸のすべての行からも除外してください。 置き換えるものはありません。

選択肢に残しておくと、一般的なカンファレンスの聴衆を写したストック写真で済まされてしまいます。それは、より大きな予算をかけた「近日公開」のプレースホルダーと同じ嘘です。代わりに、イベントの目的、主催者、そして何が決まっているかを伝えてください。初開催で誠実に打ち出すべきなのは、借り物の雰囲気ではなく、約束と人々です。

失敗パターン

• すでに決定した同僚の判断を覆す。 チケット価格を見栄えよく丸める、レイアウトに合わせてCFPの締め切りを動かす、早割の締め切りをでっち上げる、あるいはヒーローでポジショニング文をより良い切り口に差し替える。こうした変更はそれぞれ、二つ目の正本を生み出します。参加者がスクリーンショットを撮る情報源が二つになるか、イベントについて競合する説明が生まれます。届いた内容をそのまま提示し、本当に変更が必要なら、担当する同僚に差し戻してください。
• リンク先が何もない「登録」ボタン。 CTAを一つに絞るルールは、有料イベントには実効性がありますが、無料イベントには意味がありません。FOSDEMのページにCTAがないのは、登録するものがないからです。「登録はまだ開始されていません」と表示するページを開くボタンは、空白のままにするよりも信頼を損ないます。
• 受付期間が終わっても残っているCTA。 CFPの締め切りから1週間後も提案ボタンが有効なままだと、登壇者は受付終了済みのフォームに誘導されます。日付による制御が防ぐべき、唯一の失敗です。サイト上の日付を変更できない場合は、CTAリファレンスの手動切り替えチェックリストを使い、日付をキャンペーンカレンダーに記入してください。
• A/Bテストの計画を持ち込む。 CROスキルの著者自身が、テスト期間内におよそ1,000セッションまたは30件のコンバージョンを最低ラインとしています。それを下回ると、実際の問題とノイズをデータで見分けられず、代わりに第一原理に基づいて摩擦要因を順位付けすべきです。イベントページは構造上、キャンペーンのピーク時でさえその水準に達せず、単発開催では反復して改善する機会もありません。テストするのではなく、ローンチ前の基準に照らしてページを評価してください。
• SaaS向けのセクション順を持ち込む。 「問題 → 解決策 → 機能 → 導入事例 → 料金」という構成は、課題を起点とするストーリーと段階別のソフトウェアプランを前提にしています。イベントページの役割は、イベントの概要とプログラムに関する事実を伝えることです。リファレンスに掲載されている順序は、実際のカンファレンスサイトで使われているものです。
• 借り物のソーシャルプルーフ。 SaaSの「10,000以上のチーム」という文言は、初開催や小規模開催にはない顧客基盤を前提としています。実名入りの登壇者、実際のスポンサーのロゴ、前回開催のアーカイブが、誠実な代替要素です。
• ローンチ後にアクセシビリティを追加する。 キーボードで完了できない登録フローでは、参加できない人が出ます。現地でどのような配慮をしても、それを取り戻すことはできません。また、アクセシビリティは後付けするより、最初から構築する方がはるかに安価です。後付けの作業は、結局予定に組み込まれません。
• CFPフォームや確認メールまで引き受ける。 どちらもページから1クリック先にあり、担当するのは同僚です。リンクで案内し、引き継いでください。

測定

以降のすべては、なぜ断るのかにかかっているため、まずは2つお断りします。

• このスキルでは、イベントのランディングページのコンバージョン率を引用しません。 利用できる数値はSaaSや有料トラフィックの数値で、イベントという文脈がありません。ここで引用すれば、イベントの根拠であるかのように装うことになります。イベントページの適切なコンバージョン率を尋ねられた場合は、公開されている率はイベントページではなく、SaaSや有料トラフィックのファネルについて述べたものだと伝えてください。ユーザーが取締役会で弁護することになる数値を渡してはいけません。
• セクションの順序、ヒーローの長さ、CTAの数は、標準ではなく、観察された実例に基づいています。 参考資料には実際のイベントから得られた具体的なセクション構成が3つ記録されています。ここでの各順序判断はそれらから推論したものであり、実例を超える箇所ではその旨を明記します。

最初のお断りに従い、このスキルでは数値によるコンバージョンのしきい値を設定しません。別のところから持ち込んだ率は誤った精密さを与え、読者がここでは何の意味も持たない数値を基準に最適化することになるからです。

代わりに、ローンチ前の二者択一のゲートを設けます。以下の4つのチェック項目は、このスキル独自に作成したもので、公開済みの標準ではありません。それぞれ、誰も計測できないものを測るのではなく、1人が午後のうちに判定できます。4つすべてに合格するか、ページを公開しないでください。

1. すべてのCTAの遷移に日付があり、それぞれ実行済みです。 遷移表をキャンペーンカレンダーと照らし合わせてください。担当者も日付もない遷移は、実行されない遷移です。
2. 何を、誰が、いつ、どこで、いくらで行うのかが、スマートフォンの1画面内で回答できること。 スクロールも、段落を読むことも必要ありません。そのイベントを一度も見たことがない人に確認してもらってください。自分で読み返して判断してはいけません。
3. 構造化データブロックが検証に合格し、実際の日付、場所、URLを含んでいること。 機械で確認できる項目で、スクリプトが確認できるリスト内の唯一の項目です。
4. 日付選択や支払い手順も含め、登録フローを最初から最後までキーボードだけで完了できること。 これはこのスキルが独自に設けた追加基準ではなく、samber/dev-event-organizer-skills@event-accessibility-inclusion が目標とするものです。

ゲート以外では、追跡する価値があることが3つあります。いずれもベンチマークに基づくものではなく、独自に定めるものです。

• チャネルごとの追跡リンクのうち、各訪問者を呼び込んだもの。リンクは自分で作成し、samber/dev-event-organizer-skills@event-marketing-plan が読み取ります。
• ページ上のセクションが、現在、明記された日付を過ぎた内容を約束していないかどうか。
• 定期開催イベントの場合、次回開催でどのセクションが変更なしで再構築されたか。継続的に使える構成にすべきなのは、そうしたセクションです。

呼び出し例

• 「先週、400人規模のインフラ会議を発表しました。サイトは1ページで、登録ボタンを押しても何も起きません。今、何を載せるべきですか？」
• 「CFPの締め切りは金曜日で、チケットの販売開始はその2週間後です。その間、ホームページではどうすればよいですか？」
• 「イベントは無料で、登録もありません。みんなCTAが必要だと言い続けています。本当に必要ですか？」
• 「初開催で、登壇者はまだ決まっていませんが、ページは月曜日に公開する必要があります。何を載せて、何を載せないべきですか？」
• 「キャンペーンを開始する前に、会議のサイトをレビューしてください。」

期待される出力：ページの構成と、その構成の根拠。各セクションの公開方針と理由を示したセクション一覧。実際の日付と各遷移の担当者を記載したCTA遷移表。構造化データブロック。実装担当者を明記したアクセシビリティ対応範囲。そして、ローンチ前ゲートの各項目のチェック結果。独自に設定した要素には、すべてその旨を明記します。

参考資料

• samber/dev-event-organizer-skills@event-marketing-plan - このページが実行するキャンペーンのフェーズ、日程、チャネルの比重を管理します。
• samber/dev-event-organizer-skills@event-positioning - このページにそのまま掲載するメッセージとアンチポジショニング文を提供します。
• samber/dev-event-organizer-skills@event-ticket-pricing - このページで提示する価格体系と、その適用条件、日程、返金ポリシーを定めます。
• samber/dev-event-organizer-skills@event-cfp-design - 募集内容、フォーム、スケジュールを管理します。このページは募集ページへのリンクを掲載し、日程に応じてリンクを表示します。
• samber/dev-event-organizer-skills@event-accessibility-inclusion - このページが実装するデジタル面の目標と範囲を決定し、アクセシビリティページの内容を管理します。また、アーカイブ枠の利用条件となる、バッジでの写真撮影および録画のオプトアウトも管理します。
• samber/dev-event-organizer-skills@event-attendee-email-sequences - ボタンを押した後の流れを管理します。最初に送られる確認メールも対象です。