For Google Analytics (and other web analytics platforms) it would be great to attach utm codes to the links in all emails sent out by NodeBB.
Code | Value
------ | ------
utm_source | nodebb_mailer
utm_medium | email
utm_campaign |
utm_content |
utm_content isn't a high priority but it would be fairly straightforward to add the others
How standardised are UTM tracking codes? I don't know much about them and occasionally I strip them out when I click on links :confused: I'm afraid that adding them in might signal to end users that we do some sort of tracking when in reality it is not the case (at least, not out-of-the-box!)
The difficult part is that we could have the GA plugin add the UTM links, but that's actually harder to achieve than simply adding the UTM tracking codes for all emails :smile:
It's pretty much standard now for ad and email campaign tracking. I'm fairly certain all the other non-Google analytics sites can handle it.
The idea for the feature would be optional. Check a box, revert the templates and it adds them in or something like that.
I actually tried to manually add them and it didn't work. Something stripped them out. Or it's the same issue I've been having where updates to the email templates just don't work for me.
Are you sanitizing URLs before they go out? If I add utm codes to URLs in the templates, they work for the test email but get removed for regular usage.
Could this be the same issue with the templates not being written properly?
I don't think so. If I add a little message at the end of the template, the message is there but the query string utm params have been stripped out..
But it looks like there is also an error in the editor:
"Named entity expected. Got none."
If I remove the ampersands in the query string, then the error message goes away.

What system are you using for templates? It kinda looks like Handlebars or Mustache but it's not.
I see
app.set('view engine', 'tpl');
But I'm not seeing any module in the package.json that might match with that. Though, the library name may not be intuitive.
It's handled by benchpressjs
Perhaps you could try &? Seems a little counter-intuitive, though...
Well that worked and it didn't work. When I sent the test message, it was fine. But for a "real" notification all of the params were removed again.
Both the test and the actual notification appear to go through Sparkpost so I'm not certain it's them removing the params.
Any chance you can try with a new mailer or with the built-in mailer to confirm that it's SparkPost removing the querystrings?
Could also be the mail client stripping them... I know the urls get rewritten in google to go through their own intermediary service.
I've figured out the issue. NodeBB strips off the query params. I'm guessing it's a redirect?
It would be great if we could leave those on or have a way to consume them in a plugin or something. Alternatively, maybe NodeBB could track traffic from emails. It would be nice to have it all in Google Analytics but I'll take what I can get.
We strip the query params? That definitely doesn't sound like us... can you try installing the email-helper plugin and seeing if you can reproduce? (FTR, the plugin just exposes /email-helper/:template routes, so you can go to /email-helper/digest to see a rendered digest in the browser.
It's certainly easier than waiting for Sparkpost :thinking:
I'm on Postmark now.
That's weird; I could've sworn it was stripping them out. Now it's not doing it.
Okay, I figured it out by looking at the 302 redirect from Postmark.
This is the URL that is send from the 302 redirect.
https://www.axisandallies.org/forums/post/1327564?utm_source=nodebb_mailer&utm_medium=email&utm_campaign=notification&utm_content=button
NodeBB redirects this request to the canonical URL:
https://www.axisandallies.org/forums/topic/34005/1942-online-tournament/22
But in doing so, the query params are indeed removed.
I modified the /post/1=>/topic/1/test/1 redirect so it passes the query params along.
Thanks! I'm 99% sure this fixes the original and current issue. I _think_ it should be okay to close this.
Thanks @barisusakli and @djensen47 -- I guess we just needed to really drill down to the root of the problem. Appreciate your patience!
Most helpful comment
I modified the
/post/1=>/topic/1/test/1redirect so it passes the query params along.