Answering Burning Questions: Data from internal sources

Where does the data originate?

Last week’s post covered what data is needed to answer a burning question.

Today’s post will answer, “Where does the data originate?”

Let’s get into it.

Where does the data originate?  

The events needed to identify the points of friction on the path to activation originated in Integromat’s web app which, like most B2B SaaS products, was built using proprietary code. Today, it’s possible to build lightweight SaaS products without proprietary code, using a combination of no-code tools and APIs – a process that’s being aided by the general availability of Generative AI. Therefore, once we know what data is needed to answer a burning question, the next step is to figure out where the data originates. Does it come from an internal (or primary) data source or an external (or secondary) data source?

Products powered by proprietary code – web and mobile apps or smart devices – are internal data sources.

On the contrary, external or third-party tools that users interact with – tools and APIs used for messaging, support, feedback, authentication, payments, and so on – as part of the product experience are external data sources. 

From a data collection point, it’s important to highlight the distinction between internal and external data sources because when a product or even a part of a product is built using external tools (or APIs), product-usage data originates in an external environment, in which case, there’s a limitation on the data that can be collected as one has to rely on an external vendor to make the usage data available. Moreover, the data can be made available in different formats – as events (that can be fetched in real-time using webhooks or readymade integrations) or as properties (or attributes) of the entities (or objects) specific to the external app that need to be fetched using APIs or data integration tools.

Knowing where a piece of data originates expedites the data collection process and enables teams to figure out the most efficient way to send the data to the destination(s) where the data is supposed to be consumed. 

Here’s a common scenario depicting what happens when data originates in an external source:

Let’s assume that your organization uses Stripe (the payment processing giant) to power the payment flows in your app. From a user’s perspective, they’re still interacting with your app while upgrading or canceling a subscription – even though they’re interacting with Stripe (often unknowingly). Therefore, the data you can collect (pertaining to a payment flow) is limited to the data collected and made available by Stripe, an external data source.  

This scenario applies to every third-party tool used to power an experience across the customer lifecycle – payment processing being a common example. In Stripe’s case, important events that take place during a transaction can be fetched in real-time by configuring webhooks or at a later time using their Events API. It’s useful also to note that Stripe guarantees the availability of event data for 30 days (from when the event takes place) which means they don’t store the data on your behalf indefinitely. 

Since every third-party service has idiosyncrasies, going over the API docs and understanding the scope of the available integrations offered by an external service helps figure out what data can be collected, in what format, and for how long that service stores data in its servers on behalf of customers.

Confusion alert: First-party data vs. Third-party data

As Stripe’s customer, your organization owns the first-party data generated when your customers interact with Stripe’s services within your product.

Therefore, even though the data originates in an external or third-party tool such as Stripe, that data is first-party data for your org.

On the contrary, had Stripe been a data broker that sold data collected from its customers to your organization, that would have been third-party data for your org.

Data from internal sources  

Now back to my original burning question:

“We’re acquiring a ton of users every day but very few end up hitting the activation milestone; what’s preventing the rest from performing the actions leading to activation?”