[Robert]

There could be a few reasons for this discrepancy. Firstly, Google Analytics 4 (GA4) deduplicates users across devices and platforms by default using Google signals, while BigQuery simply processes raw data and does not automatically deduplicate. Secondly, GA4 applies certain thresholds to its data to prevent the identification of individual users, which may result in some user data being excluded. Essential for compliance with privacy laws, this data might be present in BigQuery. Another potential reason for the mismatch could be the processing latency. GA4 data is available in real-time, but it might take up to 24 hours for this data to be sent to BigQuery. If you’re trying to match data for the current day, the BigQuery data may be incomplete.
Consider working with your raw data in BigQuery to account for any deduplication or privacy thresholds to get a more accurate match with GA4’s interface.

[Robert]

There could be a few reasons for this discrepancy. One explanation could be due to the different ways Looker and BigQuery handle data. Looker uses a model of data that may include transformations or aggregations that aren’t present in your BigQuery query.

Another possibility is that your Looker report and BigQuery query aren’t using the exact same data range or have different filter parameters. The date range might be the same, but if Looker is accounting for time zones in a different way, it could yield different results.

Also, ensure that you are considering events in Google Analytics that could influence the number of views, such as bot filtering or data sampling. Moreover, double-check that your query in BigQuery corresponds to the same actions taken when Looker extracts the data from Google Analytics.

Lastly, it could be due to the freshness of the data. Google Analytics does take time for data ingestion in BigQuery. Differences in the timing of data accessibility in GA4 BigQuery export and Looker could account for the discrepancy.

I’d advise reviewing the settings and transformations in Looker-Studio, adjusting your BigQuery query accordingly, and verifying the freshness of your data in Google BigQuery.

[Robert]

Creating a fresh GA4 property for both Website A and Website B to use, and then adding a Config Tag in both GTM containers with a matching Measurement ID, could indeed work for your situation if you don’t want to blend data from the two sites. For Website A, the tag would be triggered by a click on an outbound link to Website B. For Website B, a Config Tag with a new data stream would be assigned to all events from page views, thus completing the cross-domain tracking setup. This gives you a setup where the domains share data streams without mixing the data from the two sites in a way that you don’t want.

[Robert]

The discrepancy in data between the Google Analytics API and BigQuery exports could be caused by various factors. One possible reason is sampling. Google Analytics API sometimes uses sampling to quickly generate approximate numbers, especially when dealing with large reports. To get an accurate count, consider breaking down your queries into smaller date ranges. Furthermore, Google Analytics Data API includes a maximum limit of 10 million rows per request, so if you’re dealing with large volumes of data, you might need to retrieve the data in multiple requests.

The differences might also be due to how BigQuery and Google Analytics process and store data differently. BigQuery includes both session-level and hit-level data, while Google Analytics API only retrieves aggregated information. Also, some events might not be recorded or considered in Google Analytics due to filters or tracking code issues, but they are included in BigQuery.

Lastly, note that handling of joins can cause difference in row numbers when you’re using more than one dimension. Google Analytics API uses left outer join. If there is no match for right dimension, you’ll get one row less. Understanding these differences can help you make correct requests and interpret results accurately.