Learn business growth with Google Analytics 4 Forums Google Analytics 4 Inconsistencies in GA4 Transactions between User Interface and API

  • Inconsistencies in GA4 Transactions between User Interface and API

    Posted by Lincoln on 9 August 2022 at 7:12 am

    Hey folks,

    So here’s the deal. I’m crunching some numbers for a client, right? They want me to pull in the number of transactions and the revenue from those transactions, all sorted by Google Ads campaign ID. I’ve got my query all set up like this:

    [display query]

    This should work fine and dandy and give me “The count of transaction events with purchase revenue. Transaction events are in_app_purchase, ecommerce_purchase, purchase, app_store_subscription_renew, app_store_subscription_convert, and refund”, straight from the API schema.

    Sweet, right?

    So the plot thickens when I run my query and get these numbers back for one of my campaigns:

    [display data]

    But when I try to match these numbers with a GA4 dashboard report I ran for the same dates, it gives me this for the same ‘example campaign’:

    [display report]

    See the issue? The numbers are off by about 25%. The revenue or event value is a bit closer but still not matching. This is the same deal for all of my client’s campaigns – the numbers from the API are always higher. But they don’t change if I pull up the report again another day.

    At this point I’m thinking, “Hey, maybe there’s another event being tracked under the ‘transactions’ in the API that I’m not seeing on the dashboard”. Testing this theory, I added this filter to my query:

    [display filter]

    But the transactions field still comes back as 331. Same as before. So much for that theory.

    So here I am, puzzled as heck, trying to figure out if I’m knocking on the wrong door (querying the wrong field), if the frontend is not showing me all the goods (under-reporting data), or the API got a little too excited (over-reporting data). Any tips, thoughts, ideas? I wasn’t allowed to post on the official GA4 Issue tracker, so maybe you guys can help a fellow data geek out.

    Lucas replied 10 months, 3 weeks ago 3 Members · 2 Replies
  • 2 Replies
  • Alexander

    Member
    30 November 2022 at 5:17 pm

    Turns out, the issue was with scopes – specifically, mixing up session and event ones. The ‘transactions’ data is session scoped, while the other stuff I was pulling in was event scoped. So the numbers I was getting were basically useless, because they weren’t compatible. Weirdly, the API let me do this while the dashboard wouldn’t. To fix this, I’m now pulling the ‘conversions’ data, only for ‘purchase’ events.

  • Lucas

    Member
    30 June 2023 at 4:15 pm

    Discrepancies between Google API numbers and dashboard data is common, often it’s because API includes more raw, real-time data before certain filters and adjustments are applied in other Google platforms. To verify if you’re querying the right field, cross-check with GA4’s documentation or Google’s API documentation.

    As for the possibility of underreporting on the frontend, it’s critical to remember that GA4’s frontend dashboard applies certain beneficial adjustments to data representation such as sessionization and deduplication. The frontend is generally more user-friendly and accessible but can sometimes oversimplify the raw data or apply built-in filters that might exclude certain event-types.

    In the case of API overreporting, realize that raw data can include duplicate events, spam, bot traffic or irrelevant events that frontend analytics platforms would adjust for. So, while API data might appear higher, it could be less refined or contain ‘noisy’ data.

    It’s also worth checking and comparing the time zone settings between your API and Google Analytics. A substantial difference in the time zone could result in a discrepancy in the data being pulled and displayed.

    Finally, make sure to take into account the natural data processing latency. GA4 data can take up to 48h to finalize, you might want to add a delay in your data analysis to account for this latency.

Log in to reply.