Is there a way to deactivate mkt_tok from all links in an email by default? It often messes up the link, or causes it to actually go to the wrong page on the intended site. Very frequently.
This link: https://lectionary.library.vanderbilt.edu/texts.php?id=85
...will actually go to ttps://lectionary.library.vanderbilt.edu/texts.php?id=81
when someone clicks. Note the 85 turning to 81, completely changing the page people land on.
The only reasonable fix is to turn off mkt_tok. I am responsible for tons of emails, with tons of links. I have to go on vacation and people have to cover for me. I need to make this reasonably simple.
Hi There have you seen this link: https://experienceleague.adobe.com/en/docs/marketo/using/product-docs/email-marketing/general/functi...
Thanks, but I'm looking to do this by default, not having to uncheck the box for every link. I see there's a thing to remove this from a link in the Template view - is there a way to make all links untracked by default on the template level?
Also to be clear (or not) , I actually do want to track the link, but not through mkt_tok. Tracking on, mkt_tok. Is there a way to do that globally or at least for a whole email?
First, mkt_tok doesn’t break anything. It’s a query parameter like any other. It doesn’t change any other query params, either, so it can’t affect the id param.
The only reasonable fix is to turn off mkt_tok. I am responsible for tons of emails, with tons of links.
If your webserver breaks when there’s an unrecognized query parameter (some do, though it’s a configuration error) the correct fix is for your web team to add it to the list of expected params. There's no reason to make any changes in Marketo if you have a competent person running your website!
I actually do want to track the link, but not through mkt_tok.
Click tracking (Click Email activities) doesn’t require mkt_tok. mkt_tok is for associating web activities (Visit Web Page, Click Link) with known leads. So are you saying you want to only have Click Email activities? That’s really shooting yourself in the foot, because they’re the least trusted activities.
Thanks for your response. Not sure what we're getting at with "my webserver" (which was not in the original title of this thread; mods changed it). Yes, my own website's links are affected by this (particularly event calendar links with =[number] URLs), but the links I provided in the thread are from Vanderbilt University. Happens to be a good resource, but mkt_tok causes the number at the end of the URL to change as I've demonstrated. This has happened with a number of websites.
This happens enough that I think I'm within my rights to wonder how to turn this parameter off globally. Yes, I understand that this will hinder my ability to do Munchkin tracking. We're tracking activity with Google, and frankly it's hoping too much of my team to bring them on board with making use of Munchkin tracking anyway. It's more important to me that the links direct to the intended destination.
Happens to be a good resource, but mkt_tok causes the number at the end of the URL to change as I've demonstrated.
It does not. Adding an additional query parameter doesn’t affect other query parameters unless the destination webserver is not competently managed, i.e. has a bug. If it were broadly true that adding arbitrary query parameter B affected query parameter A, the entire web would have broken 25 years ago.
Adding mkt_tok is like adding utm_source, it does not itself do anything to other params.
Now of course there are badly run webservers and always have been. And the size of the institution running them makes no difference, by the way! So it’s understandable that you might want to deal with that by turning off mkt_tok for all your emails. However, there hasn’t been demand for this feature because it can always be fixed at the webserver level.
There is one thing you can do if you’re adventurous, and that will have the same final effect of keeping the mkt_tok away from the destination webserver:
redirecturl
variableWe had to set this up temporarily a few years ago when people had linked to the wrong domain. By intercepting the redirect we were able to send the people to the right place.