Ordonnancement des événements GA4 avec les champs batch

Comprendre l’ordre dans lequel les événements se sont produits au sein d’une session est essentiel pour l’analyse de séquence : progression dans un funnel, analyse des parcours, calculs de temps-jusqu’à-action. Le défi dans les exports GA4 BigQuery est que event_timestamp seul ne garantit pas un ordonnancement correct. Plusieurs événements peuvent partager le même timestamp en microsecondes, et l’export ne préserve pas l’ordre dans lequel ils ont été déclenchés sur le device.

Cela a des conséquences pratiques. Un événement page_view et un événement scroll sur la même page peuvent partager des timestamps identiques. Un add_to_cart et un view_item peuvent se déclencher dans la même milliseconde lors d’une interaction rapide de l’utilisateur. Si votre séquencement d’événements repose uniquement sur le timestamp, les égalités se résolvent arbitrairement, et votre analyse de séquence produit des résultats peu fiables.

Les trois champs batch

GA4 fournit trois champs au niveau racine du schéma d’export spécifiquement pour résoudre l’ambiguïté d’ordonnancement :

Ces champs forment une hiérarchie. batch_page_id est le plus grossier — il vous indique à quelle page appartient l’événement. batch_ordering_id séquence les requêtes réseau au sein d’une page. batch_event_index ordonne les événements au sein d’une seule requête réseau.

Combinés, ils fournissent la séquence exacte des événements tels qu’ils se sont produits sur le device de l’utilisateur, résolvant les égalités de timestamp de manière déterministe.

Le pattern ORDER BY composé

Utilisez les trois champs batch comme bris d’égalité après event_timestamp dans les clauses ORDER BY de vos fonctions fenêtre :

ROW_NUMBER() OVER (
  PARTITION BY session_key
  ORDER BY event_timestamp, batch_page_id, batch_ordering_id, batch_event_index
) AS event__number_in_session

La logique d’ordonnancement fonctionne en couches :

1. event_timestamp fournit l’ordonnancement chronologique grossier
2. batch_page_id sépare les événements par page lorsque les timestamps correspondent
3. batch_ordering_id sépare les requêtes réseau au sein d’une page
4. batch_event_index fournit l’ordonnancement final au sein du batch

Cet ORDER BY composé doit être utilisé de manière cohérente dans toutes les fonctions fenêtre de votre modèle sessionisé. Si vous définissez une fenêtre nommée, incluez les quatre champs d’ordonnancement :

WINDOW w_ordered AS (
  PARTITION BY session_key
  ORDER BY event_timestamp, batch_page_id, batch_ordering_id, batch_event_index
)

Référencez ensuite w_ordered partout où un ordonnancement déterministe est important.

Colonnes positionnelles dérivées

Avec un ordonnancement des événements fiable établi, vous pouvez dériver des colonnes positionnelles utiles pour l’analyse en aval :

Le numéro d’événement dans la session donne à chaque événement une position séquentielle :

ROW_NUMBER() OVER w_ordered AS event__number_in_session

Les flags de début et de fin de session identifient les événements d’entrée et de sortie :

-- Après avoir calculé event__number_in_session et session__events
event__number_in_session = 1 AS event__is_session_start,
event__number_in_session = session__events AS event__is_session_end

Où session__events provient de :

COUNT(*) OVER (PARTITION BY session_key) AS session__events

Ces flags permettent l’analyse des entrées et sorties sans agrégation. Filtrez sur event__is_session_start = TRUE pour l’analyse des pages d’entrée, ou event__is_session_end = TRUE pour les pages de sortie. Pas de GROUP BY, pas de sous-requête, juste une clause WHERE sur la table d’événements enrichie.

Le temps écoulé depuis le début de session permet l’analyse de la cadence :

(event_timestamp - MIN(event_timestamp) OVER (PARTITION BY session_key)) / 1000000
  AS event__seconds_since_session_start

Cela répond à « combien de temps après l’atterrissage les utilisateurs achètent-ils généralement ? » directement depuis la table sessionisée au grain événement, sans jointures ni CTEs supplémentaires.

Quand les champs batch sont nuls

Les champs batch ne sont pas toujours renseignés. Les événements de versions SDK plus anciennes, les hits Measurement Protocol et certains cas limites peuvent avoir des valeurs nulles pour un ou plusieurs champs batch. Votre ORDER BY gère cela correctement — les nulls se trient à une position cohérente (en premier par défaut dans BigQuery), donc l’ordonnancement reste déterministe même s’il n’est pas parfaitement précis pour ces événements.

Si les champs batch nuls sont fréquents dans vos données, envisagez d’ajouter NULLS LAST à votre ORDER BY :

ORDER BY
  event_timestamp,
  batch_page_id NULLS LAST,
  batch_ordering_id NULLS LAST,
  batch_event_index NULLS LAST

Cela garantit que les événements avec des métadonnées batch se trient avant ceux qui n’en ont pas, ce qui est généralement le comportement correct car les événements avec des champs batch proviennent du SDK web ou app standard.

Impact pratique

La différence entre un ordonnancement basé uniquement sur le timestamp et un ordonnancement avec les champs batch est la plus visible dans :

• L’analyse de funnel : Où l’ordre des étapes détermine la complétion du funnel. Un utilisateur qui a consulté un produit puis ajouté au panier est différent de celui qui a ajouté au panier avant de consulter (ce qui suggère un lien direct ou un article sauvegardé).
• La modélisation d’attribution : Où le premier événement dans une session détermine la page d’entrée et la source de trafic. Obtenir le mauvais « premier » événement signifie une mauvaise attribution.
• L’analyse de parcours : Où les séquences d’événements courantes sont identifiées. Les égalités de timestamp qui se résolvent de manière incohérente produisent des parcours bruités.

Pour les tableaux de bord affichant des métriques agrégées (comptages de sessions, conversions totales), l’ordonnancement par champs batch change rarement les chiffres. Son impact est concentré dans l’analyse dépendante des séquences.