mcpField
E
event-marketing-plan

event-marketing-plan

github.com/samberマーケティング・グロース45.5k 回インストール2 日前に更新
リポジトリ

event-marketing-plan について

event-marketing-planは、技術イベントを告知する主催者向けの計画スキルです。対象セグメントにチャネルを割り当て、確定済みの日程に沿って施策と段階別目標を組み立てます。各チャネルのコンテンツや提携条件の設計は関連スキルに引き継ぎます。

主な機能

  1. 01対象セグメントとチャネルの対応付け
  2. 02有料・無料イベント別の基準設定
  3. 03確定日程に沿ったキャンペーン配置
  4. 04チャネル別の集客予算配分
  5. 05フェーズごとの目標設定
  6. 06実行をチャネル別スキルへ引き継ぎ

活用シーン

  1. 01技術カンファレンスのチケット販売計画
  2. 02無料イベントの登録キャンペーン設計
  3. 03複数の対象層とチャネルを使う告知の調整

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/samber/dev-event-organizer-skills --skill event-marketing-plan

インストール後、Claude Code で/event-marketing-planを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

evals/
evals.json
references/
calendar-spines-and-phase-targets.md
channel-menu-and-budget-allocation.md

詳細

イベントマーケティング計画

技術イベントに参加者を集めるための獲得計画を立てます。どのオーディエンスセグメントに、どのチャネルを通じて、どの程度の重みをかけ、いつ実施し、各フェーズの目標をどう設定するかを決めます。これは全体を統括する計画です。各チャネルにいつ、どれだけ注力するかを決め、そのチャネル独自のコンテンツは、それを担当する関連スキルに引き継ぎます。

4つの入力情報はすでに決まっています。再検討しないでください。

  • メッセージ — samber/dev-event-organizer-skills@event-positioning が、すべてのチャネルのコピーに反映する訴求内容とオーディエンスの定義を提供します。
  • 需要の見立て — samber/dev-event-organizer-skills@event-market-fit が、そもそもオーディエンスが存在するかどうかを示します。この計画が処方的であるのに対し、これは診断的な情報です。
  • 日程 — samber/dev-event-organizer-skills@event-ticket-pricing が、価格設定と早期割引の締切を決めます。これらの締切は固定された暦上の日時であり、この計画はそれに合わせて対応します。このスキルがキャンペーンの都合に合わせて締切を変更することはありません。
  • 2つのチャネルに関する取引の仕組み — samber/dev-event-organizer-skills@cross-event-promotion と samber/dev-event-organizer-skills@event-media-partnerships が、これらの物々交換型の取引をどのように開拓し、構成するかを担当します。この計画では、それらの重み付けとスケジュール設定のみを行います。

2つの主催者ガイドを、この計画の基盤とします。

  • DevOpsDays の主催者ガイドでは、5つの獲得チャネルを挙げ、メーリングリストを「チケット販売の強力な手段」としています。
  • MLH の主催者ガイドでは、キャンパスでの施策をまとめ、登録から参加に至るまでの離脱率を公開しています。

両者とも総登録者数のチェックポイントを公表していますが、そこで説明は終わっています。ファネル全体の数値は公表されていますが、単一チャネルの登録者獲得数は公表されていません。そのため、計画を提示する際には、目標がそれぞれ何を指すのかを明確にしてください。

  • ファネル全体のチェックポイント:公表済み。
  • チャネルの価値の順位付け:判断に基づくもの。
  • チャネルごとの目標:新たに設定するもの。

以下に示すすべての順位付けは既定のものであり、絶対的なルールではありません。状況や実行担当者によって変わります。ヒアリングの後、主催者についてすでに把握している情報に照らして、両方の選択肢リストを改めて順位付けしてください。以下のいずれかに該当する場合、既定の順位は覆ります。

  • すでに大規模なメーリングリストがある。
  • 人気のニュースレターやポッドキャストを持つ主催者がいる。
  • 対象が単一キャンパスのオーディエンスである。
  • 広告クレジットをまとめて提供するスポンサーがいる。
  • コンテンツ制作の能力がまったくないボランティアチームである。

インタビュー

一度に質問するのは1つにし、可能な場合は選択式にしてください。

質問4と7〜9があるのは、チャネルと予算の選択肢では、効果が出るまでの時間、持続性、労力に大きな差があり、デフォルトの順序をユーザーに代わって選べないためです。Q4は期限の軸を担います。開催日が動かせない期限です。告知から開催までの期間が短い場合、短期間で効果が出る手段(有料広告、パートナーの次回配信)を、効果が遅い手段(ゼロからのリスト構築、地域での関係づくり)より優先します。後者は、圧縮された1サイクルの間に労力に見合う成果を上げられないためです。

  1. 有料チケット制ですか、それとも無料登録制ですか?これによってスケジュールの骨格が決まり、インタビューで最も重要な回答となります。
  2. コミュニティ主催ですか、それとも企業・ベンダー主催ですか?チャネルの費用対効果が異なります(次のセクションを参照)。
  3. 目標数は何ですか。見込み有料チケット販売数ですか、それとも参加者数の目標ですか?チケット制イベントの場合は、スポンサー、登壇者、主催者、ボランティア向けの無償チケットを差し引いた販売見込み数を尋ねてください。これらのチケットは販売する必要がなかったものです。
  4. すでに確定している日付はどれですか。告知、早期割引の終了、CFPの締め切り、登壇者の発表、全プログラムの発表、開催日ですか?計画を立てる前にすべて確認してください。
  5. 目標とする参加者は、すでにどこで読んだり、聴いたり、集まったりしていますか。どのメーリングリスト、コミュニティ、ミートアップ、キャンパス、雇用主ですか?具体的な媒体や組織を挙げてもらうことで、チャネルの比重が決まり、以下の選択肢の価値が同じ場合に判断できます。
  6. イベントがすでに持っているものは何ですか。メーリングリストとその規模、ソーシャルアカウントとそのリーチ、前回開催時の販売推移、既存のパートナー一覧はありますか?
  7. 集客予算はありますか。また、誰が承認しますか?スポンサー収入で約80%以上を賄うコミュニティイベントでは、集客費用はマーケティング費目ではなく、ケータリング費用と競合します。
  8. 今回限りの開催ですか、それとも開催を重ねて資産を育てますか?資産を育てる方針であれば、1回限りの開催では投資に見合う成果を得られない、時間のかかる施策(リスト構築、地域での存在感づくり、パートナーとの関係構築)が優先されます。
  9. 労力の上限はどの程度ですか。主催者が週に使える時間、執筆担当者、対面で参加できる人員を教えてください。
  10. 今回は対面、オンラインのみ、ハイブリッドのいずれですか?

コミュニティ主催と企業主催の違い

カンファレンスのチケットを購入するのは個人の開発者ですが、費用を雇用主が負担することも多いため、どのイベントでも雇用主負担と自己負担の参加者が混在します。計画を実際に左右する軸は、イベントの主催者です。この軸は、このコレクションの位置づけやスポンサー獲得のスキルが示すものと同じです。

  • コミュニティ主催 - コミュニティ主催者向けガイドでは、ここで使用するチェックポイントとチャネルの分類を定めています。集客では、現金がイベント自体の費用と競合するため、主に自社保有チャネルと相互提供チャネルを活用します。有料掲載の代わりに、相互に露出を提供する交換施策を使います。
  • 企業・ベンダー主催 - コミュニティ主催者向けガイドはコミュニティイベントを対象に書かれているため、この場合はそのまま引用せず、応用してください。実際の予算項目、それを管理するマーケター、コミュニティイベントでは利用できない有料チャネル、そして相互提供ではなく商用広告枠を通じてベンダーのプロモーションを配信するメディア媒体が想定されます。スケジュールの骨格は変わらず、変わるのは予算の考え方だけです。

予算を割り当てる前に、計画がどちらの立場を前提としているかを明示してください。

カレンダーの軸を選ぶ — 2つを決して混在させない

カレンダーの軸には2種類あります。異なる分母を測定し、構造的に異なるイベントに適用されます。両者を平均したり、一方のチェックポイントをもう一方に持ち込んだりすると、どちらの方向にも目標が誤ってしまいます。

  • チケット制のカンファレンス → 想定チケット販売数に対する割合(DevOpsDays 主催ガイド)。販売数は告知時に急増するため、チェックポイントは固定された日数ではなく、名前の付いたマーケティング施策のタイミングに置きます。管理対象のリスクは、販売数が不足することです。
  • 無料イベント → 参加目標に対する割合(MLH ハッカソン主催者ガイド)。チェックポイントは固定された日数(2週間前、1週間前)に置き、意図的に目標を100%より高く設定します。管理対象のリスクは、販売数の不足ではなく、無断欠席です。

両方のチェックポイントの全段階、その根拠となる計算例、フェーズ目標の手法については、references/calendar-spines-and-phase-targets.md を参照してください。

この選択肢には、意図的に優劣を付けていません。2つの軸は、労力あたりの価値が異なる競合する選択肢ではありません。需要の形が異なる2種類のイベントを表すものであり、イベントの収益構造と無断欠席の状況によって、どちらを選ぶかが明確に決まります。順位付けは、実態のない精密さを装うことになります。「より効率的な」軸とは、単にそのイベントにとって測定対象が間違っている軸です。

中間的なケース、つまり名目上の参加費があるイベントや、収容人数に厳格な上限がある無料イベントでは、実際に懸念する失敗が未販売の席なのか、空席なのかに基づいて軸を選んでください。計画で目標として使うのは、選んだ軸だけにします。もう一方の軸のチェックポイントは、目標には含めない補助的な妥当性確認として参照してください。

ワークフロー

  1. インタビューを実施します。軸(Q1)、目標(Q2)、競合を差し引いた目標数(Q3)、確定日程(Q4)を固めます。
  2. samber/dev-event-organizer-skills@event-positioning と samber/dev-event-organizer-skills@event-market-fit から読み取ったメッセージと需要を、それぞれ1段落で言い直します。どちらかが欠けている場合は、いったん停止して先にそちらへ案内します。対象者が定義されていない状態でチャネル計画を立てると、労力を無作為に割り当てることになります。
  3. Q5 の回答からオーディエンスセグメントをチャネルに対応付け、以下の優先順位付きメニューを使って重み付けします。各チャネルがどのセグメント向けに使われるのかを明記します。
    • 1つのセグメントに複数のチャネルが必要となることがあります。
    • 1つのチャネルが複数のセグメントに対応することがあります。
  4. 軸のチェックポイントをカレンダーに配置し、Q4 の確定日程をすべてそこに記入します。今日から先へ進むのではなく、開催日から逆算します。最も早い基準点は T-7か月、「マーケティングが滞りなく進んでいることを確認する」(DevOpsDays 主催者ガイド)です。
  5. 以下の予算配分メニューを使って予算を割り当てます。割合配分表はイベント業界の慣行ではなく、B2B/B2C SaaS の慣行に基づいています。表を示す際は、そのことを明記し、借用した慣行がイベントの標準だと誤解されないようにします。
  6. ファネルの目標は、直線的な推移ではなく、軸のチェックポイントに照らして各フェーズごとに設定します。方法と具体例については、references/calendar-spines-and-phase-targets.md を参照してください。
  7. 各チャネルを、実行を担当する関連スキルに割り当てます(「参考資料」を参照)。重み付け、フェーズ、日程を引き継ぎます。ここでは関連スキルのコンテンツを作成しないでください。
  8. 各チェックポイントで、計画独自の進捗曲線と照らして予測を更新し、対応を変える前に未達の原因を診断します(「測定」を参照)。

主催者の優先事項の中で、参加者獲得が占める位置。 主催者が重視するのは登壇者の質に次ぐ2番目にコミュニケーションであり、その両方に役立つツールを求めています。つまり、登壇者の獲得パイプラインとキャンペーンの両方に使える、1つの連絡先データベース、1つのスケジューラー、1つのフォームツールです。これは、両方の業務に使うツールを一度に選ぶ理由として扱い、この計画が押し付ける優先順位として扱わないでください。優れたプログラムにも、この計画は必要です。「失敗パターン」にある DevOpsDays の警告を参照してください。

ハーネスに永続メモリがある場合は、開催回ごとに以下を記録します。

  • 選んだ軸とその理由。
  • 競合を差し引いた目標数。
  • チャネルの重み付けと、それぞれのチャネルを使う対象セグメント。
  • 確定日程。
  • 予算配分の方針。
  • 各チェックポイントの計画値と実績値。

次回開催の計画は、白紙のカレンダーではなく実際の過去の推移を出発点とします。これは、ペース指数の手法に必要なことです。

チャネルミックス

優先順位付きメニューは、主催者の労力1単位あたりに得られる価値の順に並べたものです。DevOpsDays の5つのチャネルからなる認知度分類と、MLH のキャンパスおよびソーシャル向けの施策カタログに基づいています。この価値の順位は測定値ではなく判断に基づくものです。主催者がすでに持っているものに応じて順位を付け直してください。

チャネル分類、ガイドからの引用、キャンパス規模の施策、Owned/Earned/Paid の枠組みについては、references/channel-menu-and-budget-allocation.md を参照してください。

  • 労力(主催者の作業時間、調整、継続性):地域およびキャンパスでのエンゲージメント > パートナーチャネル > 自社のソーシャルプレゼンス > 有料広告 == 開催前のプレス対応 > 自社のメーリングリスト > コミュニケーションハブ
  • 価値(獲得できた登録数。測定値ではなく判断):自社のメーリングリスト > 地域およびキャンパスでのエンゲージメント == パートナーチャネル > 自社のソーシャルプレゼンス > 有料広告 > 開催前のプレス対応 > コミュニケーションハブ
  • 効率:自社のメーリングリスト > コミュニケーションハブ > パートナーチャネル > 有料広告 > 地域およびキャンパスでのエンゲージメント > 自社のソーシャルプレゼンス > 開催前のプレス対応
  • コンプライアンスコスト(レビューの発生、取り消し可能性の低下):有料広告 > 自社のメーリングリスト > パートナーチャネル

残る4つのチャネルには、それ自体のコンプライアンスコストはありません。自分のアカウントへの投稿、ミートアップへの参加、リンクハブの公開、地域のメディアへの売り込みでは、同意記録も署名済みの契約も、支出承認も必要ありません。

同順位となる2組には、どちらも根拠があります。

  • 労力が同程度(有料広告 == イベント前のプレス):有料広告の実施もプレス向けの売り込みも、1〜2時間ほどの準備や執筆をした後は、誰か他者のシステムからの反応を待ちます。どちらも、ソーシャル投稿のように継続的に行う仕事ではありません。
  • 価値が同程度(地域でのエンゲージメント == パートナーチャネル):どちらも、すでに誰かが集め、運営者を信頼しているオーディエンスにイベントを届けます。違いは、主催者が直接出向くか、パートナーのチャネルが代わりに届けるかであり、どれだけのリーチを購入するかではありません。

コンプライアンスコストが実際に発生するのは、次の3段階だけです。

  • 有料広告には、組織名義の広告アカウント、プラットフォームの広告ポリシー審査、そして広告費の支出を承認できる担当者が必要です。
  • 自社のメーリングリストには、同意に関するリスクがあります。ある開催回のために収集したリストを、記録されたオプトインなしに次回の開催回でメール配信に使うと、イベント側では取り消せない削除を強いられかねない唯一の集客資産になります。
  • パートナーチャネルには、ロゴの使用許諾と配信条件が伴います。これらは samber/dev-event-organizer-skills@cross-event-promotion と samber/dev-event-organizer-skills@event-media-partnerships で扱います。

各チャネルの詳細:

  • 自社のメーリングリスト - チケット販売開始のお知らせ、早期割引、アジェンダの公開、カウントダウンなど。DevOpsDays のガイド:「エンゲージメントを維持するため、メールは有益な内容にし、配信頻度を抑えましょう。」イベントにリストがない場合は、ゼロから構築する価値があります。前回の登録フォームに、その年は参加できないと回答した人が記録されている場合は、今回の開催発表時にそのセグメントへ再度連絡しましょう。「前回は都合がつきませんでしたが、今回は参加できますか」という問いかけは、他のチャネルでは届かないリストの一部に対して有効です。
  • コミュニケーションハブ - すべてのチャネルを一元化した1ページで、QRコードで共有できます(DevOpsDays 主催者ガイド)。一度だけ作成します。他のチャネルで生み出したリーチを成果につなげるものであり、それ自体がリーチを生み出すわけではありません。そのため、価値は低い一方で効率は高くなっています。この計画ではページを管理し、samber/dev-event-organizer-skills@event-comms-channels が公開するチャネルごとの一覧(名称、役割、担当者、所要時間)を提供します。
  • パートナーチャネル - イベント間の相互告知、メディアやコミュニティのパートナー、開発者アンバサダープログラム。実施は samber/dev-event-organizer-skills@cross-event-promotion と samber/dev-event-organizer-skills@event-media-partnerships が担い、この計画では比重と段階を定めます。
  • 有料広告 - ターゲティングされたソーシャル広告。MLH のガイドでは、大学のオーディエンスに対して「安価で効果的」と説明しています(注:この主張は大学規模に特化したもので、一般論ではありません)。
  • 地域および大学でのエンゲージメント - ミートアップ、地域の雇用主、事業者団体(DevOpsDays);授業での告知、ブース出展、チラシ配布、学生団体や学部への働きかけに加え、「6時間以内の距離にある少なくとも3校」への招待ルール(MLH)。事業支援ネットワークやインキュベーターと、学校の担当者を、ひとまとめの地域リストではなく、別々の紹介元グループとして扱いましょう。アウトリーチの頻度が異なるため、個別に追跡することで、それぞれのグループのコンバージョンを把握しやすくなります。
  • 自前のソーシャルプレゼンス - イベントのアカウントで、投稿時刻に変化をつけながら定期的に投稿します。直感的な位置づけより意図的に比重を低くしています。DevOpsDays のガイドは問題を直接指摘しています。「テックコミュニティが Twitter から分散したことで、多くのコミュニティイベントが人々に情報を届けるのに苦労しています。」主催者からは、主催者個人のアカウントのほうが、支部やイベントごとのページより多くの人に届くという、確信度の低い報告も寄せられています。この比重は維持し、誰のアカウントを使うかは samber/dev-event-organizer-skills@event-social-media に判断を任せましょう。
  • イベント前のプレス - 学校新聞、地域メディア、コミュニティメディア(MLH)。プレスキャンペーンより負担の軽い依頼です。正式なプレス活動は samber/dev-event-organizer-skills@event-press-relations の担当です。

どこから始めるか:

  • デフォルトの段:独自のメーリングリストとコミュニケーションハブを持ち、その基盤として独自のソーシャルメディアでの発信を継続します。
  • 昇格条件:Q5で、対象者層が実際に合致する媒体が特定されたらパートナーチャネルを追加します。有料広告は、運用中のチャネルのいずれかで、拡大する価値のある参照元を追跡できた場合に限って追加します。達成が危ぶまれるチェックポイントに対して、最初の手段として使ってはいけません。

後回しにされる選択肢は、地域やキャンパスでのエンゲージメントです:価値は高いものの、最も手間がかかるため、効率性の観点では選ばれません。それでも、次の2つのケースでは優先します。

  • メーリングリストがない初回開催で、最上位の段が実質的に空の場合。
  • 対象者が地理的に集中している場合(1つのキャンパス、1つの都市圏)。対面での活動なら、運用中のどのチャネルでも届かない対象者層にリーチできます。

主催者向けガイドも、この方法を明確に推奨しています。DevOpsDaysは「優れたアジェンダだけで参加者が集まるという誤解を避けてください。イベントを積極的に宣伝してください」と述べ、MLHはチラシ配布や授業内での告知を、任意ではなく中核的な取り組みとして扱っています。

Q10を基準とする削除条件:オンラインのみの開催では、地域でのエンゲージメントのうち対面の部分を、格下げするのではなく削除します。ミートアップやコミュニティとの関係はオンラインでも維持できますが、ブース出展やチラシ配布はできません。削除した段が、3週目にスコープとしてひそかに復活することはありません。

予算配分の方針

順位付きの選択肢 — 資金の取り扱いや承認にかかる労力あたりで獲得できる登録数です。方針と、全体配分の詳細を示す割合表については、references/channel-menu-and-budget-allocation.mdを参照してください。

  • 労力(計画、承認、照合、監視):全体配分 > 集中投資 > 固定テスト予算 > 物々交換のみ
  • 価値(獲得したリーチで評価):集中投資 == 全体配分 > 固定テスト予算 > 物々交換のみ
  • 効率性:物々交換のみ > 固定テスト予算 > 集中投資 > 全体配分
  • コンプライアンスコスト:全体配分 == 集中投資 > 固定テスト予算

物々交換のみの場合、独自のコンプライアンスコストはかかりません。発生するのは、上記のパートナーチャネルを担当する2つのスキルが管理する、パートナー間の合意に伴う負担です。

2つの同順位には、それぞれ理由があります。

  • 価値が同順位(集中投資 == 全体配分):どちらも同じ金額を投入し、同程度の総リーチを獲得します。全体配分はチャネルの不確実性に備え、集中投資は1つのチャネルで得た学びを積み重ねます。期待値ではなく、ばらつきが異なります。
  • コンプライアンスコストが同順位(全体配分 == 集中投資):どちらも、会計担当者や財務部門の承認、および組織名義の広告アカウントが必要になる基準を超えます。一方、上限を設けたテスト予算であれば、通常は主催者1人の裁量内で実行できます。

各方針の詳細:

  • 物々交換のみ — すべてを自ら運用するチャネルと、相互に認知度を高める交換を通じて行います。現金も承認も必要ありません。
  • 固定テスト予算 — 上限を定めた予算を1つ、使用する有料チャネルを1つ、測定する質問を1つに絞ります。
  • 集中投資 — 利用可能な現金の大部分を、最も確度の高い単一のチャネルに投入します。
  • 全体配分 — 有料施策、コンテンツ、パートナー、テストの各項目に、バランスよく割合を配分します(イベント業界の標準ではなく、SaaSマーケティングの実務をもとにしています)。

開始方法:

  • デフォルトの段:コミュニティ主導のイベントでは、物々交換のみと固定テスト予算を組み合わせます。
  • 昇格条件:チェックポイントに届かず、かつ拡大する価値のある参照元を追跡できるチャネルがすでにある場合は、集中投資に切り替えます。未達だけなら、支出するのではなく原因を診断する理由になります。

後回しにされる選択肢は全体配分です。労力と承認の負担が大きいため、効率性の観点では選ばれません。継続的なマーケティング予算枠があり、その報告を担当するマーケターがいる企業主導のイベントでは、全体配分を優先してください。その場合、リスク分散の価値は運用負担に見合いますし、その負担を担うのは実際に担当業務を持つ人です。

資金がまったくない場合 — 獲得予算も自由に使える予備費もない場合 — は、3つの支出方針を下位に置くのではなく削除します。その場合、選択肢は物々交換のみです。資金を出せない段を、チェックポイント未達時の代替案として復活させてはいけません。

失敗のパターン

  • 2つの基準軸を混同すること。 「目標の200%」と「予想売上の40〜50%」は分母が異なる割合です。前者の分母は参加目標、後者の分母はコンプ分を差し引いた予想売上です。両者を平均したり、MLHの「2週間前」のルールを有料カンファレンスにそのまま当てはめたりすると、達成不可能な、あるいは簡単に達成できてしまう目標になり、どちらにしても何も分かりません。どちらか一方の基準軸を選び、どちらを選んだかを明示して、もう一方を目標の設定から外してください。
  • ここで早期割引の締切日を設定すること。 締切日は samber/dev-event-organizer-skills@event-ticket-pricing から固定で引き継がれます。キャンペーンを調整するために締切日を動かすと、価格体系とイベントの収益が変わり、価格設定スキル独自のチェックポイントも、測定した内容を示さなくなります。その日程を前提に計画してください。本当に変更が必要な場合は、判断を差し戻してください。独断で変更を取り込まないでください。
  • 別のスキルの担当範囲に踏み込むこと。 この計画の中で告知メールの作成、登録ページのデザイン、ソーシャルコンテンツカレンダーの作成を行うと、担当する別のスキルの成果物と競合する第2のバージョンが生まれます。伝えるのは重みづけ、フェーズ、日付だけにしてください。それ以上は行わないでください。
  • 無料イベントの離脱率をあらゆるイベントに当てはめること。 登録から参加までの30〜50%の離脱率は、無料ハッカソンを対象とするMLHの数値であり、だからこそ、その基準軸では200%を目標にしています。有料チケットには、それよりはるかに低い独自の欠席傾向があり、その割合はイベントごとに設定します。無料イベントの過剰登録率を、有料カンファレンスに適用してはいけません。
  • 予算の割合をイベント業界の基準として提示すること。 これらの割合はSaaSマーケティングの実務から得られたもので、イベント業界のベンチマークではありません。注記なしで示すと、イベント業界の標準として受け取られます。読者が、取締役会に対して、受け入れる根拠のない数値を擁護することになってしまいます。必ず明示的にラベルを付けてください。
  • ローンチ週を需要と見なすこと。 告知直後の急増が示すのはリーチであり、需要ではありません。キャンペーンの傾向が読み取れるようになるのは2週目です。中盤が落ち着くのは曲線の通常の形であり、失敗の兆候ではありません。
  • プログラムが確定してからマーケティングを始めること。 DevOpsDaysのガイドは、「素晴らしいアジェンダだけで参加者が集まるという誤解を避けること」と明確に警告しています。記録されている最も早い開始時点はT-7か月であり、ほとんどのプログラムが確定する時期よりかなり前です。

測定

チャネルへの貢献度の測定は、率直に言って弱点です。ファネル全体のチェックポイントには公表済みのベンチマークがありますが、チャネルごとの目標はすべて自分で設定する必要があります。 公表されているイベントの数値が測定するのはファネル全体であり、各チャネルがどれだけ貢献したかではありません。そのため、チャネルごとの数値は、追跡対象のリンクの精度に左右されます。開始前に、それぞれのシグナルが何を引き起こすのかを書き留めてください。

  • 選んだ基準に対する目標達成度:計画内で唯一、外部データに基づく目標ラインです。段階と数値については、references/calendar-spines-and-phase-targets.mdを参照してください。
  • 実行と需要を見分ける指標(チケット販売数の基準):開催1か月前の時点で、予想販売数の約40~50%に達していれば順調です。認知度向上の取り組みを見送った、または遅らせたチームは、同じ時点で25~30%程度になります(DevOpsDays)。この範囲で目標を下回っても、それはマーケティング施策の実行上の問題であり、需要がないことの証明ではありません。両者への対処は正反対なので、結論を出す前に原因を診断してください。販売数の不足を需要の弱さと捉える前に、次の3つのコミュニケーション上の原因を具体的に確認してください。プログラムや登壇者の発表が計画より遅れたこと、テーマを絞り込みすぎて想定していた参加者の一部を除外してしまったこと、そして、誰が歓迎されるのかをメッセージで明確に伝えていなかったことです。最後のケースは、漠然と「もっと宣伝すべきだった」と診断するのではなく、ファネルの問題として明示する価値があります。
  • イベント独自の過去の推移に対するペース指数:現時点までのチケット販売数を、推移から予想される販売数で割り、100を掛けた値です。100を上回れば好調で、下回れば、規模と期限が明確な不足があることを示します。過去の推移データが必要となるため、ステップ8の記録が重要です。
  • チャネル別の参照シグナル:チャネルごとに異なるトラッキングリンクまたは登録コードを設定します。開始後に追加することはできないため、開始前に決めてください。2回連続で登録者がゼロのチャネルは、次回の開催では比重を下げます。パートナーチャネルが複数の独立したクローズドコミュニティ(学校や専門家グループなど)にサービスを提供している場合は、パートナーチャネル共通のコードを1つ使うのではなく、それぞれに独自のコードを割り当ててください。どのコミュニティから実際に登録につながったかを追跡でき、そのコミュニティにも、一般的な割引ではなく自分たちに向けた招待として伝わります。
  • 参加人数以外のファネル属性(独自に設定し、ベンチマークとしては扱いません):職種の構成、地域、そして多くの計画で見落とされる1つの指標、つまり翌営業日の休暇取得など、チケット代以外に参加者が実際に負担するものの有無です。登録フォームで役職のチェックボックスだけを尋ねると、手軽に対象を絞り込めますが、該当する選択肢がない人を除外してしまいます。そのトレードオフを意図的に選ぶ場合は、節約した労力を、誰が歓迎されるのか、一般的な参加者はどのような人かといったメッセージの改善に充て、除外の問題を放置しないでください。また、ギャップが明らかになってから後付けで修正するのではなく、初回からチェックボックスの選択肢を広く設定してください。
  • 継続的に把握するオーディエンス指標(独自に設定する遅行指標):イベントが利用するビジネス向けソーシャルネットワークのフォロワー数と、動画チャンネルの再生回数を、開催ごとに1回記録します。主催者は両方を追跡します。これらが測るのは開催と開催の間にイベントが自ら獲得したリーチであり、登録数ではありません。数値をチャネルのコンバージョンとして捉えたり、自分たちの過去の実績以外に基づいて目標を設定したりしないでください。動画チャンネル自体は、samber/dev-event-organizer-skills@tech-podcast-youtube-channelの所有物です。
  • イベント後の満足度(引き継ぎ対象であり、担当範囲外):イベント後に自動送信されるアンケートの回答は、次回開催のポジショニングとチャネルの比重に反映されます。アンケートの設計はsamber/dev-event-organizer-skills@event-feedbackが担当し、送信スケジュールはsamber/dev-event-organizer-skills@event-comms-channelsで設定されます。
  • 登録フォームで尋ねる自己申告の流入元:「どこでこのイベントを知りましたか」は、自社チャネルを過少に数え、登録者が最後に目にした情報を重複して数えます。トラッキングリンクとの照合にのみ役立つもので、主要なアトリビューションとして使わないでください。
  • リーチとコンバージョンの切り分け(独自に設定する診断指標):登録ページへの流入が十分あるのにコンバージョンが少ない場合は、チャネル構成ではなく価格やページに原因があることを示します。さらにリーチを買い増すのではなく、samber/dev-event-organizer-skills@event-ticket-pricingまたはsamber/dev-event-organizer-skills@event-landing-pageに引き継いでください。

呼び出し例

  • 「10月に有料の DevOps カンファレンスを400人規模で開催します。マーケティング計画を作成してください。チャネル、カレンダー、目標を含めてください。」
  • 「無料のハッカソンに500人の参加者を集める必要があります。登録開始は3か月後です。キャンペーンはどのような内容にし、いつまでに何件の申し込みが必要でしょうか?」
  • 「開催まであと1か月ですが、チケット販売は予想の28%にとどまっています。需要の問題でしょうか。それともマーケティングが不十分だったのでしょうか?」
  • 「プロモーション予算は2,000ユーロで、ボランティアチームは4人です。どこに投入すべきでしょうか?」

期待される出力:

  • 選択した基本計画と、その選択理由。
  • 招待枠を差し引いた目標。
  • チャネルごとの配分と、各チャネルで獲得するセグメントを示した、オーディエンスとチャネルの対応表。
  • すべての確定日を基本計画のチェックポイントに割り当てた、日付入りのキャンペーンカレンダー。
  • 配分を含む予算方針。
  • フェーズごとのファネル目標。
  • 各チャネルを実行する担当スキルを示したルーティングリスト。

参考資料

チャネルの実行担当(各チャネルを適切な関連スキルに割り当てます):

  • samber/dev-event-organizer-skills@event-social-media - ソーシャルチャネル内のプラットフォーム構成、コンテンツカレンダー、拡散キットを担当します。
  • samber/dev-event-organizer-skills@event-landing-page - 登録ファネルのページ上のコンバージョンを担当します。この計画では、ここにトラフィックを誘導します。
  • samber/dev-event-organizer-skills@event-attendee-email-sequences - この計画のカレンダーで配信タイミングを定めたメールを作成します。
  • samber/dev-event-organizer-skills@event-comms-channels - チャネル選定の方法論とトーンの一貫性を担当します。この計画では選択をやり直さず、その決定を利用します。

コメント