プロファイルの結合を再考すべき理由と方法

マーケティング担当者が顧客データ プラットフォーム (CDP) の「ゴールデン レコード」を追い求めることに夢中になると、「ID」がユース ケースを台無しにする可能性があります。 それでは、CDP で単一の顧客プロファイルを作成することが常に理想的であるとは限らない理由と、レコードをマージするための正しい手順を開発する方法を見てみましょう。

「ゴールデン レコード」を作成するとカスタマー エクスペリエンスが台無しになる場合

場合によっては、顧客のすべての情報を 1 つのプロファイルにまとめると、誤ってユース ケースに干渉することがあります。 説明しましょう。

家族旅行を計画している間、私は娘のアンを彼女の個人メールアドレスを介して予約にゲストとして追加しました。 しかし、彼女は仕事のメールで旅行会社から旅行についてのリマインダーを受け取り、緊張しました。 彼女の職場のメールにリマインダーが送信されたのはなぜですか? 誰が彼女の仕事のメールについて彼らに話しましたか?

私が知る限り、これが起こったことです。 アンは、仕事関連のイベント用に仕事用のメールを使用して旅行会社のアカウントを作成していました。 途中のどこかで、旅行会社は彼女の個人的な電子メールをそのプロファイルに追加しました. 私が彼女の個人的な電子メールをゲストリストに追加すると、旅行会社はそのアクションを彼女のプロファイルに添付したので、リマインダーを送信するときが来たとき、そのプロファイルのデフォルトの電子メール、つまり彼女の職場のアドレスが使用されました. 言い換えれば、Anne の「ゴールデン レコード」を作成しようとする熱心すぎる試みの中で、彼らはユース ケースの目的を忘れていました。

別の例を見てみましょう。 ジョーは良い顧客です。 彼はオフィス マネージャーで、会社のためにあなたの店から商品を購入しています。 しかし、彼には副業があり、個人的な使用のために同じものをたくさん購入しています。 彼は、別々の電子メール アドレスを使用して、これらのアカウントを別々に保持しています。 これらのレコードをマージしても、ジョーとの関係は改善されません。 それは彼を悩ませ、経理で彼を困らせます。

掘り下げる: 単一の顧客レコードの神話

そして、私の経験があります。 私は多くの異なる企業のコンサルタントとして働いています。 異なるメール アドレスの異なるクライアントに対して、同じサービスのアカウントが必要になることがあります。 一部のサービスでは、顧客が 2 要素認証のために同じ電話番号で複数のアカウントを持つことを許可しません。 そのため、サービス プロバイダーや私にとって役に立たない回避策を見つけなければなりません。

これらはすべて、人物に関するレコードをマージすると、カスタマー エクスペリエンスが台無しになる可能性がある例です。 一方、レコードをマージしたほうがよい場合もあります。 たとえば、食品を配達するレストランで、Sam がアレルギーを持っていることがわかっている場合、Sam のすべてのアカウント間で情報が移行されるようにする必要があります。

顧客レコードのマージ: いつ、どのように行うか

要点は明らかです。ID よりもユース ケースの方が重要です。 しかし、いつ、何をマージするかをどうやって知るのでしょうか? これらの問題を解決するために、デバイス フレームワークと人物フレームワークという2 つのフレームワークを作成しました。 両方のフレームワークで各ユース ケースを検討することで、レコードをマージするための正しい手順を開発できます。

デバイス フレームワーク

デバイス フレームワークは、ほとんどの人が顧客データの問題に対処する方法です。

デバイス プロファイル: デバイスがサイトにリクエストを送信します。 CDP はそのデバイスのプロファイルを作成し、それに関する情報を収集します。 このレベルでは、オペレーティング システム、地域、画面サイズなどでセグメント化できます。

アクティビティ: そのデバイスが複数のリクエストを行う場合、アクセスされたコンテンツの種類など、他の情報でプロファイルを充実させることができます。 このアクティビティ情報を使用して、「動画が好き」や「税務コンテンツにアクセス」などでセグメント化できます。

識別子: デバイスのアクティビティの一部は、そのデバイスの背後にいる人物を絞り込むのに役立ちます。 たとえば、電子メールの 1 つをクリックすると、デバイスがサイトにリクエストを送信する場合があります。 これは、より狭いセグメントを作成するのに役立ち、場合によっては、その人物を特定するのに役立ちます. 識別子を使用して、「電子ニュースレターに登録しているすべての人」などの強力なセグメントを作成できます。

人物: 人物と強いつながりを持つ識別子もあれば、人物の身元をほのめかすだけの識別子もあります。 識別子を収集すると、収集した識別子の性質に応じて、多かれ少なかれ確実にプロファイルを特定の人に解決できる場合があります。 個人を識別するプロファイルを取得したら、有効期限が近づいている更新オファーを提示するなどのユース ケースを開発できます。

人々

人物フレームワークは、仕事用メールの悪用に関するアンの懸念や、2 要素認証に関する私のトラブルなど、上記の問題を回避するのに役立ちます。 このフレームワークでは、データ中心の世界から抜け出し、実際の人々の生活について考える必要があります。

人: デバイス プロファイルから始めて、それを人に解決しようとするのではなく、人から始めて、その人が現実の世界でどのように振る舞うかを想像します。 ジョーの話に戻りましょう。ジョーは、仕事用と在宅ビジネス用にオフィス機器を購入する優良顧客です。

デバイス: ジョーは 2 台の電話を持っています。1 台はオフィスから、もう 1 台は個人用です。 彼は 1 つで事務作業を行い、もう 1 つで家庭/個人的な仕事をすることに注意を払っています。 Joe もオフィス PC を持っていますが、自宅では Mac を使用しています。 繰り返しになりますが、彼は 1 つを事務用に、もう 1 つを自分の事業用に使用しています。

識別子: ジョーは物事を分けておくことに慎重です。 彼の会社の電子メールは事務用であり、彼の個人的な電子メールは友人や家族のためであり、副業用に別の電子メール アドレスを持っています。 Joe は、これらがマージされたり混乱したりすることを望んでいません。

ペルソナ: ジョーを 1 人の人物として考えるのではなく、ジョーの 3 つの異なるペルソナ (オフィス ジョー、パーソナル ジョー、サイド ハッスル ジョー) を考える必要があります。

より深く掘り下げる: 顧客を悩ませたり引き付けたりする可能性のある 19 の CDP ユースケース

これらのフレームワークをユースケースに使用する

基本ができたので、1 つのユース ケースを取り上げて、両方のフレームワークで処理してみましょう。 ユース ケースは次のとおりです。

デバイス フレームワーク

デバイス ファネルの最上部は、このユース ケースではあまり役に立ちません。使用しているデバイスの種類によって機械エンジニアを特定できないからです。 アクティビティ レベルに達すると、機械エンジニアに関連するコンテンツを頻繁に使用するプロファイルを見つけることができます。

オンサイトクイズまたは簡単なアンケートを使用して、識別子を収集できます。 この場合、役職。 役職が決まったら、機械エンジニアのセグメントを作成し、「機械エンジニアの求人リストにサインアップ」メーリング リストを宣伝できます。

この使用例ではこれで十分です。 名前は電子メールをパーソナライズするのに適しているかもしれませんが、身元を個人に解決する必要はありません。 後述するように、問題を人​​にまで解決すると、問題が発生する可能性があります。

人物フレームワーク

私たちの機械エンジニアであるジュリアは、新しいギグを探している人々に親切ではない会社で働いています。 IT 部門は、オフィスの住所に届くすべての電子メールを監視します。 このため、ジュリアは仕事と私生活を切り離すように気をつけています。

彼女はラップトップを 1 台しか持っていませんが、事務作業はすべて Chrome で行い、個人的な (自宅からの) ブラウジングはすべて Firefox で行っています。 彼女は個人アカウントで求人情報メールにサインアップしますが、仕事用アカウントではサインアップしません。

熱心なデータ サイエンティストがこれら 2 つのアカウントを Julia の 1 つのプロファイルに統合し、Julia の職場の住所に求人情報メールを送信し始めた場合、Julia は満足しません。

これらのフレームワークとのプロファイルのマージを再考する

人はデータ構造が認識するよりも複雑であるため、ユース ケースを次の 2 つの観点から見ることが不可欠です。

• データ側 (デバイス フレームワーク) から。
• さまざまなペルソナを通じてオンラインで行動することが多い実在の人々の人生経験と懸念を想像することによって.

データを構造化し、ルールとユースケースをマージして、人々が自分に合ったペルソナ内で行動できるようにしてください。 どのような場合でも、1 人 1 人に対して 1 つのプロファイルを作成するのに苦労しないでください。

マーテックを手に入れよう！ 毎日。 無料。 受信トレイに。

ビジネス用メールアドレス

購読 処理...

条件を参照してください。