セグメントはメンバーを返さないか、0 を返しません

この記事では、 egment が期待どおりにメンバーを返さない問題の解決策について説明します。

前提条件

• セグメントの更新状態が成功しました。
• セグメントが新しく作成または編集されるか、データのインポートまたは統一ルールまたはデータのビジネス定義が変更されました。

セグメントが以前に成功し、メンバーは 0 個表示されていて、上記で指定した他の変更がない場合は、サポート チケットを開いてください。

現象

セグメントは正常に実行され、更新されますが、メンバーは含まれません。

解決方法

根本原因を調査し、問題を解決するには、次の手順を実行します。

矛盾する条件またはルールの基本的なロジックを検証する

同じ属性に対する矛盾した AND 条件またはルールは、常に空のセグメントを生成します。 たとえば、 FirstName = Joe AND FirstName = Frank。

壊れたロジックのすべてのルールと条件を確認します。 複数の属性間のより複雑な矛盾も考慮してください (これにはデータセットに関するより多くの知識が必要です)。 たとえば、 Status = 1 AND StatusDescription = Inactive、 1 の状態値は常にアクティブ を意味します。

セット操作 (Union、 Intersect、および Except は、2 つのルールを結合するために使用されます) は、各ルールによって返される CustomerId に適用されます。 そのため、予想される結果に応じて、 CustomerId が各ルール評価の結果の一部であるかどうかを確認します。

複雑さを分解する

複数の条件またはルールで複雑なセグメントを操作する場合は、複雑さを軽減し、問題の原因となる条件またはルールを分離します。

• 完全なセグメントから開始し、条件とルールを 1 つずつ削除します。 変更のたびに、メンバーが返されるまでセグメントを実行します。
• 新しいセグメントをゼロから構築し、メンバーを生成しないセグメントから条件とルールを 1 つずつ追加します。 メンバーが返されなくなるまで、条件またはルールを追加する各ステップの後にセグメントを実行します。

セグメントルールまたは条件で使用される属性のデータがありません

何らかの理由でセグメントルールまたは条件で使用される属性の値が欠落している場合、セグメントはメンバーを返さない可能性があります。 予期される値が存在するかどうかを確認します。

• テーブル のデータと属性値を調べる。 使用可能な場合は、関心のある属性の Summary 列を確認し、それらが Missing または Error 状態になっていないことを確認します。

  Note

  概要はシステム生成テーブルでは使用できません。また、独自の Azure Data Lake Storage からインポートされたテーブルについては省略可能です。

• ソース レコードが破損 影響を受けていないかどうかを確認します。

• 特定の属性のテーブルに特定の値が存在するかどうかを確認します。 属性値でフィルター処理された、そのテーブルのメジャーを作成します。 Count オプションを使用して、フィルター条件の値を含むレコードの数を確認します。 参照レコードを検索するには、主キーまたは外部キーの First オプションを使用します。

• データ内の属性値をさらに調べるには、次のオプションを検討してください。

  • テーブル ビューのテーブルの .csv ファイルをダウンロードして、最初の 100,000 レコードを検証します。

  • Power BI コネクタを使用して、Power BI でエンティティを探索します。

    Note

    すべてのエンティティ (特に Azure Data Lake Storage データ ソースのソース エンティティ) は、このコネクタでは使用できません。 100 万行未満のテーブルでも使用することをお勧めします。

  • Azure Blob StorageAzure Data Lake StorageAzure Synapse Analytics または Azure Synapse Analytics で Azure にデータをエクスポートします。 エクスポートは、Synapse Analytics、Power BI、またはその他のデータ探索ツールを使用した詳細な調査に役立ちます。

  • Power Query データ ソースの場合は、不足している属性のフィルター条件を使用して、新しいデータ ソースまたは別の参照クエリを既存のデータ ソースに作成します。 更新したら、新しいテーブルにデータが含まれているかどうかを確認します。

テーブル間のリレーションシップに関する問題

セグメント化に使用されるテーブルと統合された顧客テーブルの間のリレーションシップが、以下に示す理由により機能しない場合、セグメントはメンバーを返しません。

• ソース テーブル (属性のフィルター条件を使用) と Customer テーブルの間で技術的に有効なパスがいくつか存在する可能性があり、目的の関係パスが使用されているかどうかを確認します。 関連するテーブルが複数ある場合は、各リレーションシップを調べて、適切な属性で正しく構成されているかどうかを検証します。

• 属性値の評価では、大文字と小文字が区別されます。 たとえば、2 つのテーブルは共通の属性 ( MembershipType) を介して関連付けられます。 属性値が一方のテーブルで GOLD 、もう一方のテーブルでは gold である場合、結合は成功せず、結果は返されません。 同じロジックが GUIDsに適用され、見逃しやすいものになります。

• 属性のデータ型がテーブル間で揃っていることを確認します。

• 重複除去プロセスでは、データの統一中に "勝者" レコードが識別されます。 重複除去されたプロファイル ソース テーブルをリレーションシップ パスで作成したメジャーとセグメントでは、"勝者" レコードが使用され、予期しない結果が発生する可能性があります。

セグメントとメジャーの評価は、リレーションシップで定義されている属性のテーブルを結合することによって行われます。 たとえば、 MembershipMaster には、 Contact テーブルとのリレーションシップがあり、 MembershipId 属性と MembershipType 属性があります。 Contact テーブルには、Customer テーブルとのリレーションシップがあり、ContactIdおよびContactId (Source1_Contact)の属性に対する統一された顧客プロファイルが含まれています。 テーブルリレーションシップの詳細については、次のスクリーンショットを参照してください。

プロファイル テーブル (この例では、 Contact テーブル) が 重複除去されている場合、リレーションシップが原因で"winner" レコードが評価されます。

この例では、C1 ("Gold" メンバーシップを持つ) と C2 ("Silver" メンバーシップ) は、C2 が勝者であると統合されています。 そのため、"Gold" メンバーを識別するためにセグメントが作成されると、リレーションシップ パスは C2 でのみ評価されるため、"First Person" はセグメントの一部になりません。