I didn't know about that link option. So in the JS validation for the mkt_tok, how do you check that is not fake, I mean I can check for the mkt_tok param and its value, but how do you tell that is a valid token instead of random characters?
The only thing that distinguishes a legit mkt_tok-enized link from a fake mkt_tok-enized link is whether, in the absence of an associated cookie, the link succeeds in pre-filling fields.
+1 on this, and this how we secure Preference centers:
In fact, we rely on how Marketo has encrypted the Mtk_tok to identify the person.
It does not cover the case of email forwarding, though. we have not found a way to cover this case. Hoping people will not forward emails to people they do not know (This is wishful thinking, obviously but it should not happen so often).
- We remove the cookie on page entry on the PC page, before the munchkin is ran. No data can be extracted from the database if the Mkt_tok is not present
That's not exactly so. You have to remove the cookie and refresh the page without the cookie in order for the database record to not be loaded. The cookie has already been transmitted to Marketo during the HTTP request, and the Pre-Fill block injected into the HTML, by the time the page is drawn into the browser. Deleting the cookie at that point after the page is drawn doesn't make the Pre-Fill info go away.
Thanks guys for your replies.
About the page with only the email address, how do you set up a form to only send an email avoiding the lead creation? Because as far as I know, any form submit will create/update a record
We do not. If some one new want to enter the database and access the preference center and indicate his preferences, that's OK, since the preference center is an opt-in form.
We all feel your pain Preferences Centers are generally discussed as easy to setup but once you start digging in there is a lot to take into account and consider even without all of the new GDPR requirements. I complete agree with Stanford and Grégoire both helped with questions as I was going through this process, one thing we did was split out our Preferences Center into different functional areas that all work together.
The public subscription page, accessible on our website. The only trick we used here was to clear the cookie value on the form submission so that data is entered without being tied to an existing cookie ID. This is only able to add to new and update existing subscription, not remove any details. This uses a double opt-in, so unless you confirm your selection by clicking a link in the confirmation email everything changes back after 24 hours.
Manage your subscriptions page, only accessible from an email link. This clears any cookies before being loaded and uses only the data provided through the Marketo URL string to pre-populate contact details and existing subscriptions. This can both add and remove contact details and subscriptions. This also uses a double opt-in for any new subscription added.
Unsubscribe page, again only accessible from an email link. This also clears any cookies before being loaded and uses only the data provided through the Marketo URL string to pre-populate contact details and existing subscriptions. This can remove individual newsletter subscription or all newsletter subscriptions. No confirmation needed, but you are only able to unsubscribe the person that the email was sent to, that you clicked over from.
...and because we have a number of different business units each with there own version of the above pages we also have a "Global Unsubscribe" page, only accessible from the individual unsubscribe page that removes you from everything across the whole organization. This also only uses the Marketo URL string to pre-populate contact details. which means you are only able to unsubscribe the person that the email was sent to, that you clicked over from.
Thanks for your imput. How do you add the values to the URL to pre-populate data in your form, a querystring will be way too easy to bypass this right?