検証可能な記録に基づくエアドロップキャンペーン計画

エアドロップ概要書にはどのような決定事項を含めるべきですか？

1ページの概要書は、配布を特定のプロジェクト決定に結びつける必要があります。対象となる受取人グループ、プロジェクトのニーズ、承認されたトークン範囲、チームがレビューする成果を記録します。プロモーション業務は後回しにします。この順序により、キャンペーン活動をチームが説明可能な目的に結びつけ続けることができます。

概要書は4つのインプットから構築します：

• プロジェクトの段階と、この配布が対応するニーズ。
• 受取人のプロフィールと、そのグループが関連する理由。
• 割り当て範囲と、変更を承認できる担当者。
• 表明された目的が達成されたかを示す証拠。

認知度と配布成果は区別します。告知のリーチは露出を説明できます。請求、適格な参加、または関連するプロダクト活動は、計画の他の部分を説明できます。ある指標を別の指標の代わりとして扱わないでください。

プロダクト、トークン、コミュニティの各担当者に同じドラフトをレビューしてもらいます。公開用コピーを作成する前に、矛盾した前提を解決します。配布がより広範なリリースの一部である場合は、トークンローンチチェックリストと整合させます。運用サポートについては、チームのニーズをエアドロップキャンペーン管理と比較してください。決定担当者と承認されたバージョンを書き留めます。その記録は、後でレビューする人に安定したリファレンスを提供します。

適格性記録には何を含めるべきですか？

適格性記録のサンプルは、ルールが一貫して適用可能かどうかを示します。参加を開始する前に、対象となるアクション、関連期間、受け入れられる証拠、除外事項、締切、異議申立経路を定義します。各基準は、概要書の受取人グループと明確な関連性を持つ必要があります。

目的に合った証拠を使用します。プロダクトの使用を対象とした配布には、プロダクトとのインタラクションが適切な場合があります。貢献については、指名されたチームメンバーによるレビューが必要な場合があります。コミュニティ活動には、定義された記録と期間が必要です。基準を組み合わせる場合は、参加者がすべての条件を満たす必要があるのか、いずれか1つの条件を満たせばよいのかを明記します。

ドラフトを4つのケースでテストします：明確な一致、境界線上にある記録、不完全な証拠、明らかな重複。それぞれの結果を書き留めます。その後、ドラフト作成グループ外のレビュー担当者に、コーチングなしでルールを適用してもらいます。レビュー担当者が異なる判断を下した場合は、公開前に文言を修正します。

修正経路を明確にしておきます。参加者には、どの情報を提供すべきか、どこに送信すべきかを伝えます。レビュー担当者には、ケースを解決するための締切を設定します。モデレーターは、公開の会話で適格性ポリシーをその場で作り出すべきではありません。別のコミュニティ参加計画が参加をサポートすることはできますが、公開された基準やレビュープロセスを置き換えるものではありません。

チームはどのように重複参加をレビューできますか？

レビューログを使用すると、チームはウォレットアドレスを完全な本人確認記録として扱うことなく、証拠を比較できます。適格性ルールに合致するシグナルを選択し、レビュー担当者がそれらをどのように使用するかを文書化し、参加者が除外に異議を唱えるための経路を作成します。目的は、完全な本人確認を主張することではなく、一貫したレビューです。

開始前に、簡潔なスクリーニングプロトコルを作成します。これには以下を明記します：

• レビュー担当者が比較できる記録。
• より詳細な調査のトリガーとなるパターン。
• 除外を承認できる担当者。
• 修正または異議申立を裏付ける証拠。

同じプロトコルを対象となるすべてのケースに適用します。判断理由をレビューした記録と一緒に保管します。参加者情報へのアクセスは、適格性判断またはサポートのために必要な担当者に限定します。これにより、チームは監査証跡を確保しつつ、場当たり的な判断を減らせます。

ウォレットは、アドレスに関連付けられたアクティビティを示すことができます。各アドレスが異なる人物に属することを証明することはできません。この制限をキャンペーン規約に説明し、ユーザーが誤った判断を報告できるようにします。参加者が理解できない、またはレビュー担当者が一貫して適用できないスクリーニングルールは避けます。公開前に、参加者サポートを担当する担当者と最終的な文言を確認します。

割り当て記録と請求はどのように連携させるべきですか？

照合シートは、承認された各適格性判断を割り当てと請求ステータスに結びつけます。キャンペーンに割り当てられた金額から始めます。次に、計算方法、上限、および請求されなかった割り当ての取り扱いを文書化します。

チームが平易に説明できるモデルを選択します。固定割り当てでは、適格な各記録に同じ金額が割り当てられます。段階的モデルは貢献レベルを区別し、各段階に一貫した証拠が必要です。比例モデルは定義されたインプットに従い、上限が必要な場合があります。選択する前に、利用可能な証拠がモデルをサポートしていることを確認します。

適格な記録ごとに1行を使用します。以下の4つのフィールドを含めます：適格性の根拠、割り当て、レビューステータス、請求ステータス。2人目のレビュー担当者が合計を承認されたキャンペーンプールと比較します。最終承認前に、重複記録、不適格記録、未請求割り当てをテストします。レビューしたモデルと最終ファイル間のすべての変更を記録します。

受取人がプロジェクト管理の請求ページを使用するか、直接配布を受けるかを決定します。選択した経路の手順を作成します。フローを構築していない担当者に、最初から最後まで従ってもらいます。コミュニティ活性化は割り当てロジックとは別にします。コミュニティ成長と参加ハブは、関連するオーディエンス目標をカバーしますが、受取人選定ではありません。

請求前に参加者が知っておくべきことは何ですか？

承認された単一の手順書が、参加者の実用的な質問に答える必要があります。プロモーション前に規約を公開し、プロジェクトウェブサイトと公式コミュニティチャネルで同じコア文言を使用します。コピーにバージョンを付け、チームが各段階でどの手順が有効だったかを識別できるようにします。

告知で以下の5つのポイントをカバーします：

• 誰が適格となり得るか、どのアクションが対象となるか。
• チームがレビューする証拠。
• 修正受付の締切と、リクエスト先。
• 請求の仕組みと、公式アップデートの掲載場所。
• アカウント固有の問題を処理するサポート経路。

公式ウェブサイトと請求経路を明記します。ウォレット接続やトランザクションについて、わかりやすい言葉で説明します。プロジェクトの代表者はシードフレーズや秘密鍵を要求しないことを明記します。モデレーターには承認済みの回答とエスカレーション担当者を提供します。参加者に公開チャネルで個人情報を投稿するよう求めないでください。

Telegramが主要なサポート手段である場合は、告知前にチャネルの担当者を割り当てます。Telegramコミュニティガイドがチャネル計画に役立ちます。クリエイターがキャンペーンを共有する場合は、承認済みの概要書1つとトラッキングリンクを提供します。仮想通貨KOLキャンペーンとメッセージを調整し、すべてのバージョンが公開された適格性条件と一致するようにします。

どのような順序で配布の決定を追跡可能にしますか？

5つのチェックポイントが作業の順序を維持します：承認された概要書、テスト済みの適格性、照合済みの割り当て、準備済みの請求経路、請求後レビュー。各チェックポイントに担当者を割り当てます。指定されたアウトプットがレビューの準備ができた場合にのみ、次のステップに進みます。

スケジュールは、参加記録の準備状況、配布方法、利用可能なレビュー担当者に従います。プロモーション開始前に、エッジケースのための時間を確保します。適格性テキストや請求経路がまだ変更中である間は、公開開始日を設定しないでください。

配布後、観察された請求と関連するフォローアップ活動を当初の目的と比較します。サポートテーマは告知のリーチとは別にします。チームがレビューできたもの、未解決のもの、修正が必要な手順を記録します。継続的なキャンペーン計画については、ブログを関連ガイドの出発点としてご利用ください。

配布前にウォレットレビューで何が確認できますか？

適格性ファイルとトランザクション記録は、異なる証拠を提供します。レビュー済みファイルは、チームが表明した基準をどのように適用したかを示します。オンチェーンアクティビティは、アドレスに関連付けられた転送とアクティビティを示すことができます。どちらも、記録されている以上の証拠として提示されるべきではありません。

オンチェーンアクティビティは、各アドレスが異なる人物を表すことを証明しません。確認された転送は、同じ配布経路では元に戻せない場合があります。請求開始前にこれらの点を参加者規約に記載し、技術担当者に正確な請求手順とユーザー向け情報を確認してもらいます。

承認前に最終レビューシートを使用します。規約が割り当てモデルと一致していること、各除外に文書化された理由があること、サポート担当者がケースをエスカレーションする先を知っていることを確認します。公開された経路がテスト済みの経路と一致していることを確認します。承認された規約と受取人ファイルのコピーを後でレビューできるように保管します。

GeoMarketing Expertsに、ドラフト規約、対象受取人グループ、割り当て範囲、希望する開始時期をお送りください。それらの資料がどのように連携するかをレビューし、次の決定のための具体的な計画推奨事項を返信します。

仕組み

1. 配布概要書を作成するプロジェクトのニーズ、対象受取人グループ、承認された範囲、レビュー指標を記録します。プロジェクト担当者が同じ目的に合意していることを確認します。
2. 適格性基準をテストする対象となるアクション、証拠、除外事項、締切、異議申立経路を定義します。公開前にサンプルケースにルールを適用します。
3. 割り当てを照合する承認されたモデルを適格記録に適用します。2人目のレビュー担当者に合計を確認させ、エッジケースをテストさせます。
4. 請求経路を準備する公式手順、サポート対応、エスカレーション担当者を確認します。フローを構築していないレビュー担当者で参加者フローをテストします。
5. 配布をレビューする請求と関連するフォローアップ活動を当初の目的と比較します。未解決の問題と将来の計画のための変更を記録します。