Un guide pratique de Safari bloque-t-il Google Analytics

Ce guide explique Safari bloque-t-il Google Analytics de manière pratique, avec un accent sur les décisions d'analytics respectueuses de la vie privée.

Safari ne « bloque pas Google Analytics » dans toutes les configurations. Une requête GA4 de base peut encore se déclencher si l’utilisateur l’autorise et qu’aucun content blocker n’intervient. Ce que Safari fait, c’est affaiblir les identifiants dont dépendent l’analytics et la publicité fondées sur les cookies.

Intelligent Tracking Prevention d’Apple bloque les cookies tiers et limite le stockage modifiable par script dans les contextes liés au suivi. WebKit documente une limite de 7 jours sur le stockage modifiable par script après absence d’interaction utilisateur, une limite de 24 heures pour certains cas de link-decoration et des défenses contre le CNAME cloaking (prévention du suivi WebKit). Des recommandations WebKit antérieures expliquaient aussi que les cookies persistants créés via document.cookie étaient limités à sept jours (ITP 2.1).

Ne simplifiez pas cela en « Safari supprime tous les cookies first-party après 7 jours ». Les cookies first-party définis par le serveur pour une fonctionnalité ordinaire du site ne sont pas la même chose que le stockage modifiable par script utilisé par des trackers. Le point analytics important est que les identifiants définis ou rafraîchis via du code de suivi client-side sont moins durables dans Safari que beaucoup de rapports marketing ne le supposent.

Ce que cela signifie pour Google Analytics

Si Google Analytics utilise des cookies first-party pour reconnaître les visiteurs de retour, les restrictions de Safari peuvent raccourcir la durée pendant laquelle cette reconnaissance fonctionne. Si des fonctionnalités publicitaires ou de suivi cross-site dépendent de contextes tiers, Safari est beaucoup plus restrictif. Les utilisateurs peuvent aussi utiliser des content blockers qui bloquent entièrement les scripts analytics.

Le résultat n’est pas toujours zéro donnée. C’est une donnée dégradée :

• Les visiteurs de retour peuvent apparaître comme de nouveaux visiteurs.
• Les fenêtres d’attribution peuvent se raccourcir.
• La mesure publicitaire cross-site devient plus faible.
• Les parcours utilisateur se fragmentent.
• Le trafic Safari peut paraître différent du trafic Chrome.

Pourquoi cela compte

Safari est particulièrement important sur iOS. Hors UE, les navigateurs iOS dépendent encore largement de WebKit selon les règles de plateforme d’Apple. Dans l’UE, Apple permet des moteurs de navigateur alternatifs pour les apps de navigateur et in-app browsers éligibles sous des entitlements spécifiques sur les versions iOS et iPadOS prises en charge (moteurs de navigateur alternatifs Apple). Cette nuance compte pour les futurs tests, mais aujourd’hui vous devez encore traiter le comportement iOS Safari/WebKit comme un environnement analytics majeur.

La direction plus large d’Apple en matière de confidentialité

Safari n’est qu’une partie de la posture confidentialité d’Apple. App Tracking Transparency exige une permission pour le suivi cross-app. Mail Privacy Protection affecte le suivi des ouvertures email. Private Relay peut masquer l’information IP pour certains utilisateurs iCloud. Les règles de confidentialité de l’App Store d’Apple restreignent aussi le fingerprinting et exigent la divulgation des pratiques de données (Apple User Privacy and Data Use).

La direction est claire : moins de suivi silencieux, plus de contrôle utilisateur et moins d’identifiants durables.

Comment adapter l’analytics

Utilisez une analytics qui n’a pas besoin de cookies longue durée pour produire des rapports utiles. Une configuration privacy-first devrait :

• Éviter les cookies tiers.
• Éviter le fingerprinting.
• Éviter le stockage de l’IP complète.
• Utiliser les UTMs pour l’attribution de campagnes.
• Suivre les conversions comme événements first-party.
• Comparer les tendances par navigateur pour rendre les lacunes visibles.
• Garder les payloads d’événements exempts de données personnelles.

Ce qu’il ne faut pas faire

Ne répondez pas aux restrictions Safari en fingerprintant les utilisateurs. Le fingerprinting est difficile à contrôler pour les utilisateurs et peut créer un risque de confidentialité plus grand que les cookies. Ne cachez pas non plus le suivi derrière du forwarding server-side ; si les mêmes données personnelles sont envoyées à des plateformes publicitaires depuis votre serveur, le problème de confidentialité reste.

Les protections de Safari sont un signal sur l’avenir du web. L’analytics qui ne fonctionne qu’en préservant les identifiants contre la résistance des utilisateurs et des navigateurs est fragile. L’analytics qui mesure le comportement agrégé sans suivre les personnes est beaucoup plus résiliente.

Comment diagnostiquer les lacunes Safari

Segmentez les rapports par navigateur et appareil. Si Safari a des comptes de nouveaux utilisateurs anormalement élevés, des fenêtres d’attribution plus courtes ou des taux de visiteurs de retour plus faibles, les limites de stockage peuvent faire partie de l’explication. Testez ensuite avec Web Inspector et un profil Safari propre. Observez cookies, local storage, blocage de requêtes et timing de consentement.

Ajustement de reporting

Ne « corrigez » pas les chiffres Safari en inventant des remplacements précis. Étiquetez plutôt la limitation et utilisez des métriques directionnelles : conversions par landing page, tendances de campagnes et résultats confirmés par le serveur. Les dirigeants peuvent prendre de bonnes décisions avec des données honnêtes et imparfaites. Ils prennent de moins bonnes décisions avec une certitude surmodélisée.

Checklist de test Safari

Testez Safari comme son propre environnement, pas comme « Chrome avec une autre icône ». Utilisez un profil Safari propre, désactivez les extensions pour le test de référence et ouvrez Web Inspector. Visitez une landing page avec UTMs, parcourez un flux de conversion et inspectez Storage, Cookies, Local Storage et Network. Notez quels identifiants sont créés, combien de temps ils persistent et si les requêtes se déclenchent avant consentement.

Répétez le même flux dans iOS Safari si le trafic mobile compte. Testez aussi les principaux navigateurs iOS importants pour votre audience, surtout dans l’UE à mesure que le support de moteurs alternatifs évolue. Une QA uniquement desktop peut manquer des différences de stockage, redirection et timing de consentement qui affectent les visiteurs mobiles.

Pour le reporting analytics, créez des vues de sanity propres au navigateur :

• Visites Safari par landing page.
• Conversions Safari par source et campagne.
• Part nouveaux versus visiteurs de retour, si votre outil le prend en charge sans identifiants intrusifs.
• Fenêtres d’attribution par navigateur.
• Acceptation et refus du consentement par navigateur.

Si Safari sous-rapporte les visiteurs de retour, ne le « réparez » pas avec du fingerprinting. Le W3C TAG a décrit le suivi non sanctionné comme nocif parce qu’il mine le choix et le contrôle utilisateur (constat W3C TAG). Une réponse privacy-first consiste à concevoir des métriques qui survivent sans identité persistante : taux de conversion au niveau campagne, performance des landing pages, résultats confirmés par le serveur et tendances d’engagement contenu.

Vérifiez aussi le traitement des query strings. Les protections de confidentialité Safari et les outils utilisateur peuvent supprimer certains paramètres de suivi, mais les UTMs qui restent doivent être capturés et sanitizés rapidement. Stockez des labels de campagne, pas des URL complètes avec des valeurs personnelles ou sensibles. Cela donne aux marketeurs assez d’attribution tout en respectant la direction que les fournisseurs de navigateurs prennent clairement.

Checklist d’analytics Safari

Lorsque vous diagnostiquez les différences Safari, notez :

• Si les identifiants sont des cookies server-set, document.cookie, localStorage ou un autre stockage modifiable par script.
• Si la link decoration ou les redirections créent des fenêtres de stockage plus courtes.
• Si les requêtes se déclenchent avant consentement, après refus et après acceptation.
• Si iOS, macOS Safari et les navigateurs à moteur alternatif pertinents en UE se comportent différemment.
• Si les conversions backend contredisent les visiteurs de retour ou l’attribution rapportés par le navigateur.

Présentez Safari comme un environnement de mesure connu, pas comme une erreur à « corriger » avec du fingerprinting.