Skip navigation
All Places > Champion Program > Blog > Authors 59ad505a0182655d4025a54f598626a5b5877516

gOSzz2q.jpg

As 2016 is coming to a close, a lot of us in marketing are winding down our schedule for the year: sending out holiday cards, making year-end articles, and building flight plans for 2017's initiatives. However, there's one common thing that can trip you up.

 

Ever looked at a website and wondered if it is still in operation? Maybe a thing or two looked like they could have been updated – and then you notice the copyright notice the in the footer. "2012. Right, this site must be dead. Let's move along."

 

Because Marketo lacks any sort of year token out of the box, it's very common for email and landing page designers to take the easy way out: simply add the year as plain text – and then as a new year rolls around, their content is stuck without updated values. But we can do better than that: let's set year dates so they're constantly up to date.

 

Setting Dates in Emails

Since Marketo only has {{system.date}} (which displays the current system date) and {{system.dateTime}} (a standard datetime stamp), we'll need to do two things: format Marketo's current date to your company's current locale, then set up the token to update in perpetuity (so we're not stuck doing this next December). To do this, we'll utilize folder tokens and Velocity scripting.

 

Need a refresher on folder tokens? Marketo Tokens: Ins and Outs and My.Tokens of Affection: Develop a Token Strategy You'll Love cover this topic at length. Remember that with something as generic as a year, you'll likely want to put this in the highest folder available.

 

You'll also want to check what timezone your Marketo instance is on--for instance, app-aba has its internal clock set to Central Standard Time, which means any datetime calculations it performs are going to be set to CST until you tell it otherwise. Now, for a year that may not matter so much to your company, but if you're sending something time-critical around the holidays or are on a very different timezone than your instance, this may not be ideal.

 

Once you're in your folder, create an Email Script Token  called  {{my.year}} with the following:

 

#set($timeZoneObject = $date.getCalendar().getTimeZone())

$date.format("yyyy", $date.getDate(), $date.getLocale(), $timeZoneObject.getTimeZone("EST"))

 

In this case, I'm setting the timezone to EST, but you should put in whatever timezone is relevant to you. From here, any emails you send with {{my.year}} that are inside this folder will correctly render the right year.

 

Setting Dates in Landing Pages

 

Thankfully, when it comes to editing dates for landing pages, the process is much more straightforward. Simply open up your template and swap out your typed date for the following:

 

<script type="text/javascript">

document.write(new Date().getFullYear());

</script>

 

Because JavaScript calculates dates on the end user's local machine, this means the year that displays will be whatever that person's current year is--whether that's 2016 or 2017, depending on the date.

concept2.jpgBasic Events: An Expanded Concept of Interesting Moments

 

Events are Google Analytics’ way of tracking notable interactions a user has with your website—clicking on a link, watching a video, sharing a link on social media, filling out a form, or interacting with Flash. The only limit is your imagination! Events are also stored separately from web activity, so they serve as a quick way to compare and contrast web activity. For instance, Events can show what actions a user took on your website before filling out a form or if time on site affects conversion events.

 

However, one way that I find Events to be really useful for Marketo users is to use Events to bridge the gap between Marketo’s limited web reporting and the important individual Moments that happen to a user—as such, I’m a fan of bringing Marketo’s Interesting Moments into Google Analytics to understand what’s causing those conversions. With Marketo’s Interesting Moments, your Moments are broken down into three main categories: Email, Milestone and Web. Google Analytics has a similar sorting system, with Event Category, Event Action and Event Label. Unlike Marketo, though, these are all completely custom fields—you’re free to populate whatever content you’d like in each. Generally, however, I recommend that you use the three fields to sort from most generic (Event Category) to most specific (Event Label).

 

Moreover, Google Analytics offers a view that Marketo cannot easily reproduce: seeing Interesting Moments in aggregate and being able to see the most prolific moments across your marketing efforts. Echoing what Interesting Moments you’re recording in Marketo in Google Analytics makes sense—and is pretty easily achievable with a very basic Marketo webhook.

 

We’re going to set up an incredibly basic webhook that will use your Smart Campaign’s name as an Event Action and its description as an Event Label. Inside of your Marketo instance, head to Admin->Webhooks. Since you’re going to be using the Measurement Protocol to write this external data into Google Analytics, you’ll need a unique string to let Google Analytics know this is the particular user adding this data to your database. Seeing as Google uses the UUIDv4 protocol to determine what a unique string is, we’re going to need to generate a random UUID value.  Visit the Online UUID Generator and copy the value it randomly generates under “Your Version 4 UUID.” From there, click New Webhook and fill out the form that pops up with the following:

 

Webhook Name:  Analytics Interesting Moments
URL: http://www.google-analytics.com/collect?v=1&tid=UA-XXXXXXXX-X&cid=YOUR-UUID-HERE&aip=1&ds=Marketo&uid={{lead.id}}&t=event&ec=Interesting%20Moment&ea={{campaign.name}}&el={{campaign.description}}
Request Type: POST

 

Leave everything else blank or as the default value and hit Save.

 

To use this webhook, simply name your Smart Campaign with the desired name of the Event Action (bearing in mind that if your Smart Campaign is in a program, you will see the full campaign name as Program Name.Campaign Name) and give your Smart Campaign the description you’d like the Event Label to be. Then simply set up your flow to use these labels in conjunction by structuring your actions using the following image as an example.

 

marketo webhook analytics interesting moments

This will result in your Google Analytics instance recording each event, like so:

 

marketo google analytics integration event

This same idea of aggregate counting can be used in a lot of different ways beyond this example, and when tied with your User ID reference, can provide some extremely powerful aggregate reporting that Marketo currently lacks.

 

Advanced Events: Debugging Forms

While using Events as Interesting Moments is a perfectly valid use of Events, it only scratches the surface of what’s possible with Event recording—and what assumptions you can make from events you record.

 

As an example, one of the questions I get asked a lot as a digital marketer is how long a form should be. Some schools of thought say that you should get a bare minimum, and others say that only qualified leads will bother to answer all your questions (and so you should have long forms). Like so many things in marketing, there’s no real “best practice” but what works best for you. The trick is to understand what actually works, though, and Events can help us figure that out.

 

A few years back I was presented with an interesting problem: a company had an event application form on their site, and while both the event and the page the form was hosted on were popular and drove a lot of phone activity, there were a lot less people filling out the application form on the site—which would have required less effort than calling! We tried talking to people who had called in to figure out why they didn’t just fill out the form, but there was no consistent answer they gave. Moreover, seeing the bounce rates on that page, something was happening that made people not want to fill out the form. But what?

 

In order to solve the issue, I set up Events to record every time a person filled out a form field—the idea being, if you can track cart abandonment in ecommerce situations, why not track “form abandonment”? Once this system was set up, it became clear that the main problem was an open text field asking people to describe an aspect of themselves in detail. Even though the field was optional, its presence caused people to stop—and consequently, not convert. The field was removed and conversions doubled.

Applying this tactic to your Marketo forms is a straightforward process and something you can implement to figure out your completion rates for each field (and overall conversions). The answer is in a small piece of JavaScript, which I’ve shared here. Upon implementation, you can see by Event hit how much of your form is being filled out.

 

2016-05-24_1429

In this example, clearly people are stopping after First Name. This empowers you to examine your form setup and figure out why.

 

Bring it on home: Taking data from Google Analytics back to Marketo

Now that we’ve built all this cool data inside Google Analytics, what do we do with it? After all, while having access to this data is great, it can be a little opaque to work with. While Google Analytics is very useful for looking at data in aggregate, it’s less useful for looking at data individually—this really is the job of platforms like Marketo and your CRM. As a result, we’re going to need to extract the data and send it back to your Marketo instance to take action.

 

The Analytics Core Reporting API is built to distribute the data you’ve collected inside Google Analytics and send it elsewhere to other web services, such as…Marketo! Google offers some quick examples using JavaScript, Java, Python and PHP on how to create an API connector, but a handful of other wrappers are available if you’re looking for help in another programming language. Once you’ve set up your API connector, I recommend using Google’s Query Explorer to get an idea of some of the basic functions you can perform with the API. Those looking to do more complex operations should do a deep dive into the Dimensions and Metrics Explorer to see what combinations of values can be extracted from the API.

 

As an example, I’ve built a very basic query to retrieve users with Marketo IDs and calculate their average time on the website for the past 30 days using: https://www.googleapis.com/analytics/v3/data/ga?ids=ga%3AYYYYYYYYY&start-date=30daysAgo&end-date=yesterday&metrics=ga%3AavgTimeOnPage&dimensions=ga%3Adimension1

 

This returns the following JSON results, which show both the Marketo ID of a user and their average time spent on a page—as you can see, good ol’ 7498 (a.k.a. this author) has no time to be spending on individual pages. From here, you can integrate the query into your larger Marketo API connections to send this data, using the Marketo ID as a key, to custom fields, storing whatever data you want.

 

The invaluable insight you get as a result of implementing these within your system—what content items are performing best, why your forms aren’t converting visitors, how many visitors shared your content—allows you to deeply analyze what works and what doesn’t, helping you to improve the quality of what you’re putting out there and how you are putting it out there.

What is DMARC?

 

Domain-based Message Authentication, Reporting & Conformance, or DMARC, is an email authentication standard introduced in 2012 to determine how unauthenticated email should be handled. It adds a third layer upon SPF and DKIM to create a holistic email confidence system. So, what does that mean? First, let's back up a bit.

 

Whenever anyone sends an email from a certain domain, SPF and DKIM records need to be set up on the domain's DNS server—it’s a way for email servers to say “it’s OK that this service (whether that's your office email, Marketo, a web server, etc.) is emailing with an address that has my domain: they’re with me.” 

 

The best way to think of SPF and DKIM is to think of SPF as the “envelope” (the original piece of data being sent over) and DKIM as the signature (the letter inside—is it forged or original?) SPF is a public declaration given by a domain; DKIM requires both a public and private key. The two work in tandem to prove an email is legitimate. DMARC builds upon this system by giving mail servers instructions on what to do when it finds emails that don't have correct SPF and/or DKIM records: should it let them through, quarantine them, or reject them? Additionally, DMARC is set up so the servers you email to will provide you a report on what emails are being sent with your domain—and if there's anyone sending rogue emails with your domain (say, for phishing purposes.)

 

While this is exciting stuff for IT, why should marketing care? Simply put, more and more email providers are now checking to make sure you have a DMARC policy to determine whether your email is considered spam—even if you have SPF and DKIM records defined! At DemandLab, we have seen examples of AOL, Yahoo and private email firewalls now rejecting emails due to a lack of a DMARC record. Defining a record is a win-win: your marketing messages are considered more trustworthy, and your users have the security of knowing anything coming from your email domain is legitimate.

 

How do I set up DMARC for my email domain?

 

You can check if your email domain currently has a DMARC policy by visiting http://mxtoolbox.com/dmarc.aspx. If your company doesn't have any record on file, we recommend a five-step approach to make sure your implementation goes smoothly:

 

1. Take an inventory of your emailing systems

 

Your company's technology stack probably has more things sending out email than you'd think—there's more to consider than just your office email and marketing automation! Consider transactional emails, emails sent from internal programs, emails from other SaaS platforms, and more. We recommend working with your IT team to look across your entire technology stack to make sure you have everything covered.

 

2. Check that all the systems you identified have SPF/DKIM definitions

 

For many marketers, the process of setting up SPF and DKIM when you first purchase your marketing automation platform is the first (and last!) time they ever think about these records, but it's important to consider how all other outgoing email is defined with SPF and DKIM records.

 

Make sure you have all IPs and/or record types defined with your SPF setup. It's important to remember that the SPF standard can only handle 10 lookups, so if you have more than 10 different places sending emails with your domain, you may want to consider consolidating your email sources or purchasing a separate domain for certain types of emails.

 

From there, you need to ensure you have DKIM records set up for each of your mailing platforms—your IT team should be able to help you see which TXT records have different DKIM signatures on them and what you may be lacking. Because some administrators aren't as familiar with DKIM setup, there's a very real possibility not all of your mailing systems are covered. Included below are setup instructions for setting up DKIM on some of the most common email systems:

 

Salesforce: https://help.salesforce.com/htviewhelpdoc?id=emailadmin_create_dkim_key.htm

Office 365: http://blogs.msdn.com/b/tzink/archive/2015/10/08/manually-hooking-up-dkim-signing-in-office-365.aspx

Exchange: https://www.emailarchitect.net/forum/yaf_postst357_Set-up-DKIM-in--Exchange-2007-2010-2013.aspx#post538

Google Apps: https://support.google.com/a/answer/174124?hl=en

Linux servers (Postfix): https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-dkim-with-postfix-on-debian-wheezy

 

3. Create an email account for receiving DMARC reports

 

DMARC requires an email address to send its authentication reports to; most commonly this address is either abuse@domain.com or postmaster@domain.com (which I strongly recommend for your own DMARC setup over custom options, since many feedback loop systems prefer these names.) Make sure you have a valid email inbox for these records that go to both IT and marketing. Do note that if you use Google Apps the process is a little different than most email providers.

 

4. Define what you want your DMARC policy to be

 

DMARC gives domains a few different options on how to handle emails that don't pass authentication (those interested in learning all potential configurations should check out this helpful overview of all DMARC tags and values.) For simplicity's sake, we'll define three main options: take no action, quarantine, or reject.

 

A very basic example of a DMARC record where servers are instructed to take no action would be:


v=DMARC1; p=none; rua=mailto:postmaster@domain.com; ruf=mailto:postmaster@domain.com

 

Generally, we recommend a phased approach where your DMARC policy over time where your policy (defined above as none via p=none) is slowly changed over time to be increasingly more restrictive—changing your record over time to have 10% quarantine, 25% quarantine, 50% quarantine, 75% quarantine and an eventual p=reject policy (where any emails that don't have SPF/DKIM authentication should be discarded altogether.) However, it's usually best to do an analysis of your DMARC reports before implementing stricter measures.

 

5. Set your DMARC policy (and monitor your reports!)

 

Once you've determined what your DMARC record should be, have your IT team place it as a TXT record in your domain's DNS manager. After applying this record, you should start to receive daily emails to the email address you chose that look similar to the following:

 

dmarc-records-1.png

 

Attached to each of these emails will be an XML report that details what that particular email provider has experienced. By breaking down the the XML tags included in each of these reports, you can get a better idea

 

dmarc-records-2.png

In this particular report from Yahoo, we can see the following:

  • The policy for this domain is to take no action (<policy_published> tag with <p> inside set to none)
  • 19 emails were sent to Yahoo’s servers on this day (<count> tag)
  • Emails sent from an IP passed SPF/DKIM (<record> tag)
  • Emails from domain.com passed DKIM (first <domain> tag inside <auth_results>)
  • Emails from mail.domain.com passed SPF (second <domain> tag inside <auth_results>)

 

This is an example of a healthy DMARC setup, but how do you know when something's wrong? By looking at the recent results report of a company that has a 20 percent quarantine policy, we can learn what to watch out for: a record that has failed authentication, yet is still being delivered.

 

 

 

Failed but not quarantined

<row>

      <source_ip>178.235.116.88</source_ip>

      <count>1</count>

      <policy_evaluated>

        <disposition>none</disposition>

        <dkim>fail</dkim>

        <spf>fail</spf>

        <reason>

          <type>sampled_out</type>

          <comment></comment>

        </reason>

      </policy_evaluated>

    </row>

 

Since both <dkim> and <spf> tags say fail, we know that this particular IP did not meet DMARC policy. Additionally, when we look at this record, the <type>sampled_out</type> tag lets us know that even though this record was flagged for not passing DKIM or SPF, this one email was allowed to still be sent since it was not part of the 20 percent quarantine.

 

If you look up the IP 178.235.116.88, you'll find it's actually a Polish spammer on many blacklists already. Therefore, in this case this spam bot is sending emails out of its system using this company's domain as an email address! Because this and several other similar records showed up for this company, they should probably consider moving to a higher percentage of quarantining more quickly. You'll know when these emails aren't delivering when you see your <policy_evaluated> tag looking like this:

 

<policy_evaluated>

        <disposition>quarantine</disposition>

        <dkim>fail</dkim>

        <spf>fail</spf>

</policy_evaluated>

 

 

With this in mind, be sure to watch your reports over the next few weeks and check that you do not see any <result>fail</result> messages, which would point to a specific domain or IP failing that you want your emails to be sent from—and make sure that you don't see any records of senders you don't want sending messages getting through.

 

DMARC is not just an IT responsibility, especially when your email deliverability is hanging in the balance. Marketers should be involved throughout the entire DMARC setup and implementation process. Together with the IT team, marketers must do periodic checkups on the reports to ensure that your email continues to deliver as it should, and you can enjoy knowing that your email is safer, more deliverable, and unspoofable.

concept1.jpgYou have likely seen a wide variety of questions around integrating Google Analytics—the most commonly used website analytics tool — and Marketo, be it with reporting, tracking or data sharing. Given that the topic comes up so often, and there are so few resources specifically targeted towards Marketo users of Google Analytics, hopefully this guide will help with the confusion around this topic.

 

Missed the first part of this series? See “Get on the Right “Track” with UTM Tagging.”

 

What is Google Analytics and Why Should I Use It?

Simply put, Google Analytics is an online platform from Google which measures web activity in a holistic manner—meaning it can fill in some gaps Marketo leaves, such as paths taken to get to a web page, e-commerce conversions, audience data and more. Where it really finds power, though, is in using custom definitions to measure success with goals, paths, events and other metrics. Goals allow you to track conversions (and micro-conversions), paths allow you to trace a user’s overall journey between webpages on your site, and events function similarly to Marketo’s Interesting Moments with advanced categorization.

 

When you combine Marketo and Google Analytics, good stuff happens.

 

I thought Google Analytics had an integration with Marketo!

Yes and no. The integration you’re likely thinking of integrates the Marketo RTP product with Google Analytics; this will bring in dimensions and metrics specifically related to Real-Time Personalization (campaigns, segments, etc.) into Google Analytics. Note that what we’re covering today both does not require the Real-Time Personalization add-on and acts as a complementary method to what RTP’s Google Analytics integration achieves.

 

Setting up Google Analytics for Marketo

Marketo Landing Pages use a subdomain to host landing pages with your branding (i.e., info.demandlab.com vs. demandlab.com.) Because of this, you’ll need to make a decision on if and how you would like to split out Marketo landing pages from your main website. Because each Marketo customer is going to have a different answer to this question, we recommend you look at each of the situations listed over at Moz to decide your view setup.

 

Once you’ve determined your views, there are a few Marketo-specific items to take care of:

 

Exclude Marketo tracking tokens from your data: Leaving the mkt_tok value in your Analytics instance is the fastest way to turn your metrics into a big mess. Visit Admin -> View -> View Settings and look for “Exclude URL Query Parameters (optional).” Add mkt_tok to the box and save.

 

view-settings

 

Activate User ID tracking: You can tie your Analytics session to your anonymous or known Marketo record by inserting the Marketo User ID as a Google Analytics User ID. Go to Admin -> Property -> Tracking Info -> User ID and follow the prompts to set up User IDs. We’ll use a custom tracking code later on to tie this to your Marketo record based on an anonymous/known user’s ID.

 

Note: though it’s tempting to use something like email address or name instead to label your session, this actually violates Google Analytics’ Usage Guidelines. Instead, you should use a third-party tool such as PII Viewer for Google Analytics to tie your Marketo user ID back to information you can read, such as email address, company or other demographics.

 

Add the Marketo User ID dimension: For clarity’s sake, I like to add an extra custom dimension explicitly labeled “Marketo ID” in order to explain what the random number assigned to a User ID is. This also makes for nicer reporting and dashboards. Head to Admin -> Property -> Custom Definitions -> Custom Dimensions and click +New Custom Dimension. Name the dimension Marketo ID and set the scope to User (meaning it will track across multiple visit sessions.)

 

marketo-id-view

 

(Spoilers: My Marketo ID for the session I had while working on this was 7498.)

 

Adding Google Analytics to your Marketo Templates

If you’re using the older free-form templates Marketo offers, you may have noticed the bottom of your template has a code block that starts with “GOOGLE ANALYTICS. ENTER YOUR CODE AND UNCOMMENT BLOCK.” While this was accurate in the days of classic Google Analytics, you’ll actually want to place new code that allows for extra Marketo data with Universal Analytics. Insert the following code before your closing body tag:

 

<script>// <![CDATA[ (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){ (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o), m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m) })(window,document,'script','//www.google-analytics.com/analytics.js','ga'); ga('create', 'YOUR GOOGLE UA ID HERE', { 'userId': '{{lead.Id}}' }); ga('send', 'pageview'); ga('set', 'dimension1', '{{lead.Id}}'); // ]]></script>

 

This will set the user ID to correspond with your Marketo user ID, as mentioned earlier, and set the foundation for any advanced tracking you’d like to do (such as events or goals, which we’ll cover in our next post.) Re-approve all pages that use the template you’ve changed, and you’re good to go.

Note: If you would like to have your Lead ID be recognized on non-Marketo landing pages (such as your corporate website), you will need to do some extra API connections that depend on your specific webserver setup.

 

Thoughts Around Adding Google Analytics Data to Marketo

Once you’ve started tagging your URLs with UTM parameters, the next question most marketers have is how to work the data into their instance.

There are several different approaches to the topic of UTM data in Marketo: creating a custom object (either in Salesforce or calling Marketo to make a custom object) to monitor traffic, recording all parameter use in strings, and using first/last utm fields are all valid schools of thought (the latter in particular if you don’t have access to Revenue Cycle Analytics or Salesforce.) Moreover, some advanced set ups of Marketo that use multi-channel attribution to content can truly benefit from extensive UTM use.

 

However, I’ve personally come to the conclusion that there are only two real, solid UTM items that need to be tracked on Marketo’s side for most companies: Lead Source/Lead Source Detail and PPC traffic. This doesn’t mean you should abandon the rest of your UTM tags: the rest of the markup helps when comparing Marketo reports to Google Analytics reports.

With that said, you’ll need to make an internal decision with your sales and marketing teams on one of two directions to track UTM data: upon engagement or upon conversion. The difference is simple, but important: does a source get credit for bringing someone to a page, even if they don’t convert, or is conversion necessary for attribution? Although Google Analytics can calculate this with Multi-Channel Funnels, your company needs to be on the same page on what Lead Source means: first interaction or first conversion. You should also keep the approach consistent with what your company does for lead source and acquisition programs to keep everything on the same page.

 

Want to capture every last detail, and plan on not using engagement instead of conversion? Good news: We have a script that will parse all UTM parameters and record them as custom URLs in your Marketo instance. This is especially useful for items like capturing content variations or keywords used in PPC, as these are less predictably defined than your source, medium, or campaign.

 

Want to capture data at the time of conversion with forms?Use Forms 2.0’s hidden field function to write data into your forms without having to do any extra programming. Simply add an extra field to capture this data:

 

utmmedium-1

 

Then, set the field to read data from the corresponding parameter in your URL:

 

utmmedium-2

 

Want to reference querystrings in your Smart Campaigns? It’s easy! You can use querystrings as a constraint filter on the following:

  • Triggers: Clicks Link on Web Page, Fills Out Form, Visits Web Page
  • Filters: Clicked Link on Web Page, Filled Out Form, Visited Web Page
  • Remember: Querystring constraints are not available for triggers/filters around email links and are not usable on any custom fields with the URL data type!

 

In case you’ve never used a constraint on a trigger or filter, you simply need to click the filter button at the top-right side of your trigger or filter:

 

query-filters

 

From there, the limit is only your imagination—create PPC programs that track your ROI and have credit in Revenue Cycle Explorer, have accurate Lead Sources and Lead Source Details, track A/B testing of promotional material, and more! Once you’ve mastered querystrings in your URLs with Google Analytics and Marketo, it’s time to take the next step: using Google Analytics to answer questions like:

 

  • Why aren’t my forms converting?
  • Who are my most effective blog authors? Who are my commenters?
  • How can I track leads who share my items on social if I’m not using Marketo landing pages?
  • How can I track events and goals in both Marketo and Google Analytics?

 

Stay tuned for information on these concepts and more!

Filter Blog

By date: By tag: