> For the complete documentation index, see [llms.txt](https://docs.wicle.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.wicle.io/visualizing-retention/lifecycle/edit-lifecycle.md).
# ライフサイクルの編集
ライフサイクルの分析対象、活性化と定着の判定条件を設定し、保存後の再集計を確認する方法を説明します。
プロダクトに合う分析対象、活性化の条件、定着とみなす来訪頻度を設定します。メインメニューの `エンゲージメント` → `ライフサイクル` を開き、画面上部の `条件の編集` を選択します。
{% hint style="warning" %}
保存すると、変更した条件で過去のデータも再集計されます。現在の設定と変更内容を確認してから保存してください。再集計の完了まで、結果の確認を待つ必要があります。
{% endhint %}
## エントリー条件
ライフサイクルの分析対象に入る条件と、対象から除外する条件を設定します。
| 設定項目 | 設定する内容 |
| ---------------- | ---------------------------------------------------------- |
| エントリーの条件 | ユーザープロファイル、ユーザーディメンション、コードレス／カスタムイベントの発生回数から、分析対象の条件を指定します |
| 活動時間が短すぎるユーザーを除外 | 分析対象に含める累計活動時間の下限をスライダーで指定します。誤タップなどの短い利用を除きたい場合に使います |
| 長過ぎる休眠を除外 | 最後の来訪から長期間経過したユーザーを除外します。除外後に再来訪したユーザーは、新規フェーズから始まります |
社内ユーザーを除いたり、契約プランやロールで対象を絞ったりする場合は、判定に使う [ユーザープロファイル](/data-extension/user-profile.md) をあらかじめ送信します。
## アクティベーション条件
初回の購入、オンボーディングの完了、一定時間の利用など、ユーザーがプロダクトの価値を体験したとみなす条件を設定します。
* `活性化済みの条件`：ユーザープロファイル、ユーザーディメンション、コードレス／カスタムイベントの発生回数から指定します。1つ以上の条件が必要です。
* `ドロップの条件`：活性化の条件を満たさないまま、最後の来訪から何日経過したらドロップとするかを指定します。`長過ぎる休眠を除外` より短い日数を設定します。
たとえば、ドロップの条件を7日にすると、活性化していないユーザーが最後の来訪から7日経過したときにドロップとなります。
## リテンション条件
活性化したユーザーについて、どのくらいの頻度で来訪すれば定着・ファンとみなすか、どのくらい来訪がなければ休眠とみなすかを設定します。
画像内の「1インターバル」は、現在の「判定単位」にあたります。
1. `推奨パターン` から、利用頻度に合うものを選択します。日々使うプロダクトは `短期`、迷う場合は `バランス`、利用間隔が数週間以上空く場合は `中長期` が目安です。個別に調整する場合は `カスタム` を選択します。
2. `判定単位` を日または週から選択します。
3. 定着・ファンの来訪頻度と、休眠予備群・休眠までの期間を確認し、必要に応じて変更します。
| 設定項目 | 意味・選び方 |
| -------- | -------------------------------------------- |
| 定着の条件 | 直近の何日・何週のうち、何日・何週以上来訪すれば定着とするかを指定します |
| ファンの条件 | 定着より高い来訪頻度を指定します。定着とは別に観測期間と、来訪した日数・週数を設定します |
| 休眠予備群の条件 | 何日・何週連続で来訪がなければ、休眠予備群とするかを指定します |
| 休眠の条件 | 何日・何週連続で来訪がなければ、休眠とするかを指定します |
判定単位が週の場合、同じ週に何回来訪しても「来訪した1週」と数えます。たとえば `8週中4週以上来訪` は、直近8週のうち4週以上で来訪している状態です。
推奨パターンや観測期間を変更すると、ほかの項目も連動して変更される場合があります。保存前にすべての期間と来訪頻度を確認してください。
### ファンの条件
ファンは来訪頻度だけでも判定できます。特定の行動を継続しているユーザーに限定したい場合は、`ファンの条件(特定行動)` を追加します。
あらかじめ [キー行動](/visualizing-retention/key-behavior.md) を作成し、`ファン条件を設定する` から対象のキー行動を選択します。来訪頻度の条件に加え、選択したキー行動のフェーズが `継続` であることがファンの条件になります。
## 設定内容の確認/条件保存
1. 画面右側の図で、設定した条件と当日時点の参考人数を確認します。
2. 画面右上の `保存` を選択し、確認画面で保存します。
3. ライフサイクル画面で再集計の進行状況を確認し、完了後に結果を確認します。
ファンの追加条件にキー行動を使う場合、キー行動が集計中だと保存できません。集計の完了後に保存してください。
---
# 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 by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.wicle.io/visualizing-retention/lifecycle/edit-lifecycle.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
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.
