[Beta] Configure AppsFlyer Web Attribution settings

The event that triggers user acquisition. This is an important business action that defines when you consider a user truly "acquired."

Why customize 

The default first visit often represents a weak signal of user value. A user might click an ad accidentally or bounce immediately. By customizing this setting, you ensure that long-term value (LTV) is attributed to the marketing source that drove a meaningful action, not just a curiosity click.

Default: first visit (user is acquired on their first website visit)

Common alternatives by industry

How it works

If set to first visit:

• Users are acquired immediately on their first website visit.
• Attribution begins from the first visit.

If set to a custom event (e.g., sign_up):

• Users enter a "pre-acquisition period" from first visit until they perform the event.
• During pre-acquisition, events are attributed to the last non-organic touchpoint within the lookback window (last-touch attribution).
• Once the custom UA event occurs, a User Acquisition conversion is created and long-term attribution begins.

Example scenario (UA event = sign_up):

• Day 0: User visits from Facebook ad → Pre-acquisition period begins
• Day 2: User visits from Google ad → Credit switches to Google (last touch)
• Day 3: User signs up → User acquisition attributed to Google ad

Day 10: User makes purchase → Purchase attributed to Google for LTV measurement

How far back in time AppsFlyer looks to find the marketing touchpoint that drove user acquisition.

This window controls how long AppsFlyer "remembers" a marketing touchpoint. If a user visits from an ad but doesn't complete the UA event until later, this setting determines whether the ad still gets credit.

Default: 30 days

Range: 1 hour to 90 days

How it works

When a user performs the UA event (e.g., sign_up), AppsFlyer looks back within this window to find the most recent non-organic touchpoint and attributes the acquisition to that marketing source.

Example 1 (30-day lookback):

• Day 0: User clicks Facebook ad and visits website
• Day 25: User returns directly and completes sign_up event
• Result: User acquisition attributed to Facebook (within 30-day lookback window)

Example 2 (window expired):

• Day 0: User clicks Facebook ad and visits website
• Day 40: User returns directly and completes sign_up event

Result: User acquisition marked as organic (outside 30-day lookback window)

How long after a re-engagement conversion AppsFlyer continues to attribute events to that marketing touchpoint.

This setting determines how long retargeting campaigns get credit for user activity. It balances giving credit to retargeting efforts while still attributing long-term LTV back to the original acquisition source.

Default: 30 days

Range: 1 hour to 90 days

How it works

When an acquired user returns via a non-organic source (e.g., retargeting ad) and meets re-engagement criteria, a retargeting conversion is created. Events within this window receive dual attribution:

1. Primary attribution → Retargeting campaign
   • Purpose: Credit the retargeting campaign
2. Secondary attribution → Original UA source
   • Purpose: Support UA view that measures full user lifetime value (LTV) back to original acquisition

Example (within window):

• Day 0: User acquired via Facebook ad
• Day 50: User clicks email retargeting campaign and returns (retargeting conversion created)
• Day 60: User makes $100 purchase (10 days after retargeting)
• Result - Dual attribution:
  • Primary (Retargeting view): Email campaign gets credit for $100 purchase
  • Secondary (UA view): Facebook ad also tracked for $100 in user's LTV
• Reports:
  • Unified view: Shows purchase attributed to Email
  • Retargeting view: Shows purchase attributed to Email
  • UA view: Shows purchase attributed to Facebook

The minimum period of user inactivity required before a non-organic touchpoint can create a re-engagement (retargeting) conversion.

Prevent crediting retargeting campaigns when users are already actively engaged with your website. This optimizes retargeting budget by ensuring campaigns target truly inactive users.

Default: Disabled

Range: 0 (disabled) to 30 days

How it works

When disabled:

• Every non-organic touchpoint from an acquired user creates a retargeting conversion

When enabled (e.g., 7 days):

• Only creates retargeting conversion if user has been inactive for at least 7 days
• If user was active recently, visit attributed to original UA source instead

Constraint:

• Cannot exceed Inactivity Window (Re-acquisition)

Example (7-day inactivity window):

• Day 0: User acquired via Facebook ad
• Day 3: User visits organically
• Day 5: User clicks retargeting ad → No retargeting conversion (only 2 days inactive)
• Day 15: User clicks retargeting ad → Retargeting conversion created (12 days inactive)

The period of complete inactivity after which a user is marked as "churned." Churned users can be reacquired, generating a new user acquisition conversion.

This setting defines your business's churn threshold. It determines when a user is considered "lost" and eligible to be reacquired, allowing win-back campaigns to get credit for bringing back churned users.

Default: 90 days

Range: 1 to 180 days

How it works

When user is marked as churned:

• User no longer attributed to original UA source for new events
• User enters a "pre-acquisition" state (waiting to be reacquired)
• Attribution windows from original acquisition no longer apply

When churned user returns:

• If user performs the re-acquisition event → New UA conversion created
• Win-back campaign gets credit as the new acquisition source
• User is treated as a completely new acquisition from a reporting perspective

Example (90-day window):

• Day 0: User acquired via Google ad
• Day 50: Last activity
• Day 140: User churned (90 days inactive)
• Day 145: User clicks email win-back campaign

Day 146: User performs re-acquisition event → New UA conversion attributed to email campaign

The event that triggers re-acquisition for churned users. Only churned users can be reacquired.

Many user acquisition events are one-time actions (e.g., sign_up, first_purchase) that cannot happen twice. This setting allows you to define a repeatable event that signals a churned user has returned.

Default: visit (Churned users are immediately reacquired on their first return visit)

Common alternatives: sign_in or purchase

How it works

If set to a custom event (e.g., sign_in):

• Churned users must perform the specific event to be reacquired
• User can visit multiple times before reacquisition occurs
• More stringent definition of "true" reacquisition.

Example (re-acquisition event = sign_in):

• User churned after 90 days inactivity
• User clicks email win-back campaign and visits → Not yet reacquired
• A day later, the user signs in → Reacquisition conversion created, attributed to email campaign

The maximum time period after the user acquisition during which AppsFlyer attributes events to that conversion.

Default: Forever

Available options: None, 1 day, 7 days, 30 days, 60 days, 90 days, 180 days, 365 days, Forever (limited by data retention)

PRIMARY (required, automatic)

• Your main website domain (set during app creation)
• Automatically added and cannot be removed
• Exactly one primary domain per web app
• Automatic subdomain exclusion: Primary domain automatically excludes all its subdomains
  • Example: example.com automatically excludes shop.example.com, blog.example.com, etc.
• Impact of exclusion: No self-attribution

INTERNAL (optional)

• Your brand's other domains not covered by primary domain
• Add up to 99 additional domains
• Example: Different top-level domains like example.co.uk, example.in
• Impact of exclusion: No self-attribution

EXTERNAL (optional)

There are two types of external domain exclusions:

External (listed by you)

• Domains used by your website directly, but not part of your brand
• These include payment gateways, payment processing sites, authentication providers
• Add up to 99 additional domains
• Examples: auth0.com, okta.com, facebook.com, google.com
• Impact of exclusion: Visits are disregarded

External (listed by AppsFlyer)

• Domains automatically excluded by AppsFlyer:
  • PayPal
  • Stripe
  • Adyen
• The list of automatic domains cannot be edited
• Impact of exclusion: Visits are disregarded

To add domains:

1. Go to your web app settings → Attribution
2. Navigate to the Excluded Domains section
3. Click Add domain
4. Enter the domain name (e.g., custom-gateway.com)
5. Select domain type: Internal or External
6. Click Save

Important notes:

• Exclusions take effect within 1 hour
• Changes apply prospectively only (do not affect historical data)
• PayPal, Stripe, and Adyen are automatically excluded (no need to add manually)

Domain format:

• Domain name only (no protocols, paths, or ports)
• Maximum 500 characters per domain
• Protocols (https://) automatically stripped, converted to lowercase

Examples:

• example.com ✅
• shop.example.com ✅ (but unnecessary if example.com is primary domain)
• https://example.com → example.com ✅ (protocol stripped)
• example.com/path ❌ (paths not allowed)
• example.com:8080 ❌ (ports not allowed)

Limits:

• Maximum 100 domains total (including 1 PRIMARY)

1. Create new web app
   1. Go to My Apps → Add App → Select Website
2. Choose Web SDK ID 
   Reuse existing PBA dev key (recommended) to avoid code changes in your website.
3. Configure settings 
   Map PBA settings to new web attribution settings
4. Add excluded domains 
   Map PBA (Brand Bundle) excluded domains to new web attribution settings

Note: Each PBA dev key can only be assigned to ONE new web app.