We do not say this lightly: Parallel Tracking is already trusted by several Fortune 100 companies, and by well-known brands such as NextEra Energy, Invesco, StubHub and Adorama, all of them exporting far more than 1 million events a day.

Pain point 1: the 1 million event BigQuery export limit

The native GA4 to BigQuery export is one of the best things about GA4. It gives you raw, event-level data you can join with the rest of your business data. But on standard properties it comes with a daily limit of 1 million events. If your property consistently goes over it, Google pauses the daily export, and the days that were skipped are not reprocessed.

The limit counts hits, not users or sessions. A single visitor on a busy e-commerce site or app can generate hundreds of events, so a business with a modest number of visitors can still hit the cap. When it does, the damage is quiet: reports and models built on BigQuery start to show gaps, and you often only notice weeks later, when the numbers do not add up. For a deeper look at the limit itself, read our guide on how to avoid the GA4 BigQuery export limit.

The usual workarounds are all compromises. You can collect fewer events, or filter what you send to BigQuery, which means giving up data you may need later.

Pain point 2: GA360 is too expensive

Upgrading to GA360 raises the export quota to billions of events, and it adds other enterprise features. For companies that need the full package it can be worth it. But for many teams the price is hard to justify when the main reason for upgrading is a single limit.

That is the trap: you are forced to buy an enterprise contract to get an export that should simply work. Many of our clients came to us in exactly this position, with enough traffic to outgrow the free version and no appetite for the cost of GA360.

Pain point 3: sampling and modelled data

The reports in the GA4 interface are not always built from all of your data. Depending on the report and the size of your property, GA4 can sample data in explorations, apply thresholds and group rare values together. When users decline consent, GA4 can also fill the gaps with modelled data instead of observed data.

None of this is a flaw in GA4. It is how a free, hosted tool stays fast. But it means that two analysts can look at the same question and see slightly different numbers, and you cannot always tell which parts of a figure are measured and which are estimated. If you are making budget decisions or training models on that data, you want to know exactly what you are looking at.

What is Parallel Tracking?

Parallel Tracking is a second data stream that runs alongside your existing GA4 setup. With a small change to your tracking code or GTM tag, every hit that goes to GA4 is also sent to our processing endpoint. Here is how it works:

1. A small tracking change. Your tracking code or GTM tag streams each hit to our endpoint in parallel with GA4. It works with GTM, server-side tagging and most setups in between.
2. Processing at scale. Our engine handles each hit much like GA4 does, but without GA4’s processing limits, so it scales with your traffic.
3. Data in your warehouse. The data lands in BigQuery by default, and we can send it to almost any other warehouse, including Snowflake and Amazon S3. It is ready for reporting within seconds.

It does not replace GA4. Your GA4 reports and integrations keep working exactly as before. Parallel Tracking simply gives you a complete copy of the raw data, in a place you own.

How it solves the three problems

• No 1 million event cap. The export runs at any volume, so your BigQuery tables are complete every day.
• A fraction of the cost of GA360. You get an unlimited export and complete data without an enterprise analytics contract. It is a popular, far more affordable alternative to GA360.
• Complete, unsampled data. You work with every event instead of estimates, so the numbers in your reports and models are exactly what was collected.
• Fully processed data in near real time. We deliver processed, analysis-ready data to your warehouse in near real time, instead of waiting for a daily export.

There are further benefits too. You can detect and exclude bot traffic, bring in additional sources alongside your GA4 data, and optionally process hits into sessions in a separate BigQuery table. And because AI tools and models work best on complete event data, a full, unsampled copy of your data is a better foundation for analysis, forecasting and AI agents. Learn more about our BigQuery services and GA4 implementation.

Trusted by some of the biggest names

Reflective Data is trusted by several Fortune 100 companies, and Parallel Tracking is in daily use by clients you will recognise, including NextEra Energy, Invesco, Adorama, Adlibris, StubHub, Educative and Camino Financial. They are all on Parallel Tracking, exporting well above 1 million events per day to their warehouses, and saving several times what the equivalent GA360 pricing would cost them.

Keep your data in the EU

If you operate in Europe, where your data is collected, processed and stored can matter as much as how. The whole Parallel Tracking pipeline can be configured to run physically in the EU: collection, processing and storage. For many companies this is a requirement under GDPR and other EU laws and regulations, and an easy way to simplify the conversation with your legal and privacy teams.

Is it right for you?

Parallel Tracking is worth a look if any of these sound familiar:

• Your BigQuery export is paused, or you are getting close to 1 million events a day
• You are considering GA360 mainly for the export quota
• You do not fully trust the numbers in GA4 because of sampling, thresholds or modelling
• You want raw event data in a warehouse other than BigQuery
• You are building models, dashboards or AI tools that need complete data
• You need your data collected, processed and stored in the EU

Book a free consultation

Not sure whether Parallel Tracking fits your setup? Book a free consultation with one of our analytics experts. We will look at your current GA4 and BigQuery setup, check where you stand against the export limit, and tell you honestly whether Parallel Tracking, or something else, is the right fix. There is no obligation. Most setups need only a small change to the tracking code or GTM tag, every plan includes full implementation support, and getting up and running usually takes anywhere from a few hours to a few days.

The post 3 GA4 Pain Points That Parallel Tracking Solves: the 1M Export Cap, GA360 Costs and Sampling appeared first on Reflective Data.

At a glance

• Client: Barbora, a large e-commerce business in the Baltics
• What we built: a dbt project and semantic layer on our platform, interactive dashboards in Explore and a custom MCP server
• Result: metrics that finally match across sources, about 75% lower data warehousing costs in the marketing department, and AI access to the same trusted data in Slack and Claude

The challenge

For a long time, the numbers coming from different sources did not match. The same question about marketing performance could produce different answers depending on which report, tool or query you used. This is a familiar problem in e-commerce, where the data comes from many places and every platform defines its metrics a little differently.

The effects were practical. Marketing and leadership spent time debating which number was right instead of deciding what to do next. Analysts spent hours reconciling reports. And with every new reporting need, queries against the warehouse grew, along with the bill.

Barbora also wanted to use AI to get answers faster. But pointing AI at inconsistent, unmodelled data would only have produced faster confusion. The foundation had to come first.

The solution

We built the solution in three steps, all on the Reflective Data platform.

1. A dbt project and semantic layer

We built Barbora’s dbt project on our hosted dbt, so every metric and dimension is defined once, in code, tested and version-controlled. A semantic layer sits on top, so a number means the same thing wherever it appears. The models also produce compact, aggregated reporting tables, so reports no longer need to scan large volumes of raw data.

2. Interactive dashboards in Explore

On top of that layer we built a set of interactive dashboards using Explore. Teams can look at the same governed metrics themselves, filter and slice them, and no longer depend on a one-off report for every question.

3. An MCP server for their data

We then built an MCP server that gives AI tools access to the same governed data through the semantic layer. Barbora’s people now use it directly in Slack and in Claude, and it also powers their weekly stakeholder emails. The answer in Slack, the number in a dashboard and the figure in the email all come from the same definitions.

The results

Metrics that finally match

The biggest win was one that had been missing for years: the numbers from different sources now match. Barbora’s marketing team and leadership were delighted to see it. Discussions moved from “which number is right?” to “what should we do about it?”.

About 75% lower warehousing costs in marketing

Because reports and queries now read modelled, aggregated tables instead of raw data, they are far more efficient. Barbora saved about 75% on data warehousing costs in the marketing department.

AI where the team already works

With a trusted data layer in place, AI became useful instead of risky. People get answers in Slack and Claude, and stakeholders receive weekly emails powered by the same governed data, without anyone assembling them by hand.

Why it worked

• Foundation first. We fixed the definitions and the models before adding dashboards or AI, so everything built on top inherited the same logic.
• One layer for every tool. Dashboards, Slack, Claude and email all read from the semantic layer, so there is only one version of each number.
• Efficient by design. Reporting tables mean queries touch far less data, which is better for speed and for cost.

Want to know more about the approach? Read why a semantic layer is essential for giving AI access to your data.

Get the same for your business

If your numbers do not match across tools, or you want AI you can trust on your data, we can help. Request a demo of the platform, or talk to one of our experts about our data build and semantic layer and AI services.

The post Case Study: How Barbora Got One Version of the Truth and Cut Marketing Data Warehouse Costs by About 75% appeared first on Reflective Data.

The problem: AI does not know what your numbers mean

Large language models are very good at writing SQL. What they cannot know is what your business means by “revenue”, “active customer” or “qualified lead”. Is revenue gross or net of refunds? Does it include tax? Which orders count as completed? Is a customer someone who signed up, or someone who paid?

Those answers live in people’s heads, in old dashboards and in scattered queries. When an AI agent is pointed at raw tables, it has to guess. Sometimes it guesses right. Often it produces a confident, well-formatted answer that is quietly wrong, and nobody notices until the number reaches a board slide.

What a semantic layer is

A semantic layer is a governed description of your business on top of your data models. It defines:

• Metrics: how each measure is calculated, such as revenue, conversion rate or churn
• Dimensions: the ways you slice them, such as date, channel, country or product
• Entities and relationships: how customers, orders and sessions connect
• Ownership and permissions: who is responsible for a definition and who may see the data

Here is what a metric definition can look like in code (illustrative):

metric: revenue
type: simple
measure: sum(order_total)
filter: status = 'completed'
owner: finance
used_by: [dashboards, notebooks, agents]

It is written once, reviewed in git like any other code, and used everywhere. Common ways to build one include dbt with MetricFlow, LookML, SQLMesh and Omni, and we work with all of them.

Why AI specifically needs it

Consistent answers

Without a semantic layer, the same question phrased two ways can produce two different queries and two different numbers. With one, the agent does not write the calculation. It asks for the metric by name and the layer produces the correct query. The answer matches your dashboards because it comes from the same definition.

Fewer hallucinations

A model choosing from a short list of defined metrics and dimensions has far less room to invent a join, pick the wrong column or misread a field. The space of possible mistakes shrinks from “anything in the warehouse” to “something the business has already agreed on”.

Trust you can verify

When an executive asks “where does this number come from?”, the answer should not be “the AI said so”. With a semantic layer, every figure traces back to a named metric, an owner and a tested model. Agents can show their working, and people can check it.

Security and access control

Giving an agent raw warehouse access also gives it everything in the warehouse, including data it should not show. A semantic layer is a natural control point: you expose only the metrics and dimensions the user is allowed to see, and the same rules apply whether the request comes from a person, a dashboard or an agent.

Speed and cost

Agents that explore raw event tables scan far more data than they need, which is slow and expensive. Queries generated from a semantic layer run against modelled, optimised tables, so answers come back faster and cost less.

One layer for every tool

Your analysts use BI, your marketers use spreadsheets, your product team uses notebooks and now your AI assistants use chat. A semantic layer gives all of them the same definitions. Add a new tool or a new AI model later and it inherits the existing logic instead of starting from scratch. This is also why the Reflective Data agent and MCP server read from a semantic layer and not from raw sources.

What goes wrong without one

We see the same patterns again and again when teams connect AI to unmodelled data:

• Revenue, customers and conversion rate calculated differently in every dashboard, and now a different way again in the chat assistant
• Agents that quietly include test orders, bot traffic or duplicate events
• Answers that change from one day to the next because the model made different assumptions
• No way to audit or explain a number once it has left the tool
• A pilot that impressed everyone in the demo and was switched off after the first wrong answer in front of leadership

In practice: how we built it for Barbora

Barbora is one of the largest e-commerce businesses in the Baltics. They wanted their teams and their AI tools to work from the same trusted numbers, so we built the foundation described above, step by step, on the Reflective Data platform:

1. A dbt setup on our platform. We built their dbt project and semantic layer on our hosted dbt, so their business logic and metric definitions are written once, tested and version-controlled.
2. Interactive dashboards in Explore. On top of that layer we built a set of interactive dashboards using the platform’s Explore feature, so teams can look at the same governed metrics themselves.
3. An MCP server for their data. We then built an MCP for them that gives AI tools access to the same governed data, through the semantic layer.

Today the whole company uses it where they already work. People ask questions in Slack and directly in Claude, and the same layer powers their weekly stakeholder emails. Because everything reads from one set of definitions, the answer in Slack, the number in a dashboard and the figure in the email all match.

That is the real payoff of a semantic layer. You do not build one integration per tool. You build the foundation once, and every new way of using your data inherits it.

How to build a semantic layer that AI can use

1. Start with clean models. Raw data is staged, tested and documented in dbt, so the layer sits on a foundation you trust.
2. Pick the metrics that matter. Begin with the dozen or so numbers leadership and teams use every week. Do not try to model everything on day one.
3. Agree on definitions with the business. Finance, marketing and product often disagree. Settling it once, in writing, is most of the value.
4. Define them in code. Metrics, dimensions and relationships live in version control, with review, tests and an owner.
5. Add descriptions for humans and machines. Clear names and descriptions help AI choose the right metric. Good documentation improves the answers.
6. Connect your tools. BI, notebooks and AI agents all read from the same layer, for example through an MCP server.
7. Monitor and improve. Track which questions are asked, where answers are wrong, and extend the layer accordingly.

How we can help

Building this layer is what our data build and semantic layer service is for. We design and build the models, work out the metric definitions with your stakeholders, and connect the layer to your BI tools and AI agents. If you already have a semantic layer in one tool, we can improve it or migrate it. If you would rather not run it yourself, our platform includes hosted dbt and a semantic layer, and our team can run it for you as a managed service.

Once the foundation is in place, our AI services help you put it to work: a company brain, custom agents, bots for your website or Slack, and training for your team.

Want to see how this would look on your data? Request a demo or talk to one of our experts.

The post Why a Semantic Layer Is Essential for Giving AI Access to Your Data appeared first on Reflective Data.

AI changes how fast we build

We are a team of data engineers, and we use AI every day. It helps us write and review code, draft and test dbt models, generate documentation and prototype new product features in a fraction of the time it used to take. That is why new capabilities in the Reflective Data platform reach customers faster than they used to.

The important part is what stays human. Our engineers design the architecture, review every change and own what ships. AI speeds up the work. It does not replace the judgement.

Talk to your data: agent mode and MCP

The platform now has a full agent mode. Instead of writing SQL or hunting through dashboards, you ask a question in chat and the agent works with all of your data to answer it. It can:

• answer questions across your sources, from marketing and product to finance and operations
• produce clear, good-looking charts and visualisations on request
• explain how a number was calculated, so people can trust it

You do not have to come to us to use it. The Reflective Data MCP server brings the same governed data to the tools where you already work, such as your AI assistant, your editor or your internal agents. Your data goes where your people are.

Why AI should read from dbt and a semantic layer, not raw sources

This is the most important design decision for any company that wants AI to work with its data. There are three tempting shortcuts, and each one causes problems.

1. Raw API connections and source-platform MCPs

It is easy to connect an AI assistant straight to Google Analytics, a CRM or an ads platform. But every platform has its own definitions of users, sessions, conversions and revenue, and they rarely match. Sampling, attribution rules, API limits and quotas change what you get back. An agent that queries each source separately will happily give you numbers that disagree with each other, and with finance, without telling you why.

2. Raw warehouse exports

Pointing AI at raw BigQuery exports looks more robust, because the data is complete. In practice raw tables are large, nested, undocumented and full of edge cases: duplicate events, test traffic, bots, schema changes and fields that only an insider can interpret. The model has to guess the business logic on every query, so answers vary from one question to the next. It is also slow and expensive, because the agent scans far more data than it needs.

3. What works: dbt plus a semantic layer

With dbt, your business logic is written once, as tested and documented code. The semantic layer sits on top of it and defines your metrics, dimensions and relationships: what counts as revenue, an active customer or a qualified lead. When AI asks a question, it uses those definitions instead of inventing its own. That gives you:

• Consistent answers. The same question returns the same number, whether a person or an agent asks it.
• Trust and traceability. Every figure traces back to a tested model.
• Control. You decide which data AI can see, and permissions apply the same way everywhere.
• Lower cost and better speed. The agent queries modelled, aggregated tables instead of scanning raw events.
• Less hallucination. A model that picks from defined metrics has far fewer chances to make something up.

This is exactly how our platform is built. Pipelines load your data, hosted dbt with a semantic layer models it, and Explore, agent mode and the MCP server read from that governed layer.

How we help you become AI-driven

Most companies do not need another AI tool. They need their data in a state AI can use, and a plan for putting it to work. Our consultants take you through that step by step:

1. Assess. We audit your tracking, data sources and reporting to find what blocks reliable AI answers.
2. Build the foundation. We set up clean data collection, pipelines into your warehouse, dbt models and a semantic layer, as part of our data infrastructure work. This is the part that makes everything else trustworthy.
3. Give AI access safely. We expose your governed data to agents and assistants through the semantic layer and MCP, with permissions and logging.
4. Build your company brain and agents. We connect your documents and knowledge into a company brain, and build custom agent harnesses and bots for your website or Slack that follow your own processes.
5. Train your team. We run hands-on AI training sessions based on your real workflows, so people use AI well and safely from day one.
6. Run it. If you prefer, our managed service operates the platform and keeps the data, models and agents healthy.

We work with all major AI labs (see our AI services) and stay vendor-neutral, so you are never locked into one model. You can use the Reflective Data platform, or we can build on the stack you already have.

Where to start

If you are curious about what an AI-ready data setup would look like for your business, we are happy to talk it through. Request a demo of the platform to see agent mode on real data, or talk to one of our experts about the right first step for your team.

The post How Reflective Data Is Built for the AI Era, and How We Help You Get There appeared first on Reflective Data.

In this article, we’re discussing solutions for exporting GA4 data into alternative destinations, including Snowflake, Redshift, S3 and others.

Option 1. Exporting from BigQuery to another destination

The first option many companies opt for is using the native export to send data from GA4 to BigQuery using the native export provided by Google. They would then build a custom pipeline or use a data transfer service to move/copy data from BigQuery to their desired destination.

While this solution works for some companies, there are a few significant issues involved here.

Paying for two platforms

If the only reason to use BigQuery is to be the middleman holding your data before sending it to your desired platform, it’s hard to justify paying for it. A better solution would be exporting data from GA4 to the final destination directly.

Limited to 1 million events per day

The free version of GA4 is limited to only 1 million events per day. This is not enough for most companies with serious traffic. You could upgrade to GA4 360, but that’s out of budget or difficult to justify for many.

See below for solutions that overcome the 1 million event limit entirely.

Data delays

The daily batch load timing from GA4 to BigQuery can be inconsistent. This can break any pipelines moving data from BigQuery to your final destination. Not to mention any BI and other workflows that depend on the data being available at a certain time.

See below for solutions that deliver data to your destination by a fixed time every day.

Option 2. Parallel Tracking

Parallel Tracking is a tool that duplicates your GA4 hits during collection and processes them exactly as GA4 does. The data is then stored in your data warehouse (BigQuery, Snowflake, Redshift, S3 or any other vendor is supported).

Read more about Parallel Tracking

The setup is very easy and depends on how GA4 has been implemented on your site: Google Tag Manager, Server-Side GTM, CRM Plugin, gtag.js and many other methods are supported out of the box.

The only other step left to configure is providing Parallel Tracking access to your data destination – usually this is going to be a key file or some other format of access token.

Parallel Tracking comes with several benefits over the native export to BigQuery.

Avoid paying for two data storage platforms

Parallel Tracking allows you to send your GA4 data straight into your desired data destination – be it Snowflake, Redshift, S3 or any other vendor out there.

No 1 million event limit

Parallel Tracking does not have a daily limit. Some Fortune 100 companies are collecting 100M+ events daily.

Reliable schedule

Unlike the native export, Parallel Tracking sends data into your data warehouse exactly when you need it. Real-time and hourly exports are also available.

Cost

Compared to GA4 360, Parallel Tracking is several times cheaper. Click here to learn more and get a quote.

If you have any thoughts or know another alternative to the native export, please share your comments below.

The post How to Export GA4 Data to Snowflake, Redshift, S3 or Another Warehouse appeared first on Reflective Data.

In this article, we are going through the steps to enable Parallel Tracking to export over 1 million events to BigQuery without upgrading to GA360.

How to check your Firebase Analytics event count

If you have GA4 to BigQuery data export already enabled for your Firebase Analytics account, you can see the daily event count in the GA4 admin panel.

Go to Admin panel –> Product links –> BigQuery links and look for the “Total estimated daily event volume to be exported” in the Event data section.

Alternatively, you can navigate to Reports –> Engagement –> Events and see the event count there.

Select the last 30 days and examine the total number of events. If it’s close to or over 30 million, consider implementing Parallel Tracking to avoid data loss.

How to enable Parallel Tracking for Firebase Analytics GA4

Enabling Parallel Tracking for Firebase Analytics GA4 to export over 1 million events to BigQuery (or another data warehouse) is rather straightforward. Below are the steps to get the pipeline up and running.

Enable Server-Side Google Tag Manager

For Android apps, you need to update your AndroidManifest.xml file by adding the following line.

<meta-data android:name="google_analytics_sgtm_upload_enabled" android:value="true" />

For iOS apps, you need to update your Info.plist file by adding the following line inside of the first <dict> element.

<key>GOOGLE_ANALYTICS_SGTM_UPLOAD_ENABLED</key>
<true/>

Sign up with Parallel Tracking

Next, you need to get an account for Parallel Tracking. Please schedule your free consultation using the link below.

Link for Parallel Tracking.

Your account manager will then assist you by connecting the Parallel Tracking data processor with your BigQuery dataset.

Once BigQuery is connected, all Firebase Analytics GA4 events will flow into your BigQuery dataset like normal, and there will be no limit to the number of hits you can export per day.

Enable Server-Side routing in GA4

In the GA4 admin panel, navigate to Data streams and enable server-side tagging for each data stream. To do so, you need to select your stream, click “Configure SDK settings” and then “Configure server-side Tag Manager”.

You need to insert the “Server container URL” provided by your account manager or use your own if you are using Server-Side Tag Manager already.

While validating the setup, you can keep the percentage at 10%. After validation, this should be changed to 100%.

How Parallel Tracking works

Parallel Tracking for Firebase Analytics GA4 duplicates all events that your app is sending to GA4 to another data processing endpoint, where data gets processed 100% the way GA4 itself does it.

In order to enable event duplication, all events must be routed through Server-Side Google Tag Manager. This is a standard process described in the official documentation from Google.

The data you are receiving from Parallel Tracking is 100% the same as you would get with the native BigQuery export. The schema is exactly the same. The only difference is that there is no limit on the number of events you can export per day.

Conclusion

If you need to export over 1 million events per day from Firebase Analytics GA4 into your BigQuery dataset and don’t want to upgrade to GA360, then Parallel Tracking is your best option.

Getting started with Parallel Tracking for Firebase Analytics GA4 is very easy; your account manager will walk you through all the steps and provide all the technical support you need.

Learn more about Parallel Tracking and schedule a free consultation session.

The post How To Export Over 1 Million Events From Firebase Analytics GA4 To BigQuery Without GA360 appeared first on Reflective Data.

In this article, we’re going to explain some of the approaches you should be taking to make sure you get the most out of your valuable data without losing any of the valuable insights. Oh, and without having to upgrade to GA360.

Common problems with GA4 for high-traffic websites and apps

1. Quota Limits and Sampling

• Issue: GA4 has quotas for API calls, data collection, and BigQuery exports. For high-traffic sites, these limits can be exceeded, leading to incomplete or delayed data.
• Symptoms:
  • Delayed or partial data in reports.
  • Data sampling in the interface or when querying large datasets.
  • Only partial data is exported to BigQuery every day

2. Latency in Data Processing

• Issue: High traffic volumes can lead to delays in GA4 processing, resulting in longer wait times for data to appear in reports.
• Symptoms:
  • Real-time reports lagging or missing data.
  • Delays in standard report updates.

3. Data Thresholding

• Issue: GA4 applies data thresholding for reports that include user identifiers or demographic data, especially when dealing with large volumes of traffic.
• Symptoms:
  • Reports showing incomplete or aggregated data.
  • Warning messages about thresholding.

4. Event Limitations

• Issue: GA4 has a limit of 500 distinct event names per property. High-traffic sites often generate a large variety of events, which can exceed this limit.
• Symptoms:
  • Events not being logged or missing in reports.

5. Data Retention Settings

• Issue: GA4 defaults to a data retention period of 2 or 14 months for detailed user data, which can be insufficient for long-term analysis.
• Symptoms:
  • Historical data is no longer accessible in GA4 after the retention period.

6. Overwhelming Volume of Custom Dimensions/Parameters

• Issue: GA4 allows up to 50 custom dimensions per property. High-traffic apps often push this limit, causing issues with tracking extra custom data.
• Symptoms:
  • Missing or dropped dimensions in reports.

7. Cross-Platform and Cross-Domain Tracking

• Issue: High-traffic businesses with complex setups (e.g., mobile app + website) may face difficulties implementing seamless cross-platform tracking.
• Symptoms:
  • Duplicate or fragmented user sessions across platforms.

8. Debugging and Testing Challenges

• Issue: High traffic can make it difficult to test changes without impacting production data.
• Symptoms:
  • Errors in tracking configurations affecting a large user base.

9. Increased Cost for BigQuery Analysis

• Issue: Exporting large volumes of data to BigQuery can result in significant costs, especially when running frequent or complex queries.
• Symptoms:
  • Unexpectedly high cloud bills for BigQuery.

10. User Privacy and Compliance Challenges

• Issue: High-traffic businesses are more likely to face scrutiny regarding GDPR, CCPA, and other privacy laws.
• Symptoms:
  • Compliance risks due to insufficient data anonymization or consent management.

If any of the issues mentioned above sounds familiar, continue reading as there are solutions to all of them.

How to tackle common issues with GA4 for high-traffic websites and apps

As companies start hitting the limits in the free version of GA4, oftentimes they consider upgrading to GA360. True, it will solve some of the issues like offering a higher number of daily exported events to BigQuery, more custom event parameters, dimensions etc. but eventually, you may end up hitting those, too. Besides, upgrading to 360 doesn’t solve some of the issues around GDPR, and data sampling can still be an issue. Not to mention the cost…

The solution we are discussing in this article is known as Parallel Tracking.

In short, here’s how Parallel Tracking for GA4 works.

1. Tracking Code Adjustment

A minor update to the Google Analytics tracking code is necessary to enable streaming all hits to Reflective Data’s endpoint. This approach, called Parallel Tracking, is compatible with all types of GA4 implementations, including GTM, server-side setups, gtag.js, and third-party applications.

2. Event Processing

The Data Processing Engine captures and processes all events in the same manner as Google Analytics. Designed for nearly unlimited scalability, it avoids the data processing restrictions found in GA4. All operations are hosted on Google Cloud, with the flexibility to choose your preferred region.

3. Data Storage in Your Warehouse

By default, data is stored in Google BigQuery, though we support other data warehouses such as AWS, Azure, and Snowflake. All data is fully processed and ready for reporting within seconds.

Reflective Data does not store any events or other data on its servers at any time.

How does Parallel Tracking solve common limitations in GA4

1. Quota Limits and Sampling

• Issue: GA4 has quotas for API calls, data collection, and BigQuery exports.
• Solution:
  • Parallel Tracking for GA4 has no limits on the BigQuery exports. We know sites that are exporting well over 10M events per day without losing any events.

2. Latency in Data Processing

• Issue: High traffic volumes can lead to delays in GA4 processing, resulting in longer wait times for data to appear in reports.
• Solution:
  • With Parallel Tracking, you can have GA4 events processed and stored in your data warehouse within seconds.

3. Data Thresholding

• Issue: GA4 applies data thresholding for reports that include user identifiers or demographic data, especially when dealing with large volumes of traffic.
• Solution:
  • Parallel Tracking for GA4 allows you to work with 100% of the data. No limits on data cardinality or event counts.

4. Event Limitations

• Issue: GA4 has a limit of 500 distinct event names per property. High-traffic sites often generate a large variety of events, which can exceed this limit.
• Solution:
  • With Parallel Tracking, there are no limits to distinct event names. Create, trigger and send as many unique events as necessary for the use case.

5. Data Retention Settings

• Issue: GA4 defaults to a data retention period of 2 or 14 months for detailed user data, which can be insufficient for long-term analysis.
• Solution:
  • Using Parallel Tracking to send GA4 data into a data warehouse of your choice (BigQuery, S3, Snowflake, Redshift etc.) ensures you have full control and ownership of your data.

6. Overwhelming Volume of Custom Dimensions/Parameters

• Issue: GA4 allows up to 50 custom dimensions per property. High-traffic apps often push this limit, causing issues with tracking extra custom data.
• Solution:
  • Parallel Tracking doesn’t set any limits on the number of custom dimensions, metrics or event parameters that you are allowed to collect.

7. Cross-Platform and Cross-Domain Tracking

• Issue: High-traffic businesses with complex setups (e.g., mobile app + website) may face difficulties implementing seamless cross-platform tracking.
• Solution:
  • With Parallel Tracking for GA4 comes the ultimate flexibility around distinguishing and joining data from various sources. This includes web domains (including subdomains), mobile apps, web apps, server applications and more.

8. Debugging and Testing Challenges

• Issue: High traffic can make it difficult to test changes without impacting production data.
• Solution:
  • Parallel Tracking comes with a robust environment for staging and testing all changes before pushing them into production. Never lose valuable data because of a broken tracking system again.

9. Increased Cost for BigQuery Analysis

• Issue: Exporting large volumes of data to BigQuery can result in significant costs, especially when running frequent or complex queries.
• Solution:
  • Parallel Tracking gives you full control over your data pipeline. This means you can adjust the settings to collect only what you need to avoid overpaying for the data warehouse vendor.

10. User Privacy and Compliance Challenges

• Issue: High-traffic businesses are more likely to face scrutiny regarding GDPR, CCPA, and other privacy laws.
• Solution:
  • With Parallel Tracking you can choose in which region your data is processed and stored. For GDPR compliance, for example, several sites keep all their data within the EU (this includes collection, processing and long-term storage).

As you can see, Parallel Tracking is the best companion to your GA4 implementation on a high-traffic website. Not only is it multiple times more affordable than its alternatives (including GA360) but it’s the only platform that provides a solution to all of the common issues.

If you want to learn more about GA4 Parallel Tracking, please schedule a free consultation session with one of Reflective Data’s account managers or data engineers (depending on your needs).

The post Optimal GA4 Setup For High-Traffic Websites and Apps in 2025 appeared first on Reflective Data.

GA360 is expensive and we felt like, for our use case, it would be too much. I was delighted to learn that Reflective Data can help us collect over 1M events per day in our BigQuery dataset for a fraction of the cost.

Jurgita, Digital Data Analyst, Vilnius

GA360 is a great tool, and for the enterprises that can afford and justify the cost, probably the best analytics tool they can invest in. At the same time, many companies don’t have the budget to pay upwards of $150k for an analytics tool.

The challenge

One of the best features of GA4 over the previous version is that even the free version has the BigQuery export pipeline available.

The free version of GA4, though, has a limit on how many events can be exported each day. More specifically, this limit is set at 1M events per day. Barbora, like many companies with large traffic numbers, was reaching this limit in GA4 but at the same time wasn’t able to justify the cost of GA360.

The solution

At Reflective Data, we built a solution called Parallel Tracking for GA4.

Here’s how it works.

Parallel Tracking duplicates all HTTP requests going from your site or app to GA4 and sends them to Reflective Data’s processing endpoint.

Data is then processed just like GA4 does it and inserted into your BigQuery dataset. There is no limit on the daily event count with Parallel Tracking.

Getting started with Parallel Tracking is easy as 1, 2, 3.

Step 1: Tracking code modification

After signing up for Parallel Tracking, you’ll have to enable it by modifying your GA4 implementation. We have plug-and-play solutions for Google Tag Manager, gtag.js, Measurement Protocol and most other implementation methods that GA4 has.

Step 2: Pipeline activation

In order to activate the pipeline, all you need to do is provide Reflective Data with a Google Cloud Platform Service Account key file. After providing the key file, GA4 data will start flowing into your BigQuery dataset.

Step 3: Querying the data

Once the pipeline is active, you can start querying your GA4 data just like with the default GA4 to BigQuery data export.

Conclusion

If your daily event volume in GA4 is close to or exceeds 1 million then you have two options. Upgrade to GA360 or implement Parallel Tracking. If the event volume exceeding 1 million is the only reason you’re looking to upgrade, Parallel Tracking is likely a better option as it is several times more affordable compared to GA360.

Ending with another quote from the customer here.

I guess you could say we were your average enterprise with LOTS of legacy data infrastructure that had been built over many years. This system was extremely complex and very expensive to maintain. When Reflective Data came in, they acted as true professionals, worked very closely with our IT and came up with the plan that pleased everyone.

Today, being on the new cloud-based data infrastructure for almost a year now, I can say with all certainty that this project was a success. Not only are we saving tens of thousands of dollars every month on the infrastructure alone, the amount of hours it takes to maintain the system has gone from hundreds down to a ten or so. This has huge impact on our business. Implementing anything new would’ve taken at least 6 months with the old system, now it’s a matter of week or two to get everything up and running.

Last but not the least, Reflective Data saved us another $150k year as we no longer needed to use GA360 and instead implemented their Parallel Tracking solution for GA4.

Daria, VP of Marketing, Warsaw

It’s feedback like this that makes us love the work we do even more! Get in touch and learn how we can help you, too.

For more case studies, see here.

The post Case Study: Overcoming The 1 Million Event Limit in GA4 Without Upgrading to GA360 appeared first on Reflective Data.

Google Analytics 4 (GA4) is not yet fully GDPR compliant. Google is working to make GA4 compliant with the GDPR, but it is a complex process that is still ongoing.

Here are some of the challenges that Google is facing in making GA4 GDPR compliant:

• The GDPR requires companies to obtain explicit consent from users before collecting or processing their personal data. GA4 collects data about users, including their IP addresses, which can be used to identify them.
• The GDPR also requires companies to provide users with access to their personal data and to allow them to delete their data. GA4 does not currently provide users with these options.
• The GDPR requires companies to take steps to protect the privacy of user data. GA4 does not currently take all of the necessary steps to protect user privacy.

Google is working to address these challenges and to make GA4 GDPR compliant. However, it is not clear when GA4 will be fully compliant with the GDPR.

In the meantime, companies that use GA4 should take steps to comply with the GDPR on their own. This includes obtaining explicit consent from users before collecting or processing their personal data, providing users with access to their personal data, and allowing users to delete their data. Companies should also take steps to protect the privacy of user data.

If you are using GA4, you should consult with a privacy lawyer to ensure that you are complying with the GDPR.

Here’s how we keep GA4 GDPR compliant

In short, for traffic coming from the EU, we skip the the step where GA4 tracker sends data to GA4 servers. Instead, we process this data within the EU (just like GA4 does on their servers in the US) and send it straight into a BigQuery dataset located within the EU.

Reflective Data Parallel Tracking Solution

Reflective Data offers a solution that can help you make your GA4 implementation GDPR compliant. The Parallel Tracking solution allows you to collect data from users in the EU without sending the data to the US. The data is instead processed and stored in the EU. This ensures that your GA4 implementation is fully GDPR compliant.

Schedule a Free Consultation

If you are interested in learning more about how to make your GA4 implementation GDPR compliant, you can schedule a free consultation with Reflective Data. During the consultation, one of Reflective Data’s data experts will discuss your specific needs and help you determine if the Parallel Tracking solution is right for you.

Questions?

If you have any questions about how to make your GA4 implementation GDPR compliant, please feel free to ask in the comments below.

The post GA4 Is Not GDPR Compliant – Here’s How to Use GA4 in the EU Safely appeared first on Reflective Data.

This came as an unwelcome surprise for anyone working in the experimentation industry. Even if you didn’t use the tool itself, it was the first tool most newcomers used to get themselves into experimenting on their websites.

For a while, Google Optimize going away was everything people talked about on Twitter and LinkedIn.

Exporting Experiment Data From Google Optimize

Since several of our existing clients asked for it, we built Google Optimize Data Exporter to store your experiment data for as long as you need it. It supports almost any data destination, including popular ones like Google BigQuery, Amazon S3 and Snowflake.

Google Optimize Data Exporter runs on the same robust and scalable Reflective Data Infrastructure that you hopefully already know and love.

We’ve made the process of exporting your Google Optimize data as simple as possible. Here’s a quick overview.

1. Planning and scoping

Get in touch with one of our data analysts to plan your Google Optimize Data export. The main questions to answer are the list of experiments, dimensions, metrics, time frames and the data destination you wish to use for your Optimize data export.

2. Data export and storage

Executing the plan. Our data analyst will configure Reflective Data Export System to pull the requested data from your Google Optimize instance and store at your chosen data storage destination.

Most exports use Google BigQuery as a data destination.

3. Reporting and consultation

The post Export Experiment Data From Google Optimize – While You Still Can appeared first on Reflective Data.