Fiabilité de l'événement session_start GA4

Compter les événements session_start pour mesurer le nombre de sessions produit des résultats incorrects. L’événement session_start de GA4 est suffisamment peu fiable pour que l’interface de reporting de GA4 elle-même ne l’utilise pas comme base pour les comptages de sessions.

Pourquoi session_start est peu fiable

L’événement session_start est évalué côté client, déclenché lorsqu’un événement inclut le paramètre _ss (un signal de session interne à GA4). Cette évaluation côté client crée deux modes de défaillance distincts :

Événements session_start en double au sein d’une même session. Dans certaines conditions — interruptions réseau, rechargements de page en cours de session, navigation rapide — GA4 déclenche plusieurs événements session_start pour ce qui est logiquement une seule session. Si vous comptez les événements session_start, vous surestimez les sessions.

Événements session_start manquants. Dans certaines configurations, notamment les sous-propriétés GA4, l’événement session_start peut être filtré tandis que les autres événements de session passent. Le ga_session_id se propage toujours à ces événements (la session existe donc toujours dans les données), mais il n’y a pas de session_start correspondant à compter.

Le cas des sous-propriétés est particulièrement insidieux : votre comptage de sessions depuis session_start sera systématiquement inférieur au nombre réel de sessions uniques dans les données, sans signal d’erreur évident.

L’approche correcte : compter les ID de session distincts

L’interface de GA4 utilise une approche différente — elle estime les comptages de sessions à partir d’identifiants de session uniques plutôt que depuis l’événement session_start. Faites de même dans vos requêtes BigQuery.

La clé de session est une composition de user_pseudo_id et ga_session_id :

-- Correct : compter les ID de session distincts
SELECT
  COUNT(DISTINCT CONCAT(
    user_pseudo_id,
    CAST(
      (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id')
      AS STRING
    )
  )) AS sessions
FROM `project.analytics_123456789.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260101' AND '20260131'

Cela compte chaque combinaison unique d’utilisateur et de timestamp de démarrage de session — la définition réelle d’une session — qu’un événement session_start se soit déclenché, déclenché plusieurs fois, ou ait été filtré.

Pour les modèles en production, extrayez la clé de session dans le modèle de base afin que les requêtes en aval n’aient pas besoin de répéter la logique UNNEST :

-- Dans votre modèle d'événements de base
CONCAT(
  user_pseudo_id,
  '.',
  CAST(
    (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id')
    AS STRING
  )
) AS session_key

Le comptage de sessions en aval devient alors un simple COUNT(DISTINCT session_key).

À quoi servent les événements session_start alors ?

Ils ne sont pas totalement inutiles. Les événements session_start peuvent servir de signal pour le début d’une session — filtrer sur ces événements donne commodément la page d’atterrissage, le référent et la source de trafic initiale. Mais n’utilisez jamais leur comptage comme métrique de session.

Si vous avez besoin de métriques au niveau session (première page, source de trafic d’atterrissage, heure de début de session), construisez-les avec des fonctions de fenêtrage partitionnées par session_key plutôt que de vous fier à la présence et à l’exactitude des événements session_start.

Le pattern de sessionisation à grain événement gère cela correctement : les attributs de session sont dérivés de FIRST_VALUE() OVER (PARTITION BY session_key ORDER BY event_timestamp), ce qui fonctionne que session_start existe ou non dans la partition.

Pourquoi cela compte pour la cohérence des rapports

Si vous construisez des tableaux de bord depuis BigQuery et que vos parties prenantes consultent également l’interface GA4, l’approche par ID de session distincts aligne votre méthodologie sur celle de GA4. Vous observerez toujours de petites divergences entre vos chiffres BigQuery et l’interface — elles sont architecturales et inévitables — mais vous n’introduirez pas un biais systématique supplémentaire en comptant des événements peu fiables.

Le comptage de sessions par IDs distincts est une définition auditable — « identifiants de session uniques » — qui ne dépend pas du déclenchement correct d’un seul événement.