Modified Transactions in Data Studio

While Enhanced Ecommerce was designed to track the final transactions associated with a purchase and some of the user interactions prior to such a purchase, there are some scenarios where Enhanced Ecommerce can be used to track transactions that are not necessarily final. These scenarios include but are not limited to reservations and lead form submissions, where future transactions may occur that modify the final revenue and included products.

Enhanced Ecommerce behavior

The following behavior of Enhanced Ecommerce should be noted when working to deduplicate transactions:

  • Whenever a hit is sent with a transaction, that transaction increases the overall count of transactions within GA for the transactions metric. This is true even when a transaction has the same ID.

  • Whenever a hit is sent with a refund, the product refund count increases, but the transactions metric is unaffected.

  • If one were to send one transaction with amount X and then a second transaction with amount -X, the revenue metric would be cancelled out but the count of transactions would be two, not one.

  • If one were to send a transaction with amount X and then send a refund of X, the transaction count and revenue metrics would be unaffected. The refund amount metric would increase by X and the product refund count metric would increase by one. The product refund count would increase by one for each product that was refunded.

  • If you send multiple transactions with the the same ID and then send a full refund, the latest transaction will be refunded but the earlier transaction will not be accounted for.

Modifying transactions

Fundamentally, accounting for transaction modifications isn't possible with the standard setup. Enhanced Ecommerce is designed for measuring the moment when a user is past the point of no return in a purchase cycle, not the point at which a user can still heavily modify their purchase.

The following details one option for creating reports that account for modified transactions. There may be other techniques to achieve this not discussed here.

Create Custom Reports

Data Studio must be used in order to generate the desired reporting. A combination of refunds and transactions should be used to create the desired reports. The following rules should be followed to ensure that transaction modifications are properly accounted for.

  • If a customer modifies their transaction to include products that increase the revenue of the transaction, only send the additional revenue in a new transaction. Do not send the total transaction revenue with the newest transaction. The new transaction should have the same transaction ID as the old transaction.

  • Whenever a product is removed from a transaction, send a hit with a refund.

  • Always specify the products being removed and the revenue, product revenue, and product quantity associated with a the refund. This should be specified even for full refunds.

A custom metric will need to be created that only ever has the value of "1" and is only ever sent when a customer requests a full refund but not a partial refund. The custom metric should be hit scoped and is necessary since there is not a metric that counts the overall number of fully transaction refunds.

Steps to create Data Studio Report

  1. Create a new Data Studio data source by connecting your main view to Data Studio

  2. Create the following fields in the data source:

    1. Deduplicated Transactions

      1. Formula: count_distinct(transactions)

    2. Final Transaction Count

      1. Formula: Deduplicated Transactions - transaction refund custom metric

    3. Final Revenue

      1. Formula: revenue - refund amount

    4. Final Product Revenue

      1. Formula: product revenue - product refund amount

    5. Final Product Quantity

      1. Formula: quantity - quantity refunded

The calculated fields in the Data Studio data source are necessary in order to create a fully deduplicated transaction metric that also removes refunds. The other calculated metrics should also take create revenue, product revenue, and product quantity metrics that take into account refund revenue and quantity.

Limitations

The main issue with building custom reports and bypassing the typical reports in GA is that features such as the multi-channel funnel reports and the attribution reports may not be very useful since transactions will not be deduplicated.

Was this helpful?
How can we improve it?