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.

The amount of load that Reflective Data was able to lift from the shoulders of my team was unbeliavable. Without their help, we’d still be building out the pipelines and never gotten to the level of advanced analysis and ML that we’re able to do now. They let us focus on what brings the most value to our business.

Melanie, Director of Data Analytics, Frankfurt

At Reflective Data, we’ve worked with companies big and small. This means we have seen all levels of maturity when it comes to the infrastructure and knowledge around data pipelines and data warehouses.

Some of the most challenging projects have been enterprises with quite some infrastructure, legacy pipelines, and of course, opinions. Smaller businesses are just starting to adopt the concept of having all of their data stored in a data warehouse but many enterprises have been doing this for a decade!

The challenge

When many of the enterprises that we’ve worked with started building their data pipelines, they didn’t have tools like Airflow, BigQuery etc. that we use and love today. This means the bulk of it was built in-house. Even the concept of cloud computing was in its early days and most operations were kept on-premise.

The challenge with this kind of setup starts by understanding the existing setup. In some cases, the documentation is close to none and the people that built it are no longer with the company. This alone can take a month or so – mapping everything out, understanding the structure, creating the plan for moving forward.

Another challenge is getting everyone on the team on board. More often than not there are people who value the work that has been put into the old system over the years so much that it blinds them from seeing the obvious benefits of moving to a much more modern infrastructure.

The solution

When working with the enterprise and legacy infrastructure, nothing happens overnight. Below are the phases of a typical project of getting an enterprise client onto a modern cloud-based data infrastructure.

Phase 1: understanding and mapping the existing situation

With most enterprises, it’s not just one team or system that depends on the data infrastructure. More often than not, this is the backbone of the entire business. This means we need to make sure we understand every aspect of the current system, where it gets the data, how it’s being processed and what processes depend on this data.

Phase 2: planning the infrastructure

We do our best to work closely with all teams involved to make sure their needs are taken into account. This means a series of on-hands meetings where we learn about their use cases and problems they’re having with the existing setup. The output of this phase is a clear plan for moving forward, including the tool stack, reporting mechanisms and several feedback rounds to make sure everyones’ needs are taken into account.

Phase 3: implementation

Depending on the in-house knowledge, resources and other aspects, a company can decide to implement the plan themselves and continue using Reflective Data as a consultant or hire us to handle the technical execution as well. By far, the most effective arrangement in our experience has been where we do the bulk of the work while including a few technical people from the client’s side in every step of the process. In some cases, those people is hired specifically for this purpose.

Phase 4: monitoring, reporting and integrations

The whole point of having high-quality data is to make it actionable. Of course, we handle core integrations within the implementation phase but in a sense, data infrastructure is a growing organism that needs constant attention. Reflective Data is here to build long-term relationships with its clients, ready to help whenever there’s a new data source to be added, a report to be built or if a new team member needs training.

Conclusion

Moving away from a legacy data infrastructure is one of the best actions an enterprise can take towards being more data-driven, more effective in managing the infrastructure and, in all reality, keeping up with the competition.

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.

Julien, VP of Marketing, Austin

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: Building and maintaining a Data Pipeline and Data Warehouse for the Enterprise appeared first on Reflective Data.

With the help from Reflective Data and using their custom data pipeline for Google Analytics, we were able to avoid sending data to Google Analytics, store everything within the EU and still benefit from the rich and actionable dataset you get with Google Analytics.

Aaron, Chief Data Officer

Everything mentioned in this article applies to both Google Analytics Universal Analytics and GA4, including the built solutions.

Data protection and privacy rules are getting tougher all over the world. This is especially true for the European Union and even more so for some specific industries. Including finance, medical and others that handle sensitive information about their users.

While Google Analytics has been making some improvements in the privacy area and is GDPR compliant, this is not enough for many businesses and industries.

At Reflective Data, we’re often working with companies that are under close monitoring of their regulators. To help them out, we’ve built custom solutions that allow storing Google Analytics data within the European Union or sometimes even completely locally, on the servers of our client.

The challenge

Do we want it or not, the regulations for collecting, processing and storing data are getting stiffer each year. European Union, with rules like GDPR, is a trendsetter in data protection.

While it’s good from a customers’ perspective, following all those rules and regulations can be quite a challenge for businesses that have to follow them. Especially, as new rules are introduced and the penalties for not following them can reach millions.

More often than not, the regulations are being launched faster than companies can adopt. Even if the company themselves are doing everything right, it’s likely that some third-party software they’re using is lacking behind.

At Reflective Data, we have been contacted by numerous companies that, for a reason or another, aren’t able to use Google Analytics but would still require a similar dataset and comparable functionality. Let’s be honest, Google Analytics and its Universal Analytics data model is still one of the best ones available for marketing attribution and website user behavior analysis.

Yes, Google Analytics 4 will be the future of tracking but it’s nowhere near being ready for production for most businesses due to lacking several critical features.

The solution

One of our most popular tools is the Parallel Tracking for Google Analytics. It’s a system that allows sending raw hit-level Google Analytics data into a data warehouse. Most commonly, our clients choose this solution for the following reasons.

• They hit the 10M/hits/mo limit
• Problems with data sampling
• Looking for alternatives for Google Analytics 360
• Need access to raw hit-level data

These are all nice features that our clients love but there’s one more – Parallel Tracking can work without sending data to Google Analytics at all. This is thanks to how our technology was built. Instead of pulling data from Google Analytics using the Reporting API (as many solutions do), we are duplicating all hits that are sent to Google’s data processing endpoint and sending them to our engine as well. This means, with a simple tracking code modification, we can disable hits being sent to Google Analytics.

Our data processing engine works very similarly to what’s happening in Google Analytics. Hits are processed and enriched using the same methodology and sessions are processed just like in Google Analytics.

Ultimately, this means you’ll get the best from both worlds. The rich and actionable dataset of Google Analytics and full ownership of your data. So, whatever regulations apply to how you can store this kind of data, now you have a solution to comply with them.

Everything mentioned in this article applies to both Google Analytics Universal Analytics and GA4, including the built solutions.

Conclusion

There are many reasons why you’d want to use Google Analytics as your analytics platform. Including the rich data model that works for both marketing attribution and user behavior analysis, (almost) unlimited amount of resources, great community, ease of finding people that can work with this model and more.

If, for some reason, you can’t use Google Analytics. Could be because they’re storing data outside of the EU or that you need to store everything locally. Then we have a solution for you!

For details and contact information, check out the product page for Parallel Tracking.

Ending with another quote from a customer here.

Before joining the financial institution that I’m currently working for, I had been a marketing director for various e-commerce companies. This meant that I was really used to tools like Google Analytics. Now, working in finance, I learned that using Google Analytics was not an option due to several regulations and we had to store all data locally on our own servers.

We had some kind of an in-house solution but that was nowhere near the capabilites and functionality I was used to. I was really lucky to learn about Reflective Data and their Parallel Tracking solution! They were really helpful, worked closely with our team to learn about our needs and finally built a solution that exceeded our expectations. 10/10 would recommend to anyone that for some reason isn’t allowed to use Google Analytics.

Michelle, Director of Online Marketing, Frankfurt

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: Storing Google Analytics Data Within The European Union or Locally appeared first on Reflective Data.

About the client

Our client is a successful e-commerce business, headquartered in the UK.

Their focus is on food supplements, nutritional products, and diet plans.

Depending on a season, their monthly online revenue is 1-1.5 million GBP (1.3 – 2 million USD). This comes from around 14k orders every month.

Due to NDAs, we are not allowed to disclose the name of the client. Everything else in this case study remains unchanged.

The challenge

When the company in the focus of this case study first contacted us, their main concerns were about properly tracking customer lifetime value (LTV) and churn. Being in the business of food supplements where, naturally, a big chunk of revenue is coming through subscriptions (automatically recurring orders), keeping track of these metrics is extremely important.

Tech stack

The main tech tool stack for this client was a fairly standard one for an e-commerce business of this size. Shopify Plus for website and order processing, ReCharge for handling subscriptions, Google Analytics for general reporting, and ShipStation for managing shipments.

***

While Shopify can provide you with reports for both LTV and churn (via ReCharge analytics), it is rather limited when it comes to attributing those numbers to your marketing and other efforts like CRO or A/B testing.

The client pointed out three main areas where they need a more detailed look into LTV and churn-related metrics:

• Ad Spend (mostly Google Ads and Facebook)
• E-mail campaigns
• CRO and A/B testing

The solution

After having several meetings with various teams from the client’s side, we had a quite good understanding of what kind of reports they’re trying to build and what kind of data it requires.

In order to accommodate all of their needs, we had to involve data from the following sources:

• Shopify
• ReCharge
• Google Analytics
• Google Ads
• Facebook Ads
• ShipStation
• Google Optimize

As our solution involved data from more than three sources, it was quite obvious that setting up a data warehouse is required. The client decided to go with our default recommendation for data warehouse software — BigQuery.

Getting data in BigQuery

As LTV and churn had always been such essential metrics for the client, they had already tried solving this in-house. Their existing tool stack consisted of Stitch, Supermetrics, MySQL database and Google Sheets. While this could’ve worked in theory, the reality was a really slow system that constantly failed and produced inaccurate numbers.

Our solution involved using Parallel Tracking technology for Google Analytics and a custom data pipeline for the rest of the sources. This enabled us to modify the ETL for maximum efficiency while meeting all the data requirements.

Building the reports

Since our client was already familiar with the rest of Google’s Marketing Suite and it works really well with BigQuery, using Data Studio for building the reports was an easy choice. Besides being a free (!) tool, by leveraging the BigQuery BI Engine, Data Studio can provide you with the best performance as well!

After understanding the reports that would be used most frequently, we built a set of 2 main dashboards:

• LTV per source/medium/country/product/campaign/age
• Churn per source/medium/country/product/campaign/age

These dashboards provide the client with a good overview of their key metrics and how they correlate with some of the more common dimensions/attributes. This is a good stepping stone for a deeper analysis and digging for insights.

Luckily, the client’s marketing team already had a few people that were comfortable working with SQL, Jupyter Notebooks etc. This meant that by pointing them in the right direction and providing a few guidelines, they had everything needed for digging deeper into data stored in BigQuery.

Besides dashboards and enabling ad-hoc analysis, a few teams also wished for a periodic automated report in their inbox. This was also something we were happy to set up using some custom software on Google Cloud.

Conclusion

While this project started as a rather standard one for us, it turned out to include several custom parts that made it fun for us and enabled maximum effectiveness for the client.

What better way to take it all together than a few words from the team we worked with on the client’s side.

We turned to Reflective Data with a rather concrete goal in mind — to fix our LTV and churn tracking and reporting. Being in the business of  food supplements, a large portion of our revenues come from recurring orders. This makes keeping track of those metrics extremely important for us. Not only was Reflective Data able to set up a proper tracking system, they helped us figure out the dashboards, email reports and helped our analysts on SQL analysis! Couldn’t be happier about this!

Nothing’s better than such warm words from a happy client!

If you, too, need help with your analytics & data setup, get in touch with us for a free consultation session. I’m sure we can find a solution that suits both of us.

The post Case Study: Sending Data From Shopify and Google Analytics to BigQuery for More Advanced Analysis appeared first on Reflective Data.

About the client

Our client, in this case study, is a large global e-commerce website, headquartered in the US.

Their main focus is on men’s clothing and they’re specialising in dress shirts, as well as ties, suits, casualwear, shoes and accessories.

Depending on a season, their monthly online revenue is between 10 and 15 million USD. This comes from around 45k monthly transactions.

Due to NDAs, we are not allowed to disclose the name of the client. Everything else in this case study remains unchanged.

The challenge

Working with skewed data can be worse than having no data at all. This is why we’re always promoting all sorts of analytics audits and making sure all data sources agree with each other. At the very least, you should know why the numbers in different tools don’t match (i.e. analytics doesn’t include offline sales but backend does).

Our client in this case study contacted us with a quite specific problem. They were running a decent CRO program with 4-6 A/B experiments running every month. The problem they had with the program, though, was that the numbers they saw in their testing tool Optimizely, Google Analytics and backend didn’t match. In fact, there was a ~35% discrepancy overall.

While it is almost impossible to reach 100% accuracy with Javascript based tools due to ad-blockers, cookie deletion etc. and some tools have different logic for calculation metrics like conversions, sessions, users — we knew that this discrepancy is way off the limits and immediate action is needed.

This kind of discrepancy was even more concerning as the client was actively running their CRO program. It wasn’t rare for them to see test results flip based on where they got their numbers (Google Analytics vs Optimizely). This put their entire CRO effort under question internally and the management wasn’t far from shutting it down. The results just weren’t trustworthy enough.

The solution

Even though the client described some rather clear symptoms, it is necessary to always start with a proper diagnosis of the problem. This way we can be sure that there indeed is a discrepancy between all these tools – in some cases, the problem can be in how you understand/read the numbers. Another goal for the diagnosis was to understand the size/reach of the problem.

Diagnosis

The very first thing we did to diagnose and measure the discrepancy was to get access to all data sources. That included the testing tool (Optimizely), Google Analytics and the client’s backend numbers. Next, we made sure the metrics are comparable (i.e. all the transactions we see in the backend are indeed supposed to show up in Google Analytics as well). We then put those numbers side-by-side in a spreadsheet and grouped them by date.

After analyzing the daily numbers, we came to the conclusion that there is indeed an average of 35% discrepancy between Optimizely and Google Analytics (less transactions in the testing tool). The discrepancy between Google Analytics and backend, on the other hand, was rather small — just below 3%. This can be considered OK for a Javascript-based analytics tool.

The discrepancy between Google Analytics and Optimizely meant we had to dig deeper on that side. Unfortunately, Optimizely doesn’t give access to the raw underlying transaction ID level data by default. Luckily, though, we were able to get this data from their support team. With Google Analytics, exporting transaction-level data was doable with a custom report and CSV export. For the Google Analytics dataset, we included dimensions that would give us some extra context — payment gateway, products, device category, country etc.

After pulling transaction-ID-level data from Optimizely and Google Analytics in spreadsheets, we wrote a quick function that would mark the transactions in Google Analytics that didn’t show up in Optimizely. Then it was time to start looking for some patterns. Is there something in common for all missing transactions?

This is how one version of this spreadsheet looked like. This was to highlight transactions in the backend that didn’t show up in Google Analytics.

Implementing the fixes

Since the website and payment processing system for this website were rather complex, it turned out there are more than one such patterns. They were all related to the use of various payment gateways, device categories and local sub-sites for specific countries.

In order to come up with a proper solution, we had to dig even deeper into how transaction tracking was set up for both Google Analytics and Optimizely. Luckily, we were able to detect the shortcomings quite fast and fixing them wasn’t rocket science either. After a few rounds of testing and a couple of A/A tests run in Optimizely, we were able to get the discrepancy number from 35% down to 2.5%.

The main reason for this mismatch was that while Google Tag Manager was in use to unify transaction tracking for Google Analytics, tracking snippets for Optimizely were all over the place. The solution involved moving all Optimizely tracking into Google Tag Manager and use the same triggers that were being used for Google Analytics.

Going forward

Since the site has a rather complicated structure with multiple payment gateways and different pages for different countries/markets, we wanted to make sure that after implementing the fixes, the discrepancy would not start sneaking in again.

The solution here was a proper monitoring system that would get data from Google Analytics, Optimizely and the backend. Since the client was already on Google Cloud, we recommended using BigQuery as their data warehouse technology. Besides being really fast and cost-effective, BigQuery has some of the best integrations which makes implementing and using it as a marketing data warehouse much easier.

Getting data into BigQuery

For Google Analytics data, we used a technology called Parallel Tracking. This allowed us to send raw hit-level unsampled Google Analytics into BigQuery. In real-time and for much cheaper than using Google Analytics 360.

To get data from Optimizely into BigQuery, we built a custom connector using Optimizely API. This solution allowed us to pull only the information that was necessary and make sure it’s always up to date.

Since the client had a custom backend infrastructure, we built a custom connector between that and BigQuery as well.

All connectors are now running on Google Cloud.

Reporting and alerts

In order for the client to be able to check the numbers from all three sources in one place, we built a dashboard using Google Data Studio which has a native connector with BigQuery.

To detect any discrepancies as soon as possible, we also created an automated reporting system with some custom code on Google Cloud Platform. This will send an email to relevant parties every time a certain threshold is passed. So far, it has already detected a few issues the client was able to fix before larger damage was done.

Conclusion

Overall, we were quite happy with the results of this project but I believe it’s better to end with a quote from the client.

We hadn’t worked with Reflective Data before but they were recommended by our friends in the industry. We needed a quick but reliable solution to our problem. Our management was questioning the results of our CRO program and we weren’t far from getting shut down.

Team at Reflective Data was able to immediately understand our problem and jumped right into solving it. I think all together it took just around 2 weeks for them to diagnose and together with out IT team fix the problems behind this rather large discrepancy.

After great success with our first project together, we’ve continued working with them on various data-related projects around our data warehouse, reporting and dashboards.

Director of e-commerce

We are so glad about these words from our client and it’s moments like this that give meaning to our work.  By the way, their CRO program has only grown since we were able to fix the mismatch. So, in a way, we were part of saving the jobs of an entire team.

Should you have similar problems with discrepancy or other data related requirements, please contact us and I’m quite sure we can work together and find a solution.

The post Case Study: Solving The Discrepancy Between A/B Testing Tool, Google Analytics and Backend Data For a Large E-Commerce Business appeared first on Reflective Data.