​

概要

Portfolio 機能は、MoEngage 内のすべてのプロジェクトを一元化し、顧客の統合ビューを提供します。これにより、複数のアプリケーションやウェブサイトにわたるプッシュキャンペーンのセグメント化、パーソナライズ、配信、分析の方法が強化されます。 この記事では、Portfolio 機能が次の主要な領域に与える影響について説明します。

• 特定のプロジェクトとプラットフォームをターゲットにする
• クロスプロジェクトセグメンテーション
• クロスプロジェクトのトリガー型キャンペーン
• パーソナライゼーション
• プロジェクト別のオプトイン率を分析する
• Portfolio レベルおよびプロジェクトレベルのリーチャビリティ
• ユーザープロファイルのリーチャビリティ

これらの概念を説明するために、2 つの異なるブランド（Project A と Project B）を持つ企業の 1 つのキャンペーンを例に取り上げます。このキャンペーンの目的は、メインアプリのロイヤルカスタマーにプレミアムブランドをクロスプロモーションすることです。

​

特定のプロジェクトとプラットフォームをターゲットにする

Portfolio 機能を使用すると、各プロジェクト固有のコンテキストに合わせてメッセージ、ディープリンク、オファーを調整し、一貫したユーザーエクスペリエンスを確保できます。 次の例では、Project A の価値の高い顧客に新しいオファーを試してもらうことを目的としています。

1. キャンペーン作成の Target Users ステップで、Target Projects/websites セクションを見つけます。
2. Project リストで、ターゲットとするプロジェクト（たとえば Project A）を選択します。
3. iOS や Android などのターゲットプラットフォームのチェックボックスを選択し、そのブランドのすべての対象デバイスに案内を送信します。

キャンペーン作成手順の詳細については、プッシュキャンペーンの作成に関するガイドを参照してください。

​

クロスプロジェクトセグメンテーション

単一プロジェクト内での行動だけでなく、プロジェクト全体にわたるユーザーのジャーニー全体に基づいてユーザーをセグメント化できます。この機能は、効果的なクロスプロモーションと、顧客ライフサイクル全体の理解に不可欠です。 次の例では、project A の高価値顧客のうち、まだ project B を利用していない顧客を見つけることを目的としています。

1. Target audience セクションで Filter users by を選択し、User behavior タブを選択します。
2. 最初のルールでは、プロジェクトのドロップダウンリストを使用して p_roject A_ を選択し、条件「Has Executed Made Purchase」を設定します。これにより、価値の高い顧客を見つけられます。
3. + Filter をクリックして 2 つ目のルールを追加します。project B を選択し、条件「Has NOT Executed App/Site Opened」を設定します。

​

クロスプロジェクトのトリガー型キャンペーン

あるプロジェクトでの顧客の行動を使用して、別のプロジェクトのキャンペーンをトリガーできます。これにより、ユーザーのアクションにリアルタイムで反応する、高度で自動化されたクロスプロモーション戦略を作成できます。Portfolio 全体でユーザーのアクションを結び付けることで、顧客を新たな発見へと導き、全体的なコンバージョンを向上させることができます。 次の例では、ユーザーが Project A でカートに商品を追加したものの、購入を完了しなかったとします。この未完了の行動をきっかけに、Project B から類似または代替の商品を提案するキャンペーンをトリガーできます。

1. Target Projects & Platforms セクションで、キャンペーンを送信するプロジェクトとして Project A を選択します。
2. Trigger Criteria で、IF user 条件に Project B のイベントを設定します（例：「Has executed AddtoCart atleast 1 time in the last 3 days」）。
3. ユーザーをさらに絞り込むために AND 条件を追加します（例：「For Project B Has not executed Purchased」）。
4. THEN trigger the message セクションでタイミングを設定します。この設定では、ユーザーが Project B でカートに商品を追加したものの購入を完了しなかった場合、その 2 日後に Project A からメッセージが送信されます。

次の画像は、このトリガー設定を示しています。 イベントトリガー型キャンペーンの作成方法の詳細については、こちらを参照してください。

​

パーソナライゼーション

パーソナライゼーションは、ターゲットとするプロジェクトに合わせてメッセージを調整し、関連性と正確性を確保します。特定のプロジェクト向けのキャンペーンを作成すると、MoEngage はユーザー属性リストを自動的にフィルタリングし、ターゲットプロジェクトの属性とグローバル属性のみを表示します。これにより、あるブランドのコンテキストのデータが別のブランドで使用されることを防ぎ、一貫したユーザーエクスペリエンスを維持します。 例：Project A の顧客に Project B をプロモーションするキャンペーンでは、パーソナライゼーションに Project A のデータが使用されます。ユーザーが Project B で異なるプロファイル情報を持っている場合でも、キャンペーンでは正しく Project A の情報が使用され、ブランドのコンテキストが維持されます。

1. キャンペーンの Content ステップで @ を入力し、パーソナライゼーション属性のリストを開きます。
2. 利用可能な Project A またはグローバル属性から First Name 属性を選択します。
   メッセージ「Hi @User Attributes.First Name! An exclusive offer awaits」では、ユーザーが Project A で提供した名前が正しく使用されます。

プッシュキャンペーンのパーソナライズの詳細については、こちらを参照してください。

​

プロジェクト別のオプトイン率を分析する

Portfolio 機能では、リーチャビリティをプロジェクト固有の属性として保存します。これにより、プロジェクトごとにプッシュ通知のオプトイン率を個別に分析・比較でき、プロジェクト単位でユーザーの意向や許可プロンプトの効果を把握するのに役立ちます。

• iOS、Android、Web では、新しいプロジェクトレベルのユーザープロパティに基づいてユーザーをフィルタリングすることで、プラットフォーム固有のオプトイン率を分析できるようになりました。
• Analytics の Filter users by セクションで、分析したいプロジェクトとプラットフォームに対応するユーザープロパティを選択します。
• これらの属性は [Attribute Name] [Platform] [Project Name] の形式に従っており、正確なセグメントを作成して各プロジェクトのオプトインのパフォーマンスを可視化できます。例：Reachability Push Android Project A.

​

Portfolio レベルおよびプロジェクトレベルのリーチャビリティ

ユーザーの Portfolio リーチャビリティは、ユーザーがコミュニケーションを受信できるかどうかを判断する集約されたステータスです。

• 関連付けられたプロジェクトの少なくとも 1 つでリーチ可能な場合、そのユーザーは Portfolio レベルでリーチ可能と見なされます。そのためには、そのプロジェクト内でユーザーのデバイスの少なくとも 1 つがコミュニケーションを受信可能である必要があります。
• MoEngage は、まずプロジェクトレベルでリーチャビリティを評価し、その結果を集約して最終的な Portfolio のステータスを決定します。

​

シナリオ例

それぞれ複数のデバイスを持ち、2 つの異なるプロジェクトに関連付けられている 2 人のユーザーを考えます。次の表は、それぞれのデバイスのステータスを示しています。

ユーザー	Project ID	デバイス	デバイスのステータス	プロジェクトレベルのリーチャビリティ	Portfolio レベルのリーチャビリティ
User 1	A	Device A	リーチ可能かつオプトイン済み	Project A でリーチ可能かつオプトイン済み	リーチ可能かつオプトイン済み
		Device B	オプトアウトによりリーチ不可
	B	Device A	オプトアウトによりリーチ不可	Project B でオプトアウトによりリーチ不可
		Device B	オプトアウトによりリーチ不可
User 2	A	Device C	オプトアウトによりリーチ不可	Project A でリーチ可能、オプトインステータス不明	リーチ可能、オプトインステータス不明
		Device D	リーチ可能、オプトインステータス不明（古い SDK バージョンの場合）
	B	Device C	オプトアウトによりリーチ不可	Project B でオプトアウトによりリーチ不可
		Device D	オプトアウトによりリーチ不可

​

分析と最終的な Portfolio ステータス

• User 1: このユーザーは Portfolio レベルで リーチ可能 と見なされます。
  理由: このユーザーは Project B ではリーチできませんが、Device A が Project A でオプトインしています。1 つのプロジェクトでリーチ可能なこの 1 件により、Portfolio 全体のステータスが「リーチ可能」になります。
• User 2: このユーザーは Portfolio レベルで リーチ可能 と見なされます。
  理由: このユーザーは 3 つのデバイスでリーチできませんが、Device D は Project A でリーチ可能（オプトインステータス不明）です。そのため、User 2 の Portfolio 全体のステータスは「リーチ可能」になります。

すべてのリーチャビリティステータスの計算方法の包括的な説明については、次のガイドを参照してください。

• Android Push Permission and Reachability
• iOS Push Permission and Reachability
• Web Push Permission and Reachability

​

ユーザープロファイルのリーチャビリティ

ユーザープロファイル内の Reachability セクションでは、ステータスの統合ビューが提供されるようになりました。Portfolio 全体のステータスに加えて、ユーザーが関連付けられている個々のプロジェクトごとのリーチャビリティステータスも確認できます。これには次のものが含まれます。

• Portfolio レベルのリーチャビリティ：すべてのプロジェクトにわたるユーザーの集約されたリーチャビリティステータス。
• プロジェクトレベルのリーチャビリティ：個々のプロジェクトごとのユーザーのリーチャビリティステータス。

​

FAQ

プロジェクト固有のプッシュキャンペーンでパーソナライゼーションに使用できるユーザー属性は何ですか？

送信元のプロジェクトに関連付けられたすべてのユーザー属性と、Portfolio 全体でユーザーに適用されるグローバル属性を使用できます。MoEngage は、ブランドの一貫性とデータの正確性を確保するため、他のプロジェクトの属性を自動的に除外します。

ユーザーが複数のプロジェクトで異なる属性値（'First Name' など）を持っている場合、プッシュ通知ではどの値が使用されますか？

プッシュ通知では、常にキャンペーンの送信元プロジェクトの属性値が使用されます。これにより、メッセージは常に正しいブランドのコンテキストで表示されます。

送信元プロジェクトのアプリやウェブサイトを一度も使用したことがないユーザーのセグメントにプッシュキャンペーンを送信するとどうなりますか？

そのセグメントのユーザーは誰もキャンペーンを受信しません。特定のプロジェクトからプッシュ通知を受信するには、ユーザーがそのプロジェクトのアプリをインストールするかウェブサイトにアクセスし、通知の受信にオプトインしてプッシュトークンが生成されている必要があります。

プッシュ通知を送信する Flow のエントリートリガーとして、クロスプロジェクトセグメントを使用できますか？

いいえ。現在、クロスプロジェクトのセグメンテーションとトリガーは、キャンペーンを直接作成する場合向けに設計されています。Flows などの高度な機能では、オーディエンスのエントリーにクロスプロジェクトのデータを使用することはできません。

​

関連記事

• Mobile App Push Settings
• Web Push Settings
• Push Preview Settings
• プッシュキャンペーンの作成
• Web プッシュキャンペーンの作成
• イベントトリガー型キャンペーンの作成
• Android Push Permission and Reachability
• iOS Push Permission and Reachability
• Web Push Permission and Reachability