Étiquette : Analytics

Si vous avez besoin d’être accompagné sur votre plan de taggage ou sur l’optimisation de vos comptes Analytics ,contactez-nous, nous serons ravi d’échanger et mettre en place les solutions qu’il vous faut;

Aussi, si vous voulez avancé par vous même et devenir un ninja Analytics, n’oubliez pas de travailler sur vos Entonnoirs de Conversion; Consultez notre artilce « Comment configurer les entonnoirs de conversion dans Google Analytics » : vous serez guidé étape par étape; Bonne lecture

On aimerait bien sûr éviter d’avoir à payer pour une machine inutile. Nous allons voir qu’il y a un moyen d’avoir zéro machine tout en ayant un système de scaling automatique.

Il y a cependant un pré-requis : il nous faut un moyen de savoir quand est-ce qu’il est nécessaire de scale up de nouveau.

Chez Adenlab nous utilisons une taskqueue (MRQ) pour nos tâches récurrentes. MRQ nous permet d’aiguiller nos jobs vers des worker groups spécifiques, en fonction de la queue et/ou de la tâche elle-même. Chaque worker group est lié à un ASG, nous avons donc ici une métrique claire : pour un ASG donné, avons-nous des jobs en attente ?

Avec tout ça nous pouvons utiliser la structure d’ASG suivante :

Une petite (lire: pas chère) machine qui sera toujours up (pas auto-scalée)

Un ou plusieurs ASG, sans politique d’auto-scaling

En créant un ASG sans politique d’auto-scaling, GCE nous laissera bien scale à zéro machine si nous le voulons. Sur notre petite machine nous aurons un script qui tournera toutes les 5 minutes et qui vérifiera pour chaque worker group MRQ s’il y a des jobs à traiter.

Si c’est le cas, le script créera une politique d’auto-scaling pour le worker group concerné et le fera un premier scale-up à 1 machine. L’auto-scaler pourra ajouter des machines supplémentaires si besoin, en fonction de la métrique de base configurée (dans notre cas, l’utilisation CPU).

Ecrivons une tâche MRQ pour ce script. Déjà les imports nécessaires :

from mrq.task import Task
from google.oauth2 import service_account
from googleapiclient import discovery
import time
import re

Premièrement, nous devons configurer quelques paramètres concernant GCP :

class ScaleUp(Task):
    project_name = "name of your GCP project"
    zone = "europe-west1-c" # adapt your zone here
    service_account_path = "service_account_credentials.json"
    # groups that are not concerned by this task
    groups_to_skip = ("group1",)

Ajoutez à groups_to_skip les worker groups qui ne devraient pas être auto-scalés : ajoutez au moins le groupe de la machine qui dépilera cette tâche.

Maintenant écrivons la méthode principale de notre tâche :

def run(self, params):
    credentials = service_account.Credentials               
        .from_service_account_file(
            self.service_account_path
        )
     
    self.service = discovery.build(
        "compute", 
        "v1", 
        credentials=credentials, 
        cache_discovery=False
    )
    # We need to have a way to know what we want our different
    # autoscaling policies to be.
    # We could store them in a DB and fetch them here,
    # so that it is shared with our Ansible playbooks for instance.
    # For simplicity here we'll just hardcode them here:
    self.autoscaler_configs = {
        "group2": {
            "min_replicas": 1,
            "max_replicas": 10,
            "cooldown": 180,
            "cpu_target": 0.80
        },
        "group3": {
            "min_replicas": 1,
            "max_replicas": 8,
            "cooldown": 180,
            "cpu_target": 0.90
        }
    }
    # First we need to fetch existing ASGs
    self.fetch_groups()
    # Next we want to know which groups currently have an autoscaler
    self.fetch_autoscalers()
    # Check each groups and see if we should scale them up
    self.check_groups()

Voici comment récupérer les infos sur les ASG :

def fetch_groups(self):
    self.groups = {}
    request = self.service.instanceGroupManagers() 
                          .list(
                            project=self.project,
                            zone=self.zone
                          )
    while request is not None:
       response = request.execute()
       for asg in response['items']:
           group_name = asg["baseInstanceName"]
           self.groups[group_name] = {
                "base_name": group_name,
                "name": asg["name"],
                "size": asg["targetSize"],
                "link": asg["selfLink"]
            }
       request = self.service.instanceGroupManagers() 
                             .list_next(
                               previous_request=request,
                               previous_response=response
                             )

On hydrate self.groups avec les infos des ASGs. Pour plus d’infos sur la structure des ASGs, allez voir ici.

Maintenant jetons un oeil au code que nous utiliserons pour créer un autoscaler pour un worker group donné :

def create_autoscaler(self, group):
    autoscaler_config = self.autoscaler_configs[group]
    config = {
        "target": self.groups[group]["link"],
        "name": "%s-as" % group,
        "autoscalingPolicy": {
            "minNumReplicas": autoscaler_config["min_replicas"],
            "maxNumReplicas": autoscaler_config["max_replicas"],
            "coolDownPeriodSec": autoscaler_config["cooldown"],
            "cpuUtilization": {
               "utilizationTarget": autoscaler_config["cpu_target"]
            }
        }
    }
    operation = self.service.autoscalers().insert(
        project=self.project,
        zone=self.zone,
        body=config
    )
    wait_for_operation(operation)

Vous pouvez trouver le code de wait_for_operation dans cet exemple.

La dernière chose dont nous ayons besoin est une méthode pour scale up un ASG :

def scale_up(self, group, size=1):
    if self.groups[group]["size"] > 0:
        # Already scaled up
        return
    # Make sure we have an autoscaler
    if not self.autoscalers.get(group):
       self.create_autoscaler(group)
    operation = self.service.instanceGroupManagers().resize(
        project=self.project,
        zone=self.zone,
        instanceGroupManager=self.groups[group]["name"],
        size=size
    )
    wait_for_operation(operation)

La logique finale de notre tâche est assez simple :

def check_groups(self):
    # Now we have everything we need for the actual task logic:
    for group in self.groups:
    if group in self.groups_to_skip:
        continue
    if self.should_scale_up(group):
        self.scale_up(group)

should_scale_down est la méthode qui doit contenir votre logique de scaling. Nous ne la fournissons pas ici, mais rappelez-vous que dans notre cas il s’agit de vérifier si nous avons des jobs en attente ou non.

Cette tâche est planifiée pour être exécutée toutes les 5 minutes. Cela est pratique pour notre cas d’usage car même si aucun job n’est en attente, un membre de l’équipe peut à tout moment exécuter une action qui entrainera la création d’un nouveau job.

On ne veut pas avoir à attendre trop longtemps avant que celui-ci soit démarré. Bien entendu pour toute action utilisateur qui crée des jobs et qui sont supposées obtenir une réponse rapidement, il nous faut une machine dédiée qui soit toujours up.

Dans la plupart des cas cependant il vaut mieux éviter d’avoir des tâches asynchrone pour les interactions utilisateurs qui ont besoin d’un feedback.

Nous pouvons donc maintenant scale up une machine quand on en a besoin et GCE prendra le relai s’il y en a besoin de plus. Mais nous avons aussi besoin d’un moyen de scale à zéro quand il n’y en a de nouveau plus besoin !

Pour cela nous avons une seconde tâche, exécutée toutes les 30 minutes, qui exécutera le même code que la première, à la différence qu’elle supprimera l’autoscaler et scalera à 0 machine s’il n’y a plus aucun job en attente.

Nous pouvons faire hériter notre nouvelle tâche de la précédente afin d’avoir à disposition les méthodes utiles pour communiquer avec GCP :

class ScaleDown(ScaleUp):

Nous avons aussi besoin de quelques nouvelles méthodes pour pouvoir scale down :

def delete_autoscaler(self, group):
    autoscaler = self.autoscalers[group]
    operation = self.service.autoscalers().delete(
        project=self.project,
        zone=self.zone,
        autoscaler=autoscaler["name"]
    )
    wait_for_operation(operation)
    
def scale_down(self, group):
    if self.groups[group]["size"] == 0:
        # Already scaled down
        return
    # Delete the autoscaler so that we can scale to zero machine
    if self.autoscalers.get(group):
      self.delete_autoscaler(group)
    operation = self.service.instanceGroupManagers().resize(
        project=self.project,
        zone=self.zone,
        instanceGroupManager=self.groups[group]["name"],
        size=0
    )
    wait_for_operation(operation)
    
def check_groups(self):
 
    for group in self.groups:
        if group in self.groups_to_skip:
            continue
        if self.should_scale_down(group):
            self.scale_down(group)

Quand on sait qu’il n’y a plus aucun job en attente, on supprime l’autoscaler et on scale down complètement. De nouveau, should_scale_down contient la logique de scale down à implémenter.

Le côté positif de cette approche est que nous pouvons avoir plusieurs critères de scaling. Par exemple, afin d’éviter de scale up et down plusieurs fois de suite de manière trop rapprochée, on peut également vérifier qu’un certain temps s’est écoulé sans avoir de job créé avant de scale down.

L’ensemble des sources de trafic représente 100% des points de l’attribution. Selon le modèle d’attribution utilisé, ces 100% sont attribués différemment :
Dernière interaction: c’est la dernière source de trafic entrant qui obtient 100% du crédit.

⇒ Première interaction: c’est le 1er point de contact qui obtient 100% des points.

⇒ Dernier clic non direct: les canaux d’attribution directs sont enlevés de l’équation, tous les points sont attribués au dernier clic de source indirecte.

⇒ Dernier clic sur une annonce Google Ads: 100% des points sont attribués à la dernière publicité cliquée sur Google.

⇒ Attribution linéaire: chaque canal emprunté par le visiteur jusqu’à la vente se partage les 100% à parts égales.

⇒ Dépréciation dans le temps: toutes les sources de trafic sont prises en compte, mais les dernières récoltent plus de points.

⇒ Attribution basée sur la position: les 1er et dernier points de contacts se voient attribuer 40% des points chacun. Les autres se partagent les 20% restants.

⇒ Attribution basée sur la donnée : Ce modèle d’attribution utilise les algorithmes de Google Ads et les données de performance réelles de vos campagnes pour déterminer comment les clics sur vos annonces contribuent aux conversions. Contrairement aux autres modèles, il est dynamique et personnalisé en fonction des données de votre compte.

Le système de tracking arrive tout en haut de la liste des configurations à mettre en place correctement. Sans cela, vous risquez de passer à côté de données clés sur les étapes de conversion existantes sur votre site.

Outils de vérification de votre configuration

Il existe différents outils pour vérifier votre configuration analytics et ainsi vous assurer que tout fonctionne correctement.

Tag Assistant : il est parfait pour vérifier la configuration et la résolution de problèmes détaillés au niveau de la « page ».

Tag Assistant est une extension Chrome qui peut être utilisée pour valider et diagnostiquer vos données Google Analytics page par page. Une fois que vous avez résolu un problème, vous pouvez retourner sur Tag Assistant pour vérifier si vos tags fonctionnent correctement.

Screaming Frog SEO Spider : idéal pour détecter les bugs sur le site à travers toutes les pages. Cet outil est parfait pour savoir si votre code de tracking est correctement installé sur toutes vos pages.

Il y a deux versions disponibles : une version FREE, pour les sites Web jusqu’à 500 URL et une version payante, au delà de 500 URL.

Votre code de tracking
Au minimum, vous devriez vérifier deux choses en ce qui concerne le code de tracking installé

La version du code de tracking : si vous ne l’avez pas encore fait,
assurez-vous de passer à Universal Analytics. Tag Assistant affichera la
version que vous utilisez et si vous devez migrer ou non.

**L’emplacement du code **: où placer votre code de tracking dépend si vous utilisez Google Gestionnaire de balises ou non.

Il est de plus en plus recommandé d’utiliser Google Tag Manager lors de la configuration du tracking.

Obtenir une bonne implémentation de code (en fonction de votre plan de taggage) est une étape cruciale pour obtenir des informations fiables à partir de Google Analytics.

Cela signifie que vous devez identifier l’utilisateur au fil du temps, même s’il utilise plusieurs appareils ou navigateurs. Heureusement, dans la plupart des cas, les actions telles que la réalisation d’un achat ou la souscription à un abonnement impliquent une certaine forme d’authentification. S’il est possible de suivre les mesures de rétention avec Google Analytics seul, dans la plupart des cas, vous obtiendrez des résultats bien meilleurs (et plus précis) en le combinant avec d’autres solutions.

Le tunnel de conversion ou les entonnoirs de vente sont essentiels pour comprendre les étapes que vos clients franchissent avant d’atteindre leur conversion finale et les obstacles qui les empêchent d’y parvenir.

Vous pouvez considérer chaque étape de votre entonnoir de vente comme un point de contact central que vous voulez que les gens atteignent sur le chemin de la conversion. Une fois que vous avez défini chacune de ces étapes, vous pouvez identifier les zones de friction : les endroits où les gens restent coincés, quittent ou ne poursuivent pas le processus de conversion. Lorsque vous disposez de ces informations, vous êtes en mesure d’optimiser le design de vos pages et le flux de votre site, en ajustant les bons élements pour capter plus de conversions. Et soudainement, vous savez ce qui fonctionne sur votre site Web et ce qui ne fonctionne pas – alors vous pouvez commencer à ajuster et améliorer

Optimisez vos données Analytics et votre plan de marquage avec Tag Manager