It has been nearly four years since the Google Tag Manager Template feature was announced. Since then, many community members have contributed to the template collection to make life easier for many of us. Today, Tagticians is adding two new Google Tag Manager templates to the Gallery:
- PostHog Google Tag Manager Template for Web containers (view Github repo)
- PostHog Google Tag Manager Template for Server-Side containers (view Github repo)
What is PostHog?
PostHog has been gaining more traction lately as an open-source product analytics platform with lots of flexibility. According to their Ycombinator profile page:
We provide product-led teams with everything they need to understand user behavior, including funnels, session recording, user paths, multivariate testing, feature flags, heat maps, and more. (source)
PostHog boasts a great collection of data collection SDKs for almost any platform, the ability to set up or even build data pipelines, query data and build reports. In addition to that PostHog also allows you to develop and run experiments. An absolute must now that Google Optimize is nearing its end of life. And last but not least, PostHog allows you to build and enable apps that integrate with the data ingestion and distribution process. Through PostHog apps, you must enhance collected data and send it to destinations such as data warehouses.
In December last year, PostHog even announced the launch of a Customer Data Platform module. PostHog can easily function as a part of a Composable Customer Data Platform challenging solutions like Rudderstack and Mixpanel, but also play very well with existing all-in-one Customer Data Platform solutions such as Segment.
What does the PostHog Google Tag Manager template do?
The Google Tag Manager templates we built will make it easier for you to implement PostHog in your existing Google Tag Manager environment. The template will help you construct the events you need tracked and specify the event properties you want to include. It is similar to setting up events for Google Analytics 4 since PostHog also uses the event data model.
The Server-side version of the PostHog Google Tag Manager template piggybacks off the GA4 tag in Google Tag Manager Web and the GA4 Client in Google Tag Manager Server-side. We are considering building a PostHog client in the future to remove the GA4 dependency.
We have attempted to build two templates, one for a Web container and another for a Server-side container. On a high level, both templates work the same and allow you to collect event data as you would expect. However, there are some subtle differences between both approaches.
Before we get into what the templates can and cannot do, it is good to understand the data flow. For the Web, the template will call PostHog methods in the global window to pass on data to your project. For Server-side, the data is sent using their HTTP API, which is less flexible to work with and has some critical limitations.
You must implement a Custom HTML tag in your Google Tag Manager Web container with your PostHog snippet. Unfortunately, PostHog does not offer an injectable solution for their Javascript SDK. This is the only solution for Web, but it is also the recommended solution for Server-side.
The benefits of the Custom HTML PostHog Javascript SDK approach are plenty.
With the Custom HTML approach, PostHog can manage important parameters inside their cookie. As our GitHub documentation explains, this will make it easier for you when using a Server-side approach. The PostHog cookie will include data such as:
- Device ID (device_id) – similar to a Google Analytics client ID value
- User ID ($distinct_id) – can store the value of a unique user ID when they login
- Session ID ($sesid) – similar to a Google Analytics session ID value
- referrer ($referrer) – contains the most recent document referrer value
- referring_domain ($referring_domain) – contains the referrer eTLD+1 value
- Search Engine ($search_engine) – contains the name of the most recent search engine referrer
- Active Feature Flags ($active_feature_flags) – see Feature Flags functionality
- Enabled Feature Flags ($enabled_feature_flags) – see Feature Flags functionality
- Feature Flag Payloads ($feature_flag_payloads) – see Feature Flags functionality
- Session Recording Enabled Server Side ($session_recording_enabled_server_side) – boolean value
- Any user bound $set or $set_once variables
Additionally, you can fully configure their Javascript SDK in the Custom HTML tag to meet your requirements. For instance, you can:
- opt-out tracking by default (can be (re)enabled based on consent)
- disable default features such as autocapture
- disable default events such as a pageview, pageleave
- store cookie data in local storage or both
- set default distinct ID values
- set default Feature Flags
- enable debug mode
- and more…
What features do the PostHog Google Tag Manager templates include?
The PostHog Google Tag Manager templates include support for the following methods:
- Capture – track custom events.
- [WEB Only]* Identify – when a user logs in, set a one-time user ID value for cross-device session stitching purposes.
- [WEB Only]** Opt-in/out – helpful in respecting a user’s consent.
- [WEB Only] Reset – useful when a user logs out or revokes consent.
- Pageview – done by Javascript SDK on Web, useful for Server-side when the capture_pageview option is set to false.
- Virtual pageview – through the custom trigger, useful for single-page applications or modals.
* Each event sent Server-side needs to include a distinct_id parameter making this method obsolete for Server-side.
** Server-side this can be achieved by passing consent data and using that as a conditional.
Since you need to implement the PostHog Javascript using a Custom HTML tag, the autocapture feature will track any interaction on your website. Also, Screen Recordings and Feature Flags will work, too.
Example of the PostHog Google Tag Manager template tracking a view_item event with event properties from the Event Data object.
What are the limitations of the PostHog Google Tag Manager templates?
There are two main caveats regarding the PostHog Google Tag Manager template.
- [MINOR] To make the Web version work, you need to implement the PostHog Javascript SDK using a Custom HTML tag. Although it is not required for a Server-side approach, the added benefit of the data created and maintained in the PostHog cookie makes it a highly recommended option.
- [MAJOR] The biggest challenge with a Server-side approach is PostHog requirements of always requiring the distinct_id parameter to be set with every API call. Although not a significant issue, it has major implications when analyzing your data. A distinct_id can only be set once and cannot be overwritten. In other words, when you try to assign a new distinct_id, a new person will be created in PostHog, making it impossible for you to stitch subsequent session data together. A solution would be to make the device_id (similar to Segment’s anonymous_id) or the distinct_id mandatory in every API call. This topic has been raised with PostHog. For now, in the template you can select the source of the distinct_id parameter, but will always default to the GA4 client ID since the whole setup is dependent on the GA4 tag and client.
Conclusion
Although the templates are not 100% perfect, they will allow you to set up PostHog quickly. This can be useful for a proof of concept or when there is a lack of knowledge in using Google Tag Manager Custom HTML tags to build out your PostHog events. We will continue to monitor changes to the Javascript SDK and the API and update the template accordingly. Please send us any feedback you might have about the template. We will be more than happy to improve the Google Tag Manager template to make it easier for everyone to use.
Tagticians is proud to be a PostHog partner. If you require support in implementing or maintaining PostHog in any way, please contact us today.
