エアドロップキャンペーン計画：ルール、審査、告知内容

エアドロップで何を達成すべきですか？

クイックテスト： ルールを友人に3文で説明してみてください。誰が対象になるか相手が言えなければ、ルールを書き直しましょう。

エアドロップは、単に注目を集めるためにトークンを配布するのではなく、明確に定義されたプロジェクトの目的に資するものであるべきです。配布がどのようなアクションや関係性を支援するためのものかを決定し、キャンペーンのあらゆる選択をその目的に照らして判断できるようにします。

考えられる目的としては、関連ユーザーへの製品紹介、過去の参加への報酬、新機能の試用促進、貢献者の表彰などが挙げられます。これらの目標は、異なる参加資格ルールを必要とします。既存の貢献者への報酬は、新規ユーザーを招待するためのオープンキャンペーンと同じように設計すべきではありません。

メカニズムを検討する前に、以下の内容を記載した簡潔な内部ブリーフを作成します。

• リーチしたいオーディエンスと、そのオーディエンスが関連する理由。
• 参加資格となり得るアクション、履歴、または貢献。
• 配布後にプロジェクトが学びたいこと、またはサポートしたいこと。
• ルール、コミュニケーション、最終的な割り当てを承認するチームメンバー。

目標に合った測定基準を選択します。プロダクトディスカバリーの場合は、分析とプライバシーのアプローチが許す範囲で、意味のある訪問数や完了したプロダクトアクションを追跡します。貢献者の表彰の場合は、貢献がどのようにレビューされるかを文書化します。参加者数が多いだけでは、キャンペーンが有用なユーザーを惹きつけたことにはなりません。トークンイベントがより広範なローンチの一部である場合は、トークンローンチチェックリストと計画を整合させ、エアドロップが全体のスケジュールにどのように適合するかを合意します。

参加資格ルールの設定方法

参加資格ルールは、誰が参加できるか、そしてプロジェクトが各提出物が条件を満たすかどうかをどのように判断するかを定義します。一貫して適用できる程度に具体的でありながら、参加者がアクションを起こす前に確認できる程度にシンプルに保ちます。

まず、自動的な基準と人間によるレビューが必要な基準を分けます。明示されたアクティビティや定義された期間に基づくルールは、主観的な判断よりも説明と検証が容易な場合があります。複数の基準を使用する場合は、参加者がすべての基準を満たす必要があるのか、一部のみでよいのかを明確にします。該当する場所、アカウント、ウォレット、または参加制限について説明しますが、レビューが完了するまでは、ある人物が参加資格があると示唆しないようにします。

ルールを理解しやすくする

プロモーションを開始する前に、以下を書き留めます。

• 参加資格となるアクションまたは貢献、およびその証拠の方法。
• そのアクションが行われなければならない期間。
• 除外事項、重複エントリーポリシー、または失格理由。
• 参加者が自分のステータスを確認したり、エラーを申し立てたりする方法と時期。

人々が行動した後に基準を変更しないようにします。修正が不可欠な場合は、何が変わったのか、なぜ変わったのか、どの参加者が影響を受けるのかを公開します。明確なポリシーは、サポートチームが一貫した回答を提供するのにも役立ちます。コミュニティタスクを使用するキャンペーンの場合は、参加デザインをクエスト計画ガイドの原則と比較します。タスクは、単に提出数を増やすためではなく、プロジェクトに関連するものであるべきです。

重複または協調的なエントリーの審査

有用な不正利用防止計画は、適切なチェックと明確なレビュープロセスを組み合わせます。デフォルトで不適格と扱うことなく、重複または協調的なエントリーを削減することを目指します。

まず、キャンペーンに適した証拠を決定します。設計によっては、チームはウォレットアクティビティ、タスク完了記録、アカウントの一貫性、または繰り返される提出パターンをレビューする場合があります。単一のシグナルは誤解を招く可能性があるため、レビュー担当者が証拠をどのように組み合わせるか、いつ説明を求めるかを定義します。参加資格に不要な個人情報は収集しないようにします。

書面によるレビュー手順を使用して、類似のケースが同様の扱いを受けるようにします。適用されたルール、考慮された証拠、下された決定の内部記録を保持します。その記録へのアクセスは、それを必要とするチームメンバーに限定し、データ収集前に保持方法を設定します。

参加者向けの説明は簡潔にします。エントリーがレビューされる可能性があること、重要視される基準の種類、修正を依頼する方法を記載します。ルールを回避しやすくするような詳細な検出方法は公開しません。配布自体を超えた継続的なオーディエンスワークについては、より広範なコミュニティ成長計画が、エアドロップタスクを追加するよりも適切かどうかを検討します。

配布方法の選択

適切な配布方法とは、チームが選択した参加資格モデルに対して説明、テスト、サポートできる方法です。メカニズムを決定する前に、参加者のエクスペリエンスと運用負荷を比較します。

これは計画の比較であり、特定のコントラクトを推奨するものではありません。技術チームは、選択されたメカニズムがトークン、チェーン、セキュリティ要件に適合することを確認する必要があります。告知から最終確認までの参加者のジャーニーをテストします。これには、誰かが間違ったウォレットを使用した場合や、ステップを完了できない場合の対応も含まれます。

ローンチ前に割り当てをモデル化します。キャンペーンに必要な金額を確保し、計画された割り当ての合計が承認された配布と一致することを確認し、変更を承認できる担当者を記録します。コミュニケーションにおいて、参加者が未承諾のメッセージを通じてウォレットを接続する必要があると示唆しないようにします。ローンチに他の配布や上場作業が含まれる場合は、より広範なローンチ計画とスケジュールを調整します。

エアドロップ計画の7項目チェックリスト

告知を出す前に、これら7つの項目を確認してください。すべてを満たす計画は、説明しやすく、防御しやすく、実行しやすくなります。

• 達成したい成果を1行で書く。
• 参加資格と除外ルールを公開する。
• スナップショット日と請求期間を確定する。
• 直接送信か請求かを選択し、その理由を説明する。
• 重複および協調的なエントリーの審査を計画する。
• 自分たちが管理するチャネルでのみ、公式リンクを共有する。
• 5つの質問からなるFAQとセキュリティ通知を準備する。

用語を1行で

スナップショット（平たく言えば、設定された時点での残高またはアクティビティの記録）。

請求期間とは、対象者がトークンを受け取ることができる期間を意味します。

告知前の準備

よくある間違い： 告知後にルールを変更すること。ルールは凍結し、スナップショットの日付を公開しましょう。

プロモーションを開始する前に、参加者向けの手順、サポートプロセス、キャンペーン記録を準備します。参加者は、非公式な投稿に頼ることなく、オファーを理解し、ルールを確認し、質問するための公式ルートを見つけられるようにする必要があります。

目的、参加資格、除外事項、配布方法、関連日付、請求手順、サポートチャネルを網羅した、信頼できるキャンペーンページまたは通知を1つ作成します。コミュニティ投稿やパートナー資料全体で同じ表現を使用します。ルールが変更された場合は、まず信頼できる情報源を更新し、他の場所でも変更がわかるようにします。

よくあるケースに対するサポート応答を準備します。参加者がステータスを見つけられない、エントリーが誤ってカウントされたと考える、ウォレットや請求に問題がある、プロジェクトを装ったメッセージに遭遇した、などです。モデレーターには、技術的または参加資格に関する決定のための明確なエスカレーションルートを提供します。参加者にリカバリーフレーズや秘密鍵の共有を決して求めないようにします。

公開前に、キャンペーンに詳しくない人に手順を読んでもらい、ステップを説明してもらいます。誰が対象となるか、どこで助けを得られるかがわからない場合は、ページを簡素化します。エアドロップキャンペーン管理のリソースは、コミュニケーション、コミュニティサポート、配布にわたる作業のマッピングに役立ちます。緊急の質問が放置されないよう、担当を明確にします。

キャンペーンの実行と結果の評価

共有スケジュールに従ってキャンペーンを実行し、参加者の資格や配布に影響を与える各決定の記録を保持します。シンプルな運用計画は、プロジェクトチーム、モデレーター、技術担当者が一貫した情報を提供するのに役立ちます。

実用的な順序としては、ルールと割り当てを承認し、参加者のジャーニーをテストし、告知を公開し、質問と提出を監視し、参加資格をレビューし、その後配布とフォローアップを完了します。各ステージに1人の責任者を割り当てます。公開アップデート、ルール変更、サポートテーマ、配布ステータスの日付入りログを保持し、チームが同じ情報源を使用して問題を解決できるようにします。

最初に設定した目的に対して結果を測定します。有用な証拠には、対象ユーザーが意図したプロダクトアクションを完了したかどうか、貢献者が決定プロセスを理解したかどうか、どのキャンペーン手順が繰り返し質問を生成したかなどが含まれます。確認された結果と仮定を区別し、ウォレット数を永続的な参加の証拠として扱わないようにします。

請求または配布期間が終了した後、簡潔なステータス更新を公開し、何が完了したか、未解決の問題をどこに報告すべきかを説明します。参加者を混乱させた点や、チームに不要な作業を生み出した点をレビューします。これらの観察結果を次のキャンペーンに活かし、他のプロジェクトのメカニズムを、そのオーディエンスや目的が自社と一致するか確認せずにコピーしないようにします。

ローンチ後でも起こり得る問題

適切な計画は回避可能な混乱を減らしますが、告知後のすべての出来事を制御できるわけではありません。オンチェーン取引はネットワーク状況やコントラクトの動作の影響を受ける可能性があり、証拠が不完全であったりルールが不明確な場合、参加資格の決定に異議が唱えられる可能性があります。

このため、公開前に技術チームと選択したコントラクトと請求経路をテストし、レビュー担当者が適用する基準を文書化し、問題に対する明確なサポートルートを準備します。プロジェクトが制御するもの（公開ルール、レビュープロセス、割り当て記録、キャンペーンコミュニケーション）を明示します。見積もりや保留中の取引を完了した配布として説明しないようにします。

キャンペーン全体を通じてセキュリティに注意を払います。プロジェクトが管理するチャネルを通じて公式リンクを共有し、なりすましの報告を監視し、サポートがリカバリーフレーズや秘密鍵を決して要求しないことを参加者に再確認させます。コントラクト、請求インターフェース、または参加資格プロセスが変更された場合は、公開された手順が現在のプロセスと一致するまでプロモーションを一時停止します。これにより、キャンペーンの検証が容易になり、問題発生時にチームが実用的な対応を取れるようになります。

仕組み

1. 目的を設定するオーディエンス、意図するアクション、プロジェクトが学ぶべきことを書き留めます。これらの決定を使用して、以降のすべてのキャンペーン選択を判断します。
2. 参加資格を承認する参加資格となるアクション、除外事項、証拠、レビュールートを定義します。参加者向けのルールを、チームが実際に適用できるプロセスと一致させます。
3. 割り当てをモデル化する配布方法を選択し、計画された割り当てを確認し、承認責任者を割り当てます。プロモーション前に、技術担当者が選択されたメカニズムを確認します。
4. 準備とテスト明確な手順を公開し、コミュニティサポートに簡単な説明をし、参加者のジャーニーをテストします。キャンペーンが告知される前に、混乱を招くステップを修正します。
5. レビューと報告参加資格の決定を記録し、配布を完了し、ステータス更新を公開します。結果を当初の目的と比較し、次回に向けた改善点を記録します。