Minimum: 5 seconds

Maximum: 30 days

Why: Blocks bots while allowing reasonable purchase consideration windows. Most online shoppers convert within 30 days or abandon the purchase intent.

Use when: Standard e-commerce with typical purchase cycles

Minimum: 15 seconds

Maximum: 7 days

Why: Forms can't be legitimately completed in under 15 seconds. Leads older than 7 days typically don't convert as sales team follows up quickly.

Use when: High fraud risk, short sales cycles, quick lead follow-up processes

Minimum: 10 seconds

Maximum: 26 weeks (6 months)

Why: Limits recurring commission liability while allowing reasonable trial-to-paid conversion timeframes. After 6 months, customer retention is internal success, not affiliate-driven.

Use when: Subscription models with recurring commissions

Minimum: 30 seconds

Maximum: DISABLED (uses 90-day default)

Why: Complex sales take time. 30-second minimum blocks bots while maximum stays open for long evaluation periods.

⚠️ CRITICAL: For sales cycles longer than 90 days, fire an intermediate event (demo scheduled, proposal sent, trial started) within 90 days to preserve the Transaction ID. Then the final "Deal Closed" conversion can fire months later.

Use when: Enterprise deals, complex purchases, long evaluation cycles

Minimum: 1 second

Maximum: 7 days

Why: App installs can happen quickly (legitimate), but retention matters within the first week. After 7 days, re-engagement is a separate event.

Use when: Mobile app campaigns with quick install-to-open funnels

Minimum: DISABLED

Maximum: DISABLED

Result: Allows conversions from 0 seconds to 90 days (hard system limit)

Why: Trusted traffic sources, low fraud risk, or complex user journeys where timing restrictions would hurt legitimate conversions.

Use when: Highly trusted partner relationships with proven quality

Likely cause: Your minimum window is too high for your actual funnel.

Solution:

1. Check the Click-to-Conversion Time Report to see your actual conversion patterns
2. If you see legitimate conversions happening at 8 seconds but your minimum is set to 15 seconds, lower it to 5 seconds
3. Start conservative (5 seconds) and tighten gradually based on real fraud data

Remember: Rejections are permanent. Always review your data before enabling strict windows.

Likely causes:

1. Conversion fired after the 90-day hard limit (click data archived)
2. Transaction ID typo in the postback URL
3. Click never actually occurred (bad actor using fake Transaction IDs)

Solution:

• Use the Investigator Tool to verify the Transaction ID exists and check the click timestamp
• If the click is older than 90 days with no prior conversion, the data is archived - implement intermediate events going forward
• Double-check postback URL formatting for typos

No. Once a conversion is rejected due to time window restrictions, it cannot be retroactively approved.

Why: This is by design to maintain data integrity and prevent manipulation.

Solution: Adjust your settings going forward. Always review conversion patterns in the report BEFORE enabling strict windows to avoid rejecting legitimate business.

Problem: Sales cycles longer than 90 days hit the hard data retention limit.

Solution: Fire an intermediate event within 90 days.

Example workflow:

1. Day 5: User submits application → Fire "Application Submitted" event
2. This creates a conversion record, "locking in" the Transaction ID
3. Month 6: Deal closes → Fire "Deal Closed" event
4. Attribution works correctly because the click was preserved by the intermediate event!

Intermediate event examples: Demo scheduled, proposal sent, trial started, application submitted, quote requested

Problem: These integrations use "clickless" tracking (no timestamp).

Solution: DISABLE Click-to-Conversion Time for these Offers.

Steps:

1. Go to the Offer using AppsFlyer iOS 14+ Advanced Privacy or TikTok Cost Integration
2. Edit → Attribution tab
3. Toggle OFF "Enable Click-to-Conversion Time"
4. Save

If you need time restrictions for other traffic: Create separate Offers for AppsFlyer/TikTok traffic vs other sources. Apply time restrictions only to the standard tracking Offers.

Best practice: Let data guide you.

Step-by-step:

1. DON'T enable time restrictions yet
2. Run your Offer for 1-2 weeks to collect baseline data
3. Check the Click-to-Conversion Time Report
4. Look for patterns:
   • If you see many conversions <5 seconds → Set minimum to 10-15 seconds
   • If 80% convert within 30 days → Set maximum to 30 days
   • If you see a spike at a specific time (e.g., many at 2 seconds) → Investigate for fraud
5. Enable windows based on your actual data
6. Monitor weekly and adjust as needed

These are separate settings that serve different purposes:

Session Duration (Unique Session Identifier):

• Purpose: Deduplicates clicks from the same user
• Typical setting: 24 hours
• What it does: If the same user clicks twice within 24 hours, only the first click counts
• Found in: Offer → Tracking → Session Settings

Attribution Window (Click-to-Conversion Time):

• Purpose: How long a click is eligible for commission
• Typical setting: 30-90 days maximum
• What it does: Controls how long after a click a conversion can be attributed
• Found in: Offer → Attribution → Click-to-Conversion Time

Example: User clicks on Day 0 (session lasts 24 hours), clicks again on Day 1 (new session because >24 hours), converts on Day 15 → Attributes to Day 1 click (most recent session).

No. Everflow does NOT waterfall attribution.

What happens: If a conversion is rejected due to time window restrictions, it is simply rejected. End of story. No automatic re-attribution occurs.

Why people think this: Some platforms (like Amazon Associates) have multi-day attribution windows where the most recent click within the window gets credit. Everflow works differently - it attributes to the first eligible click, and if that click is rejected, there's no fallback.

If you want waterfall behavior: You would need to implement custom logic using the API to manually find and attribute to alternate clicks, but this is not a built-in feature.