電子商取引データ運用（CRMシステムのデータ運用）

CRMシステムのデータ操作

CRM システムのデータ操作をうまく行うにはどうすればよいでしょうか?その核となるのはリードデータの運用と管理です。著者の分析を見てみましょう。

CRM運用の核となるのはリードデータの運用・管理です。

CRM リードは、そのソースに基づいて、一般的にオフライン データ リードとリアルタイム データ リードの 2 種類に分けられます。

オフライン データの手がかりは、主に企業が蓄積したデータ ウェアハウス データから得られます。履歴に基づいて要約された顧客タグと顧客グループ化、およびルールスクリーニングを経て、顧客のオフラインデータの手がかりを生成できます。

リアルタイム データの手がかりは、主にユーザーのリアルタイムの行動から得られます。統合された追跡ポイント プラットフォームを通じて、企業内のさまざまなサブシステムからのクライアント側追跡ポイント情報とサーバー側追跡ポイント情報が収集され、ルールに従って処理されて、リアルタイムのデータ手がかりが生成されます。

リードの生成はデータに依存します。大企業には通常、社内に多くのシステムがあり、企業のビジネス目標はシステムの調整を通じて達成されます。これにより企業の効率は向上しますが、顧客データが企業のさまざまなシステムに分散されることになります。 CRM システムがこのデータを取得するには、普遍的なデータ アクセス ルールが必要です。

一般的に使用されるデータ収集方法には、ポイントオブケア データ アクセスとデータベース データ アクセスがあります。ユーザー側またはサーバー側で生成されたリアルタイムの動作は、仕様に従って追跡プラットフォームに報告され、CRM はこれらの動作イベント データを消費します。同時に、企業の各モジュールのシステムデータもデータウェアハウスのHive、MySQL、Oracleに同期できるため、企業内のデータ障壁を打破できます。

CRM はこのデータ情報に基づいて、このデータを顧客リードに処理できます。

ユーザーのデータ ウェアハウス内のデータであれ、リアルタイムの埋め込みデータであれ、各データには大量のメタデータ情報が含まれています。

メタデータの主なタイプは、動作イベント、イベント属性、ユーザー属性、アイテム属性です。

動作イベントには、多くの場合、ユーザー動作イベントとシステム動作イベントが含まれます。ユーザー行動イベントは通常、クライアント側の埋め込みデータから取得されます。たとえば、クリックして閲覧する、カートに追加する、注文を生成する、支払いを行う、払い戻しを開始するなどです。システム行動イベントは通常、サーバーによって収集されたデータを取得します。たとえば、支払い失敗、引受失敗、リスク管理のキャンセルと返金、自動割り当てなどです。これらは、ユーザーが開始する動作イベントではありません。

各動作イベントは単独で存在するわけではなく、動作に関連する多くの派生情報（動作の開始者の「ユーザー属性」、動作自体の「イベント属性」、動作の対象オブジェクトの「アイテム属性」）が必然的に伴います。

ユーザー属性には、年齢、性別、地域、収入、職業などの情報が含まれます。

イベント属性には、アクセス デバイス、期間、IP、イベント シーン、ソース チャネルなどが含まれます。

アイテム属性: 商品、注文、またはその他のシステム オブジェクトであるアイテムの定義。アイテム属性には、製品モデル、カテゴリ、価格、在庫などが含まれます。

メタデータ情報は客観的な事実を述べるものであり、ユーザーの好みについて判断するものではありません。行動イベント、ユーザー属性、アイテム属性、イベント属性を組み合わせることで、単一の独立した行動イベント A を組み立てることができます。

前述したように、メタデータ情報は客観的な事実のみを述べています。しかし、これらの客観的なメタデータをもとに、ユーザーの閲覧嗜好、購買嗜好、ユーザー価値観などをルールやアルゴリズムに基づいて判断し、ユーザータグやユーザーグループに加工することで、企業のデータ資産として蓄積されていきます。

たとえば、30 歳のユーザー A は、過去 30 日間に 2,000 元を超えるホテルの予約を 30 件行っています。したがって、この情報に基づいて、この顧客を「高純資産者」、「ホテル宿泊を好む」、「若い男性」に分類できます。

多くの製品マネージャーは、ユーザー グループ化とユーザー タグの違いを区別できません。実際のアプリケーション シナリオでは、この 2 つの使用に大きな違いはないと思われるためです。しかし、確かに両者の間には本質的な違いがあります。

ユーザー タグは、ユーザー メタデータに基づいて要約されたユーザー機能データです。同じビジネス シナリオでも、ユーザー タグを繰り返すことができます。たとえば、ユーザーがリンゴ、ナシ、パイナップルが好きな場合、果物の好みのシナリオでは、これら 3 つの好みのラベルを同時に持つことができます。

ユーザーのセグメンテーションが異なります。ユーザー セグメンテーションでは、1 つの次元に基づいて対象ユーザーをさまざまなグループに分割します。彼には「相互独立と完全な消耗」という非常に重要な原則があります。ユーザーを性別でグループ化します。ユーザーは女性または男性のいずれかです。人間は女性と男性の両方になることはできないので、同じ次元では、人間は同時に 2 つのグループに存在することはできません。

リアルタイムのユーザー追跡データとデータ ウェアハウス データを収集すると、比較的豊富なユーザー データが得られます。しかし、知ることは言うほど簡単ではありません。保有する顧客データを顧客リードに変換する方法は、リード管理において最も重要なステップです。

純粋なオフライン データのスクリーニングは比較的簡単です。スケジュールされたタスクを設定することで、データ ウェアハウスからデータのバッチを収集し、顧客グループやタグなどのディメンションに基づいてデータを取得して CRM に同期することができます。

リアルタイムの顧客リード データは、ユーザーのリアルタイムの行動を考慮するだけでなく、データ ウェアハウス データと組み合わせてスクリーニングされることもよくあります。例えば、前述のユーザー行動イベントAでは、ユーザーは「購買力が強い」と「消費意欲が強い」というユーザータグを持っているため、「商品の閲覧」をトリガーイベントとして、「冷蔵庫カテゴリの商品」、「単価5,000元以上」、「閲覧時間60秒以上」、「購買力が強い」と「消費意欲が強い」を補助的な判断条件として使用し、「冷蔵庫カテゴリの商品を詳細に閲覧する高価値ユーザー」などのタイプの顧客手がかりをまとめることができます。

ただし、単一のユーザー行動イベントからの手がかりを要約することには、いくつかの欠点があります。たとえば、イベント A の発生後にユーザーが冷蔵庫製品を自然に購入する場合、このリード情報を CRM システムにフィルタリングし続け、営業担当者にフォローアップさせると、営業マンの労力が無駄になるだけでなく、ユーザーに不要な迷惑をかけることにもなります。

そのため、実際の運用シナリオでは、独立した行動イベントAをトリガー開始条件として使用するだけでなく、ユーザーの行動シーケンス（複数の行動の順序）を考慮して、スクリーニングの判断を精緻化することが多々あります。たとえば、ユーザーがイベント A を完了した後、30 分以内にイベント B を完了できなかったとします。または、ユーザーがイベント A を完了した後、イベント C、D、E を順番に実行します。

選別された顧客リードは、顧客リードの種類に応じてさまざまな CRM チャネルにプッシュされ、リーチされます。顧客に連絡する一般的な方法には、手動発信コール、インテリジェント発信コール、APP プッシュ、テキスト メッセージ、WeChat パブリック アカウント、エンタープライズ WeChat プッシュなどがあります。もちろん、企業はプッシュ チャネルをカスタマイズすることもできます。データのヒントをプッシュする方法を標準化するために、通常、Webhook がユニバーサル ドッキング メソッドとして使用されます。

現在、多くの大企業が大量の顧客データを蓄積しており、これらの顧客データには価値マイニングの余地が大きく残されています。データウェアハウスをスクリーニングすることで、顧客への軽量なリーチが可能になります。ユーザーがリアルタイムでフィードバックやインタラクションを生成すると、さらに詳細な二次リーチを実施できます。これにより、自社のデータ資産を有効活用し、企業に価値を生み出すことができます。

この記事はもともと、Everyone is a Product Manager で @爱吐槽的教授XU によって公開されました。無断転載は禁止です。

タイトル画像は、CC0 プロトコルに基づいて unsplash から取得したものです。

この記事で述べられている意見は著者自身の意見のみを表しており、人人士品夢家プラットフォームは情報保存スペースサービスのみを提供します。