活動運営の詳細紹介（I）：活動の事前準備

次回の記事では、7か月連続7ラウンドにわたって開催されたUGCイベントを例に、イベント運営にまつわる内容を紹介していきます。この記事は、イベント運営をよりグローバルな視点で捉えたい、1～3年の経験を持つオペレーターに適しています。

アクティビティ操作フローチャート：

理論的には、上記が活動の基本的なプロセスです。これを見ただけでは、実際に何をする必要があるのか​​、イベントを運営する際に何に遭遇するのかについて、まだ適切な概念が浮かばないかもしれません。以下の分析をご覧ください。

イベント運営：イベントの事前準備

運用集約型のアクティビティの場合、規模が大きく、初期段階に関連するアクティビティ テンプレートが存在しない場合は、初期段階でモジュールの構築、資料の準備、部門間のコミュニケーションに多くの時間が必要になります。

次の図に示すように:

この図では、イベント運営の事前準備を次のように分類しています。

1. アクティビティ商品ライン（オンラインアクティビティページおよび背景制作）
2. オペレーションライン（具体的にはアクティビティがオンラインになった後のオペレーションを指します）
3. プロモーションライン（イベントの露出とコミュニケーション準備）

次に、これら 3 つの運用面で何を行う必要があるかを詳しく説明します。同時に、実際の作業では、これらのラインはほぼ同時に実行され、アクティビティがオンラインになる前にほとんどの作業を完了する必要があることに注意する必要があります。

また、この図は、活動目標が上司に確認され承認された後に行うべきことを示しているに過ぎません。つまり、活動目標と実施する活動を確認し、その事前準備を詳細に行う、というのが本当の位置づけです。

（省略された手順は、活動提案を作成し、活動の背景、ゲームプレイ、予算、効果、各部門からのサポートとリスクなどを指定し、PPTにし、上司にレビューしてもらい、上司に承認してもらい、お金をもらうことです。上司が同意した後、活動ルールを詳細化し、実装の準備を整えることができます）

1.1 製品ライン

背景:オンラインアクティビティの場合、最も基本的な機能要件は間違いなくユーザー承認ページです。その後、アクティビティのニーズと複雑さに応じて、対応する操作バックグラウンド、ユーザー情報の抽出と表示機能などを追加する必要があります。

メンタルワクチン: R&D サポートでは、必ずしも最もスムーズなユーザー エクスペリエンスプロセスを実現できるとは限らず、他の部門からのサポートと協力のレベルがイベント運営のニーズを満たせない可能性があり、その結果、運用コストが増加する可能性があります。アクティビティを最適化することを常に念頭に置き、この最適化は一度にではなく段階的に達成する必要があることを認識し、アクティビティ中に障害に遭遇しても落胆しないようにしてください。

1.1.1 製品要件を確認する

活動目標、詳細な活動ルール、ユーザー参加プロセスを明確にすることで、基本的な製品要件を導き出すことができます。他部門からのサポートやフィードバックと組み合わせることで、製品要件の第 1 フェーズは基本的に確定します (ただし、真に実現されるわけではありません)。

【他部門からのサポート】他部門からのサポートレベルも、ある程度は製品の需要に影響します。そのため、関連する要求を行う前（または同時に）に、自分でプロセスを試し、このプロセスに関与する他の部門（通常は財務部門）のサポート作業を整理し、できるだけ早く対応する部門を見つけて、どのように実装するかを話し合う必要があります。次に、最も単純な参加プロセスに基づいて、製品要件を出力します。

例：

UGC 活動を行う際は、ユーザーに報酬を与える必要があるため、ユーザーにとっての手順と体験が可能な限りシンプルになることを望んでおり、これには財務が関係します。

財務部門ではボーナスを分配する方法として次の 2 つを提供しています。

1. 現金賞金（活動資金ローン手続きに従う）
2. 資金はユーザーアカウントに送金されます。

最初の方法では、運用在庫や賞品の授与など、多くの手動アクションが伴います。2 番目の方法は、ユーザーと運用の両方にとって簡単ですが、オープンな財務プロセスが必要であり、財務システムとアクティビティ システムの関連データを接続する必要があり、製品開発のサポートが必要です。

私たちは方法 1 から方法 2 までのプロセスを経てきました。この取り組みは 4 ～ 5 か月間続き、少しずつ資金を活用して、ユーザーにより簡単な参加と勝利の体験を提供する方法を探りました。同時に、対応する製品機能も少しずつ繰り返し調整されます。

製品への関与:

製品が関与することで、オペレーションが行うべきことは比較的シンプルになります。必要なものを整理し、それを製品に渡してプロトタイプを描くだけです。プロセス中によくコミュニケーションを取り、製品がオペレーションのニーズを完璧に表示し、最適化していることを確認します。同時に、優れたプロダクトマネージャーは、実行可能な範囲内でアクティビティプロトタイプのユーザーエクスペリエンスを最適化するために運用を支援し、また、運用がさまざまなサポート部門とコミュニケーションを取り、関連機能の実現を支援します。

製品には社内需要会議があることに注意する必要があります。通常、リソースが限られている場合、社内需要会議後にアクティビティの一部の製品機能が削減される可能性があります。したがって、ここでの前提は、製品と明確にコミュニケーションを取り、アクティビティプロトタイプ製品の機能を優先することです。

思考ワクチン：需要が削減され、割引という形で提示されることもあるので、継続的な最適化を推進し続けるだけです。ニーズの優先順位と利点を明確に表現できることは、ニーズをより迅速に実現するための前提条件です。

1.1.2 製品プロトタイプに記入する必要があるコピーを出力する

前述のように、製品部門の参加により、運用部門の手間と作業が大幅に軽減されます。製品部門は製品のプロトタイプを描き、アクティビティの構造とインタラクティブ要件を示しますが、その他のページのコピーライティングは運用部門が提供する必要があります。

一般的なプロセスは、製品要件の実装 - 操作によるコピーライティング（タイトル、ルール、ボタンのコピーライティング、インタラクティブなコピーライティングなど）の提供 - デザイン（ページ設計）とテクノロジー（操作の背景制作）の制作です。

コピーライティングとは何ですか: コピーライティングは本当にたくさんあります。

• ページコピー（メインとサブタイトル、アクティビティフロー、アクティビティルール、報酬基準、ボタンコピーなど）
• 連絡メッセージのコピー（一般的には、ユーザーが登録後に受信したテキストメッセージ、ユーザーが賞を獲得した後に受信したテキストメッセージなど、ユーザーの特定のアクションに基づいて生成されるオフサイトプロンプトコンテンツを指します）
• インタラクティブなコピーなど（おそらく、ユーザーが期待されるインタラクティブなアクションを実行した後に表示されるポップアップリマインダーや次のアクションガイダンスなど。たとえば、送信が成功した場合は、「送信が成功したことをお祝い申し上げます」、「XX 営業日以内にフィードバックが提供されます」、「進捗状況を確認するには XX WeChatを追加してください」などと表示されます。）
• 商品コピー（例えば、背景ページ上に記録する必要がある情報ヘッダーや情報ステータスの判断項目など）
• 他の……

さらに、コピーライティングの一部はデザイナーに渡されて画像に取り入れられ、一部のコピーライティングは研究開発部門によって調整されます。適応型コピーライティングを作成します。たとえば、「XX ユーザーが XX 元を獲得しました」というスクロール コピーなどです。コピーをページに直接表示するか、または適応させるかは、運用上のニーズに応じて異なります。

例:下の画像のテキストはすべて、運営側が提供する必要のあるコピーライティングであり、製品側では構造とレイアウトのみを提供しています。

1.1.3 イベント製品の設計と開発に関するフォローアップとコミュニケーション

イベント製品ラインに関しては、通常、製品マネージャーがフォローアップするとはるかに簡単になりますが、だからといって運用を無視できるわけではありません。オペレーションはアクティビティの需要側であるため、アクティビティの設計と開発の要件は、製品の要件よりもはるかに明確です。

設計フォローアップ：イベントをより少ない労力と心配で遂行したい場合は、イベント設計要件を提出する際に、製品側が提供する製品プロトタイプに加えて、運営側が設計の参考として期待されるスタイルの資料を見つけられるようにすると最適です。

デザインとコミュニケーションをとるための理想的なプロセスは次のようになります。

• 運用と設計は設計会社の設計スタイル仕様を確認します。
• オペレーターは、デザインの参考に、活動スタイルと会社の設計仕様に一致するいくつかのデザインサンプルを関連Webサイトで検索します。
• 全体的なスタイルで設計が完了したら、タイムリーに運用部門とコミュニケーションを取ります。
• スタイルや要素が問題ないことを確認後、デザインは完成です。

現在、経験の浅い人の多くは、次のようなプロセスに従います。

• 運営側が要件を提示した後、デザイナーは製品プロトタイプとアクティビティテーマに基づいてアクティビティのアクティビティページを設計します。
• 基本的なページデザインを設計および完了し、運用部門と連絡を取ります。
• 運営側がデザインスタイルがイメージしていたものと大きく異なると判断した場合は、再度コミュニケーションを取りスタイルを調整する必要があります。
• 設計の修正と継続的なコミュニケーション。
• 時間的制約により、デザインを大幅に調整することはできず、暫定的にしか確定されません。

運よくデザイナーがオペレーターの望むページをデザインできる場合もありますが、この状況ではデザイナーとオペレーターの間で暗黙の了解があまりにも多く必要になります。したがって、やり取りの手間を減らすためには、デザイン要件を伝えるときに、スタイルの参照も同時に提供するのが最善です。
(このUGC活動を行う際、運営チームは午後にデザインチームと会議を開き、ヘッダー画像の表現について話し合いました。その日の午後、運営チームは、デザインチームが企業の活動イメージのデザインスタイルや要素に関していかに具体的かつ厳格であるかを知りました。)

開発: 運用と開発が通常やり取りする問題は、基本的に特定の機能の実装を確認することであり、ここでの複雑さは製品の背景データに関連しています。
よく遭遇するのは、開発者が「ここで XXX 機能を実装するつもりですか?」と尋ねることです。もしそうなら、その設計のすべてのデータ定義を教えてください。

例：

特定の運用目的を達成するために、注文の完了情報を読み取って、注文がアクティビティに参加する資格があるかどうかを操作で判断できるようにするという概念的な要件が提案されました。この要件が開発部門に届いたら、次のように翻訳する必要があります: バックグラウンド オーダー ステータスを読み取ります。ここで、A、B、C は完了したオーダー、D、E、F は未完了のオーダー、G と H は不明と定義されます。読んだ後、アクティビティの背景に「完了/未完了/不明」が表示されます。

多くの機能が要求される場合、運用や製品マネージャーは関連するデータの複雑さを認識していない可能性があります。R＆Dが実際に実装されると、この問題が発見され、運用からのさらなる実装が要求されます。

1.1.4 発売前テスト

オンラインになる前に、オペレーターはユーザーの参加プロセスと操作ロジックに従って、テスト環境で一度アクティビティを体験する必要があります。バグの検出に役立つテストはありますが、アクティビティ プロセス ロジックにバグがあるかどうか (期待と一致していないかどうか) は、操作によって検出できます。

上記は製品ラインに関連する作業上の問題です。

運用プロセスでは、要求を上げるのにそれほど時間はかかりませんが、コミュニケーションに多くの時間がかかる場合があります。製品マネージャーとのコミュニケーション時間は不可欠です。製品マネージャーが活動のニーズを理解すればするほど、運用上の期待に応える製品プロトタイプを作成できるようになります。

設計・開発とのコミュニケーションに関しては、運用側はコミュニケーションの各プロセスで設計・開発側の思考ロジックを理解し、要件提起の際にそのロジックに従うように努めることで、コミュニケーション時間を短縮することができます。

1.2 オペレーションライン

準備をしっかり行えば行うほど、ローンチ後に発生するトラブルは少なくなります（もちろん、トラブルは発生します。結局のところ、一般の人が面倒な状況を全て解決することは不可能です）。

考慮すべき事項:

• 活動に関するユーザーからの問い合わせ
• イベント終了後に配布する賞品の調達

例：

イベントに関するユーザーからの問い合わせ：今回のUGCイベントを例に挙げると、長いUGCコンテンツを書くのは少々難しく、運営側の介入や指導、励ましなどが必要となり、多くのコミュニケーションが必要になります。活動の過程で、効果的なコミュニケーションを確保するにはユーザーのWeChatを追加する必要があり、ユーザーとの本質的な会話が必要であることが確認されました。

通常、ユーザーから寄せられる質問や問題の 80% は類似しています。このタイプの問題の場合、FAQ を予測し、対応するスクリプトを整理することで、アクティビティがオンラインになった後により落ち着いて対処することができます。理解するのがより複雑な操作やコンテンツに遭遇した場合は、画像とテキストを使用して読みやすさを向上させることができます。
これまで、ユーザーに提供していたルールの説明は、WeChat 上の長い文章でした。ユーザーは明らかに長い文章の解釈が苦手で、何度も何度も質問をしていました。しかし、この複雑な文章を画像と文章に変えた後、状況は大幅に改善されました。

例：

イベント終了後に配布される賞品の購入について：賞品がユーザー側の活動（メイン活動の促進）である場合、賞品管理担当部門に賞品の残数、応募方法などの詳細を明確にする必要があります。

以前、ぬいぐるみの賞品があったのですが、在庫が20個残っていて、4つの主要部門から同時に応募があったりしました。ぬいぐるみが製造されてから到着するまで2週間かかります。購入を申し込む場合は、1つ1つ手続きをして報告する必要があります。申し込み手続き全体に少なくとも2日はかかります。

したがって、事前にこの情報をよく理解せずに、ユーザーに何らかの賞品を提供すると軽率に約束すると、実際に賞品を交換するときに困ってしまう可能性があります。

1.3 プロモーションライン

活動を開始したら、ユーザーに知ってもらい参加してもらうためにプロモーションを行う必要があります。活動の目的が異なれば必要なプロモーション リソースも異なり、プロモーション リソースが異なればトラフィックも異なり、提供する必要のある資料も異なります。

一般的に、アプリにはフラッシュ（アプリを開いたときに表示されるもの）とバナー（一部のカルーセルバナー広告）があります。アプリを開くとすぐにフラッシュの頻度が見られ、閲覧数やクリック数も非常に多いです。バナーは、ページや場所によってクリック数も異なります。イベントを行う際には、バナーとフラッシュのどちらが必要でしょうか。それとも両方でしょうか。

• 目的によって異なります (これほど大規模な露出が必要か、これほど多くのユーザーに対応できる能力と予算があるか)
• 機能を確認します (私のアクティビティは、特定の都市の特定の時間に特定の種類のユーザーに公開する必要があります。これらのリソース/チャネルでこれを実現できますか?)
• ランキングを見てください (これらのリソース スロットはランク付けされていますか?)

1.3.1 昇進可能なポジションを整理する

一般的に、プロモーション職は社内と社外に分けられます。サイト内での活動であれば、社内プロモーション職で十分な場合もあります。社外プロモーション職が関わる場合は、通常、新規顧客獲得の目的と関係があります。

• 内部的には、各種自社運営メディア（WeChat、Weibo、 Douyin 、 Alipay Life Accountなど）、商品リソースポジション（バナー、フラッシュ、フィードストリーム、プッシュなど）、EDM、SMSなどがある場合があります。
• 外部プロモーションスペース：外部リソース連携（その他オンライン・オフライン広告スペース）。

例：

この継続的な UGC アクティビティにより、継続的な反復のプロセスで多くのリソース ポジションが発掘されました。

• すでに運用されているリソースの位置:フラッシュ、バナー、段階的なページ バナー。特にバナーや段階別ページバナーについては、後期段階の担当部門と毎月固定ポジションを予約しています。
• 新しく追加されたリソースの場所:トリガー タイプ (ユーザーが注文した後のプッシュ アクティビティ、ユーザーが注文を完了した後のプッシュ アクティビティ)、固定場所タイプ (メニュー バーの特定のカテゴリ、ユーザーの注文ページに追加された新しいボタン)。

ps: 新しいリソース位置のマイニング ロジックは、ユーザーの使用プロセスとロジックに基づいて、適切な場所に露出アクティビティ ポイントを埋め込むことです。もちろん、そのための前提条件は、生産と研究のサポートがあることです。

1.3.2 活動の推進リズムに応じて関連部門とリソース要件を調整する

一部のリソース位置は長時間占有できないため、バナー、フラッシュ、ポップアップなどのアクティビティのリズムに応じてリソース位置のオンライン時間を調整する必要があります。

一部のリソースは長期間公開できるかもしれませんが、WeiboやTik Tokなどのソーシャルメディアのように、コンテンツを頻繁に変更する必要があります。また、電子メール、テキストメッセージ、プッシュ、WeChatツイートもサブタイプとして考えられますが、頻度は部門が推奨する範囲内で制御する必要があります。

1.3.3 リソース要件を決定し、設計、技術、その他の部門にリクエストを提出する

リソースの位置によって必要な素材（画像、テキストなど）が異なり、画像の場合は制作にデザイナーの支援が必要になります。一部のリソースの場所では、電子メール内のインタラクティブな効果を持つ「画像」など、フロントエンドの画像の切り取りが必要になる場合があります。

1.3.4 関連するリソースに必要なコピーを出力する

例えば、Weibo：活動サイクル（前期、中期、後期）によって、必要なコピーライティングが異なります。事前に、異なるサイクルのコピーライティング構造を検討しておくことができます。

例えばツイート：ポジションによって必要なコピーも異なります。例えば、イベントの宣伝に別のツイートを使う場合や、毎日のツイートの下にイベント紹介の小さな部分を追加する場合など、コピーは異なります。

したがって、プロモーションの場所とリズムが多くなり、豊かになるほど、運営側が出力する必要のあるコピーライティングも増えます。

追伸: プロモーションには強力なコミュニケーションと強力なアウトプットも必要です。最初のイベントでのプロモーションポジションに慣れていない場合は、フォローアップのために時間をもっと設けるようにしてください。

この時点で、イベントの事前準備は基本的に完了しています。

最後に

上記はイベント序盤にやるべきことばかりです。イベントがオンラインになってからやるべきこと、イベント第1フェーズ終了後にやるべきことなども掲載予定ですので、どうぞお楽しみに。

また、上記の説明はすべて個人的な経験に基づいていることに留意してください。会社によって、活動目的や研究開発サポートによって、経験や問題が異なりますので、上記は参考用です。また、友人同士の議論も歓迎します~~~