Calculateur de taux de rebond

Lorsque les sessions totales valent zéro, le rapport est indéfini, si bien que la tâche échoue avec invalid_input et n'est pas facturée.

Ce que mesure le taux de rebond et comment le pourcentage se forme

Le complément est tout aussi utile : engaged_sessions est le total moins les sessions d'une seule page, et non_bounce_rate est cent moins bounce_rate, de sorte que les deux taux somment toujours à cent. Un comptage de rebonds nul est un résultat légitime — chaque session a atteint au moins une seconde page — et renvoie bounce_rate zéro plutôt qu'une erreur. Cet endpoint n'ingère pas un journal brut de hits, ne classe pas l'engagement comme le ferait un produit d'analytique ultérieur (temps sur la page, événements de conversion, seuils de durée) et ne sous-échantillonne pas.

Contrat d'entrée, forme de la réponse et erreurs

Les taux sont arrondis half-up à six décimales ; les comptages de sessions sont renvoyés tels que les nombres finis que vous avez envoyés. Envoyez par POST un corps JSON avec deux nombres finis obligatoires. single_page_sessions est le comptage de rebonds dans la fenêtre de rapport ; les alias bounced_sessions, bounces et bounced pointent vers le même champ pour qu'une colonne d'entrepôt garde son nom. total_sessions est chaque session de cette même fenêtre ; les alias sessions et total sont acceptés. Chaque champ peut arriver comme nombre JSON ou comme chaîne numérique. Les champs manquants, les chaînes vides et les valeurs non finies échouent avec invalid_input en nommant le champ. Si single_page_sessions est négatif, la requête échoue. Si single_page_sessions est supérieur à total_sessions, la requête échoue parce qu'un rebond ne peut pas dépasser les visites dont il est tiré. Ces échecs ne sont pas facturés. Si la validation passe, le corps répète single_page_sessions et total_sessions, signale bounce_rate en pourcentage, engaged_sessions comme comptage complémentaire, non_bounce_rate comme cent moins bounce_rate, et une chaîne formula qui reformule l'identité. Exemple : deux cent cinquante sessions d'une seule page et mille sessions totales donnent bounce_rate vingt-cinq, engaged_sessions sept cent cinquante et non_bounce_rate soixante-quinze. Associez le JSON à votre propre grain de date si vous avez besoin d'une série hebdomadaire ; cet endpoint calcule une fenêtre à la fois et n'émet pas de graphiques.

Où un calculateur de taux de rebond justifie son existence

Les équipes croissance et produit recourent à un calculateur de taux de rebond lorsqu'une page d'atterrissage, une campagne ou une locale est accusée de laisser fuir le trafic : elles ont déjà les totaux de sessions dans une feuille et ont besoin du même pourcentage que leur produit d'analytique imprimerait, sans attendre un export d'interface. C'est une recherche et un métier différents du calcul du taux de clics ou du taux de conversion : ces rapports placent clics ou conversions au numérateur, tandis que le taux de rebond oppose les sessions d'une seule page à toutes les sessions. Une validation en échec ne consomme pas de solde. Les agences relancent les deux comptages par créatif et par appareil afin qu'un support hebdomadaire compare bounce_rate entre variantes avec une seule règle d'arrondi partagée. Les partenaires financiers qui allouent la dépense média payant selon la qualité de session extraient single_page_sessions et total_sessions de l'entrepôt et ancrent bounce_rate dans un modèle qui ne doit pas appeler une API d'analytique propriétaire. Comme l'implémentation est parse pure de niveau A, chaque appel réussi coûte le tarif de base publié $0.002 sans jetons de modèle ni réseau sortant. Gardez total_sessions strictement positif, le comptage de rebonds à l'intérieur du total de sessions, ancrez le pourcentage arrondi dans les tests, et vous obtenez un taux de rebond web reproductible pour tableaux de bord, plugins LMS et workers de bord, sans dresser un moteur d'analytique à vous.