Why you keep AppsFlyer
AppsFlyer already solves the hardest mobile attribution problems at the top of the funnel. It measures installs, preserves media source context, handles OneLink routing, and gives acquisition teams the partner-level reporting they expect when they ask which campaign, ad set, or network drove the install. If that part of the stack is already operational, replacing it just to get server-side event forwarding is usually the wrong move. You would be trading a strong install attribution layer for unnecessary migration risk.
TrackLayer fits better as the post-install standardization layer. Once an install exists and the app starts producing meaningful business events, the real challenge becomes naming consistency, identity continuity, value normalization, consent-aware routing, and reliable server-side delivery into platforms that care about purchases, subscriptions, qualified leads, and other downstream outcomes. AppsFlyer and TrackLayer do not need to compete for the same job. One measures mobile attribution. The other makes the conversion stream cleaner and more reusable after attribution has already happened.
Prerequisites
An AppsFlyer app with admin access, S2S postback permissions, and the relevant integrated partners already connected.
A TrackLayer workspace with a production environment ready to receive mobile app events and forward canonical conversions downstream.
Stable app identifiers such as AppsFlyer ID, customer user ID, subscription ID, order ID, or hashed email/phone so identity can survive the install-to-purchase journey.
A clear event contract for the post-install moments that matter: signup, trial start, purchase, subscription renewal, qualified lead, or other downstream optimization events.
Setup
Define the post-install event scope first
Before touching integrations, decide which in-app events should move beyond AppsFlyer reporting and into TrackLayer's canonical model. The useful set is usually small: `sign_up`, `start_trial`, `purchase`, `subscribe`, `renewal`, `lead`, and a handful of funnel qualifiers. This keeps TrackLayer focused on activation-grade conversions instead of inheriting every noisy lifecycle event from the app SDK.
Configure the AppsFlyer S2S postback
In AppsFlyer, add a server-to-server postback for the events you want to export. The postback should include AppsFlyer identifiers, event name, event timestamp, revenue fields where applicable, campaign metadata, and any first-party user ID you already trust. Send those payloads to a dedicated TrackLayer inbound endpoint so staging and production remain isolated and retries stay inspectable.
Keep OneLink in place for acquisition and deep linking
Do not replace OneLink. OneLink still owns deferred deep linking, campaign routing, and install-time context. The integration point is after attribution, not instead of it. AppsFlyer should continue resolving the click-to-install path, while TrackLayer receives the resulting post-install events with enough metadata to preserve campaign context when forwarding conversions to Meta, Google Ads, TikTok, or CRM destinations.
Map AppsFlyer events into TrackLayer canonical names
Inside TrackLayer, translate AppsFlyer event names into a smaller canonical vocabulary. For example, `af_complete_registration` becomes `sign_up`, `af_initiated_checkout` becomes `begin_checkout`, and `af_purchase` becomes `purchase`. Normalize value, currency, order IDs, subscription IDs, and user identifiers at this step so every downstream destination sees one consistent contract instead of a mobile-measurement-specific schema.
Enable forwarding to downstream platforms
Once the canonical mapping is stable, let TrackLayer forward the selected events to the destinations that need them. The important split is simple: AppsFlyer keeps install attribution and partner cost reporting, while TrackLayer handles server-side conversion delivery, retry behavior, consent-aware routing, and event deduplication for post-install events. Test with a controlled install and one known purchase before widening the event set.
Event forwarding table
The safest way to connect the systems is to treat AppsFlyer event names as input and TrackLayer canonical names as output. That preserves mobile attribution detail upstream while giving every downstream platform the same normalized event contract.
| AppsFlyer event | TrackLayer canonical | Downstream platforms |
|---|---|---|
| af_complete_registration | sign_up | Meta CAPI, Google Ads enhanced conversions, TikTok Events API |
| af_login | login | Warehouse, CRM webhook, lifecycle destinations |
| af_initiated_checkout | begin_checkout | Meta CAPI, TikTok Events API, internal analytics |
| af_purchase | purchase | Meta CAPI, Google Ads, TikTok, Klaviyo, webhooks |
| af_subscribe | subscribe | Meta CAPI, Google Ads offline conversion import, CRM |
| af_start_trial | start_trial | Meta CAPI, Google Ads, lifecycle automation |
| custom qualified_lead | lead | Meta CAPI, LinkedIn CAPI, HubSpot or Salesforce |
Cost setup
Cost reporting should stay where it already belongs. AppsFlyer is the system that imports or reconciles media cost data from ad partners, then uses that spend context in its own attribution and ROI reporting. TrackLayer should not try to replace that layer or infer cost from forwarded conversions. Its job is narrower: receive attributed post-install events, normalize them, and forward them to downstream destinations without interfering with how AppsFlyer reports spend and install efficiency.
This separation matters because it avoids metric drift. If the acquisition team wants CAC, CPI, or campaign-level install efficiency, they should still read AppsFlyer. If the growth or lifecycle team wants a stable post-install conversion stream for activation, remarketing, CRM, or measurement APIs, they should read TrackLayer and the connected destinations. The systems stay complementary instead of competing to be one imperfect source for every question.
Hybrid reporting
The cleanest operating model is to let each platform answer the question it is actually designed to answer. Use AppsFlyer for installs, re-attribution logic, OneLink performance, partner breakdowns, and attributed in-app event analysis tied to the MMP lens. Use TrackLayer for the canonical post-install log: what was received, how it was normalized, which identities were resolved, and where each conversion was forwarded.
Then use Meta, Google, TikTok, or any downstream destination for the final platform-side conversion count they accepted and used for optimization. Those counts will not perfectly mirror AppsFlyer or TrackLayer because attribution windows, match rules, privacy constraints, and reporting scopes differ. That is normal. The important discipline is knowing where to look for which answer: AppsFlyer for installs, TrackLayer for post-install event movement, and destination platforms for the final accepted conversion totals inside their own optimization systems.
Common questions
Does TrackLayer replace AppsFlyer?
No. AppsFlyer remains the mobile measurement partner for installs, media source reporting, deep links, and cost visibility. TrackLayer sits after install and standardizes how qualified post-install events are forwarded to ad platforms and other destinations.
Should every AppsFlyer event be forwarded to TrackLayer?
Usually not. Forward the events that matter for activation or revenue. Install, session, and generic engagement events often belong in AppsFlyer and product analytics, while TrackLayer should focus on conversion-grade events that downstream platforms can optimize against.
Will this change install attribution inside AppsFlyer?
No. AppsFlyer still calculates installs and post-install attribution according to its attribution windows and partner rules. TrackLayer does not interfere with that crediting logic. It only consumes the resulting event stream and forwards normalized conversions elsewhere.
What identifier should be shared between both systems?
Use the strongest stable identifiers you have. AppsFlyer ID is useful for transport continuity, but customer user ID, order ID, subscription ID, hashed email, and hashed phone usually matter more for downstream matching and deduplication.
How should I read reporting differences between dashboards?
Expect differences. AppsFlyer reports installs and attributed in-app events through its own attribution model. Meta and Google report only what they receive and accept as conversions. TrackLayer shows the canonical event log and forwarding status between those two worlds.
Related implementation guides
Mobile SKAdNetwork guide
Understand the aggregate iOS lane that sits beside MMP-driven attribution.
Read guide →Meta CAPI setup
See how canonical post-install events should be shaped for Meta delivery.
Read guide →Google Ads enhanced conversions
Compare app and server-side conversion forwarding into Google's reporting stack.
Read guide →