Marketing Cloud Engagement における連絡先数のカウント概念とその内訳について

1.連絡先数のカウントについて

以下 1~3 に存在する連絡先数の合計から 連絡先キー (Contact Key) で重複を排除した値が課金対象の連絡先数としてカウントされます。

　1) すべての連絡先数 
　2) 各母集団に含まれる連絡先数
　3) トリガーによる送信の非表示管理リスト上の連絡先　

現状 2) 母集団は多くの環境でご利用は無く、3)は連絡先数全体からみて数が極端に少ない場合が多く、ほとんどの環境では、1)のすべての連絡先の数が主な課金対象の連絡先の構成要素となります。画面上では [Contact Builder] の [すべての連絡先] タブで表示される左上の [すべての連絡先] をクリックした後に表示されるカッコ内の数値が課金対象の連絡先とほぼ合致します。 

2. 連絡先の内訳の詳細について

1) すべての連絡先 
すべての連絡先はアカウント (EID) 単位で管理されており、これは大別すると以下に分類されます。

　1-1) 何等かのチャネル (Email, SMS, プッシュ通知) を購読している購読者
　1-2) チャネルのない連絡先

*「連絡先」、「購読者」 という類似した表現があります。通常は Email Studio のチャネルを購読しているもののみ 「購読者」 と呼び、Mobile Studio のチャネルを購読しているものは 「連絡先」 と呼ぶケースが多いですが、ここでは「購読者」 とします。


1-1) 何等かのチャネル (Email, SMS, プッシュ通知) を購読している購読者
メッセージの送信や、すべての購読者へのインポートなどを経由して、Email, SMS, プッシュ通知など何らかのチャネル購読者として登録済みのものを指します。 購読者は、メールのチャネルであればメールアドレス、プッシュ通知のチャネルであればデバイス ID・システムトークンなど、メッセージ配信のためのアドレス情報を必ず持ちます。

*注意*
購読者は管理の単位が以下のようにそれぞれ異なります。この点はお問い合わせでも頻繁に確認されますので、注意してください。

・すべての購読者 (メール) ：アカウント (EID) 単位
・モバイルの購読者 ：ビジネス ユニット (BU) 単位


1-2) チャネルのない連絡先
すべての連絡先に存在しても、どのチャネルの購読者にも存在しないものを指します。
想定以上に連絡先が多い場合、この種別の連絡先が増えていることがよくあります。
各アカウントが持つ余剰の連絡先を削除する場合、まずはこの連絡先を削除を検討します。なお、この連絡先が生成される契機は様々あり、詳細は後記の “補足” の項を参照してください。

2) 母集団に含まれる連絡先 
各ビジネス ユニットにおいて、母集団 (Population) に紐付けられているデータエクステンション上にあるレコードも連絡先としてカウントされます。母集団から流入した連絡先は、当初は [すべての連絡先] や [すべての購読者] に存在せず母集団データエクステンションにのみ存在します。その後、メールが送信されると [すべての購読者] にも登録されます。なお母集団そのものについての説明については、こちらのトレイル  を参照してください。

参考 : 母集団の確認方法
 Contact Builder - データデザイナーから、属性グループの横の「母集団」(Population) に切り替え、属性グループがあればクリックし母集団データエクステンションを確認できます。母集団を利用していない環境では、母集団の属性グループが何もない状態 (+アイコンのみ) になっています。
なお、本機能を利用している環境は多くは無いため、考慮外としていただいてよい場合がほとんどとなります。

3) トリガーによる送信の非表示管理リスト上の連絡先
トリガーによるメールを作成する際、 [すべての購読者] には登録しないように構成するか、あるいは、Journey Builder でのジャーニーのテスト時に、"送信種別" オプションでテストメッセージを送信するように構成すると、この種類の連絡先が作成されます。
この種類の連絡先は、データビュー _Subscribers 上では、連絡先タイプ (SubscriberType) が "Unknown External System" として存在します。

なおこの種類の連絡先が存在すると、連絡先の管理が非常に煩雑になります。
そのため、どうしてもすべての購読者に登録してはならない要件がある場合を除いては、トリガーによる送信では、 [すべての購読者] に登録するように構成することが推奨されます。
具体的にはこちらの記事の "購読者管理" において、[すべての購読者] を必ず含めるようにします。その上で必要に応じてデータエクステンションを指定します。

参考 : 確認方法
連絡先数のレポートの "Contacts from Triggered Sends" の項目が該当します
 

*よくある質問*
データエクステンションにデータをインポートした時点では連絡先や購読者とはならず、[すべての連絡先]、[すべての購読者]に登録されません。メッセージ送信などの契機を通して、連絡先や購読者として登録されます。

3. 連絡先のカウント例

上記の概念をもとに例を用いて連絡先をカウントします。
以下のような連絡先・購読者のレコードが存在する構成を想定します。

===================
小文字のアルファベットは連絡先キーとします。

[ビジネス ユニット A]
すべての連絡先 : a, b, c, d, e, g, h
母集団DE-A  :  a, f

各チャネルの購読者
Email Studio : a, b, c
MobilePush :  c, d
GroupConnect : a, e

[ビジネス ユニット B]
すべての連絡先 : a, b, c, d, e, g, h (EID単位で管理のため親BU-A と同じになる) 
母集団DE-B  : i

各チャネルの購読者
Email Studio :  a, b, c  (EID単位で管理のため親BU-A と同じになる)
MobilePush :   g
GroupConnect : - 
===================

本例の構成では以下のようにカウントします。

　1) すべての連絡先 = a, b, c, d, e, g, h = 7
　1-1) 特定のチャネルを購読している購読者 = a, b, c, d, e, g = 6
　1-2) どのチャネルにも紐付かない連絡先 = f, h, i  = 3*  
　2) 母集団に含まれる連絡先 = a, f, i  = 3

そして、課金対象については下記のとおりカウントします。

　[1) すべての連絡先] + [2) 母集団に含まれる連絡先] + [3) トリガーによる送信の非表示管理リスト上の連絡先] の合計から Contact Key で重複を排除
　= [a, b, c, d, e, f, g, h, i]　の 9 つ

*注意*
上記例のように、各種の連絡先・購読者数を足し引きしても課金対象の連絡先数などとはマッチしないケースがあることに注意してください。実運用環境では多くのケースでマッチしません。
そのためお問い合わせでもこれを試みて混乱を招くケースが頻繁に見られますため、UI 上の各種連絡先数の数値などを足し引きして整合性を取ると混乱を招くため控えることをおすすめします。

4. 補足:チャネルのない連絡先が生成された契機の詳細

チャネルのない連絡先が生成される代表的な契機について補足します。なおMarketing Cloudの機能では、各連絡先がどの契機で生成されたかを確認することはできません。チャネルのない連絡先が生成された契機の特徴を把握することで、どの契機で生成されたかを推測します。

・ジャーニーへのエントリー  

ジャーニーへのエントリー時、[すべての連絡先] に Contact Key が存在しない場合には、まず [すべての連絡先] に登録されます。そのため、連絡先が必要以上に増えている場合には、エントリーデータエクステンションのレコードを精査するなどして、エントリー数を絞ることを検討ください。ただし、フィルターを設けてエントリーから除外した場合でも、フィルターの評価段階ですべて連絡先として追加される点にご留意ください。

また、不要な連絡先の精査時に、連絡先キーの体系が会員 ID などに類似するものが多数抽出される場合、不要な連絡先をジャーニーに多数エントリーさせている可能性があります。もしこの状況に合致することが疑われる場合、Journey Builder の [履歴] タブを利用し、チャネルのない連絡先の連絡先キーがエントリーのみされ、メールなどの配信アクティビティを通過していないことを確認してください。

※すべての購読者 (_Subscribers データビュー等) への追加はエントリーだけではされません。エントリー後に Email Activity を通過し、一連の配信処理にて行われます。このようにしてジャーニーへエントリーしたのちに配信を伴わなかった連絡先が "チャネルのない連絡先" として生成します。

・同期済みデータエクステンションからのレコードの同期
Marketing Cloud Connect を構成しており、[同期済みデータエクステンション] で連絡先に関するオブジェクト (Lead / Contact 等) のレコードを同期すると、自動で [すべての連絡先] に登録されます。このとき、対象の Contact Key がすべての連絡先に存在しなければ、チャネルのない連絡先として登録されます。これらの連絡先は、Contact Key の先頭が 00X (X=3, 5 等) から始まる 18 桁の文字列 (Salesforce ID) となり、識別が容易です。
この種別の連絡先が多数チャネルアドレスを持たない状態で存在する場合は、同期条件を付けることも検討します。

※注意※
こちらのドキュメントに記載の通り、連絡先削除プロセスが完了する前にこの契機で連絡先が生成された場合、GUID形式の連絡先キーとして生成されます。GUID 形式の連絡先キーは、後述の通り主に MobilePush, GroupConnect の利用において生成されるものですが、これら機能を利用していないにもかかわらず GUID 形式の連絡先キーが生成されている場合は、この契機による同期済みデータエクステンション経由での連絡先の可能性があります。
なお、同期済みデータエクステンションは最短 15 分間隔で同期されます。そのため、この流入契機で生成された連絡先を削除しても、同期設定を見直さない限り連絡先として復活しますので、同期設定を先に見直してから削除を行います。

・GroupConnect への連絡先追加（インポート）機能で既存の Contact Key に紐づけ
GroupConnect では、Marketing Cloudと連携を行った公式アカウントに友だち追加を行うと、GUID 形式の Contact Key として生成されます。その後、GroupConnectへの連絡先の追加 で既存の Contact Key に紐づけを行うと、デフォルトで生成された GUID 形式の Contact がチャネルのない連絡先として残存します。(Email 等の他のチャネルは購読していない場合）
よって GroupConnect のインポート機能を多用している場合には定期的に不要となった連絡先の削除を検討します。

・MobilePush SDK の組み込まれたアプリから異なる Contact Key が登録
MobilePush SDK の組み込まれたアプリでは、初回起動時にデフォルトで GUID 形式 (ハイフンを含む 36 桁の16進数) の Contact Key でアノニマスな購読者として MobilePush の購読者が登録されます。
その後、ログイン時などに setContactKey/setProfileId のメソッドを通して異なる Contact Key が登録されると、デフォルトで生成された Contact Key は チャネルのない連絡先として残存します。(Email 等の他のチャネルは購読していない場合）

例：
・初回起動 
ContactKey : A が生成され、MobilePushのチャネルに  ContactKey : A、DeviceID : 1　が登録

・アプリから setContactKey ("B") を実行
ContactKey : B が生成され、MobilePushのチャネルに  ContactKey : B、DeviceID : 1　が登録
もともと DeviceID: 1 に紐づいていた ContactKey : A がチャネルのない連絡先として残存

*注意点
・setContactKey/setProfileId は指定した連絡先キーがすでに存在した場合は当該の連絡先に紐づき、存在しなければ新規の連絡先として生成されます。
・アプリ起動時に GUID 形式のアノニマスな購読者を登録させたくない場合は、Delay Registration という機能を利用します。
上記注意点に関する詳細はこちらの MobilePush に関する記事 を参照してください。


ここで紹介したもの以外にも、さまざまなタイミングでチャネルのない連絡先が生成されます。こちらの記事 の、”チャネルのない連絡先はどのようなときに表示されますか?” の項目にも、代表的な契機について記載がありますので、併せて参照してください。

5. FAQ 

Q)意図せず連絡先数が急増しました、どの連絡先がどの経緯で増えたのか確認したい。

連絡先の流入経路は明確にソース等が記載されないため、まずは "連絡先数" レポートで連絡先の内訳を確認し、いずれかのチャネルで急増していないか確認します。(下記 "参考" を参照)
また多くの場合では、上述の "チャネルのない連絡先" が生成されたことに伴うケースとなります。そのため、必要に応じて データ抽出アクティビティの  [チャネルアドレスを持たない連絡先]  を親BUで実施し※、不要な連絡先の削除を検討します。
※必ず親BUで実施してください

削除後、またすぐに [チャネルアドレスを持たない連絡先] が増えてしまうケースもあり、例えばJourney Builderに大規模なデータエクステンションを定期的にエントリーさせている、MobilePush アプリ上で同一デバイスにて異なる連絡先キーで繰り返し setProfileId を行っている (会員IDの切り替えが頻繁に行われる） 場合などが考えられます。この場合は定期的な [チャネルアドレスを持たない連絡先] の削除を行うか、Journey Builderへのエントリーやアプリの実装(setProfileId のタイミング) を見直します。

参考) 利用中の Marketing Cloud アカウントに存在する連絡先数および内訳の確認

Q)連絡先数レポートやUIの各種数値を用いて課金対象の連絡先数の整合性を取りたい・取れない場合 
UIやレポートで確認できる数値を足し引きしても、残念ながら課金対象の連絡先数の整合性をとることができません。
もしこれを実施する場合、モバイルリスト (フィルター済みリスト) を用いて、全 BU で全チャネルの連絡先キー一覧をエクスポートしたうえで、それぞれの重複を除外するなどの非常に煩雑な作業が必要となります。不要な連絡先を削除する目的であれば、まずはチャネルのない連絡先を定期的に削除することを検討します。

Q)チャネルのない連絡先がどの経路で発生したか原因を特定したい
上述のとおり、どの経路から発生した連絡先かは記録されません。
そのため、上記の ”チャネルのない連絡先が生成された契機の詳細" を参考に、どの契機に該当しうるか検討します。

*本記事に関する注意点
連絡先の構成は各環境で大きく異なるため、これらが必ずしもすべての環境に適用できない点、また、挙動は予告なく変更される場合がある点につきまして、あらかじめ了承をお願いします。