Attribution

L'attribution répond à « d'où viennent mes installs, et comment nourrir les algorithmes des régies ». Côté SDK, quatre briques y participent, toutes dans Core, toutes pilotées par le serveur. Aucune n'expose d'API produit au studio : elles démarrent avec l'Analytics et travaillent en coulisses.

Vue d'ensemble - qui envoie quoi, à qui :

Les deux consentements, la règle d'or

La règle produit : le consentement advertising décide SI les signaux partent vers les régies ; ATT décide seulement SI l'IDFA les enrichit. Une ATT refusée n'arrête pas l'activation, elle la dégrade (match par IP au lieu d'identifiant).

Sur iOS, le pattern à une seule popup : demander ATT (AppwinCore.requestTrackingAuthorization(), ou l'API Apple directement, ou un CMP) puis relayer la réponse dans setAdvertisingConsent. Le setter est l'unique porte d'entrée, peu importe qui répond.

Brique 1 : les conversion values SKAN (iOS)

SKAdNetwork ne remonte qu'un nombre (0-63) par install : la « conversion value ». Le ConversionValueManager en est l'unique pilote - si un SDK régie est embarqué, sa gestion SKAN est désactivée, sinon les deux s'écraseraient mutuellement.

La valeur ne descend jamais : elle encode le meilleur jalon atteint par cet install. Le schéma vient du serveur (modifiable par app dans le dashboard) ; AdAttributionKit est utilisé sur iOS 17.4+, SKAdNetwork sinon. Aucun consentement requis : c'est le rail privacy d'Apple, rien ne quitte le device vers nous.

À savoir : la régie décode les postbacks avec le mapping déclaré chez elle - le studio doit répliquer notre schéma dans chaque Events Manager.

Brique 2 : le référent d'installation Play (Android)

Le Play Store garde 90 jours la chaîne referrer de l'URL qui a mené à l'installation. L'InstallReferrerCollector la demande une seule fois après le démarrage de l'Analytics, et la réponse part comme événement réservé install_referrer dans le pipeline standard - mêmes consentement, batch et retry que le reste, aucun endpoint dédié.

Une réponse définitive du store (référent obtenu, ou « pas de Play Store ») consomme l'unique tentative ; une indisponibilité passagère laisse une chance au prochain lancement.

Brique 3 : l'identité publicitaire (IDFA / GAID)

L'AdIdentityReporter remonte l'identifiant publicitaire sur un canal dédié (PUT/DELETE /sdk/v1/attribution/ad-identity) - jamais dans le flux d'événements, qui est zéro-PII par contrat. La ligne serveur qui en résulte est le marqueur de consentement que lit le worker d'activation :

Révocation du consentement = suppression de la ligne. ATT retirée dans les Réglages = bascule à NULL au prochain lancement. Device sans Google Play Services = dégradation silencieuse.

Brique 4 : l'adapter TikTok (module optionnel)

TikTok n'a pas d'API serveur GA pour l'attribution des installs : son SDK App Events est donc embarqué, mais dans un module à part (io.appwin:appwin-tiktok-events / produit SPM AppwinTikTokEvents) et sous notre gouvernance. Un studio qui ne fait pas de pub TikTok n'embarque rien.

• Zéro code studio : le module se déclare tout seul (ServiceLoader sur Android, découverte ObjC sur iOS). L'ajouter au build est toute l'intégration.
• Activation conditionnelle : l'AdSignalsHub ne le démarre que si le consentement advertising est accordé ET que TikTok est câblé dans le dashboard (le TikTok App ID et son token arrivent par la config distante, au lieu d'être codés en dur dans l'app comme le veut l'intégration officielle TikTok).
• SKAN désactivé chez lui (cf. brique 1), et chaque événement relayé porte le même event_id que notre ingest : TikTok déduplique sur 48 h si le même événement arrive un jour aussi par leur Events API.
• Limite assumée : le SDK TikTok ne se dé-initialise pas. Un retrait de consentement en cours de session coupe le relais ; au lancement suivant, il ne démarre plus du tout.

Côté serveur

La suite du voyage (réception des postbacks SKAN, worker d'activation Meta) est documentée dans la chaîne SKAN et les connecteurs régies.

Pièges connus

• swift build --sdk iphonesimulator casse sur l'ObjC du SDK TikTok : compiler et tester via xcodebuild -scheme avec une vraie destination.
• L'endpoint SKAN déclaré dans l'app est normalisé par iOS à l'eTLD+1 : les postbacks arrivent sur l'apex appwin.io, jamais sur un sous-domaine.