small_frank_george.png

thumbnail_frank_george.png

frank_george.png

Mobile push is one of the most commonly used engagement channel by our customers. Last month alone, we have send over 100 million push messages on behalf of our customers. Push is cost-effective and also offer open/click rates in the range 4-7% on average. But one of the challenges in push is getting good delivery rates. This is a problem especially on Android devices, because you have all these different OEMs and they tweak (usually the cheaper ones) the default Android OS behavior to eke out better battery/cpu performance on relatively cheaper hardware.

large_push-boost-1.png

medium_push-boost-1.png

small_push-boost-1.png

thumbnail_push-boost-1.png

push-boost-1.png

Android by default uses firebase send notifications to apps and it expects apps to be in non terminated state so that it can deliver the push message and in turn for the notification to show up in device notification tray. One effect of these optimizations in cheaper OEMs is that the apps are proactively terminated when it is sent to background (user no longer interacts with the app) and this hinders the ability of firebase services to deliver the push to the app and thus leading to poor push delivery rates on such devices.

For our customers a 1% improvement in delivery rates typically means an ability to reach an additional 10K+ users, so at Castled we have spent quite some time chasing these issues and also coming up with some workarounds so that our customers get the max delivery rates for their push campaigns.

large_push-boost-2.png

medium_push-boost-2.png

small_push-boost-2.png

thumbnail_push-boost-2.png

push-boost-2.png

Following are some of our learnings and workarounds that we currently employ. In some cases we were able to push (no pun intended :)) our delivery rates to over 90% following these approaches.

large_push-boost-3.png

medium_push-boost-3.png

small_push-boost-3.png

thumbnail_push-boost-3.png

push-boost-3.png

thumbnail_arun_dp.jpeg

arun_dp.jpeg

Cloud data warehouses like Snowflake are gradually evolving as the central "backend" around which all data-centric applications will be built in the future.

It makes a lot of sense since the data warehouse is the only location in your technology stack with a 360-degree view of your customer. Moreover, applications built with a data warehouse as the backend can leverage the massive computing power to offer capabilities that were unimaginable with traditional applications.

So, when we at Castled, decided to build a warehouse-native marketing solution for B2C marketers, we were completely sold on the idea. The limitations of the traditional marketing tools to store and process billions of data points were becoming difficult to ignore.

Our amazing early customers validated our hypothesis - They were finally able to use "all the data" in the warehouse to target their customers without any tradeoffs.

But there was a catch. B2C Marketers also have this use case to engage their customers in "real time". For example, an e-commerce marketer would want to give customers real-time status updates about a pending order. Now, this was not the easiest of problems to solve on top of a cloud data warehouse. But we were determined to provide a complete solution to our customers, not one that solves 95% of the use cases.

Today, I am thrilled to announce the release of our latest feature - 

. Now Castled can trigger campaigns and user journeys with sub-second latency directly on top of your data warehouse. Moreover, the feature is exceptionally light on your data warehouse and consumes minimal resources.

large_realtime_campaigns.png

medium_realtime_campaigns.png

small_realtime_campaigns.png

thumbnail_realtime_campaigns.png

realtime_campaigns.png

I am Arun, one of the co-founders of Castled.io. I am writing today to share our struggles & learnings from acquiring our initial customers in a highly competitive marketing space — knowledge we wish we had possessed a year ago.

For context, Castled.io is a CEP built on top of customers’ cloud data warehouses like BigQuery, Snowflake, Redshift, and Postgres. So, In essence, we are identical to tools like Braze, Iterable, CustomerIO, etc., with a crucial difference — we don’t keep a copy of the customer data and hence do not share the data limitations of the existing solutions.

We were on cloud nine when we got selected for the Winter 22 batch of YCombinator. I still remember waiting sleeplessly the entire night after the interview for the confirmation call. And the call finally came from Dalton at 7 AM, when we had almost given up hope.

We were overjoyed. Our small startup had just gotten the biggest stage of our life. The three-month batch was a life-changing experience for first-time founders like us. It taught us everything we needed to know about startups. We even pivoted to our current positioning of Castled during the batch.

We came out of the batch with a lot of hope & optimism and a hunger to make it big.

After the batch, we were completely confident that Castled was the future(we still believe we are!), and it was just a matter of time before companies started adopting us. But the reality at hand was different.

Larger companies with good “clean” data warehouses had a well-established marketing stack. They were unwilling to accommodate a “newbie” like us — at least not without relevant case studies from other large companies. On the other hand, a few startups we talked to liked our product and were ready to collaborate with us. But they either did not possess a cloud data warehouse or at least not one with quality customer data to be used for marketing.

So we waited the next few months for that “perfect” customer to come along, but it never happened. This was a phase of desperation and self-doubt.

But as they say, founders are hustlers. One day, we were talking to a YC batch mate, who mentioned that Castled would actually solve all their marketing pain points. But, again, their data warehouse did not contain all the customer data required for marketing. We immediately agreed to jump in and complete their data stack.

After all, having one customer is better than none, right?

So our team spent the entire next week migrating all the required data to the customer’s data warehouse. We even self-hosted open-source ETL solutions ourselves to do these migrations and wrote dozens of scripts. One week later, we had our first paying customer!

This became a recurring theme for us. Not having a mature data warehouse was no longer a barrier to acquiring customers. We went from completing the data stack to setting up new ones for companies that did not have a data warehouse — for free. I mean, setting up a BigQuery is more cost-effective than setting up a Postgres instance. So why would they mind?

We were offering 20x more value than what they were paying us.

With more incoming customers, our product started growing more stable, and we reached a stage where engaging with our initial ICP — ones with a decent data warehouse in the first place — became more accessible. And last month, we landed our biggest account yet!

We understand that it’s still day one for us, and we are not even close to calling ourselves a successful company. We are also fully aware that more phases of desperation await us on our journey. But we now know we will overcome those hurdles as long as we are ready to “do whatever it takes”.

medium_initial_customers.png

small_initial_customers.png

thumbnail_initial_customers.png

initial_customers.png

As you know, cloud data warehouses were originally built to dismantle data silos. We started Castled to break more silos - ones on the right side of the warehouse and truly democratise the data warehouse for marketers.

However, in our pursuit of building features on top of features over the last year and a half, we overlooked a crucial aspect.

We were evolving into what we were fighting in the first place - Another data silo that vendor-locks the data we generate within our platform.

As you know, marketing platforms generate critical campaign data and delivery events that are essential to perform campaign analysis, audience building, and more.Unfortunately, this data is often siloed within the marketing tool and requires considerable effort from the data teams to make it accessible for marketing analytics.

Today, I am thrilled to announce our latest offering - 𝐑𝐞𝐚𝐥-𝐭𝐢𝐦𝐞 𝐝𝐚𝐭𝐚 𝐬𝐲𝐧𝐜𝐬 𝐭𝐨 𝐲𝐨𝐮𝐫 𝐝𝐚𝐭𝐚 𝐰𝐚𝐫𝐞𝐡𝐨𝐮𝐬𝐞.

With this launch, Castled can now write analytics-ready marketing data and channel events back to all popular data warehouses.

We believe this feature will finally enable marketers to build granular customer segments and run comprehensive marketing analytics on top of their data warehouse - without involving the data teams!

large_realtime_sync.jpeg

medium_realtime_sync.jpeg

small_realtime_sync.jpeg

thumbnail_realtime_sync.jpeg

realtime_sync.jpeg

thumbnail_abhilash_image.jpeg

abhilash_image.jpeg

We are excited to announce that Castled has achieved SOC 2 Type II compliance.

SOC 2 (System and Organization Controls) is a compliance standard for service organizations developed by the American Institute of CPAs (AICPA), which requires a third-party audit to attest that the organization implemented the necessary controls and processes to meet the industry’s highest security and compliance standards according to Trust Service Principles and AICPA standards.

For the third-party audit, we partnered with Prescient Assurance, a security and compliance attestation leader for B2B SAAS companies worldwide. An unqualified opinion on a SOC 2 Type II audit report demonstrates to Castled Data, Inc that our infrastructure, internal policies, process, and incident report plans are battle tested to ensure it achieves the highest standard of security and compliance. In addition, the report endorses the Vulnerability Assessment and Penetration Testing (VAPT) done as part of this process to ensure our application meets the highest security standards.

’We have implemented the necessary controls and processes to meet the industry's highest security and compliance standards. Achieving this standard with an unqualified opinion serves as third-party industry vali’ation that Castled Data, Inc provides enterprise-level security for customers' data secured in our system.

With our SOC 2 Type II compliance, you can trust us to handle your data with the utmost care and security. Our compliance protects your data and enables you to demonstrate compliance with industry standards and regulations.

For our existing customers, we thank you for trusting us and our process and can get in touch with us for the report. In addition, our SOC 2 Report is available on demand under NDA for our future customers and people considering Castled. 

large_soc2_blog.png

medium_soc2_blog.png

small_soc2_blog.png

thumbnail_soc2_blog.png

soc2_blog.png

CEPs or Customer Engagement Platforms have remained the backbone of all kinds of businesses varying across different verticals and growth stages for decades now. Customer engagement processes have also evolved drastically, with marketers/growth teams trying new approaches and channels to lure their customers. CEPs have stood the test of time amid this ever-changing marketing landscape and have constantly added features to keep the growth/marketing teams up to date with the latest trends.

So all is well with the world of CEPs? Well, not really! In this blog, we intend to share the learnings from the interviews we conducted with 100+ customer engagement teams. In the following sections, we will discuss in detail the 

they face with their CEPs and the solution we propose to solve their problems out of the box.

Scared of your finance teams/business execs eyeballing you before you decide to start a 

medium_volume-based-pricing.jpeg

small_volume-based-pricing.jpeg

thumbnail_volume-based-pricing.jpeg

volume-based-pricing.jpeg

If this sounds familiar, do not worry. You are not alone! Cost is, without any doubt, the prominent headache growth marketers across the globe face with the existing CEPs. Almost all the CEPs like Braze, Iterable and CustomerIO are priced in terms of the data points consumed, which can get exorbitantly expensive in this era of digital transactions. In such scenarios, your customer engagement teams are often forced to make tradeoffs in campaign efficiency to keep their marketing budgets at bay.

But why do the current tools charge in terms of data storage?

One of the primary reasons for this pricing mode is that it is challenging to build a product that scales to hundreds of billions of data points across thousands of customers.

t, probably 80% of the engineering cost, which comprises the developer cost, infra cost, maintenance, and support cost, will be spent on solving the scale at hand rather than building features that provide real business value to the end user.

Even from a business point of view, it makes sense for the CEPs to charge in terms of data storage since more storage means more value. But we believe that the current way of pricing exponentially in terms of data storage is not giving a fair ROI back to the marketer.

small_look-back-period.jpeg

thumbnail_look-back-period.jpeg

look-back-period.jpeg

Almost all the major CEPs in the market provide a data look-back period not exceeding 180 days by default. Imagine you having to pay an unreasonably high amount of money even to make sure that your most loyal customers are not treated as first-timers. You would want to remember the health package they took six months back or the products they bought from you in the last Christmas Sales.

This restriction can also be traced back to the limitation of CEPs in storing and processing massive amounts of data points across thousands of customers.

medium_quality-of-data.jpeg

small_quality-of-data.jpeg

thumbnail_quality-of-data.jpeg

quality-of-data.jpeg

There is no doubt that the CEPs that you use currently are extremely powerful in the functionality they provide. But all of that amounts to nothing if you do not have access to the right set of product usage data in your CEP. Currently, the customer data/events are fed to the CEPs using SDKs on your website or your transactional backends. Unfortunately, this data is incomplete and does not contain a 360-degree view of your customer. Many critical customer interactions happen outside your core application in third-party sales or support tools that are often missed by these SDKs.

Your cloud data warehouse is the only source of data in your entire product-tech stack that contains a comprehensive view of your customer’s product usage. Marketing/Growth teams have recently started to realize the value of the customer data in their cloud data warehouses. As a result, they have been using Reverse ETL to sync their customer data from their data warehouse back to their CEPs. While Reverse ETL solves this problem to an extent, the downside of this approach is that it adds an unwanted dependency on your data teams to create and maintain those complex data pipelines.

Imagine you having evaluated and purchased a Customer Engagement tool. How much time does it take to start your first campaign? Also, if you are migrating from an existing tool to another, how much time does it take to migrate all your campaigns to the new tool and stop using the old one? Finally, are you tired of asking your tech team about the status of the developer tickets you raised?

medium_time-to-value.jpeg

small_time-to-value.jpeg

thumbnail_time-to-value.jpeg

time-to-value.jpeg

 does not mean you can start engaging customers right away. You will need developer time from your tech team to integrate the users/events/custom objects that you need to use in your campaigns. That’s when the next problem arises. It’s almost always the case the tech resources in a company are scarce, and their main priority is to build the core product.

So in all possibilities, the tickets you raised for your 

 will not be picked up for at least a few months in the best case and for more than a year in the worst. You are potentially losing a lot of money in opportunity costs during this time. Now, this is not even a one-time effort. The same cycle must be repeated when you decide to change your CEP, which is a fairly common scenario when your business grows.

Now that we have listed down all the major drawbacks and pain points with the existing CEPs, how do we solve them?

small_wh-backend.jpeg

thumbnail_wh-backend.jpeg

wh-backend.jpeg

The solution to building a more flexible, cost-effective, and robust CEP is to build it natively on top of your cloud data warehouse. Your data team has already done all the hard work by bringing all the user/events data to your data warehouse for analysis. They have also created critical semantic models relevant to your business using a modeling tool like DBT. All that would be left for you to do is to create dynamic segments directly on top of those models and run campaigns/customer journeys using those segments.

Now let’s see how the newly proposed solution solves all our problems.

Since the CEP is built natively on your cloud data warehouse, it does not have to store your users/events/custom objects’ data. This drastically reduces the cost of a warehouse-native CEP by almost 80% compared to a traditional CEP.

Again, since all the events’ data are stored in your data warehouse, there is no restriction on data retention/look-backs from the CEP side. Storage in a cloud data warehouse is exceptionally cheap, and you should be able to retain all your events for as long as you need.

There is no need to add a dependency on the data teams to bring the data from the warehouse back to your CEP using a Reverse ETL solution. You can use the segment builder directly on top of the product usage data lying in the warehouse to create your segments.

All the data you need to run your campaigns are already lying in your data warehouse. You can start engaging your customers in a matter of few hours instead of months. Also, since your cloud data warehouse is the single source of data for all your campaigns, you do not have to worry about getting the developer time to migrate the data, even if you decide to change the CEP at some point.

Castled is a Customer Engagement Platform built on top of cloud data warehouses like Snowflake, BigQuery, Redshift, etc. Castled enables marketers to create dynamic customer segments directly within their data warehouse and engage or retarget them across diverse marketing touch points, all without the need to involve data teams.

Today, we are thrilled to announce the launch of our Mobile Marketing suite. This suite offers a range of features designed for a mobile-first marketing approach, including Push and In-App Messaging, uninstall tracking, push priming, and much more.

With this release, Castled completes the loop by becoming the first warehouse-native marketing automation platform to provide exhaustive support to fulfil every need of a B2C marketer. Castled now supports engaging customers across all mobile channels - Email, SMS, Whatsapp, Push, In-App, and Ad platforms - using the data from your data warehouse.

This advancement further solidifies our commitment to empowering marketers with the tools and insights to create more engaging and effective marketing strategies on top of their data warehouse.

The Native Trails

Castled launches the Mobile Marketing Suite

Be that visionary marketer, make every engagement count