Best Practices

Data mishaps to watch for in operational analytics | Census

Parker Rogers
Parker Rogers December 31, 2021

Parker is a data community advocate at Census with a background in data analytics. He's interested in finding the best and most efficient ways to make use of data, and help other data folks in the community grow their careers. Salt Lake City, Utah, United States

In this article, you'll learn about unexpected mishaps that can occur while operationalizing data, as well as how to avoid them. Hidden roadblocks include:

  • API Quotas
  • "That's too much data"
  • Multiple writers

Syncing data from a data warehouse to operational tools can dramatically improve the efficiency and effectiveness of your business. This is called operationalizing your data. Here are some examples:

  1. Powering targeted email marketing flows
  2. Helping customer success teams access the latest data about your users
  3. Supplying data to digital ads platforms for highly-personalized ad campaigns

Like anything that drives value, operationalizing data can have unexpected roadblocks. It can be time-consuming, error-prone, and costly to troubleshoot these problems when you run into them. In his recent talk at DRE CON, our founder and CEO, Boris Jabes, discussed the various mishaps that can happen on the way to operationalizing data, as well as how to avoid them. I'm here to break down those cautionary tales, but you can see the full presentation here.

If you are helping your company operationalize your data in any way, this article will save you a great deal of time, frustration, and money.

Roadblock one: API quotas

This is the most prevalent disaster. Every operational application, whether it’s a CRM, marketing automation tool, sales tool, etc., comes with API quotas. You can easily overwhelm these applications when you write data into them. Furthermore, the documentation for the API quotas isn't always the easiest to follow.  

You can’t just assume “I’m going to hit the data at this rate because the docs say so." Something can still go wrong, no matter how closely you follow the docs, and it can cost you a lot of money. The amount of data you write in a given day likely has both velocity limitations and quantity limitations.

Solution: Spend time to deeply understand the API limitations of each application. Learn how to back off and build incrementally on your system. It’s not easy, but it’s necessary if you want to save money and ensure accurate and up-to-date data.

Roadblock two: "That's too much data"

This may seem almost impossible, but there is, in fact, such a thing as pushing too much data. There are countless applications out there that will happily accept new rows and new columns of data without overwhelming the API quota. However, they don’t make it easy to remove data. If you have one bad JOIN statement (we’ve all been there), you might accidentally push millions of new rows of data that you cannot undo. This can cause countless issues, including:

  • Email marketing tools charing you more money
  • Duplicate emails going out to prospects (ouch)
  • Application slowdowns as they try to process too much data

Solution: Consistently monitor if the tables you are pushing have more data than you expect them to.

Roadblock three: Multiple writers

When you enter the world of operational data, you're not the only writer and you don’t control the application database. There are likely lots of other tools placing data in these applications simultaneously, which can cause your data to be overwritten and duplicated. When this data is inaccurate, the data team is to blame even though they didn't have the knowledge of the other writer(s).  

Solution: Develop a hub and spoke model where data flows into a single hub (data warehouse) and out of it via a reverse ETL tool like Census. This lets you control and test all your syncs, including whether or not other syncs are in progress, before pushing data out to a business application. Additionally, you need to align closely with the various departments in your organization so that they don’t freely write data into these applications.

An interim solution is to own a certain number of fields within an application. Example: You align with your customer success team so that they know not two write data into any fields regarding product usage.

Bonus mishaps to look out for:

  • The case of disappearing views.
  • Supposed “schema-less” applications.
  • Date and Time issues. (You experienced this before. 🙃)
  • Duplicate entries.
  • Orchestrating data syncs rather than scheduling data syncs.
  • Basic syntax issues. (Always pay attention to the semantics of applications.)

Don't let all these scary data stories chase you away from your operational analytics dreams. We've created the most reliable (and fastest) reverse ETL tool on the market to take your data worries away (and have a roster of in-house data experts to help you avoid these stumbling blocks). Interested in learning more? Try Census for free today!

Related articles

Customer Stories
Built With Census Embedded: Labelbox Becomes Data Warehouse-Native
Built With Census Embedded: Labelbox Becomes Data Warehouse-Native

Every business’s best source of truth is in their cloud data warehouse. If you’re a SaaS provider, your customer’s best data is in their cloud data warehouse, too.

Best Practices
Keeping Data Private with the Composable CDP
Keeping Data Private with the Composable CDP

One of the benefits of composing your Customer Data Platform on your data warehouse is enforcing and maintaining strong controls over how, where, and to whom your data is exposed.

Product News
Sync data 100x faster on Snowflake with Census Live Syncs
Sync data 100x faster on Snowflake with Census Live Syncs

For years, working with high-quality data in real time was an elusive goal for data teams. Two hurdles blocked real-time data activation on Snowflake from becoming a reality: Lack of low-latency data flows and transformation pipelines The compute cost of running queries at high frequency in order to provide real-time insights Today, we’re solving both of those challenges by partnering with Snowflake to support our real-time Live Syncs, which can be 100 times faster and 100 times cheaper to operate than traditional Reverse ETL. You can create a Live Sync using any Snowflake table (including Dynamic Tables) as a source, and sync data to over 200 business tools within seconds. We’re proud to offer the fastest Reverse ETL platform on the planet, and the only one capable of real-time activation with Snowflake. 👉 Luke Ambrosetti discusses Live Sync architecture in-depth on Snowflake’s Medium blog here. Real-Time Composable CDP with Snowflake Developed alongside Snowflake’s product team, we’re excited to enable the fastest-ever data activation on Snowflake. Today marks a massive paradigm shift in how quickly companies can leverage their first-party data to stay ahead of their competition. In the past, businesses had to implement their real-time use cases outside their Data Cloud by building a separate fast path, through hosted custom infrastructure and event buses, or piles of if-this-then-that no-code hacks — all with painful limitations such as lack of scalability, data silos, and low adaptability. Census Live Syncs were born to tear down the latency barrier that previously prevented companies from centralizing these integrations with all of their others. Census Live Syncs and Snowflake now combine to offer real-time CDP capabilities without having to abandon the Data Cloud. This Composable CDP approach transforms the Data Cloud infrastructure that companies already have into an engine that drives business growth and revenue, delivering huge cost savings and data-driven decisions without complex engineering. Together we’re enabling marketing and business teams to interact with customers at the moment of intent, deliver the most personalized recommendations, and update AI models with the freshest insights. Doing the Math: 100x Faster and 100x Cheaper There are two primary ways to use Census Live Syncs — through Snowflake Dynamic Tables, or directly through Snowflake Streams. Near real time: Dynamic Tables have a target lag of minimum 1 minute (as of March 2024). Real time: Live Syncs can operate off a Snowflake Stream directly to achieve true real-time activation in single-digit seconds. Using a real-world example, one of our customers was looking for real-time activation to personalize in-app content immediately. They replaced their previous hourly process with Census Live Syncs, achieving an end-to-end latency of <1 minute. They observed that Live Syncs are 144 times cheaper and 150 times faster than their previous Reverse ETL process. It’s rare to offer customers multiple orders of magnitude of improvement as part of a product release, but we did the math. Continuous Syncs (traditional Reverse ETL) Census Live Syncs Improvement Cost 24 hours = 24 Snowflake credits. 24 * $2 * 30 = $1440/month ⅙ of a credit per day. ⅙ * $2 * 30 = $10/month 144x Speed Transformation hourly job + 15 minutes for ETL = 75 minutes on average 30 seconds on average 150x Cost The previous method of lowest latency Reverse ETL, called Continuous Syncs, required a Snowflake compute platform to be live 24/7 in order to continuously detect changes. This was expensive and also wasteful for datasets that don’t change often. Assuming that one Snowflake credit is on average $2, traditional Reverse ETL costs 24 credits * $2 * 30 days = $1440 per month. Using Snowflake’s Streams to detect changes offers a huge saving in credits to detect changes, just 1/6th of a single credit in equivalent cost, lowering the cost to $10 per month. Speed Real-time activation also requires ETL and transformation workflows to be low latency. In this example, our customer needed real-time activation of an event that occurs 10 times per day. First, we reduced their ETL processing time to 1 second with our HTTP Request source. On the activation side, Live Syncs activate data with subsecond latency. 1 second HTTP Live Sync + 1 minute Dynamic Table refresh + 1 second Census Snowflake Live Sync = 1 minute end-to-end latency. This process can be even faster when using Live Syncs with a Snowflake Stream. For this customer, using Census Live Syncs on Snowflake was 144x cheaper and 150x faster than their previous Reverse ETL process How Live Syncs work It’s easy to set up a real-time workflow with Snowflake as a source in three steps: