> ## Documentation Index
> Fetch the complete documentation index at: https://flywheel.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Drop-off Trigger
> Activate when users fail to complete expected actions within a specified timeframe
## How Drop-off Triggers Work
1. **Monitor Events**: The system tracks when users perform the initial event
2. **Set Expectations**: You define what actions users should take next
3. **Wait and Watch**: The system waits for the expected follow-up events
4. **Trigger on Absence**: If expected events don't occur within your timeframe, the workflow starts
## Configuration
Select one or more events that start the drop-off monitoring. Examples: `trial_started`, `cart_created`, `signup_initiated`.
Configure the events you expect users to complete after the initial event.
The specific event you expect users to complete (part of Expected Events configuration).
How long to wait before considering it a drop-off (number value).
Time unit for the delay. Options: `seconds`, `minutes`, `hours`, `days`, `weeks`, `months`.
Priority order for multiple drop-off events. Lower numbers have higher priority.
The drop-off event data generated by Flywheel when the expected event didn't occur.
Unique identifier for this drop-off event.
Always `$fw_drop_off` for drop-off events.
ISO datetime when the drop-off was detected.
Contains drop-off specific data and system properties.
Always `flywheel` for system-generated events.
Internal user identifier.
Name of the last event the user completed that triggered the drop-off monitoring.
Full details of the original event that started the drop-off monitoring, including all event properties and custom data.
Comprehensive user information for the user who dropped off.
Unique user identifier.
Your company's external user identifier.
User's primary email address.
User's first name.
User's last name.
Current subscription status: `incomplete`, `incomplete_expired`, `trialing`, `active`, `past_due`, `canceled`, `unpaid`, `paused`, `inactive`.
Payment processor used: `stripe` or `paddle`.
Monthly recurring revenue from this user.
Lifetime value of the user.
ISO datetime of user's first payment.
ISO datetime of user's next scheduled payment.
ISO datetime when subscription will be cancelled (if applicable).
Additional contact information and preferences.
Custom user properties you've defined.
The system creates drop-off events with the name `$fw_drop_off` for all drop-off triggers.
## Use Cases
**Trial Conversion**
```
Initial Event: trial_started
Expected Event: subscription_created
Drop-off Delay: 7 days
Result: Triggers if user doesn't subscribe within 7 days
```
**Cart Abandonment**
```
Initial Event: cart_created
Expected Event: purchase_completed
Drop-off Delay: 2 hours
Result: Triggers if user doesn't complete purchase within 2 hours
```
**Onboarding Completion**
```
Initial Event: account_created
Expected Events:
- profile_completed (24 hours)
- first_project_created (3 days)
- team_invited (7 days)
```
## Best Practices
**Choose Appropriate Timeframes**
* Consider your typical user behavior patterns
* Account for different user segments (some may need more time)
* Start with longer delays and optimize based on data
**Segment Your Audiences**
* Use trigger conditions to create different drop-off flows for different user types
* Consider factors like subscription tier, user role, or geographic location
**Monitor and Adjust**
* Track which drop-off triggers are most effective
* Adjust timing based on actual user behavior data
* A/B test different delay periods