Join 10K+ people getting helpful guides, exciting case studies and much more in our newsletter.
Don't worry, we'll never share your email with anyone.
Oops! Something went wrong while submitting the form.
Connect with Yeti
Product analytics play a vital role in gauging the effectiveness of marketing strategies.
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 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:
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.
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!
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:
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.
Don't worry, we'll never share your email with anyone.
©2023 Yeti Technologies LLC
