Skip navigation
All Places > New York User Group > Blog > Authors Sanford Whiteman

This was a nice catch by user AD on the Community and something I somehow missed before! It has significant effects on tracking and on branding in general.

 

When you set up Domain Aliases in Marketo (and corresponding CNAMEs in DNS) you can access your Marketo-hosted LPs via a choice of different URLs. The path/page name stays the same, but you can use a different domain.

 

      For example, you can use go.example.com for the bulk of your pages, but publish some pages under get.mymicrositeexample.com for special products. The pages will actually be accessible under any of your Aliases as well as your Primary (i.e. if somebody manually changed the URL in their browser) but by taking care to link to the preferred domain from ads, social, and email, you can keep content/layout/logos/etc. totally different.

 

    If you're an agency, you might even use Domain Aliases to service multiple clients at the same time, the only restriction being you can't use the exact same /pagename but would have to mix it up like /jiffylube_coupons_2017 and /spiffylube_coupons_2017.

 

Cool concept, so... ?

Problem is, siloing Domain Aliases from each other falls apart if you select a Thank You page from the dropdown of Marketo LPs.

 

 

Read the full post on TEKNKL :: Blog →

A hard truth about using Marketo is that you won't always use Marketo for email.  At some point, you'll use MailChimp or SendGrid for one-off sends, or rent your list (with full opt-in of course) to a partner, or use an in-house mail blaster app for special events.

 

(On the blaster note, shouts to Gammadyne Mailer, possibly the ugliest best-of-breed app ever created, which did the trick quite well in the pre-MA days!)

 

You can only dodge this question for so long: Is there any way to track clicks on these emails if they're not sent through Marketo?  If the addresses are already in your Marketo instance, yes, there are are a few ways, with varying levels of complexity + client-side slickness (the harder you work on the back end, the more streamlined on the end user side).

 

 

Read the full post on TEKNKL :: Blog →

A good question from a reader today who asks, My client claims you can't have a From: or Reply-To: domain that's exactly the same as your click tracking domain (what Marketo calls the branding domain). Is this true?

 

Yep, within the confines of Marketo this is true.

 

That is, you can't send with the From: header:

 

From: All Eyez on Me <alleyez@example.edu>

 

and have your rewritten tracked links use the exact same domain:

 

<a href="https://example.edu/saz95jf81235jhg8712sj">Learn more</a>

 

You can of course use a subdomain

 

<a href="https://click.example.edu/saz95jf81235jhg8712sj">Learn more</a>

 

… which is what we're used to (branding domains are click-dot-whatever, landing page domains are pages-dot-whatever).

 

But why? It's not merely a tradition but based on a longstanding technical rule.

 

 

Read the full post on TEKNKL :: Blog →

Quick: How big are your Marketo LPs?

 

I know you don't have the size in KB at your fingertips. But you're probably thinking, Smallish... tiny bit of CSS, forms JS, optimized images. Definitely smaller than our corporate home page, I can tell you that much.

 

What if I told you that your Marketo LPs may be forcing users to download your home page's full HTML, twice in addition to downloading the LP and its own assets?

 

(And I do mean your home page. Not something the size of your home page,  but your actual home page.)

 

Read the full post on TEKNKL :: Blog →

Newbie Q: Where do I click to see X?

 

Oldie A: You don't.

 

the least happy type of Community thread

 

New users may search in vain for a log of all Filled Out Form events plus their point-in-time form data. (That is, even if field updates were blocked or values were later overwritten, you see the values that were on the form when each person clicked Submit).

 

First: it's not correct to say that Marketo doesn't store the original data from form posts: in fact, the REST Activity API includes historical POST payloads, including since-overwritten values. But it's true that it's not easy for a non-developer to see form data history across leads.

 

When seeking such a report outside of Marketo, users tend to say a Google Sheet (as opposed to XLS/CSV, Excel 365 online workbook, or something else). I'm not a Sheets user myself unless forced, but I know how it's done, and it's reeeeeally easy. So that's what we'll use today.

 

Read the full post on TEKNKL :: Blog →

A pesky problem with Munchkin is that you can't selectively turn it off based on visitor characteristics.

 

You can choose Disable Munchkin Tracking on Marketo LPs, but that's for every visitor, and on your corporate site you're unlikely to have access to an on/off switch. So internal visitors show up in your stats (okay when testing, but bad after go-live) and it would be great to be able to exclude them, wouldn't it?

 

Although the best place to check IPs would of course be on the Munchkin server itself (thus no extra requests) we can ping a remote service to get the end user's IP, then use a l'il JS wrapper to conditionally load Munchkin based on whether the IP appears in allowed/disallowed Access Control Lists (ACLs).

 

Read the full post on TEKNKL :: Blog →

     If you've wondered why devs still ask you for the “OS, browser vendor, and browser version” after all these years, when browser features seem so converged: it's cases like this!

 

     Was troubleshooting some fancy-schmancy Forms 2.0 JS using Cross-Browser Testing. I never reproduced the specific misbehavior that had been reported (turned out to be due to the usual form-post-to-database delay), but I did accidentally discover something else while testing across browser versions (CBT is great at providing a wide range of older releases on their boxes).

 

     Observe, in the top row, Chrome 51 and Chrome 52, and in the bottom row, Chrome 53 and Chrome 54. Pictured OS happens to be Mac OSX 10.11, but same results on Windows 8.1 and 10:

 

108_chrome53_sslerror_z46abdc3353ecff2a8bc.png

 

Read the full post on TEKNKL :: Blog →

This was originally a P.S. in the redirector page post, but I figured it deserved a post of its own.

 

     In other redirector page tutorials found around the net, the query string is used to pass the asset URL, like:

 

     http://example.com/redirector.html?http://example.com/my.pdf

 

     While my redirector code puts the asset URL after the hash (#):

 

     http://example.com/redirector.html#http://example.com/my.pdf

 

     You can build a working redirector page using either method, but my use of the hash was a deliberate choice for both performance and usability.

 

Read the full post on TEKNKL :: Blog →

When you think like a hacker, as I learned to in a long-ago role as security admin, martech can seem almost quaintly vulnerable.

 

Sometimes, DoS/DDoS and data theft openings are knowingly created —  and, to be frank, covered up in the name of demand gen and quick delivery. (You may have seen me sounding this alarm in Community threads.)

 

But in the common case, users truly don't know there's anything wrong: you're not in IT, nobody told you there was a risk, and your app didn't pop up any warnings. Nevertheless, significant vulnerabilities exist. These vulns are old hat to the security community, but marketing doesn't get those memos.

Read the full post on TEKNKL :: Blog →

There are so many posts about this. With incomplete and not-quite-right responses out there, you might not know if it can or can't be done with Marketo.

 

But it can:

 

emoji_owa_ss.png

 

So why the confusion?

Read the full post on TEKNKL :: Blog →

As you may know, there's no {{trigger.query string}} token, which can be frustrating since Marketo usually (though not always) considers a "web page" to include only the hostname, pathname, and (somewhat curiously) the hash. That is, {{trigger.web page}} omits the query string, though that may be the part you're the most interested in.

 

But run this little snippet before you init Munchkin...

Read the full post on TEKNKL :: Blog →

This trick definitely falls into the Only if you insist… category, but it'll show you a bit about how Marketo LPs work.

 

N.B. This post isn't about tracking email clicks in non-Marketo emails. Click tracking (via self-associating Visit Web Page events) is a very worthy endeavor and one that's the subject of another long-simmering blog post.

 

Rather, today's topic is an even further frontier: inserting a Marketo-aware tracking pixel that can count the number of image-enabled opens (like any tracking pixel, it only works if the lead views the HTML version of the email, has images enabled, and doesn't have a firewall that blocks such things).

 

Read the full post on TEKNKL :: Blog →

Gave y'all an extra day, but still only two guesses at the puzzle! I'm going to round up to “too challenging” instead of down to “nobody cares.”

 

Either way, read on for the answer…

Read the full post on TEKNKL :: Blog →

Of all the frustrations of Marketo's matching and filtering engine, few can rival its inability to accurately match on the domain part of an email. ([Email Address] Contains “@google.ca” is obviously inaccurate because it will match joe@google.cannot-be-trusted.co.uk).

 

Ends With isn't the only thing you might want to do with email domains, of course. You may want to scan for a match in a list with thousands of names, group domains with the same parent company (even across TLDs), or check to see which service scans inbound mail for a lead.

Read the full post on TEKNKL :: Blog →

Last night, a faithful reader and Marketo champ sent me a DKIM-related question that had a couple of interesting twists and turns. While I figured it out in a few minutes (being steeped in this sort of stuff), it struck me as a perfect “How well do you understand anti-spam/anti-forgery technologies?” puzzle to pose to the more technical part of the community.

 

I'm feeling relatively flush, so I've decided to award an actual prize to the first reader who answers correctly by this Sunday (12/4).

Read the full post on TEKNKL :: Blog →