The hit data discrepancy may be caused by a misconfiguration or by peculiarities of the related services work. Check out the possible reasons for data discrepancy and find the appropriate solution for your case.
Google Analytics settings
- Discrepancy reason: Google Analytics Collection Limits and Quotas are exceeded.
Solution: In this case, it is expected that OWOX BI collects a larger amount of data.
Please take into account the fact of exceeding GA limitations when comparing the data for the affected period.
- Discrepancy reason: Data in your Google Analytics Property is limited by View filters. While OWOX BI imports data to Google BigQuery without limitations.
Solution: Use Property View without filters.
- Discrepancy reason: The TimeZone parameter is changed in your GA Property View after OWOX BI pipeline creation. As a result, historical data in GA is updated in accordance with the new time settings. While the timestamp of BigQuery data import cannot be changed retrospectively.
Solution: Please take into account the fact of Time Zone changing when comparing the data for the affected period. Data imported to BigQuery after the Time Zone changing will have an updated timestamp.
- Discrepancy reason: Google Analytics automatically filters out the bot-generated traffic and excludes sessions triggered by various bot activities. While OWOX BI collects row data that may contain the bot-generated traffic.
Solution: The solution is currently under development.
- Discrepancy reason: There are two or more tracking methods implemented simultaneously on your website. For example, you’ve implemented tracking via GTM container with a customTask but haven’t removed gtag.js from the pages you track; or you’ve added the same tracking code twice.
Solution: Open your website in the Google Chrome web browser, then open the developer console by right-clicking on a page > Inspect element. In the console, press Ctrl+F (or cmd+F for Mac) to call the search field, then check your tracking codes using these keywords: GTM/analytics.js/gtag.js. Make sure you don’t have more than one chunk of code with either of these keywords.
- Discrepancy reason: A customTask variable is not added to every Universal Analytics tag that you use to send data to BigQuery.
Solution: Add the customTask variable to each Universal Analytics tag.
- Discrepancy reason: the Google Tag Manager container that you use to send data to BigQuery has two or more customTask variables. Any additional customTask overrides the function of the previously added one. As a result, it prevents the data to be sent to Google BigQuery.
Solution: Your GTM container must include a single customTask which function is to send hits to the OWOX BI access point.
Discrepancy reason: The hit data collection is blocked by the Content Security Policy on your website.
Solution: Adjust your Content Security Policy as follows
- if you use Google Tag Manager, add the directive script-src 'unsafe-eval' 'unsafe-inline' https://tagmanager.google.com/ https://www.googletagmanager.com/ to the Content-Security-Policy Header;
- If you use analytics.js, add the directive script-src 'unsafe-eval' 'unsafe-inline' https://google-analytics.bi.owox.com/ to the Content-Security-Policy Header.
- Discrepancy reason: Some Universal Analytics tags, that you use to send data to BigQuery, do not contain 'owox' as a tracker name.
Solution: Update tracker name to 'owox' for all required Universal Analytics tags.
- Discrepancy reason: Incorrect tags sequencing.
Solution: In tags sequencing, set the OWOX BI tag to fire before the Universal Analytics tags. Leave the tag priority and trigger empty.
- Discrepancy reason: Google Analytics Web Property ID is not defined in the Streaming tracking code.
Solution: Provide Google Analytics Web Property ID within the tag that contains Streaming tracking code
- Discrepancy reason: Fields that were specified during the tracker creation are not set in the streaming tag.
Solution: Define all the required fields in the streaming tag.
ImportantAfter you adjust the GTM container configurations, publish your container to apply the changes.
NoteIt is highly recommended to use a customTask to integrate the OWOXBI tracking code via Google Tag Manager. More details can be found here.
Measurement Protocol settings
- Discrepancy reason: Data is not sent to the OWOX BI access point.
Solution: Make sure that all the events are duplicated to the OWOX BI access point, i.e. google-analytics.bi.owox.com.
- Discrepancy reason: when you submit your MP request, Google Analytics records a transaction hit if it contains a unique actionField object. It means that out of two (or more) hits with the same parameter values in the actionField object, only one hit will be recorded by GA. While OWOX BI records all the transaction hits regardless of the received parameter values in the actionField object.
Solution: Send the unique parameter values in the actionField object per transaction hit. For example, you can do it by entering different values for Revenue, Tax, or Affiliation in each actionField object.
You can check the number of transactions collected to the BigQuery tables using these SQL requests.
- Discrepancy reason: The GET parameter tid is not defined in your request.
Solution: Adjust your request by providing GET parameter tid.
- Discrepancy reason: The hit data is sent some time after the event is completed.
Solution: If the delay between completing an order on a website and submitting the Measurement Protocol request exceeds a preset session timeout (it's 30 minutes by default), then it is essential to define the qt parameter in your request.
To see if your request already includes the qt parameter or not, review the Measurement Protocol payload_data. Alternatively, you can check this using the hit data table, which is created by the OWOX BI streaming pipeline in BigQuery. Navigate to the hit data table and find the hit sourced from Measurement Protocol. Then verify if there is the queueTime field for this hit. If you don't see the queueTime field there, then the qt parameter is not defined in the request.
To verify the source of hit, check the data source, UserAgent, and IP fields in the hit data table. Hits that you submit via Measurement Protocol might have the fixed data source, UserAgent, and IP values that differ from the corresponding field values of the user sessions.Then, do as follows:
- If the qt parameter is not yet submitted, define it in your request following these recommendations.
- If the qt parameter is already submitted, ensure that its value is dynamic. The value in the queueTime field of the hit data table should reflect the actual delay time between the order completion and the request submission for each particular transaction.
NoteIf the &qt parameter is set to more than 4 hours, the hit won’t get to Google Analytics. Meanwhile, OWOX BI can associate the hit data with the right session if the hit is completed within a 30-day period. As a result, OWOX BI will collect more data than Google Analytics.
Learn how the qt parameter affects assigning transactions to user sessions from this article.
Other discrepancy reasons
- Proxy server or firewall settings that prevent sending data to some servers.
- Browser plug-ins that block sending data to Google Analytics.
- Lag differences between an initial action and logging a hit on each analytics service server. For instance, a user may click a link to navigate elsewhere before the pageview or click event is sent.
- Different traffic processing on the data transit route from its origin to a destination server.
- Yandex submits hits from the mobile search not as 'organic', but as 'referral' to Google Analytics. This may cause discrepancies between data collected into Google Analytics and Google BigQuery.
The impact of the technical reasons above is not significant (up to 1% of data discrepancy). Still, make sure none of these reasons affect your results.
Navigate our documentation for more solutions:
Troubleshoot the transaction data discrepancies
Troubleshoot the session data discrepancies
Troubleshoot the ad cost data discrepancies
If you need assistance, contact Support at email@example.com or via online chat.