Customer teams at SaaS companies need insights on what customers are doing on their platform! This is particularly true when driving a product-led growth strategy, but even in traditional sales-led environments, monitoring and seeing metrics in customer tools, is key to any business.
This typically involves asking product and dev teams to start creating counters, sums, averages and time-related calculations of most important features; and piping these results through to analytics and customer engagement tools, often over other media such as databases and even excel sheets/CSV files.
Of course, over time, when more features have been developed and customer teams need more A/B testing, more business metrics will be asked for, and eventually, bigger portions of expensive development resources end up maintaining a myriad of code for the sole purpose of providing insights.
While counters, sums and averages might sound trivial to implement, the difficulty in creating and maintaining the code often constitutes a burden on development personnel. They are the ones needing to deal with issues that are outside the scope of their application, from storing timeline feature events with appropriate metadata on both user and account level, over keeping processes up for regular re-calculation, to eventually sync’ing new results towards connected ecosystems apps (within proper API rate limits).
An easier and frankly better approach is to simply send raw user and account events with their metadata onto a secure data pipeline, the moment features are being used, and have a customer data platform (CDP) process that raw data into required business metrics. Such CDP will typically be operated by growth (marketing) engineers, without any need for development or SQL skills, through simple point-and-click workflows. Any maintenance in updating or creating new metrics will have no burden anymore on development resources.
Here’s an example: Imagine you are building a B2B marketplace for companies to sell 2nd hand furniture and office equipment (to other companies). For each customer, you want to keep track of the amount of orders in the last 90 days and how much percentage increase that is vs previous 90 days. Rather than asking your developers to create these metrics and sync them to your Salesforce CRM, simply have them send an
Order Placed event each time a purchase occurs. A marketing growth engineer will do the rest... basically filling in below form.
Of course, changing the time period to 30 days and getting the results in absolute values instead of percentages, won’t have any impact to the development team. Nor will changing from Salesforce to HubSpot CRM.
Most often though, the metrics being asked for are a bit more complex than just counting events or calculating rate increases over periods of time. Most product- and sales-led business logic will actually resolve around processing metadata from those events and act on those results to determine product-led growth signals.
Continuing on previous example: Wouldn’t it make more sense to consider looking at actual amounts sold over the last 30 days? Or even by delivery method breakdown? That would translate into filling in the following...
Changing strategy and looking at averages or extremes (min. max) etc... won’t again (obviously) have any impact on development teams and can be defined by any data-driven marketeer with point-and-click skills.
And although the main focus on having these event metadata computed properties is to create growth motion signals and actions, and syncing them to customer apps, an additional advantage to development teams could be that they can query those computed properties back into their platform, thus avoiding the need to creating algoritmes themselves. The functions available are business-generic and include:
All above is optionally related to a moving time window of e.g. Last 24h, 7d, 14d, 30d, ...
Product-led growth resolves around being able to identify qualified leads for acquisition, expansion and retention (fight churn). Two major aspects in defining a product-led growth motions are customer fit and product behaviour. While it doesn’t need much time to explain why event computed properties are important for product behaviour, also customer fit scores often require event-related properties, mainly to segment contacts and determine fit conditions per segment.
Next to first creating computed properties, there’s also a clear need to directly include metadata in signal conditions, so to finetune PLG signals with business critical metrics.
All computed and native non-computed platform properties can eventually be made actionable in the customer tools you are using, by simply sync’ing them to custom fields. This way, you can start sending personalised email sequences and have all relevant data added to each customer record in your CRM.
Here’s our example in Close CRM email sequence:
Customer-facing teams at SaaS companies need clear insights on who their customers are, and what they’re doing on your platform. 🙌 With stage view, journy.io provides a SaaS growth pipeline, with accounts/users clearly ordered by lifecycle stage, and which includes key details, from health to triggered PLG signals. 💡
Growth teams at SaaS companies need clear insights on who their customers are, and how they differ with e.g. those who didn’t convert. By analysing data from across an entire stack, from CRM, Marketing Automation, and other engagement platforms —combined 🙌— they are now able to easily determine trends in customer segmentations and aggregations.
Changing the way you do business, within the tools you already use.
Create your free account and start driving a product-led growth strategy in the tools you're already using.