Changelog

All aboard the PostHog badgewagon!

We've released a series of new site badges you can add to the footer of your site, so everyone know you're using PostHog to build better products. It's like being in a secret club, except open source.

You've been able to add secondary metrics to A/B experiments in PostHog for a while, but we've now added much better reporting around them.

The new graphs and significance calculations will help you determine if there are knock-on effects to your experiments away from the primary metric.

For example, you may test a change to your sign-up flow to improve conversion as a primary metric, but you may also need to know about impact to activation as a secondary metric. Now you can understand both easily!

To fully support our users on PostHog Cloud, we're working on a feature to allow direct SQL access to PostHog data, so that users may query it directly.

A few weeks ago Paul noticed that our toolbar was 2.2 MB of Javascript, approximately 500 kb of which was just syntax highlighting and formatting code the feature would never use. You can see what that looks above.

So, Paul rolled up his sleeves, and set out to fix the issue. And...voila!

The new and improved toolbar.js is -61% smaller than before, dropping 1.37 MB down to a little over 800 kb.

We've made HogQL a lot easier to use with the addition of autocomplete. You can now start building your query and we'll automatically chime in with elements we think will be helpful.

HogQL, for the uninitiated, is a wrapper around ClickHouse SQL. We've got a few unique tweaks in there for efficiency and efficacy, but it is very accessible to anyone with existing knowledge of SQL.

And now it's even more accessible!

We've updated our Flutter SDK to v4.0.0, adding support for both multivariant flags and feature flag payloads.

Multivariate flags are helpful because they enable a flag to return a key instead of just true or false - which makes them useful for testing or deploying complex changes where multiple variations are needed.

Payloads, meanwhile, enable you to send additional information to your app when a flag is matched. This makes them useful for triggering simple changes, such as displaying a pop-up or notification.

The web analytics beta continues to improve with new features such as path cleaning rules, which alias URLs together to make results more digestible.

If you're in the beta you can customize your path cleaning rules within your product analytics settings. Each rule is composed of an alias and a regex pattern, so that any URL which matches the pattern is replaced with the alias.

Our experience is that path cleaning is incredibly useful for reducing complex common URLs in web analytics, but try the beta for yourself and let us know what you think!

The latest version of our iOS SDK, v3.1.0, will now automatically set $session_id, enabling the ability to do session-based analytics.

With $session_id set automatically it's now possible to delve into metrics such as the time a user spends on a page, or their average session duration.

We've added a new Recordings tab to the Groups view within the People tool, so you can effortlessly see all available recordings from a particular group.

You can use group analytics in a number of ways, but it is typically most useful for B2B teams who want to collect multiple users into a single group that represents an organization. That's how we use it at PostHog, anyway!

We've added relative data operators to PostHog feature flags, meaning we now default to the correct operator type when needed.

This means that if you start targeting a feature flag by subscription_date, for example, we'll automatically switch the operator type to a date format.

We've done a lot of work around mobile analytics recently, including updating our Android and iOS SDKs, so we felt it was about time we added a dedicated dashboard template for them too. You'll need to use either our React Native, iOS, Android, or Flutter SDKs to use this template.

The mobile analytics template contains a selection of mobile-focused metrics, including overviews of your most common OS, device, app version, and more. It's a great way to get an overview of your app adoption!

We're happy to announce that PostHog is now HIPAA compliant and offering Business Associate Agreements (BAAs) for teams on a PostHog Enterprise plan.

Enterprise plans are an add-on for PostHog plan which cost $450 per month and include SAML and SSO enforcement, dedicated support, advanced permissioning, and other features for large orgs.

HIPAA - or the Health Insurance Portability and Accountability Act, if you want to be fancy - is a US legislation which applies mostly to healthcare providers. It isn't something most teams need to concern themselves with, but now those who do can get in touch with us to find out more!

We've now rolled canvas recording out as an opt-in feature available to all users. This enables you to capture canvas elements within your session replays.

It's important to note that there is currently no way to mask canvas elements, meaning you may unintentionally capture personal information or PII.

For this reason, canvas capture is disabled by default and must be enabled via your project options page.

We hope you haven't ever seen the error message above, but if you have then we have good news: we've made it much more informative.

This error usually occurs either because a query was running for too long, or because a memory limit was hit. Both issues are generally caused by a query having an excessively large scope.

In either case, we'll now tell you exactly what the error was and give you some prompts on how to fix it. Of course, you can still raise a support request if needed!

After a short beta period, we've now released our Android and iOS SDKs into general availability, making them available for all users as version 3.0.0.

These SDKs are a complete rework of the old, legacy versions and are more efficient than they were previously. The Android SDK has been rewritten in Kotlin, while the iOS SDK is rewritten in Swift.

Both SDKs offer all the same features of the legacy versions, as well as some new functionality such as feature flag payload support. The iOS SDK also supports WatchOS and macOS for teams with products on those platforms.

Manoel continues to plug away at improving our React Native SDK and has now added support for the macOS target in addition to his previous work.

There are still some things to be aware of when using the React Native SDK however, so be sure to check the docs for more information.

We now report server timings in the session replay player inspector, enabling you to see information about the request-response cycle.

In the image above, for example, you can see that we spent 442ms waiting for the first byte, 350ms of which was spent on gather_query_parts.

Server timings like this are helpful for going deep into performance issues and discovering where delays occur, so you know where to focus performance improvements.

We've increased the amount of information session replay is able to capture about the network status of a user. You can now see the browser's reported network status while watching a replay.

This is typically going to be helpful if you're trying to debug or investigate certain types of error which a user may report as a result of losing their connection. Previously we wouldn't explicitly identify their offline status, which could have caused confusion - but now we do!

We have updated our Flutter SDK to support the macOS target, which it didn't previously. This is important if you use Flutter to deploy across multiple platforms - previously it wouldn't install at all.

Thanks to Manoel for work on this, though he believes the SDK should speak for itself in place of a longer update.

We have updated our React Native SDK to version 2.10.2, adding support for the React Native Web target. Previously if you used the React Native SDK to deploy to web, it wouldn't work and would throw errors. Now it works seamlessly!

Thanks to Manoel for work on this SDK, who (still) believes the SDK should speak for itself.

We're making a lot of improvements to the way we provide support at the moment. This includes publishing new FAQs to the forums, adding an automated CSAT email for closed tickets, and a new severity checker for the in-app support.

The severity checker will help us triage tickets by giving you the ability to self-select how critical the support enquiry is.

Is it a feature request or piece of feedback that isn't totally urgent? Or is it a critical security issue that we need to solve today? We hope it's not the latter.

Earlier this month we announced the first public beta of 2024, which enabled you to capture network requests and response payloads in session replay. Now, it's out of beta and available for everyone!

Network payload capture builds on top of the network calls and performance data we already capture using PerformanceObserver, making it easier for you to understand performance issues and debug errors. Enable it in your Project Settings!

We already capture network calls that are made and their performance data using the browsers' built-in PerformanceObserver. Adding capture of requests, responses, and status codes would allow our users to more thoroughly understand the behaviour of their applications.

We've added the ability to schedule feature flags properties in PostHog, meaning you can now enable, disable, or change the rollout conditions of a flag automatically.

Scheduled flag changes are especially useful if your release schedules fall outside of normal working hours, or if you work with remote teams in other timezones. They're also useful for coordinating product launches in line with marketing activities or announcements.

You can even add multiple scheduled changes to a single flag, which is handy if you want to organize staggered rollouts.

We try our best to make PostHog as stable and reliable as possible but, to quote our handbook, "Incidents are going to happen."

When they do, we want to be as transparent and communicative as possible - that's why we've added a in-app status indicator to the overflow menu in the sidebar. You can click it to go to our full status page for more information.

We hope you'll never need to check on the system status, and that the icon will never be anything other than green, but...well, the handbook is usually right.

We have, after more than a year of planning and distractions, added project-based routing into both US and EU environments. Your project ID is now always stored in the URL.

This is a major benefit for teams who have multiple PostHog projects set up because it makes links properly shareable with colleagues. You'll no longer get lost if you click a link from one project while logged in to a different project.

In order to better reflect the growing scope of our export functionality, and to give you more control over your bill, we've split batch exports out into their own add-on product: data pipelines.

If you're an existing user then we've automatically enabled the add-on to avoid disruptions for your product. Your bill won't increase as a result because of the way we've balanced the pricing for both the add-on and product analytics.

If you're a new user you'll need to enable the add-on from your billing page. As always, pricing is based on usage.

We originally included export functionality as part of product analytics because it made it easier to get started with both features. However, that also meant we were more expensive for users who didn't use exports. Our hope is that splitting exports into an add-on will give you more control over how you use PostHog.

We've already released the first public beta of 2024, which is now accessible via the feature previews menu in PostHog.

Network payload capture is a beta for session replay which, as the title suggests, adds the ability to capture network request and response payload and headers. This is in addition to the network calls and performance data we already capture using PerformanceObserver.

The idea is that capturing requests, responses, and status codes would help you understand application behaviour and performance more thoroughly.

As always we'd love to hear your feedback and thoughts on the GitHub issue!

With automated rollouts, you will be able to roll out a feature flag gradually based on a pre-defined schedule.