この記事では、セグメントが予期したメンバー数を返さない問題の解決策を提供します。 セグメントでは、予想よりも高い数値または低い数値が表示される場合があります。 この記事は、不一致があるかどうかを判断するのに役立ち、エラーの根本原因を特定する手順を示します。
メンバー数が正しくないという症状
セグメントが実行されて更新されますが、予想されるカウントとの差異が示されます。 このセグメントでは、予想よりも高いコンタクト ID の数または低い数が表示される場合があります。
間違ったメンバー数の例と解決策
この記事の次のセクションでは、発生する可能性のあるメンバー数の不一致について詳しく説明し、問題を解決するためのトラブルシューティングのヒントを提供します。
セグメントにメンバーが表示されないか、予想よりも少ないメンバーが表示されます
セグメントのメンバーが予想よりも少ない理由を判断するには、次のトラブルシューティング手順を試してください。
ステップ 1: 矛盾する条件またはルールの基本ロジックを検証する
同じ属性に対して矛盾する "AND" 条件またはルールを使用すると、常に空のセグメントが生成されます。 例: FirstName = Joe AND FirstName = Frank。
集合演算 (ユニオン、インターセクト、例外は、2 つのルールを結合するために使用されます) は、各ルールによって返された ContactId に適用されます。 したがって、予想される結果に応じて、予想される ContactId が各ルール評価の結果の一部であるかどうか (または一部ではないか) を確認します。
ステップ 2: 複雑さを解消する
複数の条件またはルールを含む複雑なセグメントを操作する場合は、複雑さを軽減し、問題の原因となっている条件またはルールを分離します。 これは、問題が発生する正確なケースまたは状態を特定するのに役立ちます。
- 完全なセグメントから開始して、条件とルールを 1 つずつ削除します。 変更が行われるたびに、メンバーが返されるまでセグメントを実行します。
- 新しいセグメントを最初から作成し、メンバーを生成していないセグメントから条件とルールを 1 つずつ追加します。 条件またはルールを追加する各ステップの後に、メンバーが返されなくなるまでセグメントを実行します。
- メンバーをフィルターで除外するルールが特定されたら、予想される連絡先のサンプルを取得し、それがセグメントに追加されたすべての条件に一致するかどうかを確認します。
- 除外セグメントを削除して、連絡先を追加する前に連絡先が表示されるかどうかを確認し、プライマリ セグメントから削除する可能性のある ContactId が除外セグメントにあるかどうかを確認します。
ステップ 3: 部署を検証する
組織に対して事業単位のスコープが有効になっているかどうかを確認します。有効にすると、リアルタイム ジャーニーは部署のメンバーのみを返します。
- リアルタイム ジャーニーは既定で部署を有効にします。 アウトバウンド マーケティングでは、部署がオンになる場合とオンにならない場合があります。
- アウトバウンド マーケティングでは、すべてのセグメントに部署を含めるか含めないかが許可されますが、リアルタイム ジャーニーでは、すべてのセグメントで部署が有効になっているか、どのセグメントにも部署が有効になっていないかのどちらかになります。
ステップ 4: 空のテーブルを検証する
セグメントで使用されているテーブルが空でないことを検証します。 セグメントで使用されるすべてのエンティティには、そのセグメントの同期をトリガーするために少なくとも 1 つのレコードが必要です。 エンティティが空の場合、セグメントには予期されるメンバーが表示されません。
ステップ 5: 同意を検証する
同意が有効になっているかどうかを検証します。 同意は、選択した目的と トピック に基づいて表示されるセグメントをフィルターします。 詳細: アウトバウンド マーケティングからの同意の移行
セグメントには予想よりも多くのメンバーが表示されます
セグメントのメンバーが予想よりも多い理由を判断するには、次のトラブルシューティング手順を試してください。
ステップ 1: 複雑さを解消する
- 完全なセグメントから開始して、条件とルールを 1 つずつ削除します。 変更が行われるたびに、メンバーが予想されるメンバーを追加するまでセグメントを実行します。
- セグメントに例外句または除外セグメントがあるかどうかを確認し、予期される連絡先がセグメントの一部であり、フィルターで除外されていないかどうかを確認します。
- メンバーが追加される原因となるルールが特定されたら、データが出力と相関しているかどうかを確認します。 たとえば、ルールが
firstname = 'Frank'のような場合、セグメントはfirstname = 'Frank'の連絡先のみを追加する必要があります。
ステップ 2: アウトバウンド マーケティングまたは高度なメンバー検索との不一致
アウトバウンド マーケティングまたは高度な検索メンバーとの不一致が観察された場合は、次の点を確認してください。
- 使用されているリレーションシップが同じ順序であるかどうかを確認します。 セグメントで使用される "アカウント" エンティティは、"連絡先" と "アカウント" の間の関係です。 これは、高度な検索で "アカウント" エンティティにフィルターを直接適用することとは異なります。
- リアルタイム ジャーニーでは、取引先責任者およびリード エンティティのみでセグメントを作成できます。 これらがアウトバウンド マーケティングまたは高度な検索セグメントで使用される主要なエンティティであることを確認します。
ステップ 3: 仮想フィールドが使用されていないことを検証する
現在、仮想フィールドは Dataverse テーブル内のセグメンテーション機能ではサポートされていません。
いつサポート チケットを発行する必要がありますか?
上記の条件がすべて満たされているにもかかわらず、予想される連絡先が一致しない場合は、サポート チケットを発行する必要があります。 サポートチケットを開く場合は、常に以下の情報を含める必要があります:
- 組織ID
- リアルタイムの旅行セグメントのセグメント ID
- 矛盾の原因: 高度な検索またはアウトバウンド マーケティング
- 高度な検索に対応した FetchXML
- アウトバウンドマーケのセグメント ID
- セグメントに表示すべき、または表示すべきでない ContactIds のサンプル。
- ContactId が潜在的な不一致の原因となっている属性とエンティティ。