Cross-Domain Product Analytics with PostHog

They provide clear insights into the impact of marketing initiatives on user engagement and behavior within an app or website. By tracking and analyzing data related to user navigation patterns, interactions, and sign-ups, companies gain concrete, evidence-based understanding of their products. This allows stakeholders to accurately assess the success of their marketing efforts, identify which campaigns are fostering meaningful user actions and how the product is funneling users. Unfortunately there are also a larger number of challenges, including ad blockers, difficult UIs and, as is the focus of this article, cross-domain tracking.

Luckily there are a suite of tools available to help companies gain these insights and avoid the difficulties. At Yeti, we have recently been working with PostHog to provide a low-effort, cost-effective, and flexible service which can help with some unique difficulties, namely getting data when an experience or user-flow crosses over to platforms with a different domain. 

PostHog

PostHog has been a rising star in the product-analytics space. Its user-friendly interface and easy to construct dashboards make it excellent for marketing and managers to maximize their insights, but it really shines in how easy it is to integrate into an app. At initialization it will automatically start capturing basic events, including clicks, input entries, and navigation. It also takes minimal setup work to integrate identification logic to track specific users as they move around the app. Simply use their identify API to pass a unique identifier, such as a user id or email, and thereafter, the app will track that user’s activities. In the dashboard, then, you can see users, search by properties, correlate with groups, and create cohorts. 

Here are a few reasons PostHog is gaining in popularity: 

• Generous free tier (1,000,000 free events, 5,000 session recordings, and more)
• Easy to setup insights dashboard and funnels
• It’s legal everywhere (PostHog is GDPR compliant) 
• Long term data retention
• A/B testing with feature flag

Cross-Domain User Analytics

The feature being highlighted in this article, though, is the ease of Cross-Domain analytics. The simplicity of integration is key for setting up a tracking service across domains, especially when your team or organization doesn’t control the second domain. Trying to make product decisions for other teams isn’t always straightforward or welcome, but the simpler, the better.

To demonstrate PostHog’s user tracking across domains, consider the example of a company which manages registrations for charity runs or marathons. Call it Runner Signup. Runner Signup has a partner organization, Runner Shirts, which handles the race shirt requests and corporate sponsor tracking for people signing up for the race. Here is a high-level flow of how to track a user across the platforms.

1. Runner Signup initializes PostHogs `posthog-js` library
2. When a runner registers, they are assigned an id, use this id to identify the user in PostHog
3. When the runner clicks on the Runner Shirts link, pass the id via a url param
4. Runner Shirts initializes PostHog, perhaps gating initialization dependent upon the url referrer
5. Runner Shirts takes the id url param and calls PostHog’s `identify` API

From there, PostHog will handle the rest. It will track CTAs, navigations, session times, etc. Of course, custom events and passing more detailed properties would require a deeper integration, but out of the box, PostHog is doing the heavy lifting. This is especially valuable if you’re primarily interested in session durations, and basic user behavior/funnels. There are alternative methods to passing a URL param, but that is the recommended method. For more, check out their documentation.

And that’s it! That’s how easy it is to integrate PostHog’s user tracking and product analytics across domains. For a more detailed implementation guide and example project, there is more information below, but at a setup level, that’s all there is to it!

Example Project and Group Analytics

This section tracks a frontend only dummy project setup to demonstrate PostHog’s integrations. The registration data isn’t saved anywhere and the identifying values are randomly generated on the frontend. The example screenshots are taken from a project built for the purposes of this article. It is written in React + Vite and contains two applications, RunnerSignup and RunnerShirts. The repository can be found here. To run the project locally (instead of just following along), here is what you will need: 

1. A PostHog account with access to the API key and instance URL (probably https://app.posthog.com)
2. A JavaScript package manager such as npm or yarn
3. Ngrok, or some equivalent, which can create a domain based on localhost (this isn’t strictly necessary, but this is how you will see two different domains being captured in your PostHog activities dashboard)

The complete setup guide is located in the README at the root of the project linked above. Simply reading through the example, however, is sufficient to convey the flow independent of running the project locally.

The project is based on the Runner Signup and Runner Shirts companies mentioned in the previous section. Runner Singup handles the initial registration (just creates an id and gathers basic user info) and Runner Shirts handles getting shirt size and corporate sponsor affiliation. The corporate sponsor value will be used in PostHog to see users’ group affiliation. 

Runner Signup’s main screen is a simple registration page which captures user data and identifies them in PostHog.

After setting up PostHog Activity, People, and Groups section will all be empty on initialization, but after clicking “SIGN UP”, activities will populate from the ngrok instance and Alan Turing (turing@cambridge.edu, as one may imagine) will be populated in the People section. 

At this point, though, the Groups subsection will still be empty, as it is handled in  the other service, Runner Shirts which handles correlating people with groups. After clicking “Sign Up”, the user is shown a thank you page with a link to get their shirts. The link takes them to the Runner Shirts site which is running on localhost:3001, an entirely different domain than the ngrok instance. To track across sites, the Runner Signup link passes the user id generated when the user signs up. The value is passed as `phid` in the URL’s query params, which Runner Shirts uses to identify the user on the initial page load via PostHog’s `Identify` API. In the example app, the `phid` value is stripped from the URL, but it is left in the picture for clarity. 

Prior to the user even pressing “Submit”, they are already identified and PostHog is gathering valuable data on how they are moving around the Runner Shirts app.

Notice that the same user’s “URL / SCREEN” value is now in a different domain! Precisely what we were hoping to be able to accomplish.  Now we’ll be able to correlate them to corporate sponsors via PostHog’s Group features which are fired when they submit the Runner Shirts form, providing valuable information for race organizers, sponsors, and marketers on how Runner Signup/Runner Shirts apps are being used and how successfully a race is attended and sponsors are tracked. So, after the user presses “Submit”, we see a group created, and that Alan Turing is associated with that group, in the Posthog dashboard. 

‍

All of this is accomplished in ≈25 lines of code across both applications!  Hopefully this makes your next data tracking integration all the easier. 

Yeti is an IoT application development company. If you'd like to learn more about what we do, be sure to take a look at our work page featuring insightful case studies showcasing our collaborations with renowned clients such as Google, Netflix, Westfield, and many others. For more insightful content, don't miss the Yeti blog and our extensive library of IoT software development content.