This theme component allows you to send data about your site’s usage to Segment.
The component supports calling segment.identify when a user first logs on to the site. For site’s using SSO, you can either send the user’s Discourse ID, or their external_id to Segment. The component allow you to track views of the Discourse latest, categories, category, tag, and topic pages. It also allows you to track topic and post creation, likes, flags, and bookmarks.
Installation
Follow the How do I install a Theme or Theme Component? guide to install the component. Use https://github.com/scossar/discourse-segment-theme-component to install it directly from its Git repository. You can also download it from here.
Configuration
Add your Segment Write Key to the segment write key setting. Then select which events you would like to track:
I know I am extremely late to this party, but I have a request I was hoping you might be able to accommodate.
Could you add, in addition to the user ID number the user email address when users are logged in to Discourse?
In Segment I’m trying to combine Discourse data with user data for what could be the same user on my company’s website to understand which users are checking discourse and checking out the website, but I can’t match up users right now because the Discourse user ID doesn’t match the website’s user ID.
If I was able to match them up when the email address was the same from Discourse and the site, that would be so helpful.
Amazing plugin, thanks @simon! I’ve been using it for a few months, and I’m finding that it misses topic_created events every now and then. I can’t seem to identify any patterns in these misfires, so I figured I’d write in here. Any ideas? Are there any logs I can check for errors?
This is technically possible. I have some security and privacy concerns about adding the email address to the payload though. I’ll give it some thought and ask the Discourse team to see what they think. If the email address is added to the payload, there will be a theme setting for it that defaults to not including the email address.
I’ll look into this. If you do find a pattern to it, please let me know.
I’ll try to find the time next week to test out the component and make some updates to it. When that’s been done, I’ll move it from my personal GitHub repo to the Discourse GitHub repo.
@simon I hear you and agree about the security concerns, however, I am an admin of the Discourse I’m pulling this data from, so I could find the same user emails simply by taking the provided ID and going into the user records to connect the ID to the email address that way. It’s already available, albeit manually.
Additionally, though after speaking to others in my org, we may end up just waiting until we have Oauth set up so that our users will have to use the same ID logging in to our system and the Discourse system.
Regardless I think it would still be a nice feature to have - in case a solution like that isn’t available to someone else in the community.
This seems like the ideal approach. The Segment theme component could be updated to add an option to include the provider_uid that is supplied by your Auth provider.
I’m glad you brought this up. The Segment tracking component currently has an option to add the user’s external_id for site’s that are using DiscourseConnect. Looking at it now, I see that it is using the old settings name for for DiscourseConnect - it is checking to see if the enable_sso setting is enabled. That needs to be changed to enable_discourse_connect. I’ll get that fixed tomorrow.
Thanks so much, a provider_uid field would be fantastic to have - that should make it possible for us to associate actions by user across our site and Discourse both after they’re sent to Segment.
I have fixed the issue with tracking users based on their external_id for the case where DiscourseConnect is enabled as the authentication provider for the Discourse site.
So far I’ve been unable to track down what could be causing topic creation to sometimes not be tracked. It is working for me without any issues.
I’ve updated the name that is used for the Topic Bookmarked event. Previously the event name that was being sent to Segment was “Thread Bookmarked.” I don’t remember the reasoning for that. Hopefully changing the event name to “Topic Bookmarked” doesn’t cause issues with anyone’s analytics.
When I checked the debugger screen in Segment, all that was sent on the identify call was a User Id and IP address. Can an email address also be passed with the identify call?
When enabled, the user’s email address will be passed with the identify call. If you update the theme component on your Discourse site to its most recent version, that setting will be available to you.
A minor issue I found when testing this is that if the setting is disabled, the current user’s email address will continue to appear on Segment for the duration of their session. This is related to how Segment handles things on their end. When the setting is disabled, Discourse immediately stops passing user email addresses to Segment.
I haven’t forgotten about the request to pass the provider_uid to Segment, but while I was looking at this I was wondering if it would be useful to pass other identifiers to Segment. I was wondering specifically about passing the user’s name and username to the call to identify.
As far as Name and Username, yes they would also be helpful. A long-term solution would be to implement a way to push everything included at base and also any additional User Fields created in Discourse.
Reasoning, some destinations will require a specific piece of data to work. It would be really helpful to have a UI to build out the payload inside of Discourse. Even if it’s limited to the standard fields in the segment docs https://segment.com/docs/connections/spec/identify/
Sorry for the delayed reply. I’ve looked into this some more. It is not currently possible to set the provider_uid through a theme component because Discourse does not send the provider_uid to the client. Possibly this is something that could be enabled via a site setting in the future, but for it to work some changes will need to be made to the core Discourse code.
No problem. Thanks for following up, and for looking into this. Hopefully we can find another way to connect our Discourse users on Discourse and on our site.
