[Beta] AppsFlyer Web Attribution - Overview

Once the user arrives at the landing page, AppsFlyer must capture that interaction through an integrated listener.

• Web SDK (Pixel): A client-side snippet implemented directly on the website or via Google Tag Manager (GTM).
• Server-to-Server (S2S) API: A robust server-side integration that helps bypass browser measurement prevention and ad blockers while allowing you to enrich data before it reaches AppsFlyer. The S2S integration can be done directly from a customer server or via Google Tag Manager Server Side.

After the session data is collected, the system determines whether to create a first visit record. This record serves as a preprocessing layer that captures raw user activity before the actual media source resolution and attribution. Not every session is recorded as a visit.

AppsFlyer records a visit when someone lands on your site under a new session or with recognizable source parameters, and ignores visits from excluded domains. These visit recording rules prevent double-counting of sessions.

For more information, see Visit recording.

After the data is collected and the visit is recorded, the engine evaluates it in a defined priority order. This waterfall supports both AppsFlyer-specific and market-standard parameters, so customers don’t need to change their existing attribution links during migration. The first matching signal in the waterfall is used to determine the visit origin.

• PID: The system first checks for proprietary AppsFlyer parameters.
• UTM parameters: If no PID exists, it looks for standard tags like utm_source.
• Click IDs: It then searches for network-specific IDs such as Google Click ID (gclid) or TikTok Click ID (ttclid).
• Referrer: As a final fallback, it identifies the URL the user was on immediately before arriving.

For more information, see Media source resolution.

Because most users log in within 30 minutes of a visit, AppsFlyer intentionally delays attribution decisions by that same amount of time. This delay prevents "Organic" misclassification by allowing the system to capture the CUID and correctly link returning users with expired cookies to their original source.

With the source identified and the 30-minute delay complete, the system moves to "stitching" the user's fragmented sessions into a single journey.

• CUID Stitching: If a Customer User ID (e.g. a hashed email) is captured, the engine links the session to the user's cross-device history.
• Cookie fallback: If no CUID is available, the system falls back to browser cookies, though they are less stable and device-specific.

Once the user's identity is resolved, the engine looks for the specific action that defines them as acquired. The industry standard is thefirst_visit, but this often represents a weak signal—a user might click an ad accidentally or bounce immediately. By setting a custom acquisition event, such as registration or purchase, you ensure that long-term value (LTV) is attributed to the marketing source that drove a meaningful action, not just a curiosity click.

When a user acquisition event occurs, the attribution engine searches backwards for a period equal to the Lookback window (user acquisition) to find a non-organic visit to attribute to. This setting defines the maximum time allowed between a user's visit and the completion of the UA event (Default: 30 days). If no non-organic touchpoint is found within this lookback period, the UA event is considered organic and not attributed. You can set the custom event Lookback window duration when you add your web app to AppsFlyer, see Lookback window (user acquisition).

Depending on the business model, different events can be defined as the user acquisition trigger, for example

• Registration completed event (e.g., a banking app). The acquisition event is triggered only when the sign-up flow is successfully completed.
• First order event (e.g., a food delivery app). Browsing or adding items does not count; the event fires only after a successful transaction.
• Subscription-activated event (e.g., a streaming or SaaS app). The acquisition event is recorded when the subscription is confirmed, not on trial start or app install.

For more information about setting a user acquisition event, see User acquisition settings.

After the system resolves the user’s identity but before they’re acquired, there can be a gap in the journey called the pre-acquisition period. This is relevant only if you define a custom user acquisition (UA) event instead of using the default first_visit. In this period, users can take meaningful actions, such as adding items to cart, browsing products, or engaging with content, before they complete the event that officially acquires them, such as registration or a first purchase.

AppsFlyer collects and attributes these pre-acquisition events to the marketing source and flags them in reporting as pre-acquisition. The key difference between pre-acquisition and post-acquisition attribution is the attribution window. During the pre-acquisition period, the attribution window is shorter and matches the UA event lookback window, because these events occur before the UA event that defines the user as acquired. After the custom UA event is triggered and the user is acquired, the attribution window extends to measure lifetime value (LTV), giving long-term credit to the marketing source that acquired the user.

Once a user is acquired, they may return to the site later. A re-engagement (revisit) attribution is triggered when a returning user clicks an ad and visits your site.

While re-engagement focuses on existing users, a return can also be classified as a re-acquisition if the user has been inactive for an extended period. To be eligible for re-acquisition, the user must first cross the Inactivity Window (default: 90 days), which defines the period of inactivity required to consider them "churned." Once this window has passed, if the user returns, the engine records a new user acquisition event rather than a standard revisit.

For more information, see Re-engagement settings and Re-acquisition settings

Whether the user was brought in by an initial acquisition campaign or a subsequent retargeting effort, the final goal is to measure their total value over time. Once a user is successfully attributed to a source, the system measures their ongoing activity to calculate Lifetime Value (LTV).

This measurement is governed by the Attribution Window, which is set to "Forever" by default. This ensures that every subsequent action—such as repeat purchases or subscription renewals—is credited back to the original marketing source that drove the user to the site. By capturing this long-term data, you can move beyond simple conversion counts and determine the true Return on Ad Spend (ROAS) for your campaigns.

For more information about setting the Attribution window, see the Attribution window.