> For the complete documentation index, see [llms.txt](https://manual.dxable.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://manual.dxable.com/optimizely/platform/optimizely-data-platform/customers/prevent-churn-and-win-back-customers.md).
# 離脱を防ぎ、顧客を取り戻す
顧客のブランドに対する関与のパターンによって、顧客が顧客であり続ける可能性が決まります。通常のパターンに従っていない顧客を特定することで、関係を維持することができます。[ Optimizely Data Platforms (ODP) の顧客獲得モデル](https://app.zaius.com/?#/winback)は、エンゲージメントからの日数と顧客であり続ける可能性の関係を示しているため、顧客が離脱する前に見つけることができます。 ODP は、新規購入者と以前の購入者の両方を評価します。
モデルへの主な入力は、ブランドの顧客向けのイベント日です。毎日、顧客がその日にブランドに積極的に関与した場合は「ヒット」、そうでなかった場合は「ミス」となります。このモデルは、より多くのデータソースを ODP に統合するにつれて、ブランドのエンゲージメントのパターンをよりよく理解します。
このモデルは、顧客のイベント パターンに基づいて顧客をスコアリングし、最後のエンゲージメント以降の日数の間にたどる最も可能性の高いパスと、顧客であり続ける確率を決定します。次に、顧客に残り続ける確率を割り当て、顧客をエンゲージメント、ウィンバック、またはチャーンゾーンに配置します。モデルの詳細については、この記事の最後にある「データ サイエンティスト向け」を参照してください。
### チャーン防止エクスプローラーを使用する
#### **顧客エンゲージメントの傾向**
円錐プロットは、平均的な顧客について、最後のエンゲージメントからの時間と顧客であり続ける可能性との関係を示します。各顧客は、独自のエンゲージメント パターンに基づいて、このコーンを通過する独自のパスをたどります。
* エンゲージメントが低い顧客は、エンゲージメント間の時間がすでに長いため (円錐の上端)、確率の低下がより遅くなります。
* 頻繁にエンゲージメントを行う顧客の生存確率は、エンゲージメントが遅くなるにつれて (円錐の下端に向かって) より急速に低下します。\
円錐は顧客の中間 60% を示します。顧客の 20% は表示よりも早くフェードする可能性があり (低下が急峻になる)、平均フェード率は 20% ですが、20% は表示よりも早くフェードしない可能性があります。
このコーンには、ブランドのデータに固有の、エンゲージメント、ウィンバック、およびチャーンとして示される領域も含まれています。
* ウィンバック領域は、顧客が顧客であり続ける可能性が高まると、それに応じて翌年も再エンゲージする可能性も大きく高まるところから始まります。この時点でウィンバックキャンペーンを開始します。
* ウィンバック領域は、顧客が顧客であり続ける可能性が高まると、それに応じて翌年に再エンゲージする可能性の増加が小さくなり、顧客が解約したとみなされるところで終了します。
#### **顧客の可能性の分布**
ヒストグラムは、顧客が顧客であり続ける可能性別に顧客の分布を示します。匿名ユーザーを除いた既知の顧客ベースが表示されます。新しいセグメントを構築するか、\[+ セグメント] をクリックして既存のセグメントを評価して適用します。
ヒストグラムは、視聴者の構成を理解するのに役立ちます。たとえば、ニュースレターの視聴者がチャーンに偏った場合、開封率と配信率に影響を与える可能性があります。 Winback に価値の高い顧客が紛れ込んでいる場合は、彼らとの関係に独自のアプローチをとるべきかもしれません。
#### **スコアを獲得した顧客とスコアを獲得していない顧客**
スコア付けされていない顧客には、顧客ゾーン (**エンゲージメント**、**ウィンバック**、および**チャーン**) の値がありません。スコアなしとは、顧客が 1 日しかアクティビティを行っておらず、購入を行っていないことを意味します。各分析は、スコア付けされていない顧客の数を示します。このパーセンテージは、さまざまなセグメントを**顧客可能性の分布グラフ**に適用すると変化します。
これらの顧客はブランドに適していない可能性があり、同様にキャンペーンの開封率や配信性に影響を与える可能性があるため、スコアなしの割合を調べてください。これらの顧客は、他の形式のターゲティング (セグメント同期など) でマーケティング リソースを消費することもできます。しばらくの間知られているものの、**Winback Zone** 属性の値を持たない顧客を除外することを検討してください。
### ウィンバックアクションを実行する
Optimizely の顧客獲得の出力は、次の 2 つの方法で使用します。
#### **ウィンバックキャンペーンのレシピ**
ウィンバック キャンペーンの構成には、特別にターゲットを絞ったセグメントと、2 週間にわたって 3 つのタッチポイントを送信する電子メール キャンペーンが含まれます。 「Winback キャンペーン レシピのインストール」をクリックして、事前に構築されたキャンペーンをインストールします。
このセグメントには、毎日、再エンゲージメントに最適なタイミングであるウィンバック ゾーンに入った顧客が表示されます。毎日、新しい顧客がこのしきい値を超えています。キャンペーンを利用するには、以下の操作を行ってください。
* 以前にウィンバック キャンペーンを獲得したユーザーを除外するなど、登録ルールまたは除外を追加します。
* 開始時間を選択します。ウィンバック データは夜間に更新されるため、このキャンペーンを継続的ではなく定期的に設定する必要があります。毎日キャンペーンを送信する時刻を選択します。
* 各タッチポイントを更新して、ブランドのメッセージ、ヘッダー、フッターを含めます。
#### **セグメントビルダーでのウィンバック**
また、セグメント ビルダーからウィンバック インサイトを直接使用して、独自のキャンペーン、分析、セグメント同期を作成することもできます。
**Winback Zone** は、顧客が顧客であり続ける確率に基づいて、**エンゲージド**、**ウィンバック**、**チャーン**の値を使用します。 Winback Type は、モデルが最後に実行されたとき (夜間)、顧客が Winback ゾーンに追加されたばかりの場合、Is Any Value の値を使用します。顧客は翌日にはその価値を失います。この値は、進行中のキャンペーンでウィンバック ゾーンに初めて参加する顧客のみをターゲットにするのに役立ちます。
### データサイエンティスト向け
このモデルは、顧客生涯価値モデルとして広く受け入れられているパレート NBD (負の二項分布) モデルから始まります。元のモデルは購入イベントを予測しますが、ODP モデルはあらゆる種類のエンゲージメントを予測します。このモデルは、パレート NBD の非サブスクリプション バージョンを使用し、サブスクリプション モデルなど、将来のインタラクションが過去のインタラクションによって過度に影響を受けないことを基本的に前提としています。 ODP は、過去の予測を行い、その後の再エンゲージメントを調べることで、そのモデルが将来のインタラクションを予測できることを検証しました。
挽回の機会は、ライブネスの尺度から始まり、ライブネスが増加すると、それに対応して将来のエンゲージメントもより大きく増加します。この出発点はクライアントごとに異なります。活性度を高めても、それに対応して将来のエンゲージメントの増加が小さい場合、顧客を取り戻す機会は終了し、顧客は離脱したと見なされます。各セクション (**エンゲージド**、**ウィンバック**、**チャーン**) には、すべてのアクティビティが一定に保たれた状態での再エンゲージメントの可能性が集約されています。
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://manual.dxable.com/optimizely/platform/optimizely-data-platform/customers/prevent-churn-and-win-back-customers.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.