0. Contexte
Avec la sortie d’iOS 26 à la fin de l’été 2025, de nombreuses équipes analytics ont constaté des comportements inattendus dans leurs outils de tracking, en particulier sur Safari iOS.
Sans annoncer de rupture majeure, Apple a continué à renforcer sa stratégie de protection de la vie privée, rendant la protection contre le tracking plus stricte notamment avec l’activation automatique de leur Advanced Finger Printing sur Safari 26 ainsi que son renforcement de restrictions.
Dans ce contexte, certaines implémentations analytics — pourtant fonctionnelles sur desktop car Safari 26 n’est pas obligatoirement présent — se sont mises à perdre des informations d’attribution sur iOS puisque Safari 26 y est automatiquement embarqué dans la MàJ iOS 26. Des paramètres tels que : campagnes, mediums, ou même URL précédente, ne sont alors plus accessibles bien que ces données restaient visibles dans l’URL ou accessibles via JavaScript.
Cet impact est particulièrement ressenti sur les sites en Single Page Application, où le timing d’exécution des scripts et la détection de la landing page deviennent critiques
De notre côté, nous nous sommes rendu compte de l’impact notable concernant Piano Analytics et son attribution après avoir remarqué plusieurs cas pour lesquels, depuis le mois d’Août 2025 le Direct Trafic explose 📈, tandis que le SEA et le SEO sont en chute libre 📉
Dans cet article, nous allons vous expliquer comment :
- Identifier si l’évolution de votre attribution est concernée par ce cas iOS 26 ?
- Si elle l’est, comment faire pour contourner ce problème et retrouver des données fiables ?
1. Identification typique
Ce qui nous a permis d’identifier ce problème d’attribution lié à iOS 26+ aura finalement été assez logique et simple : voir un changement important sur les sources, principalement sur iOS ☝️🤓
1.1 Premiers constats
Pour plus de détails, le cas d’usage a d’abord été établi lorsque l’on a constaté une augmentation constante et linéaire sur le Direct et une baisse toute aussi constante et linéaire sur le SEO à partir de Septembre 2025 :
En regardant de manière très macro on peut simplement se dire que le Direct performe plus notamment parce que la baisse du SEA ne parait pas si importante ou que le SEO n’est plus si optimisé.
Cependant, si on cherche à isoler le type de trafic concerné on arrive à quelque chose de bien plus parlant en ciblant iOS :
Dans ce contexte propre à iOS on voit que le phénomène est beaucoup plus marqué, le SEA/SEO chutent complètement, tandis que le trafic Direct lui, fait la même remontada que les CAVS de LeBron en final NBA 2016 🏀🏆, pour se retrouver avec 3x plus de visites que les mois précédents
1.2 Analyses complémentaires
Après ces premiers constats, nous avons tout de même souhaité reproduire ce phénomène, du moins essayer, pour mieux comprendre ce qu’il se passe, comment ? Pourquoi ? L’idée étant évidemment de résoudre le problème le plus efficacement possible.
Pour cela j’ai dû me munir de :
- 📱Un iPhone évidemment
- 🤖Un sniffer de requêtes, codé spécialement pour l’occasion (je rentabilise le temps que j’ai passé à créer mon “Analytics Logger”)
- 🧠 Mon esprit de déduction
Plus sérieusement, j’ai pour le coup réellement créé un logiciel en local me permettant de capturer les requêtes Piano sortant de mon iPhone, qu’elles soient en provenance d’une app ou d’un site web et à destination de Piano ou sGTM.
Le but étant de voir à quoi ressemblent les requêtes sortantes pour mieux comprendre pourquoi j’ai autant de Direct Traffic.
Avec tous ces éléments, j’ai pu faire plusieurs constats après avoir évidemment accédé au site par un lien sponsorisé :
- Aucun paramètre
src_dans mon hit malgré la bonne configuration de la collecte Piano Analytics - Des
UTMsbien présents dans l’URL - L’exemption des paramètres
src_ - La configuration de la collecte automatique des
UTMs - Le mapping par le SDK entre
UTMs<>src_
- Le paramètre
previous_urldu hit qui est vide
- Le referrer attribué au site consulté et non à google.com
1.3 La conclusion
Les différents éléments cités précédemment, recoupés avec les informations détaillées dans le contexte auxquelles nous avons pu avoir accès via les documentations et le changelog Safari 26 d’Apple, nous avons pu en conclure que le script du SDK Piano était ciblé et considéré comme script tiers par iOS car exécuté depuis tag.aticdn.com et pas le domaine courant.
L’impact étant donc que :
- Le contexte de navigation est évalué très tôt et de façon plus restrictive
- Piano s’exécute après cette phase initiale
- Safari ne lui fournit plus un contexte de navigation exploitable pour l’attribution automatique
- Même si l’URL et les UTM restent accessibles côté navigateur, le SDK Piano n’est plus en mesure d’en déduire automatiquement les paramètres de source
- Piano attribue donc le Direct Traffic par défaut
2. Comment résoudre ce problème ?
Comme on a pu le décrire dans ce document, le problème vient grossièrement du fait que le script du SDK Piano Analytics et le site web consulté ne sont pas sur le même domaine. Pour résoudre cela, il faut donc juste que le SDK Piano Analytics soit chargé depuis le domaine de votre site.
2.1 La solution efficace et long terme : le server-side avec proxification
La solution la plus robuste selon nous pour restaurer une attribution fiable sur iOS Safari, consiste à gérer le tracking ET le SDK Piano dans un contexte server-side.
Dans cette configuration, le navigateur ne charge plus directement le SDK depuis un domaine tiers. Les requêtes analytics transitent par un endpoint first-party, hébergé sur un sous-domaine du site et contrôlé par l’infrastructure server-side.
Il faut bien penser à proxifier le SDK Piano Analytics côté serveur car l’implémentation du tracking server-side seule n’est pas suffisante
Si nous devions résumer les grandes étapes, l’idée est de suivre cette checklist :
Mettre en place un container Server-Side (via sGTM) si ce n’est pas déjà le cas
Choisir de gérer tout le setup server de votre côté ou passer par un prestataire tel que AddingWell pour la gestion du server dédié.
→ Si vous gérez tout vous-même il faudra :
Créer un sous-domaine first-party dédié au tracking
(ex.
tagging.monsite.fr, s2s.monsite.fr)Configurer un enregistrement DNS pointant vers l’infrastructure server-side
Générer ou activer un certificat HTTPS pour ce sous-domaine
S’assurer que l’endpoint est accessible en HTTPS
Configurer la proxification des requêtes Piano via le server-side
→ Si vous passez par un prestataire comme AddingWell les étapes seront grandement simplifiées et il vous suffira de :
Choisir un nom sous-domaine dédié au tracking qu’ils créeront
(ex.
tagging.monsite.fr, s2s.monsite.fr)Suivre leur tuto pour héberger la librairie SDK Piano sur ce sous-domaine
Adapter le tracking front pour envoyer les hits vers votre endpoint sGTM
Faire un test final pour s’assurer que le fichier JS est hébergé et lisible depuis
tagging.monsite.fr/pa.js (ou autre nom de fichier)En profiter pour vérifier que les hits Piano Analytics également
L’approche server-side est selon nous la plus pertinente car elle limite l’exposition aux évolutions futures de Safari, permet d’en profiter pour aligner le tracking sur ce même contexte et reste la plus durable pour sécuriser la collecte de manière globale face aux Adblockers.
2.2 La solution sans server-side : CDN first-party
Pour restaurer une attribution fiable sur iOS Safari sans passer par du server-side, le SDK Piano doit être chargé depuis un domaine first-party. Cela implique la mise en place d’un sous-domaine dédié, pointant vers un CDN via un enregistrement DNS et protégé par un certificat SSL valide.
Le CDN peut alors soit héberger le SDK, soit le proxifier vers le fournisseur analytics. Aux yeux de Safari, le script devient first-party, ce qui restaure l’accès au contexte de navigation nécessaire à l’exploitation automatique des UTM et du referrer.
Si nous devions résumer un peu les étapes l’idée est de suivre cette checklist :
Créer un enregistrement DNS sur un CDN :
cdn.monsite.fr → domaine du CDNGénérer ou activer un certificat HTTPS pour
cdn.monsite.frS’assurer que le domaine est accessible en HTTPS
Configurer le CDN pour :
Faire un reverse proxy pour
pa.js depuis tag.aticdn.comOU
Télécharger le fichier SDK Piano
Héberger et maintenir à jour le fichier sur le domaine
Charger le SDK le plus tôt possible via le domaine first-party créé
Faire un test final pour s’assurer que le fichier JS est hébergé et lisible depuis
cdn.monsite.fr/pa.js (ou autre nom de fichier)Supprimer tout chargement direct depuis
tag.aticdn.com et mettre à jour le trackingMême si cette configuration permet d’arriver à la même conclusion concernant l’attribution, nous pensons tout de même que ce n’est pas la meilleure solution que de s’acharner sur une version first-party sans server-side.
Notamment parce que la configuration server-side est tout de même une intégration reconnue et validée depuis quelques années.
3. Et GA4 dans tout ça ?
Lors de nos analyses, un point pouvait sembler paradoxal : malgré les évolutions introduites avec iOS 26 et Safari, les problèmes d’attribution que Piano Analytics rencontrait n’étaient pas visibles sur GA4.
Alors pourquoi cela direz-vous ? Eh bien au delà des différences fondamentales dans les mécanismes de collecte et d’attribution entre les deux outils, qui doivent potentiellement influer, nous n’avons pas vraiment de “preuve” établie du pourquoi GA4 ne semble pas impacté.
Cependant, au vu des raisons faisant que Piano Analytics l’est, l’explication la plus logique et probable est que la librairie GA4, contrairement à celle de Piano, n’est pas identifiée comme étant un script faisant du fingerprinting. Ainsi, il n’est pas limité par Safari et ne fait pas face au problème de Piano Analytics.
4. Conclusion
En résumé, le problème d’attribution observé sur iOS Safari depuis la sortie d’iOS 26 tient à la manière dont le navigateur évalue le contexte de navigation et considère certains scripts tiers comme non fiables pour l’attribution. Même si les UTM et le referrer restent accessibles côté navigateur, un SDK chargé depuis un domaine tiers identifié comme semble l’être celui de Piano, ne peut pas exploiter ces informations automatiquement.
→ On se retrouve donc avec une hausse artificielle du trafic Direct et une perte d’attribution sur le SEA/SEO.
Deux solutions à date permettent de résoudre ce problème :
- La mise en place d’un server-side avec proxification, qui reste la méthode la plus robuste et pérenne
- Le CDN first-party pour le script JS du SDK, efficace à court terme mais plus sensible aux évolutions futures de Safari et aux contraintes d’infrastructure
À noter tout de même qu’il est possible que ces fix de proxification de script JS restent bloqués en navigation privée car les restrictions y sont bien plus importantes. On peut le voir notament dans leur webkit dédié à la navigation privée : ‣
Grâce à notre expertise, nous sommes évidemment en mesure de vous accompagner vous ou vos équipes pour résoudre ce type de problématiques, fiabiliser les données et sécuriser l’attribution sur tous les environnements, iOS Safari compris.
5. Annexes et liens utiles
- Changelog Safari 26 : ‣
- Webkit de tracking prevention global : ‣
- Webkit lié à navigation privée Safari : ‣
- Fonctionnalités privacy Apple : ‣
Cet article vous a plus ? Nous vous invitons à le partager sur Linkedin ou vos réseaux sociaux !
Fabien Maury
Senior Consultant Tracking et Web Analytics chez unnest, Fabien est en charge de l’expertise autour de Piano Analytics et de la gestion des implémentations clients.
Après avoir passé 3 ans au support Piano Analytics où j’aidais les clients dans leur utilisation de l’outil et le respect des consignes de privacy, j'ai rejoins unnest pour relever de nouveaux défis en matière de tracking, en apportant mon expertise pour résoudre des problématiques complexes de collecte et d'analyse des données tout en respectant les meilleures pratiques de confidentialité.
Piano Analytics / GTM / Server-side / GA4 / G.Ads
✉️ Me contacter : fabien.maury@unnest.co
🎓 Références : Alterna Énergie, Pichet, O2, Mapa Assurances, Interflora…
⚒️ Outils : Piano Analytics, GTM, GA4, Google Ads, Didomi, Axeptio, Amplitude…