L'e-commerce amélioré a été conçu pour suivre certaines interactions d'un utilisateur effectuant un achat ainsi que les transactions finales qui s'y rapportent. Toutefois, dans certaines situations, vous pouvez utiliser l'e-commerce amélioré pour suivre des transactions non finales. Cela peut concerner, entre autres, les réservations et les envois de formulaires à des prospects, où de possibles transactions futures peuvent modifier le revenu et les produits inclus.
Comportement de l'e-commerce amélioré
Lorsque vous essayez de dédupliquer des transactions, l'e-commerce amélioré peut se comporter comme suit :
-
Chaque fois qu'un appel est envoyé avec une transaction, le nombre total de transactions dans GA pour la métrique "Transactions" augmente. Cela se produit même lorsqu'une transaction est associée au même ID que les précédentes.
-
Chaque fois qu'un appel est envoyé avec un remboursement, le nombre de remboursements du produit augmente, mais la métrique "Transactions" n'est pas affectée.
-
Par exemple, si vous envoyez une transaction avec un montant de X, puis une deuxième avec un montant de -X, la métrique "Revenus" est neutralisée, mais deux transactions (et non une seule) sont comptabilisées.
-
Si vous envoyez une transaction d'un montant de X, puis envoyez un remboursement du même montant, le nombre de transactions et la métrique "Revenus" ne sont pas affectés. La métrique "Montant du remboursement" augmenterait de X, et celle du nombre de remboursements de produits de un. Le nombre de produits remboursés augmente de un pour chaque produit remboursé.
-
Si vous envoyez plusieurs transactions avec le même ID, puis envoyez un remboursement total, la dernière transaction vous est remboursée, mais celles effectuées avant ne sont pas prises en compte.
Modifier des transactions
Fondamentalement, il n'est pas possible de prendre en compte les modifications de transactions avec la configuration standard. L'e-commerce amélioré est conçu pour mesurer le moment où un utilisateur atteint le point de non-retour d'un cycle d'achat, et non celui où il peut encore modifier son achat de manière significative.
Pour créer des rapports qui prennent en compte les transactions modifiées, consultez la section ci-dessous. Il peut y avoir d'autres méthodes, qui ne seront pas abordées dans cet article.
Créer des rapports personnalisés
Pour générer les rapports souhaités, vous devez utiliser Looker Studio ainsi qu'une combinaison de remboursements et de transactions. Pour que les modifications de transaction soient bien prises en compte, respectez les règles ci-dessous.
-
Si un client modifie sa transaction pour inclure des produits qui en augmentent les revenus, envoyez uniquement les revenus supplémentaires dans une nouvelle transaction. N'envoyez pas le revenu total de la transaction avec la transaction la plus récente. La nouvelle transaction doit avoir le même ID que l'ancienne.
-
Chaque fois qu'un produit est supprimé d'une transaction, envoyez un appel avec un remboursement.
-
Indiquez toujours les produits à supprimer ainsi que le montant, les revenus générés par le produit et la quantité de produits associés au remboursement. Ces informations doivent être fournies même pour les remboursements totaux.
Vous devez créer une métrique personnalisée qui ne peut avoir pour seule valeur que "1". Elle doit être envoyée uniquement lorsqu'un client demande un remboursement total (et non un remboursement partiel). Cette métrique personnalisée doit être définie au niveau de l'appel. Vous devez impérativement l'inclure, car aucune métrique ne comptabilise le nombre global de remboursements totaux de transactions.
Étapes de création d'un rapport Looker Studio
-
Créez une source de données Looker Studio en connectant votre vue principale à Looker Studio.
-
Créez les champs suivants dans la source de données :
-
Transactions dédupliquées
-
Formule : count_distinct(transactions)
-
-
Nombre de transactions finales
-
Formule : transactions dédupliquées - métrique personnalisée de remboursement de transactions
-
-
Revenu final
-
Formule : revenu - montant du remboursement
-
-
Revenu final généré par le produit
-
Formule : revenus générés par le produit - montant du remboursement du produit
-
-
Quantité finale de produits
-
Formule : quantité - quantité remboursée
-
-
Les champs calculés dans la source de données Looker Studio sont obligatoires pour créer une métrique de transaction entièrement dédupliquée qui supprime également les remboursements. Les autres métriques calculées doivent également inclure les métriques de création de revenus, de revenus générés par le produit et de quantité de produits qui tiennent compte du montant et des revenus du remboursements.
Limites
Lorsque vous créez des rapports personnalisés et contournez les rapports classiques dans GA, le principal problème est que les fonctionnalités comme les rapports sur les entonnoirs multicanaux et les rapports sur l'attribution peuvent ne pas être très utiles. En effet, les transactions ne seront pas dédupliquées.