マーケティングキャンペーンプロセスガイド

マーケティング活動を構築する開発プロセスについて：初期のマーケティング活動は通常「カスタマイズ」されます。 1 つのアクティビティは、1 つの需要と 1 つのシナリオ用に作成されます。 徐々に、反復的なアクティビティが増え、テンプレートのアイデアを借りて、複数のアクティビティ セットを作成し、そのたびにスキンを変更するようになります。 ただし、スキンを変更するたびにゲームプレイのルーチンが制限されるため、ユーザーは簡単に疲れてしまい、効果が低下し始めます。

現時点では、アクティビティの需要は、既存のテンプレートのアイデアに基づいて既存のゲームプレイを柔軟に接続し、新しいゲームプレイを継続的に追加することになり、タスク、サインイン、抽選、投票、質問への回答、サポート、グループ形成、ランキングなど、標準的な「ゲームプレイ」を次々と沈殿させ始めました。その後は、新しいアクティビティがあるたびに、手動で開発して接続するだけで済みます。

ゲームプレイの一連のプロセス全体は、カスタマイズ開発またはR＆D構成を通じて解決できます。最終的には、R＆Dと運用構成から完全に分離できます。この記事では、マーケティング活動におけるユーザー参加プロセスまたはゲームプレイシリーズのプロセスオーケストレーションの問題について説明します。

1. 現状分析

前述のように、一般的に使用されるゲームプレイを蓄積した後、抽選、クイズ、タスク、サインインなど、さまざまな形式のゲームプレイを取得しました。使用中、通常、ゲームプレイ A のアクションは、特定のシナリオでゲームプレイ B のアクションに関連付けられます。たとえば、ユーザーはクイズに初めて参加すると抽選に当選し、タスクを完了すると現金を獲得するなどです。

カスタマイズされた関連付けに純粋な R&D 開発を使用する場合、毎回直面する関係は比較的複雑です。大きさで言えば、基本的には m*n*s (出力イベント、入力アクション、シナリオ) です。毎回沈殿があっても、ゲームプレイ間のインタラクティブな関係は基本的に過度に複雑で、維持するのが困難です。したがって、これらの相互作用を一元的に管理し、複雑さを軽減するための「バス」ツールが必要です。

2. 全体的なデザインのアイデア

これらの不安定で複雑なロジックの場合、最も直感的なアイデアは、ビジネス決定ロジックをコード決定ロジックから分離することです。アクティビティ振り付けのシナリオでは、ビジネス ロジックはゲームプレイ イベント間の関連付けと意思決定関係であり、コード関連付けはさまざまなイベントの受け入れと呼び出しです。

1. イベント駆動型設計

したがって、ゲームプレイの入力と出力を標準化し、これらのイベントの関連付けを構成する場所を用意する必要があります。関連付け間のビジネス決定ロジックについては、決定エンジンを参照するだけで済みます。抽象化全体が完了すると、アクティビティ連結のコストが m*n*s から m+n に削減され、R&D 構成関連付けステージに直接入り、コストが少なくとも 80% 削減され、後続の操作を直接手動で構成できる機能開発のエントリ ポイントが提供されます。

この時点で、これは本質的にビジネス イベント バスであることがわかったはずです。SOA イベント インタラクション バスの定義を読んだことがあるなら、その考え方は本質的に同じですが、SOA ほど強力な定義は必要ありません。 SOA アーキテクチャ設計に関連する説明があるだけでなく、マイクロサービス アーキテクチャ、イベント駆動型アーキテクチャ、DDD 設計のアイデアに精通している場合は、イベント バス設計の説明も多数あります。

ここでのビジネス イベント バスは、これらのアイデアに基づいて、アクティブなビジネス シナリオに従ってローカライズされた処理を実行し、動的な意思決定と構成の関連付け機能を追加したものにすぎません。

2. コンテキスト共有の問題

さまざまなゲームプレイを分離し、ビジネス イベント バスを通じて関連付けると、各ゲームプレイは基本的に情報アイランドを形成します。この情報アイランドは、それ自体内の変更のみを考慮しますが、これは実際にはアクティビティ ロジックには役立ちません。高い閾値のタスクによって追加された抽選会の賞品コレクションは、多くの場合、より高い価値があります。異なるグループ (異なるアイデンティティを持つチーム メンバー) は、異なる報酬値に直面します。多くの場合、ユーザーの参加に関するコンテキスト情報に頼る必要があります。情報アイランドを打破したい場合、通常、それに対処する方法は 2 つあります。

1) コンテキストを必要とするゲームプレイに対する報酬を、すべてのゲームプレイのコンテキストを認識する基本機能にします。報酬は、コンテキストを持つ各ゲームプレイによって直接呼び出されるマイクロカーネルとして存在します。

2) これらのコンテキスト認識アプリケーションをさらに抽象化し、ビジネス ルールをさらに分離します。コンテキスト情報を認識するのはビジネス ルール (ルール エンジン) のみです。他のゲームプレイのコンテキストは、ゲームプレイの通常のキー値にすぎず、ビジネス ルールを保持する式でのみ使用されます。

全体として、どちらのアイデアも本質的に受け入れられ、システム開発のさまざまな段階に適用できます。アクティビティが比較的多い場合は、最初のアイデアで十分ですが、アクティビティがより複雑な場合は、2 番目のアイデアが比較的適しています。

全体的な比較:

• 最初のタイプ: 実装は比較的単純で、ゲームプレイに対する要件は比較的低いです。ただし、操作が複数のゲームプレイコンテキストに同時に関係する場合、処理が比較的困難です。そして、コンテキストを必要とする操作の数が増え、関連性が増すと、アーキテクチャは徐々に手動での強力な関連付けへと退化します。
• 2 番目のタイプ: 実装は比較的複雑で、ゲームプレイの構成可能性に対する要件が高くなりますが、スケーラビリティが優れており、複雑なアクティビティを処理しやすくなります。

3. コンテキストデザイン

コンテキストの設計は比較的単純です。大まかに言えば、get ルートの配布として理解できます。ビジネス特性を持つデータ ソースとして理解できます。キーに基づいて、必要なユーザー参加のコンテキスト情報を見つけることができます。

具体的な実装スキームとしては、アクティビティ コンテキストを保存するための集中型ストレージ、またはゲームプレイを通じてメソッド アクティビティ コンテキストを挿入するためのプロキシとして機能する論理的な集中型ストレージなどがあります。

コンテキスト + 動的意思決定オーケストレーション = アクティビティオーケストレーションエンジン

3. パフォーマンス保証

ビジネス イベント バスは、1 つまたは複数のビジネスのイベント フローを処理する必要があるため、比較的高いパフォーマンス要件を持つ「システム ノード」です。その優れたパフォーマンスを可能な限り確保する必要があります。以下は、イベント バスの全体的な最適化プロセスです (古いルーチンに従って、最初にポイントを最適化し、次に分散シナリオで「量」を最適化します)。まず結果を見てみましょう。

1. IOの削減と高速化

イベント バスを使用する場合は、ネットワーク IO を可能な限り回避する必要があります。まず、イベント バスの呼び出しをローカライズする必要があります。次に、外部イベントのイベント バスの呼び出しを可能な限りローカライズし、論理モジュールとしてのみ機能させる必要があります。

現在のアーキテクチャでは、スケーラビリティや可用性などの要因により、アクティビティ全体をまとめてパッケージ化して展開することが許可またはサポートされていない場合、IO は避けられません。つまり、可能な限り epoll を使用してください。ビジネス開発として、これらのことはインフラストラクチャに任せて処理できます。

2. より高速なストレージ

ハードコード > メモリ > ローカル ディスク > ネットワーク IO。通常のイベント間の関係はメモリに直接保存され (DB はプロセスにプリロードできます)、強く関連付けられたイベント構成は直接ハードコードされ (ハードコードされた構成の問題ではいくつかの式を使用できます)、ネットワーク IO とディスク IO を回避します。

3. 配分量の適正化

非同期イベント処理やマイクロバッチ処理などのスループットの最適化には、kafka などの MQ の最適化のアイデアを採用するだけで、誰でもその方法がわかると思います。このようなシナリオでは、車輪の再発明をする必要はありません。非同期を実現するには、kafka を使用するだけで十分です。

一貫性と可用性のバランスを取ります。前述のように、可能な限り高速なストレージを使用します。分散シナリオでは、複数のノード間の不整合を許容できる場合は、このアプローチを使用できます。一貫性の要件が比較的高い場合は、単一ポイントの Redis を使用して関連付け関係を保存できます。信頼性の要件が非常に高い場合は、一歩下がって MySQL を使用できます。

一般的に言えば、イベント バスには大きなビジネス ホットスポットはなく、水平方向の拡張によって基本的にすべてのボリュームの問題を解決できます。重要なのは、ビジネス内の単一ポイントに注意を払い、リソースの分離を適切に行うことです。

4. データの一貫性の保証

イベント バスは強力なビジネス エンティティではなく、完全に架空の概念です。イベント バスを使用するプロセスが保証されることだけを確認する必要があります。

分散トランザクションのシナリオの場合、これは分散トランザクションの実装に依存します。TCC クラスの場合は、イベントが正常にトランザクションに参加できることを保証するだけで十分です。トランザクション メッセージに依存する分散トランザクションの場合、イベント バスの「イベント呼び出しメンテナンス」を置き換えて、トランザクション メッセージ キューにカプセル化できます。

分散トランザクションのない処理シナリオでは、べき等再試行を最大限に活用し、イベント処理を適切に実行します。ちなみに、「イベント バス」周辺のべき等再試行は、優れた処理アイデアです。

4. 既存のホイール

検索エンジンを開いて、ビジネスイベントバスを検索してください。Alibaba CloudとTencent Cloudには同様のソリューションがありますが、対象とするビジネスシナリオは比較的少ないです。これは複雑ではなく、基本的に1人で2週間で開発してリリースできます。最も重要なのは、対応するアイデアのローカライズです。実際の仕事で同様のシナリオに遭遇した場合は、コストを総合的に評価して実装してください。