# Identify early behaviors associated with retention

> Compare predefined first-window product behaviors with later retained activity, quantify associations, and design a validation step without declaring a magic cause.

## Agent adaptation contract

- Canonical human page: https://agentry.sh/workflows/activation-moment
- Execution mode: human_review
- Immutable automation template: none
- Applies to: b2c-saas, b2b-saas, devtools-api, content-media, marketplace
- Required example events: signup_completed, product_value_completed, retained_activity
- Required Agentry resources: signal_map, onboarding_state, analytics
- Do not use when:
  - Do not call a behavior a magic moment or causal driver from retrospective correlation alone.
  - Do not use incomplete cohorts, any-event retention, or events chosen only after inspecting the outcome.
  - Do not automatically change onboarding, create targeting cohorts, or contact users from exploratory results.
- Ask before using:
  - Which observed event defines signup, which predefined early behaviors are candidates, and which event represents meaningful retained activity?
  - What exact early window, later retention window, cohort dates, minimum sample, and major segments should be used?
  - How will the strongest association be validated on a later cohort or prospective experiment?

This is an adaptable workflow example, not an API recipe. Map event and property names to the project's saved signal map, require status: "verified" from GET /v1/projects/:project_id/onboarding, and confirm the required signals through live event/property metadata and rows. Fetch current OpenAPI or query-blueprint details before making calls. Do not infer unattended authority from this page.

## Why this matters

Teams want an early behavior that signals a user has reached value. Historical
retention differences are useful clues, but they are vulnerable to selection
bias: already-motivated users often both complete more actions and retain.

Use this workflow to identify candidate behaviors and design validation. Do not
turn the highest retrospective rate into a causal product rule.

## What you get

- Cohort sizes and later retained-activity rates for predefined early behaviors
- Baseline and major-segment comparisons
- Coverage, confounding, and identity caveats
- A frozen candidate definition and validation plan

## Walk through it

**You:**
> Which first-day behaviors are associated with meaningful activity four weeks later?

**Agent:**
> I will verify the signup, candidate, and retained-activity events, then compare
> complete historical cohorts. I will not call the strongest row causal.

```http
GET /v1/projects/:project_id/signal-map
GET /v1/projects/:project_id/onboarding
# Require status: "verified"; use live event/property reads for the selected signals.
GET /v1/projects/:project_id/event-names
```

```text
Endpoint: POST /v1/projects/:project_id/analytics/query
Query plan:
  - choose complete signup cohorts with a full later observation window
  - mark predefined candidate events completed within the first 24 hours
  - define retained activity from one approved value event in the later window
  - return cohort size and retained count by candidate and major segment
  - include the all-signup baseline; return no raw identities
```

```json
{
  "rows": [
    { "candidate": "integration_connected", "cohort_size": 142, "retained_users": 87, "retention_pct": 61.27 },
    { "candidate": "team_member_invited", "cohort_size": 98, "retained_users": 54, "retention_pct": 55.10 },
    { "candidate": "all_signups", "cohort_size": 620, "retained_users": 211, "retention_pct": 34.03 }
  ]
}
```

## The output

```text
Early-behavior association review — <cohort and observation bounds>

Observed
- <candidate>: <cohort size>, <retained count>, <rate>
- baseline: <rate>
- segment stability: <result>

Limitations
- <selection bias, identity gaps, sparse sample, instrumentation change>

Candidate to validate
- frozen behavior and window: <definition>
- validation: later holdout cohort or prospective experiment
```

## Setting it up

Define retained activity as a source-backed value event, not “any event.” Use a
stable identity across signup, early behavior, and the later window. Exclude
internal, test, synthetic, and automation traffic and preserve exact cohort
bounds so the analysis can be reproduced.

Do not instrument every conceivable action solely to search for a lucky
correlation. Start from a small set of plausible value behaviors derived from
the product's business logic.

## Variations

- *"Repeat the frozen definition on the next complete cohort."*
- *"Compare the association by plan or acquisition source without pooling unlike users."*
- *"Use eight-week retained activity and report how the result changes."*
- *"Design an experiment to test the onboarding intervention; do not launch it."*