Goal: Track user behavior on your Stacker apps, to get insight on how your users use your app.
- Automatically tracks all user actions (clicks on all buttons, links, tabs, pages, etc.)
- Tracks all page views (any URL change counts as a “page view”)
- Tracks the name of visited pages/tabs, to make it easier to build charts that make sense to you
- Identify the current Stacker user and associate them to all events they generate, while tracking basic user properties (first name, last name, name, email, company)
- Links the current Stacker user to the company they belong to, so you can use “Group Event Tracking” to better understand how your companies behave, as a group, and compare their engagement
- 💡 PostHog handles multi-groups, and additional groups tracking can be added on-demand, see Advanced PostHog analytics
- Session recordings (as videos you can watch) to see for yourself how your users behave and where/why they get stuck
- If you later configure a custom domain, know that you will need to whitelist it in the PostHog Settings, in order to save Recordings to PostHog
- I do this for you if you already use a custom domain, or I use
https://your-domain.stackerhq.comif you don’t
If you want to give me this mission, I suggest asking yourself a few questions beforehand:
- Do you want me to build charts for you? Or is it something you’d prefer to do yourself? Depending on the chart and its complexity, it might take x10 times for me to get it right. Do not hesitate to ask for an estimate!
- Do you need to track advanced user behavior? If so, it might be better to do it afterwards, once this custom implementation is live. This way, you can create charts by yourself, and only ask me to build those you cannot do yourself. It will also give you a better understanding of what is possible and whether you need to track new metrics.
Implementing PostHog in your Stacker app will take me:
- 2h for new customers, because I need more time to configure everything
- Such as Streamlined JS scripts deployment pipeline (CI/CD, GitHub), with a dedicated GitHub repository
- 1h for existing customers who have an existing GitHub deployment pipeline
This is an estimation, it can take more time based on various elements, such as how long do our meetings last, efficiency of our communication, etc.
If you already have PostHog installed on your app and want to track specific events, see Advanced PostHog analytics.
If you have never worked with me yet, I suggest starting with this implementation, see how it goes, and if you’re satisfied with my work we can talk about Advanced PostHog analytics, which usually require more time to get right.
Here is a list of things I need to get started:
- Does your app might track EU citizens? If so, you should create it in the EU region for GDPR compliance.
- Admin access to PostHog (I can do either, let me know what you prefer):
- Use your existing PostHog instance (you need to invite me as admin)
- Or create it for you, and then transferring ownership to you
- Admin access to your Stacker app, necessary to configure the scripts and doing testing
- This is not a blocker, and can be done later on, but it makes testing things easier to do it earlier
- An airtable “Creator” account is useful for testing purposes
- That’s not a blocker, you can create those test accounts for me, if giving me access to the database is an issue
Here is a short demo of what you will get once the integration is done.
I bill 1-2h of my time to bring this feature to you, with all the above-listed benefits. But how much does it really take, to do the actual work?
Tools like PostHog and Google Analytics can be quickly integrated into your app, by simply copy/pasting a code snippet, and that’s it! You’re done! But is it really that simple? 🤔
Unfortunately, it’s not as easy as it seems.
Sure, you can simply copy/paste that code snipped and call it done. 👍 (guess what? Many so-called devs actually do that, without a thought about how this will impact your business)
Here is what you would NOT get if you simply use the code snippet PostHog provides:
- Stacker is a SPA (Single Page App), which means PostHog would not be able to track any page view
- The code snippet only tracks the initial page view (when a user first load the app)
- All other page views would not be detected, not such a great insight on how your app is being used, right?
- PostHog does not know what a “user” is, and does not track user identity (email, name, etc.)
- PostHog does not know what a “company” (or “group”) is, and would not attach the user to a company (or group), that’s something I do manually for you, by understanding how your business works and what’s important for you
- Actual knowledge of how PostHog works and how it needs to be configured is also critical, I configure your PostHog instance to:
- Use your timezone
- Ignore your test users (so they don’t show up in charts) and make it so they are ignored by default
- Enable video Recordings, for in-depth behaviour analysis
- And many other things I consider “must-haves” for any business!
All of this took quite a lot of work, and is very specific to Stacker and PostHog internal ways of working, to make sure they work well together and understand each other. 👉 Optimizing PostHog for Stacker took me slightly more than 6 hours of actual work. Just ask another dev for a time estimate that includes all the above-listed benefits, you’ll see for yourself how much time/money they’ll ask for 😉 🤔 Why do I only bill for 1-2h, then? Because I re-use my implementation across my many clients, it makes it acceptable to bill very little time for each client, I get it back on the long-run. Also, most clients wouldn’t find it acceptable to pay too much for something they might consider “simple”. 👉 My goal is to bring as much value as possible, as fast as possible. To do so, I make sure to spend as little time as possible on anything that has no value to you, and rather focus my efforts on building a tailor-fit solution for your business!