Great thanks,
You will have to try Sanfords suggestion out. The problem I have had with the url method is that if I don;t have the users cookie when I open the url I won't have a personalized certificate. If you just need a generic Certificate then you are fine, but if you want the users name in it then it may not work. I also tried this with PURLs.
What I had to do was actually send all my "certificate" emails to a single inbox and process them from there to get the content personalized.
A link in an email will always be personalized via mkt_tok, not requiring an existing cookie. There is literally no way for the LP to not be personalized if you pass through the mkt_tok. This is how ShareMaker works, for a related example.
Jamie, let me explain why existing cookies are not required to render personalized LPs. It is impossible for cookies to be required because no cookies are sent to Marketo on the first hit to a given LP domain.
The branding domain does not set a cookie, and even if it did, it would not necessarily be readable on the destination LP domain since you only get one branding domain to share across all of your links. The branding domain (tracking server) tracks the click (Clicked Link in Email), rewrites the original link by adding a mkt_tok that is specific to both the lead and the email, and redirects the browser to the mkt_tok-enized link.
The association of the next page view -- the view of the Marketo-hosted LP -- with the lead's personalized content is done using the mkt_tok value and not with cookies, as cookies do not yet exist. The mkt_tok is also used to associate subsequent page views -- views that no longer include the mkt_tok in the URL -- with the lead via the Munchkin cookie. That cookie is only created after the initial page content is sent to the browser. Further web activity tracking depends on having that associated cookie.