Hey guys! Team and I have noticed that some of our...
# ask-questions
a
Hey guys! Team and I have noticed that some of our metrics (pageviews, session_start, add_to_cart, etc) are higher in GA compared to GB. Has anybody experienced this? Do we need to change our queries in GB?
t
Chiming in since my team actually has the opposite problem. But we're debugging this week, will let you know what we find
🙌 1
a
Appreciate it! Good luck to you and team!
🙏 1
b
Hi @alert-state-22242 and @tall-branch-42668 👋🏻 I'm going to reply to "metrics being higher in GA4 than GB" here in this thread. Matt, I'll start a new thread to discuss the opposite.
🙏 1
Conversion Window: The metric page in GrowthBook shows a count of all conversions per day, but some of those conversions may be excluded from experiment results if they didn't happen within the metric conversion window.
Ad Blockers: The use of ad blockers by visitors to your web page can affect the tracking of events. If ad blockers prevent the tracking of the
experiment_viewed
event or other relevant events, this could lead to discrepancies between GA4 and GrowthBook metrics.
Data Synchronization Issues: There could be issues with the synchronization of data between GA4 and GrowthBook, or the queries used to retrieve data from BigQuery might not be correctly configured.
Tracking Callback Implementation: If the trackingCallback is not implemented correctly, it might not be firing as expected, leading to underreporting in GrowthBook.
Data Source Configuration: The configuration of the data source in GrowthBook might be incorrect. Usually this would be an issue with the Experiment Assignment Query.
BigQuery Table Qualification: There might be an issue with the qualification of the BigQuery table in the queries used by GrowthBook. Make sure that tables are preceded by a dataset, like
my_dataset.events_table
.
a
Thank you @brief-honey-45610. Regarding Adblockers, that should not be a problem since we are running gtm server side. The data sync issues, I dont believe should have any problems since we are running your default queries (I believe). And regarding the table qualification, this is fine right?
analytics-platform-swe.analytics_123456789
r
Yes, that table qualification syntax looks correct.
1