Fonctionnement de l'environnement d'exécution Optimize

Découvrez ce qui se passe dans le navigateur de vos visiteurs et la manière dont les modifications sont appliquées.

Chaque fois qu'un visiteur accède à votre site, Optimize s'exécute en trois étapes, qui sont décrites ci-dessous.

Au sommaire de cet article :

Téléchargement synchrone et asynchrone

L'installation synchrone est la méthode la plus simple et garantit des performances optimales pour réaliser vos expériences. Toutefois, Optimize peut également fonctionner de manière asynchrone. C'est un bon point, car ainsi il n'a aucune incidence sur le bon fonctionnement de votre site. Le conteneur Optimize est téléchargé parallèlement aux autres scripts et ressources de votre page. Il ne les bloque pas : les scripts téléchargés avant le conteneur sont exécutés sans délai.

Gardez toutefois à l'esprit qu'Optimize modifie le contenu de votre page. Il est donc important de l'exécuter en priorité.

Pour ce faire, nous vous recommandons de positionner le code d'installation d'Optimize en haut de la section <HEAD> pour qu'il s'exécute dès que possible, sans être bloqué par les autres scripts et bibliothèques de votre page.

Si vous ne positionnez pas l'extrait Optimize au bon endroit, votre contenu pourrait clignoter ou être occulté trop longtemps, et le conteneur risquerait d'atteindre son délai d'expiration (si vous utilisez l'extrait anti-clignotement).

Extrait anti-clignotement

Lorsqu'un code JavaScript modifie une page HTML, il arrive fréquemment que les visiteurs constatent un clignotement : la version d'origine de la page s'affiche brièvement avant d'être modifiée.

Avec un outil comme Optimize, vos visiteurs pourraient s'interroger sur les raisons de ce comportement, ou même se rendre compte qu'ils font partie d'un test, ce qui aurait des conséquences sur votre site et sur les résultats. C'est la raison pour laquelle Optimize propose différents mécanismes permettant d'éviter ce problème.

L'outil essentiel pour éviter ce type d'incident est l'extrait anti-clignotement, nécessaire en raison de la nature asynchrone d'Optimize.

Contrairement à un script synchrone, qui empêche le navigateur d'analyser et d'afficher la page (votre site peut même ne pas se charger du tout), un script asynchrone peut s'exécuter à tout moment, même une fois la page visible. Un script asynchrone n'a donc jamais de conséquences catastrophiques sur votre site (p. ex. bloquer son chargement), mais son exécution peut provoquer un clignotement.

L'extrait anti-clignotement masque temporairement votre page Web jusqu'à ce que le conteneur Optimize ait eu le temps de se télécharger. Il n'y a pas de perte de performances sur une page Web standard si l'extrait anti-clignotement est correctement installé, car le conteneur Optimize est téléchargé parallèlement aux autres scripts et ressources de la page qui sont susceptibles de bloquer son affichage.

L'extrait anti-clignotement n'est pas le seul mécanisme auquel Optimize a recours pour éviter le clignotement. En effet, pour qu'Optimize puisse procéder aux modifications, l'extrait doit normalement se terminer avant que la page ne soit disponible pour le navigateur.

Notez que le délai avant expiration de l'extrait anti-clignotement ne correspond pas à la surcharge qu'Optimize ajoute à votre page. Il s'agit simplement du délai d'attente maximal. En outre, la valeur de délai d'expiration recommandée ne concerne pas les performances de votre site ou d'Optimize, mais principalement la vitesse du réseau de vos visiteurs (par exemple, en cas de mauvaise réception du signal, etc.).

Si le conteneur Optimize n'est pas téléchargé avec les autres ressources de la page et exécuté sur l'appareil du visiteur avant la fin du délai d'expiration, l'occultation de la page prend fin. Dans ce cas, tous les tests Optimize qui pourraient s'appliquer plus tard sont abandonnés. La visite est exclue du trafic de test.

Une fois le téléchargement du conteneur Optimize terminé, l'occultation de la page prend fin. Le conteneur évalue les règles de test et s'assure ensuite que seuls les éléments faisant partie de la variante sélectionnée restent masqués. Cela peut se produire même si ces éléments ne figurent pas encore sur la page.

Page-hiding-snippet-flow-diagram

Évaluation des règles de ciblage

Une fois téléchargé, le conteneur Optimize évalue les règles de ciblage de tous les tests devant être activés au chargement de la page (option par défaut). Les autres tests seront déclenchés en fonction des événements d'activation définis.

Remarque : La page de modèle de test utilisée pour le lancement de l'éditeur Optimize est initialement définie comme règle de ciblage par défaut, mais n'entre pas en ligne de compte pour le ciblage. Pour savoir exactement quelles règles s'appliquent à un test, vous devez consulter l'onglet de ciblage sur la page des détails du test.

Une variante est attribuée à chaque visiteur qui consulte une page pour la première fois après le début du test (même si le visiteur a déjà consulté la page avant le début du test). Chaque variante est attribuée de manière aléatoire aux différents ID clients Google Analytics selon sa valeur de pondération. Le visiteur continue d'être lié à la même variante jusqu'à la fin du test, et les actions qu'il réalise par la suite (à savoir les objectifs) sont attribuées à cette variante.

L'attribution de la variante est enregistrée dans un cookie propriétaire dédié (_gaexp) qui est utilisé lors des futures visites de l'utilisateur, afin de lui offrir une expérience cohérente. Cela ne signifie pas nécessairement que la variante s'affichera lors des visites suivantes. Les règles sont réévaluées chaque fois, mais si elles correspondent, l'utilisateur voit la même variante. Sachez toutefois que les conversions de cette page ou de toute autre page seront attribuées à cette variante, quelles que soient les règles.

Si un visiteur est impliqué dans plusieurs tests en cours (sur n'importe quelle page), ces attributions sont concaténées dans le même cookie. En raison des limites du navigateur concernant la taille des cookies, il existe un nombre maximal de tests simultanés auxquels un utilisateur peut être associé. Lorsque le cookie d'un visiteur dépasse cette limite, il est exclu du trafic de test et ne voit pas de variantes de tests supplémentaires. Lorsqu'un test est terminé, les attributions de variantes sont supprimées, et le visiteur peut être ajouté à d'autres tests.

Une fois qu'un visiteur a été attribué à un test, l'environnement d'exécution veille à ce que Google Analytics assure le suivi des informations nécessaires sur les variantes. Pour les tests activés avec la configuration par défaut "Chargement de page" (et qui n'utilisent pas l'activation personnalisée), l'attribution des variantes a lieu avant l'appel de page vue à Google Analytics, et le suivi du test est effectué à l'aide de cet appel. Dans les autres cas (ou si vous n'avez pas respecté l'installation recommandée d'Optimize), un appel de données supplémentaire à Google Analytics sera exécuté pour assurer le suivi du test.

La modification des valeurs de pondération des tests ne permet pas d'attribuer des visiteurs. Même si vous définissez une valeur de pondération de zéro pour une variante, celle-ci peut encore enregistrer du trafic de la part des visiteurs qui lui ont été attribués avant votre modification.

Les tests sont indépendants les uns des autres. Une seule visite peut participer à plusieurs tests. Vous devez donc éviter toute conséquence indésirable. Ainsi, même si vous pouvez tout à fait exécuter plusieurs tests sur une même page, vous devez veiller à ce que chacun d'eux soit lancé dans une zone distincte afin de ne pas influencer les résultats (par exemple, si la variante d'un test favorise la variante d'un autre test).

Remarque : Les variantes Optimize sont appliquées "au mieux". Si certains des sélecteurs CSS de vos variantes n'existent pas ou si vos modifications JavaScript comportent des exceptions, la visite est quand même considérée comme faisant partie de la variante du test.

Enfin, certaines de vos règles de ciblage peuvent être évaluées côté serveur. Dans ce cas, le test est complètement supprimé du conteneur téléchargé.

Targeting rule evaluation flow diagram

Application des variantes A/B et TMV sélectionnées

Une fois que le conteneur a choisi ses variantes, il tente de les appliquer. Une variante se définit comme une liste d'opérations de modification (indiquées dans l'éditeur Optimize) qui sont généralement appliquées dans l'ordre (les optimisations s'appliquent en l'absence de conflits).

Chaque modification cible un sélecteur CSS qui peut correspondre à un ou plusieurs éléments. Si une modification cible plusieurs éléments, l'éditeur le détecte et Optimize en tient compte.

Souvent, l'élément concerné par la modification n'est pas encore disponible sur la page au moment où Optimize est exécuté. Dans ce cas, Optimize ajoute une règle CSS nécessaire et interrompt temporairement l'exécution de la liste des modifications pour que cet élément reste masqué jusqu'à ce qu'il soit disponible.

Dès que cet élément cible est disponible, Optimize applique la modification, supprime la règle CSS d'occultation, puis tente d'appliquer la modification suivante de la liste en utilisant le même processus.

Une fois que la page est prête dans le navigateur (après l'événement DOMContentElement), Optimize tente une dernière fois d'appliquer les modifications restantes. Si l'élément concerné par une modification est introuvable à ce stade, Optimize l'ignore simplement et passe à la règle suivante.

Remarque : Les modifications de style sont généralement apportées via des règles CSS. Elles ne sont donc pas soumises au processus ci-dessus, mais appliquées immédiatement dès le chargement d'Optimize. Aucune autre opération d'occultation n'est alors nécessaire.

Les modifications JavaScript sont également associées à un sélecteur CSS cible. Elles sont exécutées une fois que l'élément désigné par le sélecteur est disponible dans le navigateur.

Dans Optimize, nous vous déconseillons d'intégrer une variante complète dans une seule modification JavaScript (par exemple, avec jQuery) au niveau de la section <BODY>, car votre code risque d'être exécuté plus tard que prévu. Essayez de limiter le sélecteur cible du code JavaScript aux seuls éléments que vous souhaitez modifier, ou à l'élément de conteneur parent le plus petit possible.

Enfin, une modification peut être associée à un sélecteur CSS qui cible plusieurs éléments susceptibles d'apparaître sur la page à différents moments. (Dans l'éditeur Optimize, vous pouvez sélectionner plusieurs éléments avec la combinaison MAJ + clic.) Optimize les modifie à mesure qu'ils apparaissent, mais ne supprime l'occultation qu'à la fin, pour tous les éléments à la fois.

Application of variants flow diagram

Si vous utilisez des événements personnalisés pour activer votre test, les règles de ciblage ne sont pas évaluées qu'une seule fois lors du chargement de la page, mais chaque fois que vous envoyez un événement d'activation. La première fois que les règles sont mises en correspondance, une variante est attribuée au visiteur et un appel à Google Analytics (généralement un appel de données) est émis pour assurer le suivi du test. Les modifications apportées à la variante sont également appliquées.

Cette opération ne met pas fin à la tâche de l'environnement d'exécution, comme c'est le cas lors de l'activation au chargement de page (option par défaut). En règle générale, vous devez envoyer d'autres événements d'activation, chaque fois qu'il y a un changement important concernant l'état de la page (par exemple, URL ou arborescence DOM). Dans ce cas, deux cas de figure peuvent se présenter :

  • Les règles de ciblage sont respectées et la variante est "réactivée" : l'environnement d'exécution tient compte des modifications apportées à votre variante, mais ne les applique qu'aux nouveaux éléments qui n'étaient pas disponibles lors de l'exécution précédente.

  • Les règles de ciblage ne sont pas respectées et la variante est "désactivée" : les modifications sont annulées et les éléments retrouvent l'état auquel ils étaient associés avant l'application des changements. Pour chaque événement, toutes les désactivations ont lieu avant les activations. La page revient ainsi à son état d'origine afin d'être prête à appliquer correctement le nouveau test. Notez toutefois que les modifications JavaScript ne peuvent pas être rétablies automatiquement.

Ressources associées

Ces informations vous-ont elles été utiles ?
Comment pouvons-nous l'améliorer ?
Recherche
Effacer la recherche
Fermer le champ de recherche
Applications Google
Menu principal
Rechercher dans le centre d'aide
true
101337
false