Best Practices

Two lessons in implementing DIY & OOTB reverse ETL tools | Census

Sarah Krasnik
Sarah Krasnik August 18, 2021

Sarah Krasnik is a data consultant by day and data blogger, advisor, and generally curious data person by night. Previously a data engineer at Perpay, she has since transitioned to an advisory board member for Census and Superconductive. Philadelphia, Pennsylvania, United States

As someone who has built reverse ETL jobs before tooling for this type of work was largely available, I have one important takeaway: When bespoke reverse ETL implementation is done, the ongoing maintenance time will snowball as APIs change, new fields are added, or data grows. In short, while a DIY solution may seem like a great way to move data from A to B, you’ll save some time, sanity, and engineering effort by adopting a pre-built reverse ETL tool to automate an otherwise grueling task.

If you aren’t already familiar, ETL tools retrieve data from third-party sources to populate your data warehouse, while reverse ETL does the exact opposite. Reverse ETL tools like Census sync your data from your warehouse to the platforms used by various business teams.

Implemented in-house, the sync to a single platform includes dozens of hours of data engineering time to understand the unique API integration. And adding more platforms just means dozens of hours more of data engineering time. If it’s the first reverse ETL process you’ve tackled, scheduling and infrastructure capacity for running the sync will need attention for a smooth implementation.

That’s where Census comes in. As a dedicated, pre-built reverse ETL tool, it lets the analytics team focus on the business needs of the sync as opposed to the nitty-gritty technical specs (effectively making operational analytics possible).

Empowering the marketing team to build emails quickly and iteratively was the driver for reverse ETL for my team (and, honestly, I wanted to spend my time as a data engineer doing less reactive work and more exciting stuff like introducing a data lake architecture, something that’s not possible to automate right out of the box). Leveraging a third-party tool enables the organization to send branded and highly personalized communications thanks to the data sent from our warehouse.

With this goal in mind, we decided it was time to explore out-of-the-box reverse ETL tooling like Census. We’re still in our evaluation phase, but I wanted to share some of the lessons we’ve learned in implementing reverse ETL. So, without further ado, here are two things that will make your Census and reverse ETL implementation easier.

Lesson one: Loop in stakeholders early and often.

Consider the data you need to sync from your data warehouse to Salesforce, Facebook Ads, and Intercom. The analytics team serves the rest of the organization by providing personalized experiences to end customers; however, they’re not actually the end-users of the third-party tools.

Sales, marketing, and customer success teams have their own goals attached to the data going into the tools they use day in and day out. As such, these stakeholders are core resources for analytics teams building reverse ETL processes. Make sure that you’re checking in with them so you don’t have to redo instrumentation work later on.

Now, I wanted to get this nugget out of the way early on: It’s not the place for the analytics team to decide what data gets sent. You’re not the ones using the output, so you shouldn’t be the ones deciding the output. Rather, your job is to understand the strategic importance of the data your stakeholders need and find the easiest and most scalable way to send it from A to B.

Instead of data teams dictating the whole data exchange, analytics and the business unit consuming the data should have an open conversation (or many) to define the specs of the reverse ETL process. Oftentimes, these two teams don’t collaborate as closely as needed, which means stakeholders get data they don’t need and analytics teams have to rehash work they already did to adjust outputs (which sucks for everyone involved).

Pro tip: Collaboration isn’t a one-time process. In my case, the analytics and marketing teams had, and currently have, ongoing conversations about new data requirements.  

Here are two things the analytics teams did to keep these conversations productive.

  1. Talk to stakeholders earlier. This will pay off in the long run and help you avoid schema and field definition changes mid-implementation. Keep the people who will be using your output involved and in the loop from the jump.
  2. Get specific goals and requirements. You’re (ideally) removing a stakeholder’s manual step of uploading data. But, if the data you send doesn’t contain what they need, they’ll have to find a workaround, which will just make the whole ordeal a manual mess again. Make sure you understand the use case and how the data schema you’re building addresses it to avoid future ad hoc solutions and debt.

When building the dataset, it was particularly helpful for me as the data engineer implementing Census to understand how my business teams would use the data early on. As a data-led eCommerce company, we wanted to start incorporating product information (such as a user’s recently viewed products) in emails.

Although we had a pretty straightforward use case, it wasn’t specific enough to instrument the data flow well. By working with marketing on the exact email template needed, we agreed to format the products as a list of dictionaries (instead of a dictionary of lists, or list of strings, or a number of other options). This ensured the marketing team could use the data right away for the template design vs having to wait for rounds of changes to be made.

Similarly proactive and detailed communication with your business team kept implementation on track and broke down org silos in the process. But we still had to tackle another often-overlooked communication chasm: How often to send data.

Lesson two: Get specific with your SLA definitions.

In the reverse ETL world, data SLAs outline the maximum amount of time the data should lag. For instance, if a new customer signs up on your site, an SLA of six hours means the destination tool promises to have personalized user information within six hours of signup time.

One hour, six hours, or 24 hours? Let’s talk about how this number gets defined.

If you’re like me, the software engineer in you wants to only send the data every 24 hours. After all, updating data once a day requires the least amount of effort. But from your stakeholders’ point of view, that’s not fresh enough. Most likely, they’ll want data to be no more than one hour behind as this guarantees that they won’t have to worry about the staleness of data. While you and your stakeholders can debate these extremes for days, the reality is that both timeframes are “nice to have.”

Instead, data SLAs should be defined by striking a balance between use-case and technical requirements.

Balance is nice, but how is it actually achieved? Here’s how our team approached it.

Evaluate the use case. Just like you did when building the underlying data, understand what workflows the data will power. Will it be used once a week to send a personalized marketing email blast? Your SLA then has a maximum of 24 hours. Will your sales reps use it to follow up with leads within six hours? You’ll probably want an SLA of about four hours (to give your reps a two-hour response window).

Gauge business value. Let’s say the sales reps set a new goal to follow up with leads within an hour, making the four-hour SLA inadequate. If it would take weeks for the analytics team to re-implement upstream processes to update the underlying data once an hour instead of once every four hours, it begs the question: Will following up after one hour really move the needle on business KPIs? That’s a delicate subject (and one I don’t have a quick answer for), but you should closely evaluate it with the stakeholder. If those conversations yield that yes, a faster SLA will positively and noticeably impact KPIs, you can invest the time to re-implement. If not, your analytics team should use their time elsewhere on higher-leverage tasks.

Finding this balance isn’t easy, which is why communication between analytics teams and business teams is key. When deciding on our SLAs, transparency between the limitations of both marketing and analytics teams determined our success. Marketing told us how much the time of day impacted performance, and in exchange, my team communicated the capacity constraints we would hit if we spent our time refactoring queries to hit lower SLAs. At the end of the day, everyone’s on the same team and we’re united behind one goal: Enhancing the experience of our organization’s end-users.

Final note: Keep communication channels open post-implementation

Integrating Census and reverse ETL capabilities more broadly into your business should remove manual data uploads entirely. To do this successfully, you’ll need to communicate early and often with stakeholders and clearly define sync behavior with those team members along the way.

After all, the reduction of manual processes should make your -- and your stakeholders’ -- lives easier. Keeping communication channels open during, before, and after reverse ETL implementation will ensure you get the most out of Census and quickly move off your bespoke reverse ETL tools.

Have questions about my reverse ETL experience? I’m happy to chat on Twitter or LinkedIn. Or, if you’re looking to dive into Census, sign up for a demo.

Related articles

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:

Best Practices
How Retail Brands Should Implement Real-Time Data Platforms To Drive Revenue
How Retail Brands Should Implement Real-Time Data Platforms To Drive Revenue

Remember when the days of "Dear [First Name]" emails felt like cutting-edge personalization?

Product News
Why Census Embedded?
Why Census Embedded?

Last November, we shipped a new product: Census Embedded. It's a massive expansion of our footprint in the world of data. As I'll lay out here, it's a natural evolution of our platform in service of our mission and it's poised to help a lot of people get access to more great quality data.