レビュー: マーケティングキャンペーンの浮き沈み

マーケティングキャンペーンは、計画から実行まで、多くのステップを踏むことが多く、一定量の人的資源と物的リソースを必要とします。この記事の著者は、自身が経験したマーケティングキャンペーンを振り返り、キャンペーンのプロセスと、その過程で遭遇した落とし穴について共有します。著者は、これが皆さんの今後のマーケティング活動における回り道を避けるのに役立つことを願っています。

PV20w、最大同時実行数2w、アクティビティフロー420万、ファンインタラクション100万超。これらはマーケティングキャンペーンによって残されたデータです。皆さんにとっては当たり前のことかもしれませんが、私にとっては若い女性がブライダルセダンに乗るのは初めてのことです。具体的なプロセスについては詳しく説明しませんが、警告として私が遭遇したいくつかの落とし穴を皆さんに共有したいと思います。

1. プロジェクトの立ち上げ時間が短すぎる

この活動は会社の上司から直接提案されたもので、与えられた時間は1か月でした。複数の既存製品の機能変換、多数の製品ルールの検証、新しいB/Cエンドの要求などが含まれていました。最初のステップで、製品担当の私は残業することになったのです。

当時の視点からすると、本当にアイデアが尽きていました。ドキュメントには考えられるすべての側面を書き留めていました。しかし、開発に入り、オンラインになった後、最初に見逃していた問題が次々と発見されました。そんなことをすべきではありませんでした。結局、テスターは製品について多くの質問をし、私にいくつかの問題を提起しました。

新しい機能を計画するときは、ドキュメント内の各新しいフィールドのソース、ステータス、およびさまざまな状態間の切り替えルールを慎重に記述する必要があります (非常に重要なステップなので、慎重に検討する必要があります)。
機能レベルのインタラクションについては、すべてのボタンとユーザーの操作による効果を含め、開発者に完全性を確認する必要があります。（忙しかったため、ドキュメントを放り投げて気にしませんでした。その結果、開発者はインタラクションの理解に曖昧さを持ち、多くの時間を無駄にしました。完全なインタラクティブプロトタイプを作成するのに十分な時間がなくても、インタラクションの詳細について開発者とコミュニケーションを取る必要があります。）

要約すると、マーケティングキャンペーンの要件ドキュメントを作成する場合、複数の製品ラインと複数のシステム間の接続を含めた広範かつ包括的な内容にする必要があり、詳細な粒度ではすべてのフィールド、ボタン、インタラクションを考慮する必要があります。

2. 多くのビジネスの変化

時間の切迫感は、非常に面白い現象を引き起こしました。私は要件を完璧にし、コードを開発していましたが、ビジネスはビジネスルールを更新していました。その結果、要件ドキュメントは 2 日ごとにわずかに、3 日ごとに大幅に変更されました。開発者から最もよく聞かれた質問は、「また変更されたの?」でした。私はまさに石を触りながら川を渡っていたのです。とてもパンクでした!

もちろん、これは良いことではなく、誰もが真似することはお勧めできません。ビジネスルールの繰り返しのジャンプに加えて、製品設計レベルでは、他の人の見解や意見を提示することに依然として非常に「フレンドリー」です (1 日でインターフェイスのバージョンを 2 つ変更するようなタイプ)。

したがって、この穴は十分に大きいため、いくつかの解決策が提案されています。

事業部/マーケティング部が活動計画書を発行する場合、技術的な成果物として、問題点を特定するために逐語的に読む必要があります。曖昧な日付と数量については、明確な数値測定が必要です。日付は日から秒まで正確である必要があり、数量は最大値と最小値まで正確である必要があります。
ビジネスルールが不明確な状態で開発が必要な場合は、まずビジネス側で全体のルールを決め、大きなルールから細かいルールまで段階的に標準化していきます。ルールが決まったら、大きな枠組みから細かい部分まで開発を進めていきます。
「注意深く聞くが、実行はしない。その背後にあるニーズを深く掘り下げる。」これは以前に聞いたことがあるかもしれませんが、実行するのは難しいことです。これには強い権限と製品に対する十分な責任が必要です。私はまだこれを達成していないのではないかと自分自身に問いかけます。

3. オンライン化後に明らかになる問題

約 2 か月の懸命な努力を経て、ついに製品の発売準備が整いました。予想外に、私たちは発売後に非常に不安になり、疲れ果てました。イベントは「大成功」し、さまざまなデータから、イベントの人気が予想をはるかに上回ったことが示されました。しかし、私たちは予想をはるかに上回る規模のイベントに備えていませんでした。

1. オンライン化後の最初の深刻な問題は、販促品の過剰販売でした

以前の注文トランザクション設計について簡単に説明します。ユーザーが支払いをクリックすると、システムは注文を生成し、製品の割り当てを占有します。ユーザーが 10 分以内に支払いを行わない場合、注文取引は終了し、割り当てが解放されます。皆さんはここで問題がおわかりでしょうか。

同時実行数が膨大だったため、問題が発生しました。データベースが注文を処理するのにかかる時間が 10 分を超えました。つまり、(ユーザーは注文を支払いましたが、ユーザーの支払いコールバック処理がシステム内で 10 分以上キューに入れられた) ユーザーが支払いました。

しかし、支払いメッセージを受け取らなかったため（メッセージがキューに入れられたため）、商品を再度販売しました。このサイクルにより、深刻な過剰販売が発生しました。商品を 2,000 セットではなく 5,000 セット販売しました（商品は基本的に赤字で販売されました）。

これは重大な生産事故と言えるでしょう。上司に報告したところ、大きな問題ではなく、対処できるとのことでした。そこで、広報部は後日、Weiboに「皆さんの強い購入意欲により、事業部は販売量を数倍に増やしました」と投稿しました。これは素晴らしい対処方法でした。

2. 2つ目の問題は、新規ユーザー数の増加により、アカウントシステムに問題が生じていることである。

弊社独自のアカウントシステムでは、携帯電話番号/メールアドレス+実名ユーザーID情報が1つのユーザーデータに相当します。ユーザーが新しい携帯電話番号を使用すると、システムは彼を新しいユーザーとして登録します。

さらに、本人確認情報が旧アカウントに紐付けられているため実名の確認ができず、旧アカウントの携帯電話番号も使えないという袋小路に陥り、メールアドレスで登録していたユーザーが携帯電話番号を使ったら新規ユーザーと判定されるなどの問題が相次いでいる。

核心は、元のアカウントシステムの設計には多くの問題があったが、古いユーザーに直面したときには大きな問題はなかったということです。しかし、大量の新規ユーザーに直面したとき、元の設計上の欠陥が露呈しました。

要約: 取引システムを設計するときは、完璧さを考慮する必要があります。片手で支払い、もう一方の手でお金を集めるという一般的なロジックに加えて、高同時実行下でのシステムデータ量の過剰、コールバック要求の過剰、処理速度の低下、その他の異常な取引ロジックによって引き起こされる一連の問題も考慮する必要があります。

解決：

取引システムの設計では、注文の支払い結果はシステム時間ではなく支払いコールバックに基づく必要があります。つまり、注文を出した後、トランザクションが成功/無効であるかどうかを判断し、トランザクションの結果はトランザクションコールバックに基づいて決定する必要があります。高い同時実行性におけるトランザクションシステムの詳細については説明しません。ここでは 1 つの方法だけを紹介します。
フロントエンドは、システムの稼働状況に応じて制限を行います。サーバーが満杯になった場合やデータベースキューが一定数を超えた場合、フロントエンドからの新規アクセス数を制限します。
アカウントシステムの設計において、アカウントシステムの中核は依然として人をベースにする必要があります。しかし、1人が複数のアカウントを持つ状況は間違いなく発生します。これは、一般的な電子商取引企業にとっては良いことかもしれませんが、ユーザーデータに厳しい要件を持つ企業にとってはそうではないかもしれません。今後、メンバーアカウントシステムの構築と例外の取り扱いについて、私の見解を共有する機会があります。

まとめると、製品として存在する問題は次のとおりです。