Nouvel algorithme OWOX BI pour la collecte des données de session

Le changement est constant; c'est notre réalité, et c'est parfois difficile à accepter. Mais les changements que nous souhaitons partager avec vous impressionneront tous les utilisateurs d'OWOX BI.

Vous savez peut-être déjà qu'OWOX BI a récemment changé la logique de collecte des données de session ; les nouvelles fonctionnalités sont disponibles pour tous les utilisateurs depuis le 1er mars. Dans cet article, nous vous en dirons plus sur nos nouvelles fonctionnalités et comment elles peuvent profiter à votre entreprise.

Auparavant, OWOX BI créait des tables de session dans Google BigQuery à l'aide des données de session de Google Analytics. D'une part, cette approche a assuré un ajustement complet des données entre les sources. D'autre part, une partie des données pourrait être perdue sur le chemin du site Web vers le système d'analyse et le stockage dans le cloud en raison des limitations de l'API Google Analytics Core Reporting.

Pour éviter ce problème, nous avons modifié l'algorithme de collecte des données de session. Désormais, les données de session sont formées à l'aide des données d'appel d'OWOX BI, de sorte que les limites de Google Analytics ne peuvent pas influencer le processus de création des tables de session. Grâce à ce nouvel algorithme, vous pouvez collecter des données complètes et non échantillonnées sur le comportement des utilisateurs sur votre site Web et attribuer ces données aux sessions appropriées. Voyons tous les avantages en détail.

Avant : si les utilisateurs de votre site Web génèrent plus de 200 000 sessions par jour, Google Analytics (la version gratuite) appliquera généralement un échantillonnage. Ainsi, votre projet Google BigQuery ne recevra qu'un échantillon aléatoire des sessions.

Maintenant : Les utilisateurs d'OWOX BI obtiennent des données brutes et non échantillonnées de toutes les sessions dans Google BigQuery sans aucune limitation de la valeur du trafic ou de la taille de l'entreprise.

Avant : si vous atteignez les limites de volume et de données collectées dans Google Analytics, le système ne traitera pas les données dépassant ces limites et ces données n'entreront pas dans Google BigQuery. Ces limites sont de 200 000 visites par utilisateur et par jour, 10 millions de visites par mois et 500 visites par session. De plus, Google ignore les hits d'une taille supérieure à 8 Ko.

Maintenant : Le nouvel algorithme OWOX BI n'a aucune de ces limites, et la taille maximale d'un hit est doublée à 16 Ko. Cela signifie que vous pouvez collecter des données sur toutes les actions des utilisateurs sur votre site Web.

Avant : les données de session peuvent être mises à jour avec un délai de plus de 24 heures, car ces mises à jour dépendent des informations mises à jour dans l'API Google Analytics.

Maintenant : Accéder aux sessions de formulaire du côté OWOX BI, de sorte que la collecte des tables de session ne sera jamais interrompue en raison d'un dépassement des limites ou d'un manque d'accès à Google Analytics. Les données entrent plus rapidement dans BigQuery, ce qui est très important si vous l'utilisez pour déclencher un marketing par e-mail ou mettre à jour des rapports en temps réel.

Avant : Dans Google Analytics, la source de trafic est définie par le modèle Last Non-Direct Click. Si le dernier canal de la chaîne d'action client était direct, ce canal est ignoré et remplacé par le dernier canal non direct.

Par exemple, supposons que votre client ait cherché sur Google et trouvé un produit sur votre site Web. Ils se sont souvenus de l'adresse de votre site Web et, après un certain temps, l'ont saisie directement dans le champ URL. Dans ce cas, la source de cette session serait google/organique mais pas directe/aucune. Cela exclut la possibilité de connaître la part précise du canal direct comme source de trafic pour votre site web.

Maintenant : Le nouvel algorithme OWOX BI utilise également le modèle Last Non-Direct Click pour définir la source de trafic. Mais nous avons ajouté un champ spécial trafficSource.isTrueDirect à la table de session pour vous aider à définir le trafic direct. Ce champ binaire obtiendra une valeur vraie si une session a commencé par une visite directe du site Web et une valeur fausse si la session suit une session de canal payante. Grâce à ce champ, vous pouvez évaluer la valeur réelle des chaînes payantes et leur effet sur les conversions. Dans Google Analytics, le champ isTrueDirect fonctionne différemment, car il obtient la valeur "true" lorsqu'il existe une source directe ou lorsque deux sessions ont les mêmes données sur la campagne.

Avant : Si vous avez quelques sites Web et que vous souhaitez suivre la façon dont les audiences se croisent, vous pouvez configurer la mesure inter-domaines dans Google Analytics. Mais cette solution ne fonctionne que si votre public utilise des liens croisés pour passer d'un de vos sites Web à un autre. Que se passe-t-il si vous avez besoin de suivre un utilisateur visitant les deux sites Web qui ne sont pas liés à des moments différents ? On s'en est occupé ↴

Maintenant : Nous avons ajouté un ID utilisateur OWOX aux tables de données de session. Cet identifiant d'utilisateur anonyme vous aidera à combiner des données sur les actions des utilisateurs à partir de vos sites Web, même s'ils ne sont pas directement liés. De plus, vous aurez la possibilité de regrouper les utilisateurs suivis pour séparer les audiences publicitaires et éviter de payer plusieurs fois pour le même trafic.

Avant : Si vous suivez des événements sur votre site Web à l'aide du protocole de mesure, n'oubliez pas qu'une partie de ces événements peut être perdue. Le fait est que dans Google Analytics (y compris dans la version payante, GA360), la durée maximale entre le moment du hit et l'envoi d'informations sur le hit pour le paramètre &qt n'est que de quatre heures. Si l'écart est plus long, l'événement ne sera pas attribué du tout. Par exemple, supposons que votre visiteur paie en ligne sur votre site Web. La transaction sera comptabilisée après réception d'une confirmation bancaire, même si cela prend quelques jours. Dans une telle situation, la transaction ne sera pas attribuée à la bonne session, ce qui signifie que la source qui a conduit à cette transaction ne sera pas évaluée correctement.

Si le paramètre &qt a été envoyé sans valeur, la session distincte pour l'événement sera créée automatiquement. Dans tous les cas, cela affectera la précision de vos données.

Maintenant : Dans les sessions basées sur le nouvel algorithme OWOX BI, la durée maximale du paramètre &qt est étendue à 30 jours. Cela signifie que vos événements envoyés par le protocole de mesure seront attribués à la bonne session.

Dans le nouvel algorithme OWOX BI, les tables ont la même structure que dans l'ancien. Seule la logique selon laquelle les valeurs sont définies diffère pour certains champs :

• Lors de la création d'un nouveau pipeline de streaming Google Analytics ⟶ Google BigQuery, les données de session commenceront automatiquement à être collectées à l'aide du nouvel algorithme.
• Pour modifier l'algorithme de collecte des données de session dans les flux existants, accédez aux paramètres de flux et activez la collecte de données de session .

Après cela, l'ancien algorithme deviendra indisponible.

• Avec le nouvel algorithme OWOX BI, vous n'aurez pas besoin d'une dimension personnalisée au niveau de la session dans Google Analytics. Vous pouvez supprimer cette dimension et ajouter d'autres paramètres nécessaires.​
• Vous n'aurez pas besoin de mettre à jour le code de suivi OWOX BI sur votre site Web.
• Pour activer le balisage UTM automatique par Google Ads (gclid), vous devez configurer la collecte de rapports de données brutes pour Google Ads dans BigQuery. Vous pouvez le faire en un clic grâce à l'intégration native avec Google Data Transfer.
• Si vous avez une liste d'exclusions de références dans Google Analytics, dupliquez-la dans les paramètres de flux pour OWOX BI.
  

La structure des nouvelles tables est la même que celle des anciennes tables, vous ne devez donc modifier que les noms des tables dans vos requêtes. Pour adapter vos requêtes existantes aux nouvelles tables, il suffit de changer les noms des anciennes tables session_streaming_ par les nouvelles tables owoxbi_sessions_ .

Si vous voulez savoir s'il est temps pour vous de passer au nouvel algorithme OWOX BI, répondez aux questions suivantes. Si vous avez au moins un oui, vous savez quoi faire :

• Avez-vous environ 200 000 séances par jour ? Ou pensez-vous que vous atteindrez ce nombre dans quelques mois ?
• Avez-vous déjà expérimenté l'échantillonnage?
• Avez-vous déjà créé des rapports non standard et expérimenté l'échantillonnage ?
• Avez-vous déjà atteint la limite de 500 visites par session ?
• Vous souhaitez suivre correctement le trafic direct mais vous ne souhaitez pas acheter le pack GA360 complet ?
• Vous souhaitez combiner les audiences des sites Web et analyser leur chevauchement ?
• Voulez-vous envoyer tous les hits avec transactions pendant 30 jours, et non 4 heures ?
• Est-il important pour vous d'obtenir les données des tables de session dès que possible ?

Même si ces questions ne vous semblent pas pertinentes pour le moment, il vaut mieux se préparer le plus tôt possible.

Si vous n'avez pas encore essayé OWOX BI Pipeline, nous vous invitons à faire un essai routier pendant une période d'essai gratuite :

Si vous avez des questions, posez-les dans les commentaires ci-dessous.