iGaming mobile attribution: Meta Ads, Keitaro, and AppsFlyer

The scenario

Consider an iGaming companion app promoted through several Meta campaigns. Each campaign introduces a particular experience, and the app can present an appropriate onboarding before a person chooses to visit a partner website. Different campaigns may lead to different approved partners. The product team wants to connect a confirmed partner registration back to the app acquisition journey, while keeping install attribution, partner conversion reporting, and advertising-platform reporting distinct. This reference design develops that proposed flow; it does not report a completed client project or measured campaign results.

The complete app-to-partner journey

The forward path introduces the product and an eligible partner. The return path carries a verified conversion between servers. The following is a proposed integration architecture, rather than a claim that Keitaro provides a native one-click AppsFlyer connector.

1. 01Meta ad → store → first app launch

   AppsFlyer measures the install where attribution is available. A supported campaign deep link can supply an onboarding context.

2. 02App → campaign-aware onboarding

   An approved experience key selects relevant content. An unavailable or delayed result uses the normal onboarding.

3. 03Partner selection → Keitaro click → partner website

   A backend-controlled route selects an eligible partner. A stored handoff connects the Keitaro subid to the app installation reference.

4. 04Partner registration → Keitaro postback

   The partner reports a confirmed registration using the original click reference and a stable partner event identity.

5. 05Keitaro → delivery adapter → AppsFlyer S2S

   A configured outbound postback enters a durable adapter, which resolves the installation and submits the permitted event.

6. 06AppsFlyer → configured Meta partner integration

   AppsFlyer forwards the mapped event according to sharing settings, platform requirements, and consent. It does not deliver a postback into the Facebook SDK.

Personalize from supported context, with a useful fallback

Install attribution and deferred deep linking solve different problems. Meta is a self-reporting network, so a generic OneLink or UDL assumption is insufficient: the campaign objective, platform, and supported Meta deep-link setup must be checked together. The app would accept only known experience keys, such as an introduction to a particular partner category, rather than executing a destination URL from an ad parameter.

A short decision window would keep first launch responsive. If context is unavailable, restricted, or late, the person would receive the normal onboarding and could choose a partner explicitly. A late callback would not restart a completed flow. Consent and iOS App Tracking Transparency requirements would be respected; aggregate measurement cannot be treated as a reliable person-level campaign signal.

Keep partner choice and identity mapping explicit

A versioned routing configuration would map allowed experience keys to eligible partner IDs. Availability, market eligibility, and a person’s explicit choice could affect the result. The app would identify the destination before opening it in a supported browser or approved in-app experience. Campaign variations would remain consistent with the product and its published functionality.

Before handoff, the backend would create an opaque reference linked to the app ID, AppsFlyer installation ID where available, consent state, routing version, and selected partner. When Keitaro creates the outbound click, the integration would persist its subid against that reference. The partner would receive the agreed click token, not email addresses, access tokens, or the complete mobile attribution record. A visit without a trustworthy installation mapping would remain a partner click rather than being attached to an invented install.

Treat registration as a confirmed server event

A partner callback would represent a completed registration, not a page load or a tap on a sign-up button. The agreed postback contract would preserve the Keitaro subid, map registration to a configured conversion status, and use a stable partner event ID as tid. Keitaro requires subid and status to identify a conversion. Registration and any later conversion would remain different event types.

The partner channel would be authenticated using the supported integration mechanism, with verification at an owned gateway where necessary. A configured Keitaro outbound S2S postback would notify the delivery adapter. The adapter would store the notification durably before acknowledging it, resolve the original handoff, and deduplicate by partner, event type, and event identity. A repeated Keitaro notification would not create a second delivery job.

Send the event through AppsFlyer, then inspect Meta separately

The adapter would use the correct mobile app ID and AppsFlyer installation ID to call the AppsFlyer S2S events API with an agreed registration event name and the actual event time. The S2S credential would remain on the server. Partner identifiers and registration details would be minimized; sharing would recheck current consent, including withdrawals, and apply the integration’s supported controls.

In AppsFlyer, the Meta integration would be activated and the event mapped to the agreed Meta event. Because registration happened on a partner website, the team would first confirm that reporting it through the mobile integration is supported for that app, partner relationship, and campaign. Otherwise it would stay a partner/web conversion under the appropriate measurement setup. AppsFlyer accepting an event would not by itself prove that Meta attributed it or made it eligible for optimization.

One system would own registration delivery. If a Meta SDK or another integration also reports the same action, duplicate reporting must be resolved deliberately. The adapter would use bounded retries and retain uncertain outcomes for reconciliation: a local deduplication key alone cannot guarantee exactly-once processing by an external API. Operational views would distinguish received, matched, submitted, and downstream-confirmed states.

What to validate

• Two campaigns select their configured onboarding and eligible partners; an unknown campaign receives the default.
• A partner registration resolves to the original app/installation and Keitaro click without exposing private identifiers in public links.
• Duplicate, delayed, invalid, and unmapped callbacks do not fabricate conversions.
• The AppsFlyer event and configured Meta postback are verified independently, with denied-consent and iOS-restricted paths included.
• A timeout after submission can be reconciled without assuming automatic downstream deduplication.

The tradeoff

This connects three measurement boundaries and several independent reporting rules. It requires a cooperating partner and a maintained backend mapping, rather than just SDK installation. Some journeys will remain unattributed, and platform reports may legitimately differ. Begin with one partner and one documented conversion before extending the routing matrix.