@Nate A You can't delete the user's cookies if they don't visit your website again, but if they do follow a link, you can certainly clear their Munchkin cookies before loading Munchkin.js, therefore making a new anonymous lead for subsequent page views. ... View more

@Kristen M but I still see nothing about it that isn't safe or surefire.  If it's known to not work in some way, we should file a bug with Marketo, not cast doubt on a feature we actually trust every day.  Also, assuming a PDF is actually saved from that same web page, I don't see how that's easier to digest, or any less ugly; some computers even open PDFs in a separate reader app, which surely isn't easier. That said, if View as Web Page created PDFs automatically I would probably take advantage of that option for very old emails because they seem more archive-y. ... View more

I don't see any reason to trust View as Web Page links for day-to-day marketing, but not for an archive.   Either they work or they don't.  Do you exclude them from your e-mails? ... View more

@Courtney G: perhaps you mean something else, but View as Web Page links (to http://landingpages.example.com/index.php/email/emailWebview?...) certainly don't require that you be a known (associated) lead when viewing.  ... View more

Assuming you're talking about Marketo-hosted landing pages, those page views should already be registering, albeit as anonymous visitors (for that is what they are). ... View more

A user will not be automatically associated unless they fill out a form.  The form submission can happen after they visit your website -- their old anonymous activities will be merged in. But if they don't fill out a form, you have to write server-side code (using either Munchkin API and/or the REST/SOAP API) that captures the lead's info based on the link they clicked and then passes it in to Marketo. However, stay tuned as we (my company) will be releasing a powerful complement to Marketo/Munchkin that provides the lead association out-of-the-box, with no programming! ... View more

... interesting that Josh and I came at this from opposite angles.  He's of course totally right that you could have a From that doesn't accept messages and a Reply-To that does, so in that case you're putting the Reply-To "in front" to make sure a human reads those. Either way, you should be able to manage your marketing process so that the Reply-To and From are the same address.  Make the decision now as to how you are going to process human responses to your marketing e-mails and then choose an address appropriately.  For the record, we do not use a <do-not-reply...> but a real sales group mailbox that is checked... well, regularly enough! ... View more

Simply: Reply-To is the mailbox to which you want human-generated (i.e. manually composed) replies to be sent. Technically speaking there is no need for a Reply-To if the From is the same address. The From address will be used in the absence of a Reply-To.  However, these days most people set both even if they're the same. You'd have a different From and Reply-To if you want the From to reveal a human owner of the message that someone can deliberately copy-and-paste into a new message if they insist, while the Reply-To is an mailbox that doesn't actually accept messages (they are deleted or rejected).  This setup makes it less likely you'll get useless replies like "unsubscribe me" instead of people going to your web-based unsubscribe form.  Typically, tip people off that the Reply-To isn't ever to read a reply by calling it <please-do-not-reply@example.com>, <no-reply@example.com> or similar.  Really, if you don't call it something obvious like that you are implying that a human will read replies to the message, and it is unethical to then discard replies.   ... View more

As Josh suggests, you should make mailto: links as generic as possible to maximize the chance of it actually functioning for a given lead.  I would add both mktNoTrack and mktNoTok to such links.   mktNoTrack means you no longer rely on a browser bouncing from a web page (Marketo's click tracking page) back to the user's preferred mail app, but rather stay within the mail app in which the user is reading the message, which is by extension the preferred mail app.  By counterexample, if the system's default mail app is Outlook, a mailto: link that bounces off a click tracking page will typically open Outlook -- even if the user read the message in GMail. mktNoTok means your mailto: URLs look as non-dangerous as possible to mail apps. The spec for mailto: specifically says, "Only the Subject, Keywords, and Body headers are believed to be both safe and useful." When Marketo adds its token, the final URL becomes something like mailto:someone@example.com?mkt_tok=aabbcc. Technically this means you are asking the mail app to set the unsafe mail header `mkt_tok` to 'aabbcc.' A mail app is free to see that attempt as malicious and never bring up the new message window. By simplifying the link to just mailto:someone@example.com, you stay within boundaries. Edit: here are two examples of what your leads experience if you don't include mktNoTrack and they are exclusively webmail users (they haven't configured a local mail app).  It ain't pretty.   Windows 8: app.crossbrowsertesting.com/public/i75b45d927357249/livetests/2584450/videos/z0d245b96ed9a303d02d Mac: app.crossbrowsertesting.com/public/i75b45d927357249/livetests/2584460/videos/zf9e3897cd2c9ddcec88   ... View more

@Dory Viscogliosi it will show up in the Editora and in Preview as well... though completely understandable that we wouldn't notice this "fixup"! ... View more

I also don't see a particular advantage to having a background image, but hey, it's an aesthetic decision. @Heather P remember that text needs to be legible even if the bg doesn't load, since you cannot assume mail apps will load images.  Meaning you want to set a fallback background-color (in my sample the bgcolor is transparent). ... View more

As @Shannan notes you can think of the task as adding a background-image to text, not the other way 'round. And its use is not llimited to tables; for example, a simple A tag can have  style="background: transparent url(http://example.com/img/background.png) center center no-repeat;" etc. I strongly disagree with @Jim C that burning text onto images is a best practice. Creating manageable templates is key, and hard-coding text onto every image is hardly manageable -- and of course defeats any attempt at dynamic signatures. ... View more

As @Adam W said, if content changes end up affecting deliverability, they will in turn affect openability. A low ratio of text to image area is considered spammy (error-prone or not, this relationship is coded into major anti-spam software, based on the practice of hiding text within large images).  So if by reducing the # of images, you change the text:image ratio from, say, 2:1 to 6:1, you will likely see more deliveries. ... View more

OK, thanks.  Small suggestion: Get Usage shouldn't itself count toward the limit.  Operational queries like that could have their own limit. ... View more

Yeah, the problem with that UI is it doesn't get updated immediately and it's the total for 7 days.  With multiple apps running it is difficult to isolate what is being counted. I see that REST (I have been using SOAP) has the Get Daily Usage method, so that should work. I can already see that getting stats itself also counts as an API call (!) so it's clear that pagination is irrelevant (that is, every call counts).  On the other hand, REST is more generous with batch size (max of 300 results at once, as opposed to SOAP's max of 100) so that will be helpful. ... View more

The closest to this kind of obfuscation (or "friendliness," if you will) is the TITLE attribute, not ALT.  The ALT is designed to be displayed in place of the image when the image is not available or when the device does not support images, not as a tooltip above a successfully loaded image. However, bear in mind that it is up to the mail app (in which I include both browser-based mail and HTML-aware standalone apps like Outlook) to decide to show you the TITLE as a tooltip.  Many versions of Chrome do not render the TITLE as a tooltip and Google may well discontinue its use because it isn't accessible; mobile browsers also are under no obligation to continue this non-standard behavior from the olden days; and plenty of standalone apps don't interpret TITLE at all. And, regardless, modern browsers will show the actual target URL in their Status Bar as a security measure.  There is no way to fully conceal the HREF of a standard HTML A tag (of course you can do whatever you want via JavaScript but that is rather far afield from usable HTML email). I guess I also wonder what you expect to gain from seeing a tooltip during testing. It doesn't actually guarantee that the link is "correct," as the URL could still be wildly mismatched from the TITLE and you wouldn't know it. Can you explain in more detail the use case for this?   ... View more

I'll open an Idea now. ... View more

Marketo has no way to mandate that a given Lead is included in a Smart List. Users cannot be trusted to always include specific clauses in their SLs. Thus the only way to ensure that Leads receive an e-mail or range of e-mails is to use trigger logic. For example, if our web video team always must be included, there's no way the marketing team is always going to remember to add those matching addresses onto Every. Smart. List. Ever, including ad hoc sends. ... View more

See also https://community.marketo.com/MarketoDiscussionDetail?id=90650000000Py5HAAS ... View more

Well, of course something is being displayed: the or URLs that I inserted into my original email, as well as the JS redirect code, which could be effortlessly read -- and almost as easily altered -- on its way to the browser. If an email links to example.com/my/product/page/?some=query a marketer would reasonably expect the pathname/query to be secure on the wire. But it isn't, because it bounces off the insecure branding domain. To be fair, there isn't deeply sensitive information transmitted in our clickable URLs. But we do sometimes include tokens w/ the Salesforce and/or Marketo ID for the lead (for later API work) and it stands to reason that we want to keep those tokens as secure as was the original URL. More important, though, an interested (and only marginally skilled) hacker could alter redirects to go wherever s/he wanted. Imagine a classic phishing attempt with a lookalike login page, using as cover the lead's/customer's existing comfort with our brand (and the fact that the mail was DKIM-signed and SPF-passed to boot).  I know this attack vector sounds crazy to most Marketo users, but any targeted attack, especially such an easy one to execute, is something we need to cover. (Turning off tracking isn't a solution because obviously we need that functionality.) ... View more

Thanks for thinking about it. Yes, this limitation is confirmed (in fact, voluntarily conveyed) by Marketo's professional services team. Landing pages are relatively flexible but not branding domains.  You just get one. I'm glad you agree that exposing the parent brand is not good for your image -- in our case there could even be legal complications if we linked to the parent's domain.  Actually we use one of the sub-brands now.  This is okay for some of its related brands (kind of like Foot Locker and Lady Foot Locker, no big deal) but for other ones the marketing department is very clear that it's unacceptable.  As a result we are now spinning up a new instance, with no shared leads or anything.  It's a real pain. When Marketo creates pURLs it is able to track a click not only to the lead but to the originating e-mail send activity. As far as I know there is no way to replay or simulate what an e-mail specific pURL would be, as it only gets created at send time.  If you don't have Marketo create a pURL I don't see how you could retrieve what it would have been and then redirect to it. Not to mention that populating custom pURL fields for every lead -- adding a new such pURL for every lead and unique e-mail -- might be technically feasible but it doesn't matter because the marketing team will never adapt their workflow for this.  If you have more suggestions I'm all ears.  ... View more

... unless you have some magic that allows Munchkin to associate the lead without manually inserting an identifiable value in every URL you ever use an e-mail.  I am 99.999% sure no such thing exists. ... View more

I'm aware that I can turn off click tracking, thanks. Then you no longer get clicks tracked automatically by lead. If I didn't need this functionality I wouldn't be using personalized links/link rewriting in the first place. ... View more